Vulnerability Management Metrics That Matter

The vulnerability management metrics that matter measure how quickly and completely you reduce risk, not how many problems your scanner finds. A solid core set covers mean time to remediate by risk tier, SLA compliance, scan coverage (including authenticated scanning), exposure window, time to fix known-exploited vulnerabilities, recurrence rate, vulnerability age and an overall risk trend. The raw count of vulnerabilities found, which still leads many reports, is mostly a vanity metric. Below, we explain how to calculate each useful metric, what it tells you, and how to present it to executives, IT teams and auditors.

Why do vulnerability management metrics matter?

Metrics answer three questions: is the program working, where is it stuck, and does it need more resources? Without them, vulnerability management becomes a treadmill of scans and tickets with no clear sense of progress.

Good metrics also change conversations with IT. "Your team has 14 overdue high-tier findings, the oldest at 71 days" leads to action. "We found 12,000 vulnerabilities this month" leads to a shrug.

Which vulnerability metrics are vanity metrics?

A vanity metric looks impressive or alarming but doesn't help anyone make a decision. The common ones in vulnerability management are:

• Total vulnerabilities found. This number goes up when you scan more assets or switch to authenticated scans, both of which are improvements. It also swings with scanner plugin updates. It says little about risk.
• Number of scans run. Activity, not outcome.
• Patches deployed. A patch count doesn't tell you whether the right systems were patched, or patched in time.
• Total critical findings, unqualified. Without exploitation status, exposure or asset context, a critical count mixes urgent problems with theoretical ones.
• Vulnerabilities closed. Without a time dimension, closing 500 low-severity findings looks better than fixing the one that mattered.

Raw counts still have a place in the operational data your team uses. They just shouldn't headline a report.

What are the most important vulnerability management metrics?

Here is the core set, with what each one tells you.

Mean time to remediate by tier

Mean time to remediate (MTTR) is the average number of days between detecting a vulnerability and verifying that it's fixed. Calculate it over findings closed in the reporting period.

Always break it down by risk tier. A single overall MTTR blends two-day fixes on critical systems with 200-day fixes on low-risk test machines, and the result means nothing. Report the median alongside the mean too, because a handful of very old findings can drag the mean far from typical performance.

SLA compliance rate

If you have remediation SLAs, measure them in two ways:

• Closed within SLA: of the findings closed this period, the percentage closed before their due date.
• Currently overdue: of the findings still open, the percentage already past their due date.

The first shows past performance. The second shows the backlog you're carrying right now. A team can have a strong closed-within-SLA rate while quietly ignoring its hardest findings, which only the overdue figure reveals.

Scan coverage

Every other metric depends on this one. If you scan only 70% of your assets, your MTTR and SLA figures describe 70% of the environment.

Track scan coverage as:

• Assessment coverage: the percentage of known assets scanned or assessed by an agent within your target interval, such as the last 7 or 30 days.
• Authenticated coverage: the percentage of assets assessed with credentials or an agent.
• Inventory gaps: assets found by discovery scans, cloud consoles or network data that aren't in your inventory.

Authenticated coverage deserves its own line. Unauthenticated scans see only what a system exposes over the network, so they miss most missing patches in locally installed software. If you're subject to PCI DSS, version 4.0 adds requirement 11.3.1.2 for authenticated internal scanning. It's a best practice until March 31, 2025, when it becomes mandatory.

Watch for failed authentication, too. A scan that ran but couldn't log in often gets counted as covered when it wasn't.

Exposure window

MTTR starts the clock at detection. The exposure window starts it earlier, usually when the vulnerability was publicly disclosed or when the vendor released a fix, and stops it at verified remediation.

The difference between the two is your detection lag. If MTTR looks healthy but the exposure window is long, the problem sits upstream: infrequent scans, gaps in coverage, or slow scanner updates. Measure exposure window for your higher tiers at minimum.

KEV remediation time

CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of active exploitation. These deserve their own metric because they carry the clearest real-world risk.

Track two things:

• Median time to remediate KEV-listed vulnerabilities, measured from the later of the KEV listing date or your first detection.
• Open KEV findings, with a target of zero on internet-facing systems.

