Remediation SLAs That Actually Hold
Most vulnerability SLAs are a number copied from a framework into a policy nobody enforces. A deadline without a start event, an owner, and a breach process is a wish. Here is how to design remediation SLAs that get met instead of quietly missed.
Open almost any vulnerability management policy and you’ll find the same table: critical in 15 days, high in 30, medium in 90. The numbers are usually lifted straight from a framework, pasted into a document, and never looked at again. Then the next audit asks for SLA attainment, someone exports a report, and the answer is some embarrassing number well under half. The SLA didn’t fail. It was never built to hold in the first place.
A remediation SLA is a promise about time. Most of the ones written down are missing the three things that make a promise real: a clear moment the clock starts, a person who owns the consequence of it running out, and a process for what happens when it does.
A due-date field is not an SLA
The most common failure mode is the quietest. A finding gets a due date when the ticket is created, the date passes, the ticket stays open, and nothing happens. No alert, no escalation, no entry in a breach log. The deadline was decorative.
If breaching your SLA produces no event — no notification, no escalation, no record — then you don’t have an SLA. You have a date field, and a date field enforces nothing.
An SLA earns the name only when crossing it changes something. That’s the bar. Everything below is how to clear it.
Start the clock at the right moment
Half of all SLA disputes come down to when the clock started, and teams that haven’t decided this in advance argue about it after the breach. Pick one event and write it down.
The defensible choice is the moment the finding becomes known to you, which usually means first ingestion from the scanner, not the moment an engineer happens to open the ticket. Starting the clock at “ticket acknowledged” lets the deadline drift every time someone is on holiday, and it hides your real exposure window, which is the time the vulnerability sat in production whether or not anyone was looking at it.
There’s a wrinkle worth handling explicitly: a vulnerability that was disclosed months before your scanner picked it up. The honest version tracks both the discovery date and the disclosure date, and reports against the one that makes your risk visible rather than the one that flatters the metric.
Set the window to the risk, not the calendar
“Critical in 15 days” treats every critical finding as identical, and they aren’t. A critical on an internet-facing asset that’s on CISA’s exploited list is a different emergency than a critical on an internal box behind two firewalls, and a single number can’t tell them apart.
The SLAs that hold are the ones tied to exploitability and exposure, not severity alone. Confirmed active exploitation gets the tightest clock you can actually meet. High likelihood gets the next tier. Theoretical severity on a contained asset can wait, and saying so out loud is what keeps the urgent tiers credible. When every finding is a 15-day emergency, the team triages by gut and the policy becomes fiction.
A deadline needs an owner and an exit
A date with no name attached belongs to everyone, which means it belongs to no one. Every SLA-bound finding needs a single accountable owner, and the owner needs somewhere for the problem to go when the deadline is at risk. An escalation path that nobody can name is the same as no path at all.
The mechanics are simple and most teams skip them anyway: a warning before the breach, not after; an automatic escalation to a named manager when the window closes; and a clear record of who held the item when it slipped. None of this is about blame. It’s about making sure a missed deadline surfaces while there’s still time to act, instead of showing up in an audit export six months later.
Measure the breach, not just the hit rate
“SLA attainment: 86%” is a vanity metric on its own. The 14% is where the program actually lives. A breach log that captures why each deadline slipped — waiting on a vendor patch, change-freeze window, a dependency that couldn’t be updated without a major version bump — turns a number into a roadmap. After a quarter, the breach reasons cluster, and the clusters tell you exactly which part of the process to fix.
Attainment without root cause tells you that you’re failing. The breach analysis tells you how to stop.
Exceptions are part of the design, not a failure of it
Every real program needs a way to say “we can’t meet this, and here’s why” without that turning into a silent miss. A documented exception with an approver, a reason, and a review date is a healthy part of an SLA. An undocumented one is just a breach wearing a disguise. The difference matters enormously to an auditor, who is far more reassured by a tracked, justified exception than by a suspiciously perfect attainment rate.
The test of a good SLA
A remediation SLA is good when it’s met most of the time, when the misses are explainable, and when the deadline pressure pushes work toward the findings that actually matter rather than the ones that happen to be loudest. If your SLAs fail all three, the problem isn’t your team’s discipline. It’s that the promise was written to be filed, not to be kept.
A deadline you don’t enforce isn’t a standard. It’s a note to your future self, apologizing in advance.
Want to see severity-based SLAs that enforce themselves and log their own breaches? Book a remediation workflow review.