Every penetration test ends the same way: a report lands in someone’s inbox, a list of findings gets triaged around a meeting table, and a plan takes shape to fix the worst of it before the next audit cycle. What happens next is where most companies quietly drop the ball. The fixes get made, or they get marked as made in a ticketing system, and nobody circles back to confirm the vulnerability is actually gone. Six months later an auditor, an insurer, or an attacker discovers the gap was never properly closed at all.
The gap between fixed and confirmed fixed
A patch gets applied, a configuration gets changed, a firewall rule gets tightened during a routine maintenance window. On paper it all looks resolved and the ticket gets closed. In practice, patches sometimes fail silently without anyone noticing, configuration changes get reverted by an unrelated update pushed the following week, and firewall rules get overwritten the next time someone touches the router for an unrelated reason. Without independent verification, ‘fixed’ is really just ‘we believe this is fixed’, which is a materially different and much weaker claim to be making to a client or a regulator.
This is exactly the gap that regular vulnerability scan services is designed to close, quietly and continuously. Running a fresh scan after remediation confirms the specific issue no longer appears in practice, rather than relying on someone’s memory of having applied a patch three months earlier under pressure. It sounds like a small step in the overall process. It is genuinely the difference between an environment that is secure and one that merely looks secure on a spreadsheet somebody prepared for a board meeting.
Why retesting gets skipped
Budget is usually the honest answer, if anyone is willing to say it plainly. Companies pay for the initial test, absorb the shock of the findings, fix what they can afford to fix within the timeframe available, and move straight on to the next competing priority. Retesting feels like paying twice for the same problem rather than progress. But a test that never confirms remediation only tells you where you stood on the day of the original assessment, not where you actually stand now, and that gap widens every single week that passes without proper verification.
William Fieldhouse sees this play out from the other side of the table constantly, in conversations that repeat themselves year after year.
“Clients often ask us to just send the report and skip the retest, thinking they’ve saved a bit of money along the way. Then a year later a different auditor tests the same system and finds the exact same flaw still sitting there, because the fix was never actually verified in the first place, only assumed and quietly filed away as done.”
— William Fieldhouse, Director of Aardwolf Security Ltd
That scenario plays out more often than most businesses would like to admit, and it rarely comes up until an insurer or a client’s due diligence team asks pointedly for proof. Assumption is not evidence, and increasingly the people asking the hard questions know the difference and expect a real, documented answer.
Make the proof part of the process
Build retesting into the plan from the very outset rather than treating it as an optional extra once the invoice for the first test has already been settled and filed. If you want independent confirmation that your fixes genuinely hold up under real scrutiny, a penetration testing quote for a full test-and-retest cycle is the sensible starting point for the whole conversation, and it turns ‘we think it’s fixed’ into something concrete you can actually stand behind when it matters most.
