Measure vendor vulnerability response with timing metrics for each stage: time to match, time to first status, time to notify, time to fix and time to publish VEX. Add the overdue tail and the correction rate. Report medians and the worst cases, not a single compliance percentage.
Why these and not others
A count of vulnerabilities fixed says little. It rises when you scan more, and falls when you scan less. Timing metrics on each stage show where the process is slow, and can be compared quarter to quarter whatever the volume.
The seven metrics
| Metric | From | To | What it reveals |
|---|---|---|---|
| Time to match | Advisory seen | List of affected products | Quality of your component index |
| Time to first status | Advisory seen | Status for every hit | Triage capacity |
| Time to notify | Status known | Exposed customers told | Communication process |
| Time to fix | Triage confirmed | Fix available | Engineering flow |
| Time to publish | Fix available | Advisory and VEX public | Publishing friction |
| Overdue tail | Target date | Still open | The worst cases, hidden by averages |
| Correction rate | Published | Later changed | Accuracy of first answers |
How to collect them
- Log a timestamp at each state change in your tracker. Do not reconstruct from memory.
- Define the start event for each clock in writing, as covered in when the SLA clock starts.
- Tag each item with severity and known exploitation.
- Report the median and the 90th percentile, per severity band.
- List every item past target, with an owner and a reason.
- Review quarterly and pick one stage to improve.
Reading the numbers
- A long time to match with a short time to fix points to an inventory problem, not an engineering problem.
- A long time to publish after the fix suggests approvals or tooling are the bottleneck.
- A high correction rate means first answers go out too fast, or the not affected reasoning is weak.
- A good compliance rate with a bad tail means a few hard items are ignored. See the overdue tail.
Cautions
Do not set targets so tight that people hide delays. Do not compare teams with different product exposure. Do not publish internal metrics externally without checking they mean what readers will assume. Note too that the start of a clock is a decision, and changing it changes the metric.
What customers can ask
Customers sometimes ask for response timing in questionnaires. Answer with your definitions and your recent medians, and offer the method. See answering vulnerability SLA questions.
Quick check
Is mean time to remediate enough?
It hides the slowest items and mixes severities. Use medians, percentiles and a list of overdue items.
How many incidents do I need before the numbers mean anything?
With only a handful of cases in a quarter, medians are noisy. Look at each case and track the trend over several quarters.
Safeguard's compliance and evidence automation and policies can record the timestamps these metrics need. A free scan is a place to start building the inventory.
Last reviewed: 19 October 2026.
