Track time to fix separately for OS patches and dependency updates, and measure applied and running as separate stages. A blended average hides slow restarts on one side and slow deploys on the other, so the number looks fine while real exposure stays open.
Why one number misleads
Suppose host patches take twelve days and dependency fixes take two. A blended average sits somewhere in between and describes neither. Worse, the people who could improve each number get no signal. Different delays have different causes, so they need different metrics.
NIST SP 800-40 Rev. 4 notes that different audiences need different metrics, for example a Linux administrator needs metrics about Linux patching while business leaders want an overall view. Start from the audience, then choose the metric.
The core set
| Metric | OS layer | Dependency layer |
|---|---|---|
| Time to apply | Fix published to installed | Fix published to PR merged |
| Time to run | Installed to restart done | Merged to deployed |
| Open past deadline | Hosts past clock | Services past clock |
| Age of oldest open item | Oldest unpatched host group | Oldest open update PR |
| Exceptions | Count and age | Count and age |
Define each metric once and keep the definition stable. Changing definitions mid year makes trends meaningless.
Why split apply and run
Applied and running often differ. Hosts can have updates installed but not restarted. Pull requests can merge but sit undeployed. Splitting the stages shows where the delay lives. Large gaps between apply and run point at restart policy or release process, not at the patching tool.
Avoid vanity numbers
- Percent patched with no scope. Patched against what, as of when?
- Counts of vulnerabilities closed. One library can account for hundreds.
- Average only. Report the median and the slowest items too.
More on this: patch metrics that show risk, not just percent patched.
Weight by risk
Not every open item matters equally. Split by severity and by whether the issue is known to be exploited or reachable in your code. A short list of old, high risk items beats a long list of low risk ones, and the report should say so.
Report it simply
One page a month: the table above for each layer, a trend line for time to run, and the five oldest open items with owners. Add one sentence on what you will change next.
Where Safeguard fits
Safeguard's vulnerability management, continuous monitoring and compliance and evidence automation provide dated records you can compute these metrics from for the application layer. Try the free scan: gold.safeguard.sh/scan.
Quick check
What is a good time to fix?
It depends on severity and your obligations. Set targets in your policy and measure against them, rather than against another company's figure.
Should exceptions count as patched?
No. Report them separately with their age and owner.
Sources
Last reviewed: 19 October 2026.
