Most engagements end when the PDF lands in someone's inbox. The findings are written, the severity is agreed, the invoice is paid, and everyone moves on to the next quarter.
That is the weakest moment in the whole process.
A finding is a claim about how a system behaves. Claims are cheap. I can write "critical authorization bypass" in ten seconds. What makes it worth paying for is that I reproduced it, captured the requests, scored it, and then came back later to confirm the fix actually closed it.
What verification actually involves
The retest is not a formality where I rerun the same request and tick a box. Three things have to be true:
- The original proof no longer works, using the same preconditions as before.
- The fix did not break something adjacent. Authorization checks have a habit of being added in one place and missed in another.
- The change is in the environment that matters. A patch sitting on a staging branch is not a fix.
If any of those is unclear, the finding stays open. That is the whole point of separating findings from status.
Why teams skip it
Usually cost, sometimes process. A retest is a second engagement with the same vendor, or a line item someone has to argue for. It is also emotionally unappealing: you have to look at the thing you were told was handled.
The teams that get this right treat the retest as part of the purchase, not an extra. The ones that don't end up with a risk register full of items marked "remediated" that nobody has verified in a year.
What I do differently
Every project I run includes one retest window, and the output is a short closing report: what is closed, what remains, what changed. Not a victory lap, just the state of each finding.
That report is usually two pages. It is also the part of the work that tells you whether the first report was worth anything.