vulnerability SLAs: patch timelines by severity

TL;DR

Pick four timelines, one per severity band, and define done as scanned-clean in production. Critical in days, high in weeks, medium in a month or two, low on the normal cycle. The SLA is only real if missed deadlines escalate automatically and exceptions have expiry dates.

vulnerability SLAs: patch timelines by severity

Use this when

• You are writing your first vulnerability remediation policy
• Leadership or a customer asks what your patch SLAs are
• An audit requires documented remediation timelines
• Teams keep asking how fast is fast enough for a given severity

Not for

• Deciding the priority of one specific CVE (thats triage)
• The technical work of patching
• Incident response timelines during an active breach

Steps

1. Set the four timelines.

A common starting point: critical 7 days, high 30 days, medium 90 days, low next normal release cycle. Adjust for your risk appetite, but write the numbers down. Vague timelines are no timelines.

Expected: four numbers, one per band, published where the team can see them.

2. Define what counts as done.

Done means the fix is deployed to production and a fresh scan confirms it, not merged, not staged. Write this definition into the policy so nobody closes early.

Expected: one sentence everyone agrees on.

3. Start the clock at detection, not at triage.

The SLA clock starts when the scanner or advisory first reports the CVE, not when someone gets around to looking at it. Triage delays are part of the timeline, which is the point.

Expected: every tracked CVE has a detection date as its deadline anchor.

4. Build the escalation ladder.

When a deadline is missed, it escalates: owner to team lead at 50 percent overdue, to security leadership at 100 percent, to execs beyond that. Automatic, not optional.

Expected: a written ladder with names or roles at each rung.

5. Handle exceptions with expiry dates.

No-patch-available and wont-fix items get exceptions with an owner, a reason, a mitigation note, and an expiry date. Expired exceptions re-enter the SLA clock.

Expected: an exception list that shrinks instead of growing.

6. Report compliance monthly.

Percentage of CVEs closed inside SLA per band, mean time to remediate, oldest open item. This is the number leadership and auditors ask for.

Expected: a one-page monthly report with the compliance percentage.

Variant phrasings

How fast should we patch critical vulnerabilities

Days, not weeks. Seven days is the common SLA for criticals, faster if there is a public exploit. Write the number down.

Patch SLA policy template

The four timelines plus the definition of done, the clock start, the escalation ladder, and the exception process. Thats the policy.

What happens when we miss a patch deadline

Escalation per the ladder, plus the miss shows up in the monthly compliance report. Chronic misses mean the timeline or the resourcing is wrong, not the team.

Why it happens

Without written timelines, every CVE becomes a negotiation: is this urgent, who decides, how long is reasonable. The SLA removes the negotiation by pre-deciding the answer per severity band. Teams that skip this step rediscover the same argument on every single CVE.

Edge cases

• Zero-day with active exploitation: the SLA is too slow. Active exploitation overrides the timeline, patch or mitigate immediately regardless of band.
• Timeline is impossible for your team size: if you miss 80 percent of high SLAs, the timeline is fiction. Loosen the numbers or get help, but keep them honest.
• Third-party or vendor dependency: the SLA still applies, but the clock may need a vendor-response allowance. Track vendor SLAs separately and escalate to procurement when they slip.
• Regulated industry with mandated timelines: some frameworks dictate the numbers. Use theirs where they exist and document the mapping.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ktCbHwCrPbY-zj5wwPkgXg