Patch compliance is one of the most reported security metrics in any organisation. Every month a dashboard shows a high, reassuring percentage, and every month the steering committee moves on. It is also one of the most misleading numbers in security reporting.
The problem is not the effort. IT teams work hard to keep thousands of devices up to date. The problem is that a single average hides exactly the systems that matter most.
How the average hides the risk
Every device counts the same
A laptop in the marketing team and the internet facing VPN gateway each count as one device. Patch 950 laptops and miss 50 servers, and the dashboard shows 95%. The attacker does not care about the laptops.
Missing devices are not counted
The percentage is calculated against what the patching tool can see. Devices that were never enrolled, appliances, network equipment and forgotten servers are simply not in the denominator. They are often the most exposed systems in the estate.
Operating systems, not applications
Many dashboards report Windows updates well and say little about third party software, database platforms, firmware or the open source libraries inside business applications.
Exceptions that never expire
Systems that cannot be patched because of a vendor or a fragile legacy application are excluded from the metric. The exception is approved once and then forgotten, while the risk grows every month.
Measure what matters instead
1. Patch by exposure and exploitation
Prioritise vulnerabilities that are known to be exploited in the wild, such as those in CISA's Known Exploited Vulnerabilities catalogue, and systems reachable from the internet. Report these separately and with tight deadlines.
2. Report time to patch, not percentage patched
Measure how many days critical and exploited vulnerabilities stay open, by system tier. "Internet facing systems: median 4 days, longest 37 days" says far more than any percentage.
3. Show the long tail
List the oldest open critical vulnerabilities by name, with owners. A short, named list gets attention and action in a way that an average never will.
4. Reconcile the inventory
Compare the patching tool's device list with the asset inventory, network scans and cloud consoles. Every device missing from the tool is a device nobody is patching.
5. Manage exceptions as risks
Every unpatchable system should have an owner, compensating controls such as isolation or extra monitoring, and an expiry date when the exception is reconsidered.
What auditors should test
- Coverage. Reconcile the patching population with the asset inventory and a network scan.
- Critical systems. Pick internet facing and business critical systems and check their actual patch level, not the dashboard.
- Known exploited vulnerabilities. Check how quickly recent widely exploited vulnerabilities were fixed across the estate.
- Exceptions. Review the exception list for owners, compensating controls and expiry dates.
- Third party software. Confirm that browsers, PDF readers, Java, databases and network devices are within scope.
Four questions for leadership
- How long, at worst, does a critical vulnerability stay open on a system facing the internet?
- Which devices are not in our patching tool at all?
- How many systems are excluded from patching, and who has accepted that risk?
- Does our patch report show the systems attackers would target first?
A high patch percentage is a measure of effort, not of exposure. Attackers do not average across the estate. They look for the one unpatched system they can reach. Report what is exposed, how long it stays exposed and who owns it, and patching becomes a risk conversation leadership can act on.
References and further reading
- NIST, SP 800 40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA, Known Exploited Vulnerabilities Catalog
- Center for Internet Security, CIS Critical Security Controls v8 (Control 1, Inventory of Enterprise Assets, and Control 7, Continuous Vulnerability Management)
- ISO/IEC 27001:2022 (Annex A control 8.8 Management of technical vulnerabilities)