Retesting and fix verification

A fix that passes code review and unit tests can still leave the weakness exploitable. The common reasons are predictable:

Access control issues such as IDOR and BOLA are especially prone to partial fixes, because the same missing check is often repeated across many endpoints.

A retest is narrower than a full test, but it is not a checkbox. A good one covers four things:

1. The original attack: the exact steps from the report, run against the current production system (or the agreed target environment).
2. Close variations: different parameters, encodings, HTTP methods, roles and API versions that a narrow fix might miss.
3. The impact path: if the original finding exposed invoices, can invoices still be reached by any other route?
4. Side effects: did the fix break something else or introduce a new weakness, such as an overly broad error message?

Retesting is usually done by the same team that found the issue, because they know the context. Ask your vendor before signing whether a retest is included, how long after the report it can be scheduled, and whether it covers variations or only the literal steps.

A finding has a lifecycle, and it helps to use the same states everywhere: in the report, your ticketing system and any customer-facing summary.

• Open: reported, not yet fixed.
• Fix ready for retest: your team believes it is fixed and deployed.
• Verified fixed: a retest could not reproduce the issue. This is the only state that means closed.
• Still vulnerable: the retest reproduced it, fully or partially. It goes back to the owner with new evidence.
• Mitigated: exposure reduced by a compensating control (for example the feature is disabled) while a full fix is built.
• Risk accepted: a named owner has decided not to fix, with a reason and a review date.

Compliance frameworks and customers increasingly want proof that findings were fixed, not just that a test happened. The Payment Card Industry Data Security Standard (PCI DSS) v4.0.1 is explicit: under requirement 11.4.4, exploitable vulnerabilities and security weaknesses found during penetration testing must be corrected according to the entity's risk ranking, and penetration testing repeated to verify the corrections. For SOC 2 and ISO/IEC 27001, the specifics depend on your controls, but auditors typically look for evidence that identified vulnerabilities are tracked to resolution. See penetration testing for compliance for more.

Useful closure evidence for each finding:

• The original finding ID, severity and date reported.
• The fix: a reference to the change or release, and the date it was deployed.
• The retest date, who performed it, and what was tried.
• The result, with evidence such as the request and the now-rejected response.
• For mitigated or accepted items, the approver, the reason and the review date.

Mean time to remediate (the average time from report to verified fix) is the most common measure. Track it by severity, and measure to verified fixed, not to ticket closed, or the number will look better than reality.

Also watch the reopen rate: how often a retest finds a fix did not hold. A high rate usually points to root causes being skipped, such as authorization logic scattered across handlers instead of enforced in one place. That is a design conversation, not a bug-fixing one.

A one-time retest proves a fix on the day it ran. Code keeps changing, so the same weakness can return months later. Three habits help:

• Turn each verified finding into an automated test in your own pipeline where practical, such as an access control test that one user cannot read another's records.
• Fix the class of bug, not the instance: shared authorization middleware, safe query builders, central output encoding.
• Re-run past attacks periodically, either in the next scheduled test or through continuous penetration testing, which can re-check closed findings after each significant change.