Vulnerability Management Metrics: 15 KPIs That Matter, With Formulas and Targets

Vulnerability management metrics tell you whether your program finds the vulnerabilities that matter and closes them before an attacker uses them. The 15 KPIs worth tracking fall into four groups: coverage (are you scanning everything, with credentials), speed (time to remediate, deadline adherence, patch latency), exposure and backlog (open KEV-listed flaws on internet-facing systems, the overdue backlog, capacity against inflow) and quality (prioritization accuracy, false positives, reopened findings, expired exceptions). Each comes with a formula, a starting target and the trap that makes it lie.

To have the numbers produced for you, our vulnerability management program runs validated scans on a fixed calendar and re-scans every fix, priced per scan on the vulnerability scanning cost page: $1,500 for up to 250 devices.

Why vulnerability management metrics matter more in 2026

Exploitation of vulnerabilities is now the most common way into a breach, at 31% of initial access, according to Verizon’s 2026 Data Breach Investigations Report. Organizations fully remediated only 26% of KEV-listed vulnerabilities in 2025, down from 38%, and the median time to full resolution rose from 32 days to 43. Attackers move faster: Mandiant measured an average time-to-exploit of five days for vulnerabilities exploited in 2023 (Google Cloud, Time-to-Exploit Trends). Your metrics exist to measure that gap and shrink it.

What makes a vulnerability management KPI worth tracking

NIST’s SP 800-55 Volume 1 (December 2024) sorts security measures into implementation, effectiveness, efficiency and impact. Coverage KPIs measure implementation, speed KPIs efficiency, exposure and quality KPIs effectiveness, and the board view turns them into impact.

NIST’s patching guide, SP 800-40 Revision 4, adds the warning most dashboards ignore. Section 3.6 says “metrics that are too simple are generally not actionable,” and notes that monthly-only or unauthenticated scanning underreports vulnerabilities and skews every metric built on top. Three tests weed out vanity metrics:

1. It drives a decision. If it moved 20%, would anyone change a deadline, a budget or an owner?
2. It is split by risk. One average blends a three-day emergency with a low that can wait, and describes neither.
3. It cannot improve by looking less. Total open vulnerabilities falls when you stop authenticated scanning, which is why it is not on this list.

Vendor risk scores are left off because they cannot be compared across tools; time to triage sits inside MTTR.

Our guide to a vulnerability management program covers building what these numbers measure.

The 15 vulnerability management KPIs at a glance

#	KPI	Formula	Starting target
1	Asset coverage	Assets scanned this cycle ÷ assets in the inventory	100% of internet-facing and tier-1 assets
2	Authenticated scan coverage	Hosts where a credentialed scan succeeded ÷ hosts that accept credentials	95% or more, every failure explained
3	Scan cadence adherence	Scans completed and reviewed on schedule ÷ scans scheduled	100%
4	Mean time to detect	Detection date minus KEV listing date (CVE publication to detection tracked separately)	Within a day of a KEV listing, for exposed assets
5	Mean time to remediate (MTTR)	Verified-fix date minus detection date, averaged per risk tier	Inside each tier’s deadline
6	Median and 90th percentile time to remediate	Same durations, open findings counted at current age	90th percentile inside the deadline
7	SLA adherence	Fixed within deadline ÷ all findings due, open overdue ones included	95% in the top two tiers
8	Patch latency	Install date minus vendor patch release date	Critical patches within 30 days
9	Open KEV on exposed assets	Count and age of open KEV-listed findings on internet-facing systems	Zero past deadline
10	Overdue backlog and age	Open findings past deadline, by tier and age bucket	Zero in the top tier
11	Capacity versus inflow	Findings verified closed ÷ new findings, per quarter	1.0 or higher
12	Prioritization coverage	Newly KEV-listed CVEs in your estate already in your top tiers ÷ all such CVEs	Rising each quarter
13	False positive rate	False positives reaching engineers ÷ findings sent to engineers	Zero reaching engineers
14	Reopen rate	Closed findings detected again within two cycles ÷ findings closed	Falling
15	Expired risk exceptions	Accepted risks past review date ÷ all accepted risks	Zero

