Vulnerability Remediation SLAs: Why They Keep Slipping and How to Fix Them

Key Takeaways

• Most vulnerability remediation SLAs are missed. One study found 60% of organizations with formal SLAs miss their critical remediation target more than half the time.
• CVSS alone is a weak prioritization signal. Only about 4% of vulnerabilities scored above 7.0 are ever exploited in the wild.
• Exposure-based SLAs (asset criticality plus exploitability) close more real risk than severity-based SLAs.
• Remediation fatigue is a design problem, not a discipline problem. Teams burn out chasing volume instead of exposure.
• Boards and cyber insurers now expect documented SLA performance, not just a policy on file.

A vulnerability remediation SLA looks simple on paper: patch Critical in 30 days, High in 60. In practice, most programs miss that target more than half the time, according to a 2026 practitioner analysis of risk-based patching data. The gap between the policy and what actually gets fixed is where most of the real risk sits.

Why Do Vulnerability SLA Targets Keep Getting Missed?

The honest answer is that most SLAs were never built to be met. They were built to look good in a policy document.

Here’s the pattern that shows up again and again:

• The vulnerability backlog outpaces the team. Large enterprises now carry backlogs where 66% have more than 100,000 open findings, with critical flaws sitting unpatched for an average of 252 days, according to recent vulnerability management research.
• CVSS gets treated as the whole story. CVSS measures theoretical severity in isolation. It doesn’t factor in whether a flaw is being actively exploited or what it actually touches in your environment.
• Scanner findings pile up faster than context gets added. A scan can return thousands of “Critical” items in an afternoon. Sorting which ones are actually dangerous takes people, not another tool.
• Remediation fatigue sets in. Teams patch 100 items and watch the backlog grow by 500 the next month. That’s not a motivation problem. It’s a math problem, and 76% of cybersecurity professionals report burnout or cyber fatigue at least occasionally because of it.

The Cost of Missing the Target

This isn’t just an internal metrics issue. Attackers move fast. The MOVEit Transfer vulnerability was exploited within 48 hours of public disclosure in 2024, hitting more than 2,700 organizations and exposing data belonging to 93 million people. A patch existed. Most affected organizations just hadn’t deployed it yet.

That’s the real cost of a missed SLA. Not a red cell on a dashboard, but a window an attacker walks through, and one that shows up in the numbers: IBM’s Cost of a Data Breach Report puts the average breach at $4.88 million.

How to Set Exposure SLAs by Asset Criticality

Severity-only SLAs treat a forgotten dev server and a production payment system the same way if they share a CVSS score. That’s the core flaw. Two vulnerabilities can carry identical CVSS ratings and pose completely different levels of risk depending on what they touch.

A better SLA model layers three things on top of the raw score.

1. Start With Asset Criticality, Not Just CVE Severity

Before you set a deadline, map the asset. Ask what business function it supports, what data flows through it, and what happens if it’s compromised. A vulnerable print server and a vulnerable payment processing node might carry the same score. Their remediation urgency should not be the same.

2. Layer in Exploitability

CVSS tells you how bad a flaw could be. It doesn’t tell you whether anyone is actually using it. Pairing CVSS with real-world exploit signals, and checking new findings against CISA’s Known Exploited Vulnerabilities catalog, gives a far sharper picture of what to fix first. CISA’s own guidance, most recently reinforced under Binding Operational Directive 26-04, tells federal agencies to prioritize the vulnerabilities with confirmed exploitation on internet-facing systems ahead of everything else. Most private organizations would benefit from the same discipline. This is also where exposure management earns its keep over plain vulnerability scanning, a distinction we broke down in Exposure Management vs. Vulnerability Management.

3. Map Attack Paths, Not Just Individual Findings

A single low-severity misconfiguration rarely causes a breach on its own. A chain of three or four smaller issues that connects an exposed endpoint to a privileged account often does. Reviewing attack paths, not just isolated scanner findings, is how teams catch the combinations that matter.

A workable exposure SLA framework might look like this:

• Confirmed exploited, internet-facing, high-criticality asset: 24 to 72 hours
• High severity, exploitable, business-critical asset: 7 to 14 days
• High severity, no known exploit, lower-criticality asset: 30 days
• Medium and low severity, standard assets: 60 to 90 days, reviewed on a regular cadence

These windows echo what underwriters and auditors already expect. Cyber insurers commonly ask for critical vulnerabilities remediated within 7 to 15 days on exposed systems, and ISO 27001 and NIS2 auditors will ask to see both the SLA and the evidence that it’s being met.

Turning SLA Performance Into Governance Evidence

Setting the SLA is the easy part. Proving it works, quarter after quarter, is what turns a spreadsheet into a governance program.

Connect SLAs to the Risk Register

A risk register with 300 open items tells a board nothing useful on its own. What matters is which five or six of those items carry real exposure this quarter, and whether remediation is tracking against the SLA tied to each one. When SLA data feeds the risk register directly, risk acceptance decisions stop being guesswork. If a vulnerability can’t be patched within its window, whoever accepts that risk should be named, and the decision should have an expiration date, not sit open indefinitely.

Align to NIST CSF, Not Just Internal Policy

Tying SLA tiers to the NIST Cybersecurity Framework gives auditors and regulators a shared reference point instead of a homegrown scale nobody outside the security team recognizes. It also makes CTEM governance easier to operationalize, since Continuous Threat Exposure Management depends on the same loop of scoping, discovery, prioritization, validation, and mobilization we cover in What Is CTEM? The CISO Guide.

Make SLA Data Board Reportable

Boards don’t need scanner output. They need a small number of numbers that tell a clear story:

• Percentage of critical vulnerabilities still open past 30 days (industry guidance built on the NACD’s Director’s Handbook on Cyber-Risk Oversight points to under 5% as a healthy target)
• SLA compliance rate by severity tier, tracked quarter over quarter
• Number of open risk acceptances and their expiration dates

Keep Cyber Insurance Renewals Clean

Underwriters ask the same core questions every renewal cycle: how often you scan, how fast critical patches go out, and whether you can prove it. A documented SLA with a remediation log, not a promise in a policy binder, is what actually satisfies that ask and can help avoid a denied claim after a breach traced back to a known, unpatched flaw.

FAQs

Conclusion

A vulnerability remediation SLA only means something if it survives contact with a real backlog. That takes moving past CVSS-only tiers, adding asset criticality and exploitability into the mix, and treating SLA data as governance evidence instead of a compliance checkbox. Get that loop working, and the next board update or insurance renewal stops being a scramble.