Percent patched is a weak metric because it treats every asset and every vulnerability as equal. NIST SP 800-40 Rev 4 recommends a matrix that crosses asset importance with vulnerability importance and reports, per cell, the share patched by deadline plus mean and median time to patch.
Why the simple number misleads
NIST calls counting vulnerabilities and the percentage patched "not actionable." Its example: if you hear that 10 percent of your assets are not being patched, what does that say about risk? If they are your most important assets, it may be a serious problem. If they are the least important, it may be a reasonable use of limited resources.
A single figure cannot tell those two cases apart. A board reading it will either panic or relax for the wrong reason.
The matrix
NIST shows a notional table. Rows are vulnerability importance (low, medium, high, critical) and columns are asset importance (low, moderate, high), with the categories defined by your organization. Each cell reports:
- The percentage of assets patched by the deadline in the relevant maintenance plan.
- The average (mean) time to patch.
- The median time to patch.
The numbers in NIST's table are illustrative, so do not copy them as benchmarks. The shape is what matters. You expect the top right cell, critical vulnerabilities on high importance assets, to be fast and nearly complete. If it is not, that is where to look first.
How to build yours
- Define asset importance with three levels. Use business impact, exposure and data sensitivity.
- Define vulnerability importance with four levels. Combine severity with exploitation evidence. See the CVE, CVSS, EPSS and SSVC comparison.
- Tag each patch event with both levels, the deadline from the plan, and the dates found and fixed.
- Compute percent by deadline, mean time and median time for each cell.
- Slice the same data by platform, business unit and maintenance group.
NIST notes this slicing helps find where mitigation most needs improvement, and supports audience specific views for executives, technology leaders, IT operations and compliance staff.
Show both mean and median
A few very old items can drag the mean up while the median looks fine, and the reverse can hide a long tail. Showing both tells you whether the problem is typical or limited to outliers.
Garbage in, garbage out
NIST warns that low-level data must be accurate. If you scan monthly, you will count fewer vulnerabilities than exist, which paints a misleading picture. It also notes that passive scans, compared with active authenticated scans, generally underreport vulnerabilities and skew the higher-level numbers. Before you present the matrix, check how fresh and how complete your inventory and scan data are.
Pair it with an SLA view
The matrix works well beside a deadline dashboard. See how to build a vulnerability SLA dashboard. Safeguard's SBOM and dependency scanning and its policies provide the code-side inputs: what is present, how severe, and what is reachable.
Quick check
Should we report a single patch compliance number to the board?
Report the high importance cells, since that is where risk concentrates. A single number can be added for trend, with the matrix behind it.
Are the figures in the NIST table benchmarks?
No. NIST labels the table a notional example of the format.
Sources
Last reviewed: 19 October 2026.
