A retest is a focused follow-up after you've remediated the findings from a penetration test: the tester re-attempts the original exploit for each fixed finding, confirms it now fails, checks nothing new broke, and issues verified closure evidence — a revised report or attestation showing the findings remediated. It matters because unverified fixes fail more often than you'd think, and because auditors and customers want proof of closure, not a claim. Retest once fixes are deployed but while the engagement is fresh — typically within 30–90 days, prioritising critical and high findings. It's the step that closes out a SOC 2, PCI DSS or regulator requirement.
// 01 What retesting is
A penetration test ends with a list of findings and fixes. Retesting is what happens after you've made those fixes: a targeted assessment that verifies each remediation actually worked. The tester takes every finding you've marked as fixed, re-runs the exact exploit that proved it in the first place, and confirms the attack now fails. Where it still succeeds, the finding stays open with notes on why the fix fell short. It's a narrow, efficient exercise — it re-examines the specific findings, not the whole scope again — and it converts your remediation from an internal claim into independently verified fact.
// 02 Why "fixed" isn't enough on its own
Remediations fail more often than teams expect, and almost always for mundane reasons:
- The patch was incomplete — it closed one entry point but not another.
- The fix masked the symptom (e.g. a client-side check) without addressing the server-side cause.
- It was applied in one environment but not another, or reverted by a later deploy.
- It introduced a new issue or broke related functionality.
Without a retest, none of this surfaces — and your report still legitimately shows open critical findings. That's the quiet failure mode: a test is commissioned, fixes are made in good faith, and nobody ever confirms the risk is actually gone.
// 03 How a retest works
Remediate & deploy
You fix the findings and deploy the changes to the tested environment, then flag them ready for retest.
Re-attempt each exploit
The tester re-runs the original attack for every remediated finding to confirm it now fails.
Check for regressions
Confirm the fix didn't open a new hole or break related functionality nearby.
Issue closure evidence
Produce an updated report or attestation letter showing findings remediated and verified.
// 04 Timing and priorities
Retest once remediation is complete and deployed, but while the original engagement is still fresh in everyone's context — commonly within 30 to 90 days of the test. Good providers build a retest window into the engagement for exactly this reason, so you're not paying for a whole new test to confirm a handful of fixes. Prioritise by severity: get critical and high findings retested first, since those are the ones holding up an audit or a customer sign-off; lower-severity items can often be confirmed at the next scheduled test. Feed the whole cycle into a sensible testing cadence.
// 05 The evidence it produces
The output is the artefact your stakeholders actually want. After a successful retest, the provider issues updated evidence — a revised report or an attestation letter — showing the previously identified findings as remediated and verified. This is what closes out a SOC 2, PCI DSS or GCC regulator requirement, and what an enterprise customer accepts as proof during their security review. A test report that says "here's what was wrong, and here's proof it's now fixed" is far stronger than one that only does the first half. This is why a retest should be part of every engagement, and one of the questions to ask when choosing a provider.
// 06 Frequently asked questions
What is penetration test retesting?
A focused follow-up after remediation that verifies each fix actually closed the vulnerability and didn't introduce a new one. The tester re-attempts the original exploit for every remediated finding, confirms it now fails, and issues updated evidence showing the findings closed.
Why is retesting important?
An unverified fix is just a hope — remediations fail often (incomplete patches, symptom-masking, fixes applied in one place only). Retesting confirms closure with evidence auditors and customers accept, and catches fixes that broke something else. Without it, your report still shows open criticals.
When should you retest?
Once remediation is complete and deployed, while the engagement is fresh — commonly within 30–90 days. Reputable providers include a retest window. Prioritise critical and high findings first; lower-severity items can wait for the next scheduled test.
Does retesting give a clean report for auditors?
Yes — after a successful retest the provider issues updated evidence (a revised report or attestation letter) showing findings remediated and verified. That's the artefact auditors and enterprise customers want, and what closes out a SOC 2, PCI DSS or regulator requirement.
// 07 Related reading
- How to prioritise and triage findings — what to fix, and retest, first.
- How to read a penetration test report — understand what you're closing out.
- How to choose a provider — confirm a retest is included.