Show leadership metrics that weight by what matters: how fast the most important vulnerabilities on the most important assets are fixed, and how many urgent items are overdue. NIST says simple counts of vulnerabilities and percent patched are not actionable because they ignore which assets and which flaws were involved.
Why counts mislead
NIST SP 800-40 Rev. 4 makes the point with an example. If you were told that 10 percent of assets were not being patched, what would that mean for risk? If they are the most important assets, it could be a major problem. If they are the least important, it may reflect sensible use of limited resources.
A falling total can come from changing scanners, closing old items in bulk, or a quiet month. Neither direction of the number says whether risk went down.
What NIST suggests instead
The guide proposes metrics that vary by the importance of assets (low, moderate, high) and the severity of vulnerabilities (low, medium, high, critical), with categories defined by the organization. Each cell shows how much was patched in that combination. The point is to see whether the important things got done first.
It also says different audiences need different metrics. An administrator wants patching performance for their platform. Business unit leaders may want to compare their units. Leadership wants a view of risk and trend.
A starter set
| Metric | What it shows | Watch out for |
|---|---|---|
| Overdue urgent items | Whether the emergency path works | Show the oldest item, not only the count |
| Time to fix by tier | Speed where it counts | Report median and the slow tail |
| Coverage of important assets | Are critical systems scanned and inventoried? | Unknown assets are a risk themselves |
| Open exceptions and their age | How much risk is being carried | Include expiry dates |
| Recurring causes | Why items go late | Turn into a fix, such as a shared library upgrade |
A compliance percentage can hide the long overdue tail, so always put the oldest open items beside it.
How to present them
- Lead with one sentence of judgment: improving, steady, or worsening, and why.
- Show three to five numbers, each with a trend and a plain label.
- Name one decision you need from leadership, such as resourcing a platform upgrade.
- Keep a detailed appendix for those who want it.
Avoid unexplained scores and invented precision. If a number cannot be explained in one sentence, leave it out of the main page.
Be honest about limits
Say what the data does not cover. Unscanned assets, unknown software, and findings with no fix are all part of the picture. Leadership trusts a report that names its gaps.
Try it yourself
Open the demo and look at how vulnerability data can be sliced by severity and status. Think about which view you would put in a leadership summary.
Click through it at your own pace, or open it full screen.
Quick check
Is mean time to remediate a good headline number?
Only with context. Averages hide the slow tail, so show it by tier and include the oldest open item.
How many metrics should one report have?
Three to five in the main view. More dilutes the message.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (also available as a PDF)
Last reviewed: 19 October 2026.
