Vulnerability Remediation SLAs: How to Set Them

What Are Vulnerability Remediation SLAs?

A vulnerability remediation SLA (service level agreement) defines how many days an organization allows for fixing a vulnerability after detection, based on the finding's severity or risk tier. SLAs translate risk tolerance into measurable deadlines that remediation teams can plan around. Without defined SLAs, remediation happens on an ad hoc basis, with critical findings sometimes waiting weeks while low-severity issues get fixed quickly because they happen to be easy.

SLAs are the contract between the security team that identifies vulnerabilities and the operational teams that fix them. They set expectations, create accountability, and provide the benchmarks needed to measure program effectiveness. A vulnerability management program without defined SLAs lacks the structure to answer basic questions: Are we fixing things fast enough? Which teams are falling behind? Where are the process bottlenecks?

How Should SLA Timelines Be Structured?

Severity-Based SLA Tiers

The most common SLA structure assigns remediation windows based on CVSS severity tiers. A typical starting framework looks like: Critical (CVSS 9.0-10.0) within 15 days, High (CVSS 7.0-8.9) within 30 days, Medium (CVSS 4.0-6.9) within 90 days, and Low (CVSS 0.1-3.9) within 180 days. These numbers vary by organization. Financial services and healthcare organizations often set shorter windows due to regulatory pressure and the sensitivity of their data. Companies operating under PCI DSS typically target 30-day SLAs for critical and high findings, while FedRAMP authorization requires specific remediation timelines by severity level.

Why Severity Alone Falls Short

Severity-only SLAs treat all critical vulnerabilities as equally urgent, which misses important context. A critical vulnerability on an isolated test server does not carry the same risk as the same vulnerability on an internet-facing payment processing system. Two findings with identical CVSS scores can represent very different levels of actual business risk, yet a severity-only SLA assigns them identical remediation deadlines. This creates situations where teams spend equal effort on a CVSS 9.8 affecting a development sandbox and a CVSS 9.8 affecting a production customer database, even though the latter represents far greater organizational risk.

Establishing Baselines Before Setting Targets

Organizations implementing SLAs for the first time should start by measuring their current remediation performance without SLAs to establish a baseline. This baseline reveals the actual time it takes to remediate findings at each severity level, which informs realistic initial SLA targets. Setting SLAs without baseline data is guesswork. Setting them with data is engineering. The baseline also serves as the benchmark against which improvement is measured after SLAs are introduced. If the organization currently averages 45 days to remediate critical findings, setting a 7-day SLA guarantees failure. Starting at 30 days and working toward 15 days over two quarters is achievable and builds credibility.

What Is Risk-Based SLA Differentiation?

Adding Context Beyond CVSS

Risk-based SLAs add layers of context that differentiate urgency within severity tiers. A critical vulnerability listed in the CISA KEV catalog as actively exploited warrants a shorter SLA than a critical vulnerability with no known exploitation. A high-severity vulnerability on an internet-facing server handling customer payments warrants a shorter SLA than the same severity on an internal development workstation. Building these contextual distinctions into the SLA framework directs the most urgent remediation effort at the highest-risk findings.

Tiered Risk Models

Implementing risk-based SLAs requires the prioritization model to output a risk tier that maps to a specific SLA, rather than mapping SLAs directly from CVSS scores. For example: Tier 1 (KEV-listed or high-EPSS plus critical/high CVSS on high-criticality assets) receives a 48-hour or 7-day SLA. Tier 2 (critical/high CVSS on standard assets without exploitation indicators) receives a 14 to 30-day SLA. Tier 3 (medium CVSS) receives a 90-day SLA. This tiered model produces SLA assignments that reflect actual risk rather than theoretical severity. The prioritization model feeds directly into the ticketing system, so each ticket carries its SLA deadline calculated from detection date and risk tier.

How Should SLAs Be Communicated Across Teams?

Making SLAs Visible and Understood

SLAs are only effective if the teams responsible for remediation understand and accept them. Publishing SLA definitions in a policy document that nobody reads is insufficient. Security teams should communicate SLA expectations through onboarding sessions for new team members, integration into ticketing system workflows where SLA deadlines are visible on each ticket, regular reporting that shows SLA compliance by team, and cross-functional reviews where SLA performance is discussed alongside remediation blockers. When a team lead can see that 3 of 12 critical tickets are within 48 hours of SLA expiration, that visibility drives action in a way that quarterly compliance reports cannot.

Diagnosing Low Compliance