For a benchmark, CISA's Binding Operational Directive 22-01 requires U.S. federal civilian agencies to remediate KEV entries by the due dates in the catalog, with a default of two weeks for CVEs assigned from 2021 onward. It doesn't bind private organizations, but it gives your leadership a reference point they will recognize.

Recurrence and reopen rate

This is the percentage of remediated findings that reappear within a set period, such as 90 days. It's one of the most useful metrics for spotting process problems.

High recurrence usually points to root causes like:

• Outdated golden images or templates that redeploy old software
• Patches rolled back after compatibility problems
• Configuration drift that re-enables a service or setting
• Hosts restored from old backups or snapshots

A finding that keeps coming back costs you remediation effort every time. Fixing the source is almost always cheaper.

Vulnerability age distribution

Group open findings into age buckets, for example 0–30, 31–60, 61–90, 91–180 and over 180 days, and show the count in each bucket by tier.

Averages hide the long tail. An age distribution shows it directly. Findings older than 180 days are often end-of-life systems, forgotten assets or unresolved ownership disputes. Each of those needs a decision, whether that's remediation, an exception with an expiry date, or decommissioning.

Risk trend

Leadership eventually asks, "Are we getting better?" A risk trend answers that with one line on a chart.

Keep it simple and stable. One practical option is a weighted count of open findings, where each finding is weighted by tier. Another is the count of open high-tier findings on internet-facing or critical assets. Document the formula and don't change it casually, because a changed formula breaks the trend.

How do you present vulnerability metrics to different audiences?

The same data should be cut differently for each audience.

Executives and the board

Show three to five numbers with trends, in plain language:

• Open known-exploited vulnerabilities on internet-facing systems
• SLA compliance for the top two tiers
• Scan coverage
• Risk trend over the last four quarters
• Accepted risks, with the business owner and expiry date for each

Explain what changed and why. Executives need context and decisions, not a data dump.

IT teams and system owners

Operational detail works best here, and weekly is often better than monthly. Give each team its own view: findings due soon, findings overdue, oldest open items and any recurring findings with likely causes. Keep it to their assets so it's actionable.

The security team

The security team needs everything, including the diagnostic measures that other audiences don't: detection lag, failed authentication rates, scanner plugin currency and inventory gaps.

Auditors and compliance

Auditors usually want evidence of process rather than trends. Be ready to show scan coverage, adherence to your remediation policy, the exception register with approvals and expiry dates, and proof of verification scans.

How do you get started with vulnerability metrics?

You need four data sources for most of these metrics:

1. An asset inventory with owner, criticality and internet exposure for each asset
2. Scanner or agent data with first-detected and last-detected dates per finding
3. Ticket or change records showing when work was done
4. The KEV catalog, which CISA publishes as a free feed

Don't try to launch all eight metrics at once. Start with scan coverage, MTTR by tier and open KEV findings. Those three will expose the biggest gaps, and you can add the rest as data quality improves.

Frequently asked questions

What is a good mean time to remediate?

It depends on the tier and on the SLAs you've set. Compare MTTR against your own targets and your own trend rather than chasing industry figures, which often use different definitions and populations.

Should we report mean or median time to remediate?

Report both where you can. The median shows typical performance, while the mean reveals the drag from long-running outliers. A big gap between them tells you the long tail needs attention.

How often should vulnerability metrics be reported?

Weekly for the teams doing the work, monthly for security and IT leadership, and quarterly for executives or the board. Keep definitions identical across all three so the numbers reconcile.

Why did our vulnerability count go up after we improved scanning?

Because you can now see more. Broader coverage and authenticated scans reveal findings that were always there. That's one of the main reasons raw counts make poor headline metrics.

Key takeaways

• Measure speed and completeness of risk reduction, not the volume of findings.
• Break every time-based metric down by risk tier, and pair means with medians.
• Treat scan coverage, especially authenticated coverage, as the foundation for every other number.
• Track known-exploited vulnerabilities separately, with a goal of zero open on exposed systems.
• Tailor the view to the audience, but keep one set of definitions behind all of it.