Remediation Timelines and SLA Standards for Different Vulnerability Severities

Most vulnerability remediation SLA programs get missed in practice, and the reason isn't a lack of discipline. The frameworks themselves were never built to be met. A policy document can say "patch Critical in 30 days" and still fail the team that has to live by it, because the deadline was set without asking whether it was achievable.

The pattern appears the same way across organizations. A 2026 practitioner analysis of risk-based patching data found that a majority of organizations with formal SLAs miss their critical remediation target more than half the time. That same analysis found that at large enterprises, a critical flaw sits unpatched for 252 days on average, which is far past any stated SLA window. The MOVEit Transfer breach in 2023 is the clearest illustration of what that gap costs: it hit more than 2,700 organizations and exposed data on roughly 93 million people, and a patch existed the whole time. Most affected organizations simply hadn't deployed it yet.

The mechanical causes build on each other. Scanner findings pile up faster than anyone adds context to them. Remediation fatigue sets in once engineers notice that closing tickets doesn't shrink the queue, it just makes room for the next scan to fill it back up.

A handoff problem causes this: a CVSS score and a CVE number dropped into a ticket with no context gets deferred, and the SLA clock keeps running regardless.

CVSS severity alone as an unreliable basis for a remediation deadline

CVSS measures theoretical severity in isolation. Building an SLA around CVSS alone misallocates remediation effort at scale, because the score was never designed to answer the question an SLA needs answered: how fast does this specific thing need fixing, here.

The practitioner analysis found that only a small fraction of vulnerabilities scored above CVSS 7.0 are ever exploited in the wild. A CVSS 6.5 vulnerability in authentication middleware exposed directly to the internet can be the single most urgent item on the list. Same scoring logic, opposite real-world outcome.

Scale makes the problem worse. A single scan can return thousands of "Critical" findings in an afternoon. When everything is marked urgent, nothing gets prioritized, so teams go numb to the reports landing in their queue.

Two more failure modes compound CVSS's unreliability, and both get ignored by severity-only policies. An SLA that skips both of these inputs sets teams up to fail on paper the moment it's written.

The three inputs that determine how fast a vulnerability needs to be fixed

A remediation deadline should reflect three things at once: how bad the flaw is, what it touches, and whether anyone is actually exploiting it. Severity score alone answers none of those questions on its own.

Asset criticality comes first. Before setting a deadline, tier the asset by asking what business function it supports, what data flows through it, and what the blast radius looks like if it's compromised. Four tiers cover almost any environment. A confirmed-exploited, internet-facing flaw on a crown-jewel asset is a 24-to-72-hour job. The identical CVSS score on a low-impact box waits for the routine remediation cadence. Same score, different clock, because the asset tier changes what's actually at stake.

Exploitability signals come second, and they carry more weight than CVSS ever can. CISA's Known Exploited Vulnerabilities catalog (KEV) is the most reliable real-world signal available: a KEV listing means exploitation is confirmed, and it should trigger the tightest remediation window a program has, regardless of what the CVSS score reads. EPSS, the Exploit Prediction Scoring System, adds a probability layer on top: a vulnerability with an EPSS score above 0.50 should trigger a Critical SLA on its own, independent of CVSS. Attackers exploit critical flaws in as little as five days after public disclosure, and when a public proof-of-concept exists, that window frequently shrinks to 48 hours or less. Attackers move faster than CVSS-based timelines assume they will.

Reachability is the third input, and it's a supporting signal rather than a standalone trigger. Static analysis tools can determine whether a vulnerable function is reachable in a specific codebase, and that answer should shift the deadline up or down accordingly.

A concrete SLA matrix that maps severity and asset tier to defensible, achievable deadlines

Crossing severity against asset tier produces deadlines that are tighter where they need to be and realistic everywhere else, something a CVSS-only policy structurally can't deliver. The recommended matrix breaks down as follows.

