Retesting after pentests

You received a pentest report. The team implemented fixes. Is that the end? No. Without verifying that fixes actually work, you can’t be certain vulnerabilities were eliminated. Retesting is an essential part of the vulnerability management process.

Why Retesting is Necessary

Fixes Often Fail

A significant portion of implemented fixes are incomplete or incorrect:

Incomplete fix – developer patches one vulnerability variant but not all
Regression – subsequent code changes restore the vulnerability
Incorrect implementation – fix introduces new problems
Bypass – fix works in tested scenario but not in others

Example: SQL Injection “Fixed”

Original vulnerability:

SELECT * FROM users WHERE id = ' + user_input + '

Developer’s “fix”:

SELECT * FROM users WHERE id = REPLACE(user_input, "'", "''")

Problem: Fix protects against single quotes but not other vectors (e.g., backslash, unicode). Retest will detect this.

Compliance Requires Validation

Regulations like PCI DSS, NIS2, DORA require not only conducting tests but also documenting vulnerability remediation:

PCI DSS 11.3.3 – requires fixing and retesting high-risk vulnerabilities
DORA – requires documenting the remediation process
NIS2 – requires continuous vulnerability management

📚 Read the complete guide: Penetration Testing: Penetration testing - types, methodologies, process

When to Conduct Retests

After Every Critical/High Fix

Critical and High vulnerabilities should be retested immediately after fix deployment:

Risk too high to assume effectiveness
Fast feedback loop for developer
Documentation for compliance

Before Production Release

If tests were on staging/dev environment:

Validate fixes before production promotion
Ensure production configuration is analogous
Check that deployment didn’t introduce regression

In Quarterly/Annual Cycles

For Medium and Low vulnerabilities:

Group retests with regular testing
Verify that fixes survived subsequent releases
Check if new variants appeared

After Major Code Changes

When the team significantly modifies an area where vulnerabilities existed:

Refactoring can restore old problems
New features can expose similar bugs
Architecture changes affect previous fixes

Retest Scope

Minimum Scope

For single vulnerability:

Verification of original attack vector
Test variants (other payloads, other parameters)
Check nearby functions

Recommended Scope

For comprehensive validation:

All fixed vulnerabilities
Regression testing on changed areas
Verification that fix didn’t introduce new problems
Test from different user/role perspectives

Full Retest

When justified:

Significant application changes since original tests
Development team change
Compliance requirements
External audit preparation

Retest Process

Step 1: Fix Analysis

Before starting retests:

Review commit log/changelog for each fix
Understand what was changed and why
Identify potential gaps in the fix

Step 2: Environment Preparation

Ensure:

Test environment with deployed fixes
Access analogous to original tests
Current test data
Ability to compare with original state

Step 3: Fix Validation

For each vulnerability:

a) Original vector test

Use exactly the same payloads as in original test
Verify attack no longer works
Document result

b) Variant testing

Check alternative vectors
Test edge cases
Try to bypass the fix

c) Regression check

Did the fix break other functions?
Were new vulnerabilities introduced?

Step 4: Documentation

For each retested vulnerability:

ID: VULN-001
Original status: Critical
Fix: Implemented parameterized queries (commit abc123)
Retest date: 2025-01-15
Tester: John Smith

Result: FIXED
- Original vector: blocked ✓
- Variants: tested 5 alternative payloads, all blocked ✓
- Regression: none ✓

Notes: Fix correct. Recommend adding WAF rule as defense-in-depth.

Step 5: Retest Report

Summary should include:

List of retested vulnerabilities
Status of each (fixed/partially fixed/unfixed)
New findings (if detected)
Recommendations for further action

Retest Billing Models

Included in Original Test Price

Pros:

Predictable cost
Motivation for pentester to provide clear recommendations
Simpler process

Cons:

Limited retest scope
May be time-limited

Typical terms:

Retest within 30-60 days of report delivery
Covers only original findings
One retest cycle

Paid Retests

Pros:

Full scope flexibility
Multiple cycles possible
Deeper verification

Cons:

Additional cost
Requires budget planning

Typical rates:

A fraction of the original test cost
Per person-day rate
Hour pool to use

A retest is one of three items that usually stay outside a testing offer, alongside your own team’s time and the fixes themselves — how to account for them in the budget is shown in the article on how much penetration testing costs.

Retainer Model

Best for:

Organizations with continuous release cycles
DevSecOps / CI/CD environments
Continuous compliance requirements

How it works:

Monthly/quarterly fee
Hour pool for retests and ad-hoc verifications
Priority pentester availability

Common Retest Mistakes

1. Testing Only the Original Vector

Problem: Developer fixes specific payload but doesn’t solve root cause.

Solution: Always test variants and alternative paths.

