Vulnerability SLAs: What They Are and How to Set Them

Vulnerability management without SLAs is reactive firefighting. With SLAs in place, it becomes structured risk reduction with clear priorities and someone accountable for each miss.

What a Vulnerability SLA Actually Is

A vulnerability SLA is a predetermined timeframe within which a security vulnerability must be remediated. Timelines are set by severity:

• Critical: 24 hours. Patch if you can, isolate or disable if you can't.
• High: 30 days.
• Medium: 60 days.
• Low: 90 days.

This tiered structure lets a team focus on the most dangerous issues first without letting lower-priority vulnerabilities quietly pile up and go unaddressed.

Why Each Timeline Is Set Where It Is

Critical, 24 hours. Critical vulnerabilities can hand an attacker full control of a system, remote code execution, or direct access to sensitive data. Once a critical vulnerability is disclosed, attackers start scanning for unpatched systems within hours, sometimes before the vendor has even confirmed it. The 2017 WannaCry ransomware attack is the textbook case: Microsoft had released a patch for the underlying Windows vulnerability (MS17-010) two months before the attack, but many organizations hadn't applied it. WannaCry infected hundreds of thousands of machines, hit healthcare systems particularly hard, and caused more than $4 billion in damages. A 24-hour SLA would have made that someone else's problem.

High, 30 days. High-risk vulnerabilities could enable unauthorized access to non-critical systems or data leakage under specific conditions. Thirty days gives a team room to test a fix properly without leaving the exposure open indefinitely.

Medium, 60 days. Medium-risk issues, like certain misconfigurations or outdated software versions not directly exposed externally, get scheduled behind the more urgent work without falling off the list entirely.

Low, 90 days. Minor issues, like small configuration gaps or non-critical software updates, still get fixed. They just don't justify pulling a team off something more pressing to do it.

Setting SLAs for Your Organization

Lifting these tiers wholesale onto your environment is a reasonable starting point, but the timelines should be checked against your own risk profile:

1. Assess your risk tolerance. A critical vulnerability in a system that handles customer payments warrants a faster response than the same severity rating on an internal reporting tool. Industry (healthcare, finance) and your current security capacity (headcount, tooling, automation) both factor into what's realistic.
2. Define severity clearly. Write down, in your own environment's terms, what separates critical from high from medium from low. Vague definitions are how SLAs become guidelines instead of commitments.
3. Automate where you can. Automated scanning and patch deployment are what keep an SLA achievable instead of aspirational, especially for the medium and low tiers that would otherwise get deprioritized indefinitely.
4. Build in a testing step for anything non-trivial. Rushing a high-severity patch to make a deadline can cause the outage you were trying to avoid. A staging pass before production deployment keeps "fast" from becoming "sloppy."
5. Review and adjust. After a major vulnerability event, look at how your SLAs actually held up. Threat landscapes shift, and a tier that made sense a year ago might need tightening now.

What People Get Wrong About SLAs

• "SLAs are unrealistic." You can't fix everything instantly, which is exactly the point. SLAs give you a framework for sequencing the work instead of reacting to whatever is loudest.
• "Low-risk vulnerabilities aren't worth an SLA." Leaving them open indefinitely is how a low-risk item becomes the missing piece of an attacker's chain. An SLA just means it gets handled on a slower, defensible clock.
• "SLAs only matter to the security team." They benefit the whole organization: fewer incidents, cleaner audits, and a smaller attack surface overall.

Why Compliance Frameworks Care

Some frameworks set actual remediation windows: PCI-DSS v4.0 requires critical patches within one month. Others, like HIPAA, require timely remediation without specifying a fixed deadline. GDPR governs breach notification timing, not patch timelines. None of them accept "we try to patch things" as an answer during an audit. A documented SLA, with a record of hits and misses, is the evidence that holds up.

The Cost of Skipping This

Missing SLAs isn't just a scheduling problem. Delays on critical vulnerabilities leave systems exposed to exactly the kind of exploitation an SLA exists to prevent, and a pattern of misses reads as a control gap on your next assessment. Treat a missed SLA as a signal to investigate why, not something to quietly let slide.

If you don't have SLA tiers in place yet, start simple: four severity levels, realistic timelines, and someone accountable for each miss.