How to Set Effective Vulnerability Remediation SLAs by Severity and Business Impact

TL;DR

Critical vulnerabilities should be fixed within 24–72 hours. High-severity within 30 days. Medium-severity in 60 days. Low-severity in 90 days. Severity alone isn’t enough — factor in exploitability, asset value, and business impact. Most organizations take 60–150 days to patch critical vulnerabilities. Attackers exploit critical flaws in as little as 5 days after public disclosure. Good SLAs need clear ownership, automation, and regular reviews — not just deadlines on paper.

Key Takeaways

• A vulnerability remediation SLA is a formal policy that sets deadlines for fixing security gaps based on risk.
• CVSS scores are a starting point — but real-world exploitability and asset criticality matter more.
• 60% of breaches in 2024 were linked to a known, unpatched vulnerability.
• The average cost of a data breach hit $4.88 million in 2024 (IBM).
• Automating SLA tracking keeps remediation on schedule without burning out your team.

Introduction

In 2024, the MOVEit Transfer vulnerability was exploited within 48 hours of public disclosure — affecting over 2,700 organizations and exposing data of 93 million people. Patches were available. Most organizations just didn’t deploy them in time.

That’s the real cost of weak vulnerability remediation SLAs. Without clear timelines tied to severity and business risk, critical patches get buried in backlogs and attackers move faster than your team can respond.

This guide walks you through how to set SLAs that actually work.

What Are Vulnerability Remediation SLAs?

A Vulnerability Remediation SLA (Service Level Agreement) is a policy that defines how fast your team must fix a security vulnerability based on how serious it is.

Think of it as a fire response plan. Not every fire needs the same response time. A grease fire in the kitchen needs immediate action. A small ember on the patio can wait a few minutes. Vulnerabilities work the same way.

SLAs are typically built around CVSS scores — a 0–10 scale that measures how severe a vulnerability is.

But CVSS scores don’t tell the full story. A “medium” vulnerability on a public-facing payment server is far more dangerous than a “critical” one on an isolated test machine. That’s why business impact must factor into how you set these timelines.

What Else Goes Into an SLA Beyond Severity?

Exploitability — Is there a known exploit in the wild? The EPSS (Exploit Prediction Scoring System) estimates the probability a vulnerability will be exploited within the next 30 days based on real-world threat intelligence. A medium CVSS score with active exploitation in the wild deserves a critical-level SLA.

Asset criticality — A vulnerability on a crown jewel system (your core database, payment processor, or customer-facing app) gets a faster deadline than the same flaw on a dev environment.

Business impact — Does this system handle regulated data (PCI, HIPAA)? Does it affect availability of services customers depend on? Higher stakes = tighter SLA.

Compliance requirements — NIST, PCI-DSS, HIPAA, and CISA’s KEV (Known Exploited Vulnerabilities) catalog each have their own remediation mandates. Your SLAs must meet or exceed these.

How to Set Effective Vulnerability Remediation SLAs

Setting SLAs isn’t just about picking deadlines. It’s about making sure those deadlines reflect actual risk — and that your team can realistically meet them.

1. Know Your Risk Tolerance

Before writing a single SLA, ask: what level of risk is your organization willing to accept? A healthcare company handling patient records has near-zero tolerance for data exposure. A startup with a dev-only environment may accept more risk in exchange for speed.

Risk tolerance shapes everything — your timelines, your escalation paths, and where you spend remediation effort.

2. Classify Vulnerabilities the Right Way

Don’t rely on scanner severity alone. Scanners default to CVSS, which doesn’t account for whether an exploit exists in the wild. Use threat intelligence (like Mandiant or CISA’s KEV catalog) to reclassify findings. When you use threat intelligence instead of raw CVSS, you often go from 1,000 “critical” items to 6–20 truly urgent ones — a number your team can actually tackle.

3. Tie SLAs to Asset Value

Group assets by business criticality: Tier 1 (crown jewels), Tier 2 (important but not mission-critical), Tier 3 (low-value or isolated systems). Apply tighter SLAs to Tier 1, regardless of CVSS score. A critical vulnerability on a Tier 3 asset may get 30 days. The same flaw on a Tier 1 asset gets 24 hours.

4. Make Timelines Realistic

Overly aggressive SLAs lead to burnout, shortcuts, and incomplete fixes. If your team is consistently hitting 15% SLA compliance, the timeline isn’t realistic — not the team. Overly aggressive SLAs create burnout and incomplete fixes rather than improved security. Start with achievable goals and tighten them as your process matures.

