Vulnerability Remediation SLAs: How to Set Them by Severity and Risk

A vulnerability remediation SLA is the maximum time your program allows between finding a vulnerability and fixing it, set per risk tier. To set one, define tiers by real risk (severity plus exploitation, exposure and reachability), give each tier a deadline your teams can actually meet, start the clock at detection, and write down how exceptions work. Then measure SLA compliance per team and escalate before a deadline passes, not after.

This guide covers what a remediation SLA is, what PCI DSS and CISA require, example timelines you can adapt, and the mistakes that make SLAs look healthy while risk stays open.

What is a vulnerability remediation SLA?

A vulnerability remediation SLA is an internal commitment: findings in tier X will be fixed, mitigated or formally accepted within Y days of being found. It's called a service-level agreement because it works like one. Security sets the target, engineering teams own delivery, and both sides report against it.

Every SLA has four parts:

• Tiers: the buckets findings are sorted into (for example Critical, High, Medium, Low, or Tier 1 to 4).
• Deadlines: the number of days allowed per tier.
• A clock: when it starts (detection, triage or patch release) and when it stops (fix deployed, or exception approved).
• An exception path: who can extend or waive a deadline, for how long, and with what compensating control.

Why remediation SLAs matter

SLA compliance is the number boards, auditors and customers ask security leaders about, and it's often what a Director of Security is measured on.

The point of an SLA is not the deadline itself. The point is that it turns "we should fix this" into a commitment with an owner and a date. Without one, a finding's urgency depends on who is shouting about it this week.

SLAs also make trade-offs visible. If a team breaches SLA every month, the conversation moves from "why is security nagging us" to "this team needs more capacity, or fewer, better findings."

What the standards require

Most frameworks don't hand you a full SLA table. They set a few hard deadlines and expect you to define the rest through a documented risk ranking. Two are worth knowing.

PCI DSS

PCI DSS v4.0.1 Requirement 6.3.3 requires patches for critical vulnerabilities to be installed within one month of release. Other applicable patches follow timeframes your organization sets through its risk ranking process (Requirement 6.3.1). The standard is published in the PCI Security Standards Council document library. Note that this clock starts at patch release, not at the moment you detect the vulnerability.

CISA BOD 26-04

For US federal civilian agencies, CISA's Binding Operational Directive 26-04, issued June 10, 2026, replaced the fixed deadlines of BOD 19-02 and BOD 22-01 with risk-based timelines. Urgency is set by four factors:

• Asset exposure: whether the vulnerable asset is publicly exposed.
• KEV status: whether the CVE is in CISA's Known Exploited Vulnerabilities catalog.
• Exploit automation: whether every step of exploitation can be automated.
• Technical impact: whether an attacker gains partial or total control.

Two details are useful for any program. The clock starts when the vulnerability is added to KEV or when the agency identifies it on an asset, whichever comes first. And if a vulnerability is added to KEV after you've already found it, the deadline shortens.

BOD 26-04 doesn't apply to private companies unless a contract requires it. It's still the clearest public model for risk-based SLAs.

How to set vulnerability remediation SLAs

1. Tier by risk, not by severity label

A CVSS Critical in a test fixture and a CVSS Medium in an internet-facing payment API should not share a deadline. Build tiers from the same factors BOD 26-04 uses, plus one it can't see: whether the vulnerable code is reachable in your deployment.

A practical tier rule:

• Tier 1: known exploited (KEV or exploit evidence) and reachable on an exposed asset.
• Tier 2: high impact and reachable on an exposed asset, or known exploited on an internal asset.
• Tier 3: high impact and reachable on an internal asset, or medium impact on an exposed one.
• Tier 4: everything else that's real and reachable.

Findings that aren't reachable or aren't deployed get recorded with evidence and re-checked when the code changes. They don't need an SLA, because there's nothing to fix yet.

2. Pick deadlines your teams can meet

An SLA that every team breaches is a suggestion. Start from your current median time to remediate per tier, then set targets that are tighter but achievable. Shorten them each quarter as the process improves.

Here is an example policy to adapt. These numbers are a starting point, not an industry benchmark:

If you handle card data, check that your Tier 1 and Tier 2 deadlines also satisfy the PCI DSS one-month rule for critical patches.

3. Start the clock at detection

