Why every finding needs a retest

A ticket marked done is not a fixed vulnerability. Somewhere between the report and production, fixes go wrong more often than most teams expect, and the only way to know is to test again.

Fixes fail more often than you think

• The patch went on one server, but not its twin behind the load balancer.
• An input filter blocks the payload in the report, but not a simple variation of it.
• The fix is in the main branch, but the vulnerable version is still deployed.
• A configuration change was made, then reverted by the next deployment.
• The root cause was fixed in one endpoint and copied, unfixed, into three others.

None of these is unusual, and none of them shows up in a ticket system.

What a good retest does

A retest repeats the original attack against the fixed system, following the steps to reproduce from the finding, then tries the obvious variations: other parameters, other hosts, other encodings. If the issue cannot be reproduced, the finding is verified fixed, with the date and the evidence. If it can, the finding stays open with fresh evidence, and nobody has to argue about it.

A retest is also a chance to check that the fix did not break something else, or simply move the problem one step along.

When to retest

• As soon as a fix is deployed, while the context is fresh
• For critical and high findings, before the fixed release reaches production, where possible
• In bulk at the end of a remediation window, for everything else

Scanning-led work has its own version: the verification scan, which shows which findings no longer appear. A scanner not finding something is not quite proof, though. A host may have been down or out of scope for that scan, so an analyst should confirm each one before it is closed.

What to send with a retest request

A retest goes faster when the request says:

• What was changed, and where: which hosts, applications or environments
• When the fix was deployed, and in which version
• Anything the tester needs, such as a fresh test account or a new URL

When a retest fails

A failed retest is useful information, not a setback. The finding stays open with new evidence showing exactly what still works, and the fix can be adjusted with that evidence in hand. The usual causes are the ones above: an incomplete deployment, a fix that covers only one variation, or a change that was rolled back.

Why it matters

Evidence of a verified fix is what auditors, boards and customers actually ask for. A report showing that a critical finding was retested and closed on a given date, with evidence attached, carries far more weight than a spreadsheet of tickets marked done.

Retests in Cerberos Nexus

The client requests a retest from the Client Portal when a fix is ready, and the pentest company records the result against the original finding, so the report carries the retest history. In continuous projects, verification scans flag findings that look fixed, and an analyst confirms each one.