Targets are our recommended starting points, not industry benchmarks.

Coverage KPIs: are you looking at everything?

1. Asset coverage

You cannot measure remediation on assets you never scanned. Report the share of inventoried assets scanned, plus the count of assets discovery found that the inventory missed. For internet-facing systems, external attack surface management is how those unknowns get found. CIS Controls v8.1 asks for an inventory reviewed at least twice a year (Safeguard 1.1) and weekly handling of unauthorized assets (1.2). Coverage against a stale inventory is 100% of the wrong list.

2. Authenticated scan coverage

Count hosts where the credentialed check succeeded, not where it was configured: an expired service account silently downgrades the scan to banner-grabbing. PCI DSS v4.0.1 Requirement 11.3.1.2 requires authenticated internal scanning, with hosts that cannot accept credentials documented.

3. Scan cadence adherence

For Implementation Group 2 and above, CIS sets the floor at quarterly internal scans, authenticated and unauthenticated (Safeguard 7.5), and monthly external scans (7.6). A skipped scan flatters every speed metric, because a vulnerability nobody detected has no clock running.

Speed KPIs: mean time to remediate and the clocks around it

4. Mean time to detect

Days from a KEV listing to the vulnerability appearing in your findings. CISA’s Binding Operational Directive 26-04, issued June 10, 2026, starts federal clocks at the KEV listing or the agency’s own identification, whichever comes first, so slow detection buys no time. Monthly scans alone leave a mid-cycle disclosure unseen for about two weeks on average, so a one-day target means checking each new KEV entry against your inventory or running a targeted scan.

5. Mean time to remediate (MTTR)

The headline number: average days from detection to verified fix, per risk tier. The clock stops when a re-scan or retest confirms the fix, not when the ticket closes.

6. Median and 90th percentile time to remediate

The median shows the typical finding; the 90th percentile shows the slow tail, where the risk sits. Verizon’s 2026 DBIR shows third-party cloud MFA exposures as a survival curve (the share still open on day 7, 28, 90 and 240), the honest way to show speed while some findings remain open.

7. SLA adherence by risk tier

Boards read this without explanation, and it answers 23 NYCRR 500.5(c), which requires timely remediation prioritized by risk. The denominator must include open, overdue findings. Our vulnerability remediation guide has a deadline table to start from, and our guide to risk-based vulnerability management maps BOD 26-04’s tiers (3, 14 or 60 days, or the next upgrade) onto private-sector findings.

8. Patch latency: the patch management metric

Patch management metrics measure the patching process: days from vendor release to installation, and the share of assets on the current patch level. PCI DSS v4.0.1 Requirement 6.3.3 starts its clock at release and requires critical patches within one month (PCI DSS v4.0.1, PCI Security Standards Council). Report it by maintenance group, the asset grouping SP 800-40r4 recommends.

Exposure and backlog KPIs: what is open, and for how long

9. Open KEV-listed vulnerabilities on exposed assets

If you report one number to leadership, make it this: how many vulnerabilities on CISA’s Known Exploited Vulnerabilities catalog are open on internet-facing systems, and how old each is. Our October 2026 KEV roundup shows how fast the list moves.

10. Vulnerability age and overdue backlog

Bucket open findings by age (0-30, 31-90, 91-180, over 180 days) and tier. Age catches what MTTR misses: a finding open for a year adds nothing to MTTR until it closes.

11. Remediation capacity versus inflow

Below 1.0, the backlog grows however hard the team works. Add capacity or tighten the rule for what must be fixed. In the median case, Verizon’s 2026 DBIR found organizations had 50% more critical (KEV-listed) vulnerabilities to patch than a year earlier.

Quality KPIs: can you trust the numbers?

12. Prioritization coverage and efficiency

