Remediation SLAs and MTTR: Measuring Vulnerability Management That Works

If you cannot answer "how fast do we fix what matters?", you cannot manage a vulnerability program — you are just generating reports. Two metrics turn vulnerability management from activity into accountability: the remediation SLA and MTTR. Here's how to define them, measure them honestly, and avoid the traps.

Why outcome metrics matter

The most common vulnerability metric — "number of open vulnerabilities" — is a vanity metric. It goes up and down with scanning scope and says nothing about whether you are actually getting safer. What leadership and auditors want to know is simpler: when something dangerous appears, how quickly do we fix it, and do we hit our own targets?

What is MTTR?

MTTR (Mean Time To Remediate) is the average time from when a vulnerability is detected to when it is remediated. It is the heartbeat of a remediation program. The critical detail is segmentation: a single blended MTTR across all findings is almost meaningless, because fixing a low-risk issue in 90 days and an actively exploited one in 90 days are wildly different outcomes. Always report MTTR by risk tier.

What is a remediation SLA?

A remediation SLA is a documented policy that sets the maximum acceptable time to remediate, by risk tier. It is the target; MTTR is the measurement against it. A good SLA is tied to risk, not raw CVSS severity — an actively exploited vulnerability deserves a tighter deadline than a theoretically severe one nobody is touching.

Setting risk-based SLAs

Avoid a one-size-fits-all deadline. A practical tiering:

• Actively exploited (in CISA KEV) or confirmed toxic combination → 24-72 hours.
• High EPSS or internet-facing critical asset → ~7 days.
• High severity, low likelihood → ~30 days.
• Medium / low risk → next maintenance cycle.

These mirror the logic of risk-based vulnerability management: the deadline follows the risk.

Measuring MTTR properly

• Pick the right start point — detection or disclosure date — and apply it consistently.
• Segment by tier. MTTR for KEV / actively exploited items is the number that matters most.
• Track SLA attainment (the percentage of items fixed within target), not just the average.
• Watch the aging backlog — items breaching SLA are your real exposure.

Metrics that actually matter (beyond MTTR)

• Risk reduction over time, not raw closure counts.
• SLA attainment % per tier.
• Coverage of KEV and high-EPSS items.
• Reopen / recurrence rate — fixes that did not hold.

Common pitfalls

• Blended averages that hide slow remediation of the riskiest items.
• Measuring activity, not outcomes (tickets closed vs risk removed).
• Gaming the metric by closing easy, low-risk findings to flatter the average.

How priorIQ.ai helps

priorIQ.ai tracks closure across your reconciled inventory, computes MTTR and SLA attainment by risk tier, and exports the reports that satisfy management reviews and ISO 27001 audits. Request a demo.

Frequently asked questions

What is a good MTTR target? It depends entirely on tier. Hours for actively exploited issues; weeks for low-risk ones. A single target across everything is a red flag.

MTTR vs MTTD? MTTD (mean time to detect) measures how fast you find issues; MTTR measures how fast you fix them. Both matter.

SLA or MTTR — which do I report? Both: the SLA is the promise, MTTR and SLA-attainment are how you prove you are keeping it.