Vulnerability remediation SLAs typically run 15 days for critical severity, 30 days for high, 60 to 90 days for medium, and 90 to 180 days for low, based on CVSS or CVSS-plus-EPSS scoring and how exposed the asset is. The number every team misses: an internet-facing or actively exploited vulnerability needs a tighter clock than its base severity tier suggests, no matter what the CVSS score says on paper.
- Vulnerability remediation SLA in 2026: 15 days critical, 30 days high, 60-90 days medium, 90-180 days low.
- CISA's BOD 22-01 sets a 15-day patch deadline for known exploited vulnerabilities on federal networks.
- PCI DSS 4.0 Requirement 6.3.3 requires critical and high-risk vulnerabilities patched within 30 days.
- EPSS and confirmed exploit activity should override CVSS-only severity when the SLA clock starts.
- Brinqa combines CVSS, EPSS and asset criticality into one score to flag SLA breach risk before it happens.
Why this matters
An SLA that isn't tied to a real deadline is a suggestion, and auditors, regulators and your own security operations center treat suggestions differently than commitments. A vulnerability remediation SLA gives your team a number to be measured against and gives leadership a number to report on.
Most programs still set SLAs off CVSS base score alone, which is why so many "critical" backlogs sit at 200+ days past due. A platform like Brinqa is built around a different model: severity plus exploit likelihood plus asset context, so the SLA clock reflects actual risk instead of a static score assigned at CVE publication.
How do you set vulnerability remediation SLAs by severity
Start from a published external anchor, then adjust down for exposure and up for compensating controls. Here's the baseline most security teams converge on for 2026:
| Severity | Typical SLA | Basis |
|---|---|---|
| Critical | 15 days | CISA BOD 22-01 (Known Exploited Vulnerabilities catalog) |
| High | 30 days | PCI DSS 4.0, Requirement 6.3.3 |
| Medium | 60-90 days | Common industry practice, risk-based tiering |
| Low | 90-180 days | Common industry practice, often bundled into patch cycles |
This table is a starting point, not a ceiling. Regulated environments and internet-facing infrastructure should pull every tier tighter; internal, segmented, low-blast-radius systems can run the upper end of the range without raising audit flags.
Critical vulnerabilities: 15-day SLA
A 15-day SLA for critical severity is the tightest defensible number in 2026, and it's not arbitrary — it's the exact deadline CISA's Binding Operational Directive 22-01 imposes on federal civilian agencies for vulnerabilities added to the Known Exploited Vulnerabilities catalog. Private-sector teams that adopt the same 15-day window are matching the federal floor, not exceeding it. Verdict: use 15 days as your default critical SLA and shrink it further for anything internet-facing with a known exploit.
High severity: 30-day SLA
Thirty days for high severity lines up with PCI DSS 4.0 Requirement 6.3.3, which mandates that critical and high-risk vulnerabilities get patched within one month of identification. Any organization handling cardholder data is already contractually bound to this number, which makes it a sensible default even outside payment environments. Verdict: 30 days is the floor for compliance-bound programs, tighten to 15-20 days if the asset also touches sensitive data.
Medium severity: 60-to-90-day SLA
Medium severity SLAs vary more than critical and high because no single regulation pins down an exact number — most programs land somewhere in the 60-to-90-day range, often tied to the next scheduled patch cycle rather than an emergency push. This is where EPSS-based prioritization earns its keep: a medium-CVSS vulnerability with a high EPSS score can get pulled forward ahead of a nominally higher-severity finding that has zero exploitation activity. Verdict: 60-90 days is workable for most medium findings, but score against EPSS before you let anything sit for the full window.
Low severity: 90-to-180-day SLA
Low severity findings get the longest runway, typically 90 to 180 days, and in practice many programs simply fold them into standard maintenance patching instead of tracking a dedicated SLA at all. The risk with a 180-day window is backlog rot — low findings pile up, nobody revisits them, and the count becomes an audit finding of its own. Verdict: 90-180 days is fine as long as the backlog gets a quarterly review, not a one-time triage.
Why remediation timelines vary
Severity tier is the starting point, not the whole answer. These factors move the actual deadline up or down from the baseline:
- Asset criticality — a critical vulnerability on a domain controller gets a shorter clock than the same CVE on an isolated test box.
- Exploit availability — a CVE in the CISA KEV catalog or with a high EPSS score should never wait the full baseline window, regardless of CVSS.
- Internet exposure — externally facing assets compress every SLA tier; internal-only, segmented assets can run the upper bound.
- Compensating controls — a WAF rule or virtual patch can justify extending an SLA temporarily, but the underlying fix still needs a real deadline.
- Patch or fix availability — vendors without a patch yet require documented risk acceptance, not an SLA violation on the books.
- Regulatory mandate — PCI, HIPAA, SOC 2 and similar frameworks can force a shorter SLA than your internal policy would otherwise set.
“If your critical SLA is longer than the time it takes an exploit to weaponize, the SLA isn't protecting anything.”
What SLA should you set for a critical vulnerability with a public exploit?
A critical vulnerability with a confirmed public exploit should get a 7-to-10-day SLA, tighter than the standard 15-day critical baseline, because active exploitation changes the math entirely. CISA's own KEV catalog exists specifically to flag these cases for accelerated remediation.
Should the SLA clock start at scan date or disclosure date?
The SLA clock should start at detection date, not public disclosure date, because a vulnerability sitting undetected in your environment for weeks before a scan finds it doesn't get a grace period on top of that. Most audit frameworks, including PCI DSS, measure from when the organization identified the vulnerability, not when the CVE was published.
How strict should SLAs be for internet-facing assets?
Internet-facing assets should run 50% tighter than the internal baseline across every severity tier — a 15-day critical SLA becomes 7 days, a 30-day high becomes 15. Exposure to the open internet removes the assumption of a defended perimeter that internal SLA timelines are built around.
Tracking all of this by hand across scanners, ticketing systems and asset inventories is where most SLA programs fall apart — not the policy, the execution. Brinqa's vulnerability and exposure management platform pulls CVSS, EPSS, and asset context into one prioritization score and flags SLA breach risk before the deadline passes, which is also where reducing mean time to remediate actually starts — not with a stricter policy, but with visibility into which findings are about to blow their window.
Automate SLA tracking by severity
See how CVSS, EPSS and asset context combine into one prioritization score.
FAQ
What is a vulnerability remediation SLA?
A vulnerability remediation SLA is a fixed deadline, usually 15 to 180 days depending on severity, by which a security team commits to patching or mitigating a finding. It's typically tiered by CVSS severity and adjusted for exploit activity and asset exposure.
What is the standard SLA for critical vulnerabilities in 2026?
The standard SLA for critical vulnerabilities in 2026 is 15 days, matching CISA's Binding Operational Directive 22-01 deadline for known exploited vulnerabilities. Internet-facing critical findings with a public exploit often get compressed to 7-10 days.
Does PCI DSS require a specific remediation SLA?
Yes, PCI DSS 4.0 Requirement 6.3.3 requires critical and high-risk vulnerabilities to be patched within 30 days of identification. This applies to any organization in scope for cardholder data handling.
Should SLAs be based on CVSS score alone?
No, CVSS score alone misses exploit likelihood and business context. Pairing CVSS with EPSS and asset criticality catches high-risk findings that a CVSS-only SLA would let sit for the full 60-90 day medium window.
How do you measure SLA compliance?
SLA compliance is measured as the percentage of vulnerabilities remediated within their assigned window, tracked by severity tier. Programs typically report this monthly alongside mean time to remediate.
What happens when a vulnerability can't be patched in time?
When a patch isn't available or remediation slips past the SLA, the finding needs a documented risk acceptance or compensating control, not a silent miss. This keeps the SLA metric honest for audit and board reporting.
Is 90 days too long for a low-severity vulnerability?
Ninety days is reasonable for low severity if the backlog gets reviewed quarterly; the problem isn't the 90-to-180-day window, it's letting low findings sit untouched past that window without revisiting them.
One last thing
The SLA number gets all the attention, but the metric that actually predicts audit trouble is SLA compliance rate by tier, not the SLA itself — a program with a strict 10-day critical SLA and a 40% compliance rate is in worse shape than one running the standard 15-day window at 90% compliance. Set the deadline, then track whether you're hitting it before you tighten it further.