| Severity | Tier 1 (Crown Jewel) | Tier 2 (Business Critical) | Tier 3 (Standard/Low) | |---|---|---|---| | Critical (CVSS 9.0–10.0) | 24–48 hours | 72 hours | 7 days | | High (CVSS 7.0–8.9) | 7 days | 14 days | 30 days | | Medium (CVSS 4.0–6.9) | 30 days | 45 days | 60 days | | Low (CVSS 0.1–3.9) | 90 days | 90 days | 90 days | | CISA KEV-listed | 24 hours | 48 hours | 7 days |

A set of accelerators cuts the standard window in half whenever certain conditions apply: exploit code is publicly available, active exploitation is confirmed through CISA KEV, the asset is internet-facing, the EPSS score exceeds 0.50, or a previous breach occurred through a similar vulnerability type. Crossing tiers this way means a medium-severity finding on a crown-jewel asset can land a tighter deadline than a high-severity finding on an isolated dev sandbox, and that's the correct order of priority.

The matrix only works if the clock itself is managed with discipline. The clock starts when the vulnerability is detected in the environment and assigned a risk tier, not when the CVE is published, since teams can't fix what they don't yet know is there. The clock pauses when no fix exists from the upstream vendor: the SLA should track time with a fix available rather than raw time since detection, and resume counting once a patch ships. Reclassifying a vulnerability to a lower tier can extend the deadline, but it never resets the timer back to zero, which closes off the most common way teams game the system.

Building the exception and escalation process

A severity matrix without a working exception process produces one of two outcomes. Teams either ignore the policy outright, or they hit the deadline by closing tickets without fixing the underlying flaw. Both results defeat the purpose of having an SLA.

Exceptions need to be narrow and documented. Four reasons should qualify: the system can't be patched without major downtime and needs a scheduled maintenance window, no vendor patch exists yet and a compensating control is required in the meantime, a patch breaks critical functionality and test results prove it, or the system is end-of-life and pending decommission with a documented risk acceptance on file. Exception rate functions as its own KPI. If more than a tenth of findings carry active exceptions, the SLA tiers are miscalibrated, or the asset tiering itself is wrong. Exceptions need to stay rare, because they can't become the default way around a deadline nobody can hit.

Escalation is what turns a breach from a number nobody looks at into an event someone has to answer for. The ladder runs on a fixed schedule: a warning email to the asset owner at 75% of the SLA window elapsed, a breach notification to the manager and CISO once the window closes, executive escalation to a VP or CTO seven days past breach, a formal risk acceptance required from the CISO at 30 days past breach, and mandatory compensating controls with a board report at 90 days past breach. None of that carries weight without sign-off from above. The SLA policy needs the CISO's signature and engineering leadership's acknowledgment before a breach means anything more than a line on a dashboard.

Wiring the SLA into the engineering workflow

The SLA breaks down at the handoff. A scanner produces a finding, a ticket opens without enough detail for an engineer to act on it, and the ticket sits in the backlog aging past its deadline. Fixing that means removing friction from the process, not applying more pressure to the people stuck inside it.

Routing has to happen automatically. A mapping table connecting repository or service name to the right engineering team's Jira project key means a finding in the auth-service repository lands directly in the auth team's project, assigned to that team's security champion, without a human sorting tickets by hand. Duplicate prevention matters just as much: before a new issue gets created, the system should check for existing open tickets matching the same CVE ID and component, and only open a new one if nothing matches.

The ticket's format decides whether an engineer engages with it or lets it sit. A working sprint story template includes a summary stating the vulnerability type, component, CVE ID, SLA tier, and due date. It includes background written in two or three sentences for an engineer who has never seen this CVE before, not a generic description copied from an advisory. It includes numbered reproduction steps with exact commands or HTTP requests, and acceptance criteria that spell out what "fixed" actually means and how it gets verified. When tickets miss reproduction steps and remediation guidance, they get closed without a fix applied in a majority of cases, so the ticket format drives the completion rate; it isn't a cosmetic detail.

Catching a vulnerability before it reaches production costs less to fix than remediating it after deployment, and for many classes of findings, it keeps the SLA clock from ever starting.

The KPIs that show whether the SLA is working