When SLA compliance drops, the response should be diagnostic rather than punitive. Low compliance may indicate that SLAs are unrealistic for the organization's change management process, that remediation teams lack capacity, that ownership routing is broken, or that findings include too many false positives. Diagnosing the root cause and adjusting either the SLA structure or the underlying process is more productive than escalating missed SLAs without addressing why they were missed. One common pattern is that SLAs are met for operating system patches but consistently missed for application vulnerabilities because the application team lacks a staging environment for testing.

Waivers and Formal Exceptions

SLA waivers and exceptions should be governed by a formal process that requires documented justification, compensating controls, and time-limited approval. Without formal exception handling, SLA non-compliance becomes normalized and the SLA framework loses its effectiveness as an accountability mechanism. With formal exceptions, SLAs remain the standard while accommodating legitimate situations where the standard cannot be met. Common justifiable exceptions include waiting for a vendor patch release, scheduling a maintenance window on operational technology, or completing regression testing for a business-critical application.

Adapting SLAs to Different Environments

Cloud vs. On-Premises

SLA structures should accommodate different technology environments. Cloud-native environments with immutable infrastructure and CI/CD deployment pipelines can remediate faster than traditional on-premises environments that require manual patching and maintenance windows. Setting uniform SLAs across both environments either under-serves the cloud (where faster remediation is feasible) or creates unachievable targets for on-premises (where operational constraints are real). Environment-specific SLA tiers acknowledge these differences while maintaining consistent accountability. A cloud workload might carry a 7-day critical SLA while an on-premises legacy system gets 21 days for the same severity.

Regulated Industries

Organizations in regulated industries must align SLAs with compliance framework requirements. PCI DSS expects timely remediation of critical and high vulnerabilities, typically within 30 days. FedRAMP specifies remediation timelines as part of continuous monitoring requirements. HIPAA does not prescribe specific timelines but requires organizations to demonstrate reasonable risk management, which auditors evaluate partly through remediation speed. SLAs that meet or exceed regulatory expectations provide compliance evidence while also reducing actual risk.

Reviewing and Improving SLAs Over Time

Review Cadence

SLA review cadence should align with the organization's planning cycles. Annual SLA reviews coincide with security program planning, budgeting, and staffing decisions. Quarterly reviews provide more frequent adjustment opportunities for organizations actively improving their remediation processes. Each review should examine current compliance rates, identify the root causes of non-compliance, evaluate whether SLAs need adjustment, and document any changes with rationale. This documented evolution demonstrates the continuous improvement that compliance frameworks expect.

Incentive Alignment Across Teams

When the security team sets SLAs but remediation teams have no stake in meeting them, SLAs become the security team's problem rather than a shared organizational commitment. Including vulnerability SLA compliance as a metric in remediation team performance evaluations, operational reviews, and team objectives creates shared ownership of the outcome. Teams that are measured on SLA compliance prioritize vulnerability remediation alongside their other operational responsibilities. Some organizations include SLA compliance in quarterly business reviews alongside uptime and incident metrics, treating vulnerability remediation as a core operational responsibility rather than a security add-on.

How Do SLAs Connect to Program Maturity?

Measuring SLA Effectiveness

SLA compliance is one of the most telling metrics in vulnerability management reporting. Tracking the percentage of findings remediated within their SLA window, broken out by severity tier and by team, reveals where the program is working and where it is not. If critical SLA compliance is at 95% but high-severity compliance is at 60%, the program is doing well on its top priorities but struggling with volume at the next tier. This granularity guides investment decisions: does the team need more remediation capacity, faster testing environments, or better ticket routing?

Maturity Progression

The relationship between SLAs and vulnerability management maturity is reciprocal. Mature programs set and meet ambitious SLAs because they have the automation, ownership clarity, and operational capacity to do so. Immature programs set aspirational SLAs they cannot meet, creating a cycle of non-compliance that undermines confidence in the program. Starting with achievable SLAs and tightening them as the program matures is a more effective maturity pathway than starting with aggressive targets that produce persistent failure.

Demonstrating consistent SLA compliance, even at initially modest targets, builds organizational confidence that enables the program to pursue more aggressive timelines in subsequent improvement cycles. A program that meets 90% of its 30-day critical SLA has earned the credibility to propose moving to 21 days. A program that consistently misses its 7-day target has not. This progression, from achievable to ambitious, is how SLAs drive genuine improvement rather than generating compliance reports that nobody trusts.