Patched Doesn't Mean Safe: Why Security Teams Need to Test After They Fix
A new survey of 750 security leaders finds that fewer than one in three organisations check whether a fix actually stopped an attacker. The gap between completing work and reducing risk is where breaches still happen.

Key points
- Only 30% of CISOs surveyed say their organisations patch a vulnerability and then test to confirm the risk is truly gone.
- A global investment firm found 85 security weaknesses that, when chained together, opened 251 ways for an attacker to cause serious damage.
- After fixing those weaknesses and retesting, the firm cut successful attack outcomes from 251 to zero.
- In a survey of 750 security leaders and practitioners, 22% named fix verification as their single biggest challenge heading into 2026.
- Closing a ticket and reducing risk aren't the same thing; only one of them stops a real attacker.
What is the difference between patching and actually being safe?
Patching means applying a software update that removes a known flaw. Being safe means an attacker still can't reach your systems after that update. Those two things are not automatically the same.
A vulnerability scanner, a software tool that checks your systems for known weaknesses, will confirm the flaw is gone. It won't tell you whether a criminal could still break in by a different route, or by combining several smaller problems. Closing the ticket feels like finishing the job. For an attacker, it changes very little if the door's still open.
Research published by CSO Online, drawing on a survey of 750 security leaders and practitioners, puts a number on that gap. Nearly half of organisations rescan with a vulnerability scanner after patching and call it done. Just 30% of CISOs, the executives responsible for an organisation's security, said their teams actually test whether an attacker could still succeed.
How bad can the gap get in practice?
Bad enough to be alarming. One global investment firm operating across 18 offices had vulnerability data, security assessments and regular reporting. What the team lacked was certainty.
An internal penetration test, a controlled exercise where security professionals try to break in the way a real criminal would, found 85 weaknesses. That number alone sounds manageable. What wasn't manageable was what happened when analysts chained those weaknesses together the way an actual attacker would: 251 distinct ways to cause serious harm. Our 5 August story "Fixing One Hole at a Time Is No Longer Enough" covered exactly this pattern, where attackers chain weaknesses across apps, accounts and cloud systems that each look minor in isolation.
| Outcome measured | Before fixes | After fixes |
|---|---|---|
| Total harmful attack outcomes | 251 | 0 |
| Credential theft successes | 52 | 0 |
| Servers or endpoints taken over | 67 | 0 |
| Active Directory passwords cracked | 40 | 0 |
Active Directory is the system most organisations use to manage who can log in and what they can access. Cracking those passwords is roughly equivalent to stealing a master key to the building.
After the firm fixed the identified weaknesses and ran the same test again, every outcome dropped to zero.
Should you be worried about organisations that skip this step?
Yes, in practical terms. When a company holds your personal data or your medical records, the security of that data depends on whether their fixes actually work, not whether their dashboards look clean.
The survey found 22% of practitioners called fix verification their biggest challenge for 2026, ahead of budget problems and staff shortages. A significant share of organisations protecting your data aren't confident their repairs held.
If a company you deal with announces a breach, ask what testing they did after fixing it. A straight answer matters more than a polished press release.
What does a mature approach look like?
The discipline is straightforward, even if execution takes effort: find the weakness, fix it, test again to confirm it's gone, and repeat as the environment changes. Financial services firms and defence suppliers in the underlying research built this loop into normal operations because their leadership demanded proof, not progress reports.
Scan and patch. Then verify. That last step is what turns activity into actual confidence, and it's the one most teams still skip.
The metric that should matter isn't whether a ticket closed. It's whether an attacker could still get through. Those two questions have different answers more often than most security programmes want to admit.