Start the SLA clock when a scanner first reports the finding, not when someone triages it or files a ticket. Starting late hides the slowest queue, which is usually triage. If a finding's tier changes, for example because it lands on KEV, recalculate the deadline from the original detection date.

4. Define what stops the clock

Decide what counts as "remediated." A merged and deployed fix stops the clock. So does an approved mitigation with a documented compensating control. A closed ticket, a suppressed alert or a "won't fix" does not, unless it went through the exception path.

5. Write down the exception process

Exceptions are normal. Some fixes need a vendor patch that doesn't exist yet, or a migration that takes a quarter. Make the process explicit:

• Who can approve an exception for each tier.
• The maximum length of an exception before it must be reviewed.
• The compensating control required (WAF rule, feature flag, network restriction).
• Where exceptions are recorded, so they show up in reporting.

6. Assign an owner to every finding

An SLA without an owner is a countdown nobody is watching. Route each finding to the person who owns the code, using commit history and CODEOWNERS, and check they have the capacity to take it on.

7. Escalate before the deadline, in the channel people read

Escalation should start well before the deadline, with the risk and the date stated. A Slack message to the owner on day two of a seven-day Tier 1 finding is worth more than a red cell on a dashboard on day eight.

8. Report SLA compliance per team

Report the percentage of findings fixed within SLA, by tier and by team, along with the number currently overdue. Track each team against its own trend, because teams with older code will start from a different place.

Common remediation SLA mistakes

• One deadline per CVSS band. It sends unreachable Criticals to the top and lets exposed Mediums sit.
• Counting suppressions as on time. Closing findings as "accepted risk" without the exception path makes compliance look great while exposure stays the same.
• Setting aspirational deadlines. If every team breaches, nobody takes the SLA seriously.
• Escalating only after breach. By then the deadline is gone and the conversation is about blame.
• Never revisiting the tiers. A finding's risk changes when it lands on KEV or when the code moves behind a public endpoint. The tier and deadline should change with it.

Remediation SLA checklist

• Tiers are defined by exploitation, exposure, impact and reachability, not CVSS alone.
• Each tier has a deadline, an escalation start and an exception approver.
• The clock starts at first detection.
• "Remediated" means a deployed fix or an approved mitigation.
• Exceptions have a maximum length and a compensating control.
• Every finding has a named owner.
• Escalation starts before the deadline, in Slack or email.
• Tiers are recalculated when KEV status or exposure changes.
• SLA compliance and overdue counts are reported per team and tier.
• Deadlines are reviewed each quarter.

How Nullify tracks and enforces remediation SLAs

Nullify's Security Program Management keeps one prioritized backlog across code vulnerabilities, leaked secrets, cloud misconfigurations, supply-chain risks and validated pentest findings. Each item is scored 0–100 on severity, exploitability, reachability and business impact, not raw CVSS, and actively exploited vulnerabilities that affect your stack move up automatically.

Owners come from CODEOWNERS, commit history and service metadata, and assignment accounts for each person's open PRs and tickets. Stalled security PRs and tickets are escalated through Slack with the risk and SLA stated, and the program reports MTTR, SLA compliance and per-team progress. See how it works on the security program management page.

Frequently asked questions

What is a typical vulnerability remediation SLA?

There is no single standard. Many programs give the highest-risk tier days to two weeks, high-risk findings two to four weeks, and lower tiers one to three months. PCI DSS requires critical patches within one month of release. Set your own deadlines from your current remediation times and tighten them over time.

Should remediation SLAs be based on CVSS?

CVSS alone is a weak basis, because it doesn't know whether a vulnerability is exploited, exposed or reachable in your environment. Use CVSS as one input for impact, and combine it with KEV status, exposure and reachability to set the tier. CISA's BOD 26-04 uses this kind of risk-based model.

When should the SLA clock start?

Start it at first detection, when a scanner first reports the finding. Starting at triage or ticket creation hides the time findings spend waiting in queues. PCI DSS measures its one-month rule from patch release, so track that date too if you're in scope.

What happens when a vulnerability misses its SLA?

It should go through a defined escalation and exception path: the owner and their lead are notified, and either the fix is prioritized or an exception is approved with a compensating control and an end date. Breaches should be reported per team so capacity problems become visible.

How do you measure SLA compliance?

Divide the number of findings remediated within their deadline by the total number remediated in the period, per tier and per team. Report the current count of overdue findings alongside it, because compliance only counts findings that were closed.