FIRST defines coverage as the share of exploited vulnerabilities a prioritization threshold catches, and efficiency as the share of vulnerabilities acted on that were actually exploited (FIRST, How EPSS works). Ask quarterly: of your CVEs that CISA added to KEV, how many were already in your top tiers? A low number means the model ranks the wrong things. The check is the same whatever does the ranking: CVSS v4.0 scores (FIRST stresses that CVSS is not just the Base score), EPSS, or a decision tree such as CISA’s SSVC.

13. False positive rate

Version-based detection flags backported fixes and disabled features. Track two shares: findings rejected at validation (a scanner-tuning signal) and false positives that reached an engineer anyway (the trust metric, and the one with a target). Both need a validation status recorded for every finding; our vulnerability assessment report template lists the statuses to use.

14. Reopen rate

Reopens point to process faults: a fix applied to one server but not the base image, or a patch rolled back after an outage. A rising rate means MTTR is measuring ticket closure, not risk reduction.

15. Expired risk exceptions

Every accepted risk needs an owner, a compensating control and an expiry date. SP 800-40r4 Section 3.5.5 says exceptions to maintenance plans should be reviewed regularly, and accepted risks deserve the same discipline. Exceptions that never expire are how a 2019 finding is still open in 2026.

How to calculate mean time to remediate without fooling yourself

One quarter of findings in the 14-day tier at a fictional company: seven were verified fixed in 2, 3, 3, 4, 5, 6 and 9 days, one took 41 days, and two are still open at 60 and 75 days. The same data, reported different ways:

Calculation	Result	What it suggests
MTTR, closed findings only	9.1 days	Comfortably inside the deadline
Median, closed findings only	4.5 days	Even better
SLA adherence, closed findings only	88% (7 of 8)	Close to target
SLA adherence, all findings due	70% (7 of 10)	Well short of 95%
Mean days, all 10 findings (open ones at current age)	20.8 days and rising	Outside the deadline
Oldest open finding in the tier	75 days	The number leadership needs

Five rules keep MTTR honest:

1. Start at detection. When a tier changes (a new KEV listing, a newly exposed system), set a new deadline from that event and keep the original date for age. BOD 26-04 also treats deadlines as dynamic: a new KEV listing shortens one, and taking a system off the internet lengthens it.
2. Stop at verified fix, confirmed by re-scan or retest.
3. Count open findings at their current age, or show a survival curve.
4. Split by tier and asset importance. SP 800-40r4 Table 1 sketches this matrix, each cell showing the share fixed by deadline plus mean and median days.
5. Never reset the clock on re-import. Match on asset and CVE so a renumbered finding keeps its age.

A vulnerability management dashboard for each audience

SP 800-40r4 notes that a board, a CIO and a system administrator need different metrics.

Audience	Cadence	KPIs	The question it answers
Board and executives	Quarterly	9, 7 (top tier), 10 (oldest open), 15	Are we exposed to what attackers use now?
CISO, CIO, IT leadership	Monthly	5-7 by tier and business unit; 1, 2, 11, 12	Is the gap people or process?
IT and engineering teams	Weekly	Overdue list by owner; 8; 13; 14	What do I fix this week?

What compliance frameworks expect you to measure

Framework	Requirement	The metric it implies
CIS Controls v8.1	7.3, 7.4 monthly patching; 7.5, 7.6 scan cadence; 7.7 monthly remediation	Patch latency, cadence, adherence
PCI DSS v4.0.1	6.3.3 critical patches within one month; 11.3.1 quarterly internal scans, high-risk and critical findings resolved and rescanned; 11.3.1.2 authenticated scanning	Patch latency, verified closure, authenticated coverage
NYDFS 23 NYCRR 500	500.5(a)(2) automated scans plus manual review; 500.5(c) risk-prioritized remediation	Asset coverage, adherence by tier
CISA BOD 26-04 (federal agencies)	Deadlines set by KEV status, exposure, automatability and impact	Open KEV on exposed assets, time to detect
SOC 2, ISO 27001	CC7.1; Annex A 8.8	Proof the process operates

The metrics are evidence. The SOC 2 opinion comes from your CPA firm, and ISO 27001 certification from your certification body.

Metrics a scanner cannot give you

