Almost every pentest report ends the same way: a list of findings, each with a severity rating and a recommended fix. What happens after that report is delivered is where a lot of the value quietly leaks out — because a fix that looks correct in code review can still miss the actual exploit path.
The gap between "fixed" and "verified fixed"
We've retested findings that were confidently marked resolved, only to find the patch closed the specific proof-of-concept we used but left the underlying logic flaw intact — a slightly different request still got through. The team wasn't being careless; they fixed what they understood the bug to be. But understanding a bug from a written description is a different exercise than exploiting it yourself.
Why we build retesting into every engagement
- It closes the loop with the same methodology that found the issue, not a fresh guess at what "fixed" should look like.
- It catches partial fixes before an auditor or, worse, an actual attacker does.
- It gives you a defensible answer when a client, insurer, or regulator asks "was this actually resolved?"
If a vendor treats retesting as a separate line item you have to ask for, that's worth noticing. A finding isn't closed because someone believes it's fixed — it's closed because someone tried to break it again and couldn't.