What a patch report does and does not prove

A patching report that shows 95% complete looks reassuring. The report answers a narrower question than it appears to: which systems, on which list, received which updates. The report does not by itself show that the organization’s exposure to the vulnerabilities attackers use is going down.

According to the executive summary of Verizon’s 2026 Data Breach Investigations Report (page 9), exploitation of vulnerabilities is now the most common initial access vector for breaches, having risen to 31% in this year’s reporting dataset. The report defines critical vulnerabilities as those in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and finds that only 26% of them were fully remediated by organizations in 2025, down from 38% the year before. The median time for full resolution went up to 43 days, from 32 days the previous year. This is a finding about Verizon’s reporting dataset, not a claim about any particular organization’s exposure. The finding establishes that exploitation, not just discovery, is the trend worth accounting for when a completion percentage is the only evidence offered.

A completion percentage answers a narrow question

“95% patched” depends entirely on the denominator. The figure can mean 95% of a known, current asset inventory, or 95% of whatever the scanning tool happened to see this cycle. The percentage says nothing about which 5% remains, whether that remainder includes anything actively exploited, or how long it has been open. A high percentage and an unmanaged, aging exception list can coexist in the same report.

A five-part evidence checklist

The patching check in our review starts from the same records. Ask your IT provider or internal team for records that answer each of these, not just a percentage:

1. Asset and inventory coverage. What population does the percentage cover, and how was that inventory established and kept current?
2. Exploited-vulnerability priority. Are vulnerabilities on CISA’s KEV catalog, or otherwise known to be actively exploited, patched ahead of the general queue?
3. Exceptions and their age. What remains unpatched, why, and for how long has each exception existed?
4. Accountable owner and due date. Who owns each open exception, and what is the committed resolution date?
5. Independent remediation verification. How was closure confirmed, by re-scan, by someone other than the person who applied the fix, or by the reporting tool’s own say-so?

Questions for a provider conversation

Bring these to the next patching or vulnerability review, without prescribing a specific tool or vendor change:

• Which systems are outside the current inventory, and how would we find out?
• How does the exploited-vulnerability list get prioritized against the general backlog?
• What is the oldest open exception, and who owns it?
• How is remediation confirmed, and by whom?
• What would change your recommended cadence if exploitation trends like this year’s DBIR figures continue?

Match the next step to the evidence

If the inventory is unclear, start there before asking about patch speed. If exceptions exist without an owner or a date, assign both before adding new controls. If the report already answers all five questions cleanly, a bounded, independent spot-check of a handful of closed items is a reasonable next step, not a wholesale rebuild of the process.

Our guide to what an MSP contract actually covers helps you confirm what patching work you purchased, and who owns the gaps between your security providers helps when patching responsibility is split across more than one party.