A documented SLA on its own proves nothing. What proves a program works is a set of tracked KPIs showing both the compliance rate and exactly where the system is breaking down, and that's what auditors, boards, and cyber insurers ask to see now.

SLA compliance rate measures the percentage of vulnerabilities remediated within their SLA window, with a target above 90%. Mean time to remediate tracks the average number of days from discovery to fix, with Critical findings targeted under 3 days and High findings under 10 days. Vulnerability backlog measures how many findings sit open past their SLA, and the target is under 5% of total findings. Mature vulnerability management programs hit an MTTR under 30 days for high-severity findings, but the industry average runs 60 to 90 days, and attackers get that whole gap to work in.

KPIs need tracking at the team and department level, not just across the organization as a whole. Trends matter as much as snapshots. Vulnerability density per asset counts findings per host, and it flags which systems are accumulating risk faster than anyone is remediating it.

None of this stays optional for long. ISO 27001 and NIS2 auditors ask to see the SLA itself and evidence that it's being met, not just the policy document. Cyber insurers commonly require critical vulnerabilities on exposed systems to be remediated within defined windows as a condition of coverage. A policy with no KPIs behind it doesn't satisfy either one.

What regulatory frameworks require from your remediation program

A well-structured remediation SLA, tracked with evidence of actual performance, satisfies the core vulnerability management requirements written into every major compliance framework. But the mapping only holds if you actually practice the SLA, rather than filing it away as a document nobody checks against.

ISO 27001:2022 is the relevant standard now. The transition deadline for ISO 27001:2013 passed on October 31, 2025, and every certification under that older version has expired, meaning ISO/IEC 27001:2022 is the only valid version as of November 2025. Control 8.8, Management of Technical Vulnerabilities, requires information about technical vulnerabilities to be gathered, the organization's exposure evaluated, and appropriate measures taken. Control 8.29, Security Testing in Development and Acceptance, requires you to define and implement security testing processes within the development lifecycle. A documented SLA with tracked KPIs serves as direct evidence for both.

HIPAA sets a different bar. Section 164.308(a)(8) requires a periodic technical and nontechnical evaluation, based initially on the standards implemented under the rule and then on environmental or operational changes affecting the security of electronic protected health information, and it establishes how well a covered entity's security policies meet the subpart's requirements. As of September 2026, those provisions remain a proposal, so healthcare organizations should prepare for them but not treat the annual mandate as current law.

A single properly scoped penetration test can satisfy SOC 2 CC4.1, ISO 27001 Annex A controls, and PCI-DSS Requirement 11.4 at the same time. Running one rigorous test that covers all three beats running separate checkbox exercises for each framework individually.

How retesting closes the loop between finding a vulnerability and reducing risk

Remediating a vulnerability and verifying that the remediation actually worked are two separate steps, and most SLA programs track only the first one. That gap raises the recurrence rate metric, because fixes that were never real show up again in the next scan.

Penetration testing that skips retesting leaves the investment half-finished. The effort goes into finding vulnerabilities and pushing fixes out the door, and the program never confirms whether those fixes held or introduced new problems elsewhere. Retesting catches both. A patch applied under time pressure to meet a 24-hour SLA is precisely the kind of fix most likely to introduce a bypass or break something adjacent to it. A high recurrence rate signals that retesting is missing or insufficient, and it functions as the feedback mechanism that closes the loop the SLA opened.

A finding proven with a working exploit, followed by a retest confirming the fix holds, produces the kind of evidence auditors, insurers, and enterprise customers actually trust. The vulnerability existed, it was exploitable, it was fixed inside the SLA window, and the retest confirmed closure. That chain satisfies SOC 2 CC4.1, ISO 27001 Control 8.8, and cyber insurer requirements at once, and it carries more weight than a ticket marked closed on a dashboard.

Continuous pull-request scanning extends that same verification model earlier into the development lifecycle. Catching a regression before it reaches production eliminates the remediation cycle entirely for that class of finding, and it marks the logical next step for a program built to catch problems at the point they happen.