31 October 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
The penetration testing retest: what it verifies, when to schedule it, and what auditors accept as remediation verification
A penetration test report is a list of open doors. Until someone tries those doors again, nobody knows which ones are actually shut. The retest is that second attempt, and it is the piece of evidence auditors, insurers and customers ask for first. This guide explains what a pentest retest covers, how to time it, and when it is the wrong instrument.
What a pentest retest is, and what it is not
A penetration testing retest (also called remediation verification, remediation testing or a fix-verification round) is a follow-up engagement in which the original testers attempt to reproduce every finding from the initial report after your team has applied fixes. For each finding the tester records one of three outcomes: remediated (the original attack path no longer works and no trivial variant does), partially remediated (the specific proof of concept fails but the underlying weakness can still be reached), or not remediated. The result is an updated report in which every finding carries a verification status, a verification date and the evidence behind the verdict.
A retest is not a new penetration test. The tester does not re-enumerate the attack surface, does not hunt for new vulnerability classes and does not re-run the full methodology. It is a targeted, finding-by-finding exercise, which is why it takes a fraction of the original effort and why it has to be scheduled within a defined window. The longer the gap between test and retest, the more the environment has drifted and the less the retest proves about the current state of the system.
The distinction matters for compliance. An auditor who sees a report with twelve findings and no closure evidence will treat all twelve as open. The same report with a dated verification appendix showing ten remediated, one partially remediated with a compensating control, and one accepted as a documented risk, is a closed loop. Most frameworks that require penetration testing require that loop, not just the test.
What the retest verifies, finding by finding
Good remediation verification is more than re-running the original exploit. These are the checks a competent tester performs for every item on the list.
1. The original attack path is closed
The exact proof of concept from the report is repeated against the same target, from the same test position, with the same privileges. If the request that returned a database error now returns a clean 400, or the privilege escalation that landed a domain admin token now stops at a standard user, the primary check passes. This is the minimum, and on its own it is not enough.
2. Trivial variants are also closed
A fix that blocks one payload but not its URL-encoded twin, or that patches one endpoint but leaves the sibling endpoint with identical logic, is a partial fix. The tester spends a bounded amount of time, typically 30 to 60 minutes per finding, probing the obvious variants: alternate encodings, adjacent parameters, other roles, other hosts in the same cluster. A retest that only replays the original payload rewards cosmetic fixes.
3. The root cause was addressed, not just the symptom
A SQL injection fixed with a web application firewall rule is a different outcome from one fixed with parameterised queries. Both may pass check one. The tester documents which kind of fix was applied, because auditors under PCI DSS and reviewers under ISO 27001 A.8.8 distinguish between a vulnerability that was corrected and one that was merely shielded.
4. The fix did not introduce a regression
Hardening often breaks something adjacent. A tightened CORS policy that now reflects any origin on error paths, a new authorisation check that can be bypassed with a method override, or a patched library that reintroduced a known CVE through a transitive dependency are all regressions a retest should catch, within the boundary of the original finding.
5. Compensating controls actually compensate
Where a finding cannot be fixed at source within the window (a legacy component, a vendor dependency, a change freeze), organisations document a compensating control. The retest validates the control, not the paperwork: if network segmentation is the control, the tester attempts to reach the asset from the segments that should be blocked.
Retest versus new penetration test: which one you need
Choosing the wrong instrument wastes money in one direction and leaves exposure in the other. The table sets out where the boundary sits.
| Situation | Retest is sufficient | New test is required |
|---|---|---|
| Fixes applied to the findings in the report, no other changes | Yes | No |
| Timing | Within 30 to 90 days of the original report | More than 90 to 120 days have passed, or the environment has materially changed |
| Major release of the tested application (new features, new roles, new authentication flow) | No | Yes, scoped to the changed surface at minimum |
| Infrastructure change (migration to a new cloud account, new identity provider, re-architected network) | No | Yes |
| Fix applied by replacing the component entirely (new framework, new vendor product) | No | Yes, for the new component |
| Compliance cycle (annual ISO 27001, PCI DSS 11.4.2 and 11.4.3, DORA Art. 24) | Only as closure of the previous test | Yes, the annual test itself |
| Significant change under PCI DSS v4.0.1 Req. 11.4 (new payment flow, new segmentation) | No | Yes, as a change-triggered test |
What the frameworks say about remediation verification
Most security frameworks do not use the word retest. They describe a closed loop between finding, correction and verification. These are the clauses auditors cite.
PCI DSS v4.0.1, Requirement 11.4
Req. 11.4.1 requires a documented methodology with a documented approach to assessing and addressing the risk posed by exploitable vulnerabilities found. Req. 11.4.4 requires that exploitable vulnerabilities found during penetration testing are corrected in accordance with the entity's risk assessment, and that penetration testing is repeated to verify the corrections. Req. 11.4.5 adds the same expectation for segmentation controls. A QSA will ask for the retest evidence by finding.
ISO/IEC 27001:2022, Annex A.8.8 and A.8.29
A.8.8 (management of technical vulnerabilities) expects that information about vulnerabilities is obtained, exposure is evaluated and appropriate measures are taken. A.8.29 (security testing in development and acceptance) expects testing processes to be defined and implemented. Certification auditors read the two together: the test identifies, the retest proves the measure was effective.
DORA, Articles 24 and 25
Article 24 requires financial entities to have procedures to prioritise, classify and remedy all issues revealed through testing, and internal validation methodologies to ascertain that all identified weaknesses are fully addressed. That validation language is a retest requirement in all but name. For TLPT under Article 26, the remediation plan and its follow-up are part of the closure with the supervisor.
SOC 2, Common Criteria CC7 and CC4
CC7.1 covers the detection of vulnerabilities and configuration changes; CC4.2 requires that internal control deficiencies are evaluated and communicated to those responsible for corrective action. A service auditor testing operating effectiveness over a 12-month period will sample findings from your penetration test and ask for evidence that each was tracked to closure and verified.
NIS2, Article 21(2)
Article 21(2)(e) requires policies on vulnerability handling and disclosure, and Article 21(2)(f) requires procedures to assess the effectiveness of cybersecurity risk-management measures. National supervisors reviewing an essential entity will expect the testing programme to show that identified vulnerabilities were handled, which in practice means retest evidence.
NIST SP 800-115, Section 8
The NIST technical guide to security testing describes post-testing activities: reporting, remediation and the recommendation that organisations verify remediation through follow-up testing. US federal programmes (FedRAMP Rev. 5 control CA-8, CMMC 2.0 Level 2 via NIST SP 800-171 Rev. 3) inherit this expectation.
What auditors want to see: the verification evidence pack
An auditor cannot verify your fixes. They verify that someone independent did, and that the record is dated, specific and complete. Have the following ready for every penetration test in the audit period.
- The original report with every finding uniquely identified (ID, title, severity, affected asset, test position, date observed)
- A dated verification appendix or updated report in which every finding carries a status: remediated, partially remediated, not remediated, or risk accepted
- Evidence per remediated finding: the repeated request or action, the new response, a screenshot or log excerpt, and the tester's name
- For partially remediated findings: what still works, what the residual risk is, and the agreed next step with a date
- For risk-accepted findings: the signed acceptance by the risk owner, the justification, the review date and any compensating control, with the retest result for that control
- An attestation letter on the testing firm's letterhead summarising scope, dates, methodology, named testers and the closure status, which is what customers and insurers usually want instead of the full report
- The ticket trail linking each finding to a change record in your own systems, so the auditor can trace from report to fix to verification
- A timeline showing the original test date, the remediation deadline per severity, and the retest date, demonstrating the window was met
Timing the retest: the 30 to 90 day window and what drives it
Most mature programmes schedule the retest between 30 and 90 days after the final report. The lower bound is set by how long realistic fixes take: a critical finding in a web application can often be patched in days, but an Active Directory privilege path that requires a tiering redesign takes weeks. The upper bound is set by drift. After roughly 90 days, enough code and configuration has changed that the retest no longer speaks to the current system, and most frameworks and many customer contracts start to treat the original findings as stale.
Severity should drive the schedule inside that window. A common and defensible approach is a critical and high retest at 30 days and a medium and low retest at 90 days, both documented in the report before the test starts so that the remediation team works to known deadlines. PCI DSS leaves the timing to the entity's risk assessment, but QSAs expect criticals addressed promptly; ISO 27001 auditors look for consistency with your own vulnerability management policy, which typically sets 14 to 30 day targets for criticals.
Two practical notes. First, do not wait until everything is fixed before requesting the retest; a retest with three open items and a clear status for each is a better audit artefact than a report that sits unclosed for six months. Second, agree the retest window in the original statement of work. Retests negotiated after the fact are the ones that slip past the window.
Partial fixes, compensating controls and when a retest is not enough
Partial fixes are the most common retest outcome after full remediation, and they are where the retest earns its keep. Typical patterns: an input validation fix applied to the form field but not to the API endpoint behind it; a password policy tightened for new accounts but not enforced on existing ones; a vulnerable library updated in one service but still present in a shared base image. The report should name the residual path precisely enough that the development team can close it without a third round.
Compensating controls are legitimate when the root cause cannot be fixed within the window, provided they are specific, tested and time-boxed. A compensating control is not a line in a risk register; it is a mechanism the tester can attempt to defeat. If the control is a WAF rule, the retest includes bypass attempts. If the control is segmentation, the retest includes reachability tests from the relevant segments. If the control is monitoring, the retest confirms the detection fired and someone received it.
A retest stops being the right instrument when the change is larger than the finding. A major release that adds new features, roles or an authentication flow creates attack surface the original test never saw. A migration to a new cloud account or identity provider changes the trust boundaries that the original findings were framed in. Replacing a vulnerable component with a different product means the original finding is moot and the new product is untested. In each case the correct response is a new, scoped penetration test of the changed surface, with the retest of the original findings folded into it where they still apply.
How HackersHub handles the retest
Every HackersHub penetration test includes one retest round of all findings, scheduled in the statement of work at a date agreed with you, normally between 30 and 90 days after the final report. The same named tester who found the issue verifies the fix, because the person who built the attack path is the fastest at probing its variants. For each finding you receive the verification status, the evidence and a plain statement of what, if anything, is still reachable.
The deliverable is an updated report with a dated verification appendix plus a one-page attestation letter signed by the lead tester, written so that it can be handed to a QSA, an ISO 27001 certification auditor, a SOC 2 service auditor or a customer's third-party risk team without the full report. Where a finding is partially remediated or covered by a compensating control, we say so plainly and name the residual path, which is what makes the letter credible when an auditor reads it against the report.
If the environment has changed materially between test and retest, we tell you that a retest will not give you the assurance you are paying for and propose a scoped test of the changed surface instead. Our testers are OSCP-certified, named in every report, and 10+ years of offensive security work has taught us that a retest done honestly is worth more to a security programme than a clean report that nobody checked.
Frequently asked questions
Need a penetration test that closes the loop?
Every HackersHub engagement includes a retest round and an auditor-ready verification appendix, performed by the same named tester. Talk to an expert about scope and timing.