2. Premature Retest

Problem: Fix is on staging but not yet on test environment.

Solution: Verify deployment completed before starting.

3. No Fix Documentation

Problem: You don’t know exactly what was changed.

Solution: Require changelog/commit reference for each fix.

4. Retest by Different Team Than Original

Problem: Lack of context, different vulnerability understanding.

Solution: If you must change teams, ensure full knowledge transfer.

5. Skipping Retests for “Minor” Vulnerabilities

Problem: Low severity doesn’t mean “unimportant” – may be part of attack chain.

Solution: Retest everything, even in limited scope.

Retest Automation

When Automation Makes Sense

Vulnerabilities detected by scanners (easy to automatically validate)
Repeatable tests (regression)
High volumes of findings
CI/CD integration

When Manual Retest Required

Business logic vulnerabilities
Complex exploit chains
Vulnerabilities requiring context
New attack types

Automation Tools

Burp Suite Enterprise – scheduled scans, regression testing
OWASP ZAP – CI/CD integration, API testing
Nuclei – custom templates for specific vulnerabilities
Custom scripts – dedicated tests for your applications

Integration with Development Process

Shift-left Retesting

Include security validation in pipeline:

Commit → security unit tests
Build → SAST scan
Deploy to staging → automated security tests
Manual verification → retest critical findings
Production → continuous monitoring

Developer Feedback Loop

Fast feedback (days, not weeks)
Specific guidance on what to fix
Access to pentester for questions
Training based on recurring mistakes

Summary

Retesting is not a cost – it’s an investment in actual security:

Fixes often fail – verification is necessary
Compliance requires documentation – retest provides evidence
Scope depends on context – retest critical immediately
Document everything – for auditors and future tests
Build a process – retests are a cycle element, not one-time action

A pentest without retests is like diagnosis without treatment – you know what’s wrong but aren’t sure you solved the problem.

Planning retests after pentests? Contact us – we’ll help organize an effective fix validation process.

The failure a retest is designed to catch

The common failure is not an unfixed finding — it is a fix that removes the exact symptom the tester demonstrated while leaving the underlying weakness reachable by another route. Input filtered in one endpoint and not in three others, a permission tightened for one role and not for the service account, a patched host restored from an old image a month later. None of these shows up in a ticket marked done.

Where the queue has grown faster than the team can close it, prioritising and verifying the fixes can be taken over as a separate engagement: remediation support.

Learn key terms related to this article in our cybersecurity glossary:

IT Infrastructure Penetration Testing — IT infrastructure penetration testing is a controlled and ethical process of…
Wi-Fi Network Penetration Testing — Wi-Fi network penetration testing is the process of assessing the security of…
Penetration Testing — Penetration testing, also known as pentesting, is a controlled process of…
Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
DevSecOps — DevSecOps, an acronym for Development, Security, and Operations, is an approach…

Learn More

Explore related articles in our knowledge base:

Explore Our Services

Need cybersecurity support? Check out:

Penetration Testing - identify vulnerabilities in your infrastructure
Red Team - advanced attack simulations

Explore Our Products

Solutions mentioned in this article that can help protect your organization:

RidgeBot — Ridge Security

Frequently asked questions

What is retesting in the context of penetration testing and why is it important?

Retesting is a follow-up assessment conducted after an organization has applied remediation for vulnerabilities identified in an initial penetration test. It is important because it confirms that fixes were implemented correctly and completely, since organizations sometimes apply partial fixes that address the symptom but not the root cause. Without retesting, there is no verified evidence that the vulnerabilities have actually been closed.

How should organizations decide which vulnerabilities to prioritize for retesting?

Organizations should prioritize retesting critical and high-severity vulnerabilities first, particularly those that were successfully exploited during the pentest or that would allow an attacker to gain significant access. Critical systems hosting sensitive data or providing privileged access should be retested regardless of finding severity. All vulnerabilities should eventually be retested, but resource constraints may require staged retesting aligned with remediation priority.

What is the difference between a full retest and a targeted remediation validation?

A full retest repeats the complete scope of the original penetration test to both verify remediation and check whether new vulnerabilities were introduced during the fix process. A targeted remediation validation focuses only on the specific vulnerabilities identified in the original test, verifying each fix without repeating the full engagement. Organizations typically use targeted validation for time-sensitive remediation and schedule full retests periodically or after major changes.

How does retesting support compliance requirements?

Many compliance frameworks explicitly require evidence that identified vulnerabilities have been addressed. PCI DSS requires retesting after vulnerabilities above a certain risk level are remediated, ISO 27001 expects corrective action effectiveness to be verified, and NIS2 requires organizations to demonstrate their risk management controls remain effective. Retest reports provide the documented evidence needed to satisfy these requirements during compliance audits.