Twenty organizations out of the 300 Vicarius surveyed for its 2026 State of Vulnerability Remediation report have eliminated manual remediation entirely, and every one of them shares the same three traits: one platform for the entire remediation lifecycle, full authority for the identifying team to fix what it finds, and a definition of "remediated" that requires a verified fix rather than a completed task.
That's the finding the published report didn't dig into. We went back into the raw survey data to find out what separates that group from the other 93%, and to test a harder question the report only hinted at: does how loosely an organization defines "done" predict whether it gets breached by something it already knew about.
What the 7% have in common
The first piece in this series covered the headline numbers: 58% of remediation work still requires a human, 82% of organizations can't fix a vulnerability without a handoff, and 79% had a security incident in the past year involving a vulnerability that was already sitting in their inventory.
Buried inside that same 300-person sample is a group of 20 respondents who reported zero manual remediation, full automation, end to end. We isolated those 20 and cross-referenced every other question they answered. The uniformity is what makes it interesting.
All 20 run their entire remediation lifecycle through a single platform. Not the sample average of three tools. Not the 39% of organizations juggling four or more. One.
All 20 said their identifying team can fix a vulnerability without handing it to anyone else. Across the full sample, only 18% can say that.
All 20 use the strictest available definition of remediated: a fix deployed and verified through a rescan or automated check, not a ticket, not an unverified patch, not a risk acceptance.
And all 20 reported zero security incidents involving a known vulnerability in the past 12 months. Across the other 280 respondents, 79% had at least one.
What didn't matter as much as we expected: vendor choice. This group used a mix of CrowdStrike Falcon Spotlight, Microsoft Defender, Tenable, and Qualys, with no single platform dominating. Company size mattered a little, 60% of the group sat in the 1,000 to 1,999 employee range versus a roughly even split in the full sample, but with only 20 respondents in the group, that's a pattern worth watching rather than a rule to bank on.
The takeaway isn't "buy the right tool." It's that automation shows up downstream of three decisions: consolidate to one system of record, give the team closest to the problem the authority to solve it, and stop counting activity as if it were an outcome.
Testing the harder question
The published report presented two findings side by side without connecting them. Only 50% of organizations mark a vulnerability remediated after a verified rescan. Another 18% count it done once a ticket is created and assigned, 13% once a patch ships without verification, and 18% once leadership formally accepts the risk. Separately, 79% of organizations had an incident involving a vulnerability they already knew about, and in more than half of those cases, the vulnerability had been known for 30 to 90 days before it was exploited.
We ran the cross-tab the report didn't. For every respondent, we compared their stated definition of "remediated" against whether they'd experienced a known-vulnerability incident.
Collapse the three looser definitions into one group and the pattern holds: 91.4% incident rate under loose definitions, 65.8% under the strict one. We ran a chi-square test on that split. It's statistically significant at p < 0.0001, well past the threshold where you'd chalk this up to sampling noise.
That's a 26-point gap in breach exposure tied to nothing more than what a tracking system counts as "closed."
Why this isn't about detection failures
It would be easy to read the 79% incident rate as a story about attackers moving faster than defenders can react. The timeline data doesn't support that. Only 2% of incidents involved a vulnerability identified less than a day before, and the exploitation window most organizations report, 30 to 90 days of prior knowledge, is not a zero-day problem. It's a remediation problem wearing a detection costume.
Organizations using loose definitions of "remediated" aren't necessarily missing more vulnerabilities. They're closing the file on the ones they find before the exposure is gone. A ticket gets created, ownership gets assigned, the dashboard shows green, and the vulnerability itself never left the environment. Leadership accepting a risk is a legitimate governance decision, but it isn't remediation, and treating the two the same thing on a scorecard makes a security posture look stronger than it is.
This matters most for the people who sign off on that scorecard. A GRC or compliance manager reviewing a risk register built on "leadership accepted the risk" is, according to this data, looking at a program with an 88.9% known-vulnerability incident rate hiding behind a green status. A CISO presenting MTTR and closure rates to a board is measuring speed, not whether the organization's actual exposure went down. Neither number is dishonest. Both can still be misleading if nobody checks what "closed" was built to mean.
What this means for the other 93%
You don't need to be one of the 20 to close this gap, but you do need to be honest about which of the two problems you have. If your organization is still spread across three or four tools with unclear ownership between the team that finds a vulnerability and the team that's supposed to fix it, that's a structural problem, and it's the one covered in part one of this series.
If your organization has decent tooling and reasonable ownership but still marks vulnerabilities "remediated" the moment a ticket closes or a patch ships without confirmation, that's a definitional problem, and based on this data, it's the more expensive one to leave unaddressed. A 26-point swing in known-vulnerability incident rates is not a rounding error on a compliance report. It's the difference between a program that reduces risk and one that produces paperwork about risk.
The fix isn't complicated to describe, even if it's harder to execute: require verification before you close the ticket, not after someone asks why the vulnerability got exploited anyway. vIntelligence was built to close exactly that gap, validating that a fix actually worked instead of assuming it did because a task moved to "done."
Want to see the complete findings?
Join our upcoming webinar where we'll break down the key insights from the 2026 State of Vulnerability Remediation Report, explain what separates high-performing remediation programs from the rest, and share practical strategies to reduce manual work and close vulnerabilities faster.
Register here and download the report here
Frequently asked questions
What did the organizations with fully automated remediation have in common? Based on Vicarius's raw 2026 survey data, all organizations reporting zero manual remediation used a single platform for the entire remediation lifecycle, gave the identifying team full authority to fix vulnerabilities without a handoff, and required a verified rescan before marking anything remediated.
Does the definition of "remediated" affect breach rates? Yes. Cross-referencing Vicarius's 2026 survey data, organizations that require a verified rescan before closing a vulnerability had a known-vulnerability incident rate of 65.8%, compared to 89 to 93% among organizations using looser definitions such as ticket creation or unverified patching. The difference is statistically significant (p < 0.0001).
Is the rise in known-vulnerability breaches a detection problem? No. Only 2% of incidents involved a vulnerability identified less than a day before exploitation. More than half were known for 30 to 90 days beforehand, which points to a remediation and verification gap rather than a failure to detect the vulnerability in the first place.
Does the vendor platform matter more than the process for achieving full automation? Not based on this data. The fully automated group used a mix of vendors including CrowdStrike, Microsoft Defender, Tenable, and Qualys, with no single platform dominating. Consolidation to one tool and clear ownership mattered more than which specific vendor was chosen.
