Retesting: why 'fixed' is not evidence until someone checks

A finding is discovered, a ticket is raised, a developer changes some code, the ticket is closed. At no point in that sequence did anyone with attacker knowledge verify that the vulnerability is actually gone. That is not a hypothetical failure mode — in our experience a meaningful proportion of fixes verified during retesting are incomplete, and a smaller but real proportion introduce a new issue.

The three ways a fix fails

Fixed at the reported location only

The tester reported an authorisation flaw in the invoice export endpoint because that is where they found it. The same missing check exists on four other endpoints sharing the same controller pattern. The ticket said export endpoint, so the export endpoint was fixed.

This is the most common failure and it is structural: findings are reported as instances, and instances get fixed. A good report mitigates it by stating whether the finding is likely systemic, but the retest is what actually catches it.

Fixed in a way that can be bypassed

Input is now filtered — client-side. A parameter is now validated — but only on the primary code path, not the legacy one. A check was added — after the sensitive operation rather than before it. The fix is real, visible in the diff, and defeated in under a minute by someone who knows what they are doing.

Fixed, and something else broken

Tightening an authorisation check breaks a legitimate integration, so an exception is added for a service account. The exception is broader than the original flaw. This one is particularly insidious because the ticket genuinely was completed correctly, and the regression arrived a week later under operational pressure.

What a retest should actually cover

Getting the timing right

Retest too early and you are verifying against an incomplete remediation programme, which wastes the engagement. Retest too late and the environment has moved far enough that findings and fixes no longer correspond cleanly.

1. Agree a remediation window at the time of the original report — commonly 30 days for critical, 60 to 90 for high.
2. Require the development or operations team to confirm in writing which findings they consider remediated, and which they are risk-accepting.
3. Schedule the retest shortly after that confirmation date, not on a fixed calendar slot chosen months earlier.
4. Retest only what was claimed as fixed. Findings still open do not need re-verification; they need a date.
5. Issue a retest report that states, per finding, the original state, the claimed remediation, and the verified outcome.

The retest report is the compliance artefact

This is the part most organisations undervalue. The original test report shows that you found problems. The retest report shows that your process closes them — which is precisely what NIS2's effectiveness clause, DORA's remediation requirement and ISO 27001's vulnerability management control are asking about.

A retest report should be short and should contain, for each finding: the original identifier and severity, what the customer stated they changed, what the tester attempted, what was observed, and a verdict of resolved, partially resolved, not resolved, or risk accepted by the customer. Partially resolved is an important category and providers who lack it are rounding in an unhelpful direction.

Making it a process rather than an event

• Contract retesting at the same time as the original test. Mobilising a separate engagement later adds cost and delay, and is the reason most retests never happen.
• Import findings into your existing ticketing system with the stable identifiers from the report, so remediation status is visible where work actually happens.
• Treat systemic findings as a code review task, not a ticket. If an authorisation check is missing in one place, the useful action is a search across the codebase.
• Track time-to-remediate as a metric. It is more informative than finding counts, and it is the number a supervisory authority will ask for.
• Keep both reports together permanently. A test report without its retest is half an artefact.