Measuring Mean Time to Remediate Instead of Counting Open CVEs

Open vulnerability counts are the most common metric in vulnerability management, and one of the least informative.

They're easy to produce. Every scanner reports them. They fit on a slide. They also move for reasons that have nothing to do with how well the organization is fixing things.

Why raw totals mislead

Consider what makes the open count rise:

• Adding a new scanner or expanding coverage
• A large batch of new CVEs published against widely used software
• Better asset discovery finding systems that were already there
• A scanner update that changes how findings are counted

And what makes it fall:

• Actually fixing vulnerabilities
• Decommissioning systems
• Reducing scan coverage, deliberately or accidentally
• Deduplication changes

A program that improves coverage can look worse. A program that loses visibility can look better. That's backwards.

Totals also treat every finding equally. Ten thousand low-risk findings on test systems look the same as ten thousand exploited vulnerabilities on internet-facing servers.

What to measure instead

The question that matters is: when a vulnerability that matters appears, how quickly and reliably do we fix it?

Mean and median time to remediate

Time to remediate measures the interval from detection to verified fix. Report it by priority tier, because averaging P1 and P4 findings together hides everything useful.

Report the median alongside the mean. A handful of very old findings can drag the mean up; the median shows typical performance. Percentiles, such as the 90th, show how bad the slow cases get.

Define "detected" and "fixed" carefully. Detection should be when the finding first appeared. Fixed should mean verified by a rescan or inventory check, not when a ticket was closed.

Remediation within SLA

What share of findings in each tier were fixed within the target timeline? This connects remediation speed to the commitments the organization has made.

Aging

How many open findings in each tier are older than their SLA, and how old is the oldest? Aging shows backlog risk that averages can hide. A team with a good median but a long tail of very old critical findings has a problem worth seeing.

Reopen rate

How often do closed findings come back? A high reopen rate suggests fixes that don't hold, such as patched hosts that get reimaged from an old template, or dependency fixes that never reached production.

Exceptions

How many findings are under exception, by tier, and how many exceptions are past expiry? A program can look fast by moving hard cases into exceptions. Tracking them keeps that honest.

Tie metrics to prioritization

Remediation metrics only mean something if priority is meaningful. If most findings are classified as critical, time-to-remediate for "critical" becomes a measure of overall throughput, not risk response.

Use a risk-based model that accounts for exploitation, exposure, and asset criticality. Then the P1 metric genuinely reflects how quickly you respond to the vulnerabilities most likely to cause harm.

Break it down by stage

Overall time to remediate tells you whether you're improving. Stage-level timing tells you where to focus:

• Detection to assignment
• Assignment to fix ready
• Fix ready to deployed
• Deployed to verified

If most of the time sits in assignment, the problem is ownership data, not patching. If it sits between fix-ready and deployed, release processes may be the constraint.

Break it down by team

Team-level metrics help identify where support is needed. Use them carefully. The goal is to find bottlenecks, not to shame teams that own the oldest, hardest systems. Context matters, and some teams carry far more legacy risk than others.

Keep counts, but in their place

Totals aren't useless. Trends in open findings by tier can show the overall shape of exposure. They just shouldn't be the headline measure of program performance.

What good looks like

A healthy program shows steady or falling time to remediate for high-priority tiers, high SLA compliance, a short and shrinking aging tail, low reopen rates, and exceptions that close. Those numbers describe a team that fixes what matters, quickly, and makes the fixes stick.