Scan-based KPIs count only what a scanner can detect, so an authorization flaw in your own code or an Active Directory permission that leads to domain admin never enters them (an Active Directory security assessment is the test that maps those paths). A penetration test adds four metrics worth trending:

• Findings with no CVE: if this share is high, your scan metrics describe a fraction of the risk.
• Proven attack paths: chains that reached a critical system, and in how many steps.
• Repeat findings: issues from last year’s test that are back.
• Retest pass rate: remediated findings confirmed closed at the first retest.

Our guide on how to read penetration test results explains attack narratives, retests and tracking repeat findings year over year, and security between penetration tests covers the months in between. In CTEM terms, this is the validation stage.

What it costs to have these metrics produced

Our vulnerability management program produces the raw data for most of these KPIs each cycle: authenticated and external scans of the agreed scope, analyst validation with every false positive listed, ranking by KEV, EPSS, exposure and asset value, each finding tracked from open to verified, and trend reporting. Re-scans of remediated findings are included, so MTTR can stop at a verified fix.

What you buy	Price at published rates	What it feeds
One scan from our validated vulnerability scanning service, up to 250 devices (251 to 1,000: $2,500)	$1,500	A baseline: coverage, KEV exposure, backlog
Monthly external and quarterly internal scans, up to 250 devices each	$24,000 a year (16 × $1,500), fixed in writing	Most KPIs: external monthly, internal quarterly
Annual external and internal penetration tests	From $4,200 and from $6,000	No-CVE findings, attack paths, retest pass rate

Internal and external scans are priced separately; quarterly internal scans alone cost $6,000 a year, and estates over 1,000 devices are quoted. Every penetration test includes a free retest of remediated findings, and onboarding starts within 24 hours of a signed proposal. This is a testing and validation program, not a SOC, MDR or software license. The sample report shows the format.

Frequently asked questions

What are the most important vulnerability management metrics? Four cover most of what matters: open KEV-listed vulnerabilities on internet-facing systems, SLA adherence by risk tier, median and 90th percentile time to remediate, and authenticated scan coverage.

What is a good mean time to remediate for vulnerabilities? One inside your own deadline for each tier, with the 90th percentile inside it too. BOD 26-04 gives federal agencies as little as 3 days for the most dangerous KEV-listed flaws, and PCI DSS requires critical patches within one month of release.

How do you calculate MTTR for vulnerabilities? For each finding closed in the period, subtract the detection date from the date a re-scan or retest verified the fix, then average per risk tier. Report the median and 90th percentile alongside it, with open findings counted at their current age.

What is the difference between vulnerability management metrics and patch management metrics? Patch management metrics measure the patching process, such as latency from vendor release to install. Vulnerability management metrics also cover misconfigurations, flaws with no patch, exceptions, scan coverage and prioritization quality.

What is a good SLA adherence rate for vulnerability remediation? We suggest 95% in the top two risk tiers as a starting target. No framework sets a figure, so treat it as our recommendation, not an industry benchmark. The rate only means something if the denominator includes findings that are open and overdue: in the worked example above, the same quarter reads 88% on closed findings and 70% on all findings due.

Which vulnerability metrics do auditors ask to see? Evidence that the process runs to its own rules. For PCI DSS, that is the quarterly internal scan reports with rescans showing high-risk and critical findings resolved, proof the scans were authenticated, and critical patches installed within one month of release. For NYDFS Part 500, it is scan coverage and remediation prioritized by risk. For SOC 2 and ISO 27001, have SLA adherence by tier and the exception register ready, because they show the process operating.

How often should vulnerability metrics be reported? Weekly to the teams fixing, monthly to IT and security leadership, quarterly to the board, and never faster than the scans that feed them.

The short version

Track coverage, speed, exposure and quality, split by risk tier, and drop any metric that improves when you scan less. Lead with open KEV-listed vulnerabilities on exposed systems and SLA adherence, count open findings in every time-to-remediate figure, and stop every clock at a verified fix. To have the scans and re-scans behind these numbers run at a fixed annual price, see our vulnerability management program and its published pricing, or scope it now.