These are the common vulnerability management metrics, defined in plain language. Many are used loosely, so always state the clock start and stop when you report one. Definitions vary between organizations, which is why a short glossary in your own reports prevents most arguments.
Time based metrics
| Term | Plain definition | Typical clock |
|---|---|---|
| MTTD, mean time to detect | How long a vulnerability exists in your environment before you find it | Disclosure or introduction to detection |
| MTTA, mean time to acknowledge or assign | How long a finding waits before someone takes ownership | Detection to assignment |
| MTTR, mean time to remediate | Average time from the start of the clock to the fix | Triage or detection to deployed fix |
| Exposure window | Time a vulnerable, reachable component runs in production | Disclosure or detection to production fix |
| Time to triage | Time to decide if a finding applies and how urgent it is | Detection to triage decision |
The R in MTTR is also used for "respond" and "recover" in incident work. That is a different measurement. See MTTR in incident response versus remediation.
Volume and state metrics
| Term | Plain definition |
|---|---|
| Open findings | Findings not yet closed, ideally split by priority tier |
| Inflow | New findings in a period |
| Outflow | Findings closed in a period, by closure type |
| Past SLA | Open findings older than the tier's target |
| Aging | Distribution of open findings by how long they have been open |
| Backlog | Open findings beyond what the team can address in a normal cycle |
Quality and coverage metrics
| Term | Plain definition |
|---|---|
| Scan coverage | Share of known assets or repositories scanned within a defined window |
| Ownership coverage | Share of open findings with a valid accountable owner |
| False positive rate | Share of findings closed as incorrect or not applicable |
| Recurrence or reopen rate | Share of closed findings that come back |
| Exception rate | Share of findings closed as accepted risk |
For scan coverage definitions, see how to define a security scan coverage metric.
Risk context terms
| Term | Plain definition |
|---|---|
| Reachability | Whether the vulnerable code can actually be called in your software |
| KEV | The CISA Known Exploited Vulnerabilities catalog of vulnerabilities with evidence of exploitation in the wild |
| EPSS | An estimate of the probability a published CVE is exploited in the next 30 days |
| CVSS base score | A severity rating, which FIRST says should not be used alone to assess risk |
How to use this glossary
- Copy the terms you report into a one page definition sheet.
- Add your own clock start and stop for each time metric.
- Attach the sheet to executive reports or link it.
- Revisit when a number is questioned. Most disputes are definition disputes.
A reusable template is in the metric definition card template.
Safeguard's dependency scanning, reachability analysis and compliance evidence automation can supply the inputs for most of these. You can check what a baseline looks like with a free scan.
Quick check
Is MTTR the best metric for a vulnerability program?
It is useful but incomplete. Pair it with past SLA counts and ownership coverage, and prefer the median to the mean when a few items are very old.
What is the difference between aging and MTTR?
Aging describes open findings today. MTTR describes how long closed findings took. Both are needed.
Sources
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- FIRST, EPSS: https://www.first.org/epss/
- FIRST, CVSS v4.0 user guide: https://www.first.org/cvss/v4-0/user-guide
Last reviewed: 19 October 2026.
