Proof that a fix worked comes from a retest, not from the developer's word.

After a test, your team fixes what was found. A retest sends the tester back to those findings only, using the original reproduction steps and a few variations. Each item is marked closed, partly fixed or still open.

Fixes fail more often than teams expect. A filter blocks the exact payload in the report but not a slight variation; a permission check is added to one endpoint but not its twin. The retest catches that before an attacker or an auditor does. It also produces the evidence that closes the loop: SOC 2 and ISO 27001 auditors look for findings tracked to closure, and payment-card rules expect exploitable weaknesses to be corrected and testing repeated. A report that says "remediated, verified on a stated date" carries more weight with buyers than one that only lists findings.

The penetration test proposal

A line stating whether a retest window is included and what it covers.

The retest letter or updated report

Each finding with its new status and the date it was verified.

Customer security reviews

Buyers ask whether high findings from the last test are closed and verified.

Penetration test

Looks for new weaknesses across a scope. A retest checks only the known findings and does not hunt for fresh ones.

Remediation

The fix your team makes. A retest is the independent verification of that fix.

Rescan

Running a scanner again. It may confirm a patched version but cannot verify a logic fix the way a manual retest can.

• Confirm before the test starts whether a retest is included and how long after the report it can be used.
• Send the tester a list of what changed for each finding, so they can target variations, not just the original request.
• Retest critical and high findings at least; batch lower ones where it makes sense.
• File the retest result with the original report as one evidence pack.

• GuidePenetration testing for SOC 2What auditors look for in a test report, and what they ignore.
• GuideSecurity testing servicesVulnerability assessment and penetration testing, scoped to what your buyers and auditors ask for.
• GuidePen tests & recovery testsNo criterion demands either. Your own control wording does.

Sources: NIST SP 800-115 (post-testing activities); PCI DSS v4.0.1, requirement 11.4 on penetration testing and correction of findings; OWASP Web Security Testing Guide (reporting).