What a patch report does and does not prove

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

According to Verizon’s 2026 Data Breach Investigations Report, exploitation of vulnerabilities is now the most common way attackers gain initial access to a breach, up to 31% of its reporting dataset. Of critical vulnerabilities in CISA’s Known Exploited Vulnerabilities (KEV) catalog, only 26% were fully remediated by organizations in 2025, down from 38% the year before, and the median time to full resolution rose to 43 days. This is a finding about Verizon’s reporting dataset, not a claim about any particular organization’s exposure. It 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. It can mean 95% of a known, current asset inventory, or 95% of whatever the scanning tool happened to see this cycle. It 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.

What the statistics do and do not establish

The DBIR and KEV figures describe a trend across a large reporting dataset: exploitation has become more common, and remediation of critical vulnerabilities has gotten slower, not faster, industry-wide. They do not establish that this organization’s unpatched systems are being targeted, and they are not a benchmark to hit for its own sake. Use them to calibrate how much a completion percentage alone should reassure you, not as a statement about your own exposure.

A five-part evidence checklist

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 actually purchased, and who owns the gaps between your security providers helps when patching responsibility is split across more than one party.