5. Automate Tracking and Escalation

Manual SLA tracking across hundreds of vulnerabilities is nearly impossible to sustain.  Integrate your vulnerability scanner with your ITSM platform (like ServiceNow or Jira) to automatically create tickets, assign owners, and trigger alerts before deadlines are missed. Automation doesn’t replace judgment — it prevents critical vulnerabilities from falling through the cracks. 

6. Review and Update SLAs Regularly

The threat landscape shifts. New exploit techniques emerge. Compliance rules change. A quarterly review of your SLAs keeps them relevant and effective — not just a policy document nobody reads.

Steps to Set Up Vulnerability Remediation SLAs

Here’s a practical setup process you can follow from day one:

Step 1 — Identify critical assets. Map out which systems, apps, and data stores are most essential to your business. These are your Tier 1 assets and they set the foundation for all SLA decisions.

Step 2 — Run a risk assessment. For each asset tier, determine what a breach would cost — in dollars, compliance penalties, customer trust, and operations downtime. This tells you how fast each asset needs to be protected.

Step 3 — Define severity levels and timelines. Use CVSS as a baseline, but layer in exploitability data and asset criticality. Assign remediation deadlines for each combination.

Step 4 — Assign clear ownership. Every vulnerability needs a named owner — not a team, a person. Ambiguous ownership is where SLAs die. Security finds it, IT owns the patch, and management tracks compliance. Write this down.

Step 5 — Set up automated tracking. Use your vulnerability management tool to auto-assign SLA deadlines on discovery and send alerts at 75% of the deadline window. Don’t wait until something’s overdue to notice it.

Step 6 — Measure and improve. Track SLA compliance rates by severity tier, asset class, and team. Share reports with leadership monthly. Treat SLA misses as learning opportunities to refine processes, not blame sessions that discourage transparency.

Why Vulnerability Remediation SLAs Matter

Here’s what happens when SLAs are vague or missing:

• 60% of data breaches in 2024 were traced to a known, unpatched vulnerability.
• In 2024, attackers exploited critical vulnerabilities in as little as 5 days after public disclosure, with some high-profile exploits occurring within 48 hours (as seen with MOVEit Transfer).
• The average organization takes 60–150 days to patch — giving attackers a massive window.
• A data breach now costs an average of $4.88 million (IBM, 2024).
• In 2024, exploited vulnerabilities with patches available for over 30 days increased by 61% year over year.

SLAs create accountability. They move patching from “we’ll get to it” to “this must be done by Tuesday.” That shift alone can significantly shrink your attack surface.

Beyond risk reduction, SLAs also support compliance with frameworks like NIST SP 800-40, PCI DSS, and CISA KEV mandates. CISA requires federal agencies to patch known exploited vulnerabilities within two weeks — and most enterprise compliance standards align with this direction.

Challenges of Vulnerability Management SLAs

Even well-designed SLAs run into friction. Here are the most common challenges and how to address them:

Too many vulnerabilities, too little time. More than 40,000 CVEs were published in 2024, but fewer than 5% had active exploits in the wild. Not all vulnerabilities are urgent. Without smart prioritization (threat intel + asset criticality), teams get overwhelmed trying to fix everything at the same severity tier.

Business disruption fears.Over 80% of CIOs and CISOs report delaying patches to avoid disrupting operations. The fix is better testing environments and maintenance windows — not postponing patches indefinitely. A missed patch costs far more than a planned maintenance window.

Unclear ownership. When IT, security, and dev teams all point fingers at each other, nothing gets patched on time. SLAs must name owners, not just teams.

Incomplete visibility. Incomplete visibility. 80% of CISOs have discovered that patches they believed were deployed hadn’t actually updated all devices. Automated verification — not just deployment — is essential.

Legacy systems that can’t be patched. Some systems can’t accept patches without breaking functionality. For these, compensating controls (network segmentation, WAF rules, enhanced monitoring) should be documented in the SLA framework as accepted risk exceptions with defined review periods.

FAQs

Conclusion

Vulnerability remediation SLAs aren’t paperwork exercises. They’re how your security team decides what gets fixed, how fast, and who’s responsible — turning reactive firefighting into proactive risk management.. Without them, you’re leaving the decision to chance — and attackers are counting on that.