Use one severity scale but let each layer have its own clock where the work genuinely differs. A single table is easier to explain, yet OS patches carry restart cost and dependency patches carry rebuild and test cost. If you keep one SLA, define what starts the clock and what counts as done.
Option one: a single SLA
One table, one set of deadlines, by severity.
Good when: the team is small, the stack is mostly containers, and both layers ship through the same pipeline.
Watch out for: deadlines tuned for the faster layer that the slower layer constantly misses, which trains people to ignore the SLA.
Option two: two SLAs
Same severity labels, separate deadlines per layer.
Good when: hosts have fixed restart windows and applications deploy daily.
Watch out for: two sets of numbers to explain to auditors and customers. Keep the structure parallel.
Option three: one SLA with layer notes
One table, plus a short note per layer on how the clock behaves. This is often the practical middle.
| Severity | Deadline | OS note | Dependency note |
|---|---|---|---|
| Actively exploited | Emergency lane, fastest path | Restart may be forced | Deploy outside normal cycle |
| Critical | Short deadline | Use next window or force one | Merge and deploy in normal flow |
| High | Medium deadline | Next monthly cycle | Next sprint or earlier |
| Moderate and low | Routine cycle | Routine cycle | Batched updates |
Fill the deadline column with your own numbers. Do not copy ours, and do not copy another company's.
Define the clock
Whatever you pick, decide three things in writing.
- Start. Advisory published, patch released, or your detection time. See when does the patch SLA clock start.
- Stop. Fixed version deployed to production, not merged to a branch.
- Pause. When a vendor has not shipped a fix, the clock turns into a mitigation deadline.
Align with known external signals
NIST SP 800-40 Rev. 4 describes routine and emergency patching as separate scenarios, with emergency patching on a highly accelerated schedule of hours or days depending on urgency. It also warns that delaying routine patching makes emergency patching harder. Many teams use a catalog of known exploited vulnerabilities as the trigger for the emergency lane. Whether any external deadline binds you depends on your sector and contracts, so check your own obligations.
How to decide
Ask three questions. Can both layers meet the same deadline today without heroics? If yes, use one SLA. If no, is the gap the restart window? Then use layer notes. Is the gap the whole process? Then use two SLAs and fix the process.
Where Safeguard fits
Safeguard's compliance and evidence automation records when findings were detected and when fixes landed, which gives you the data to measure either approach. See define critical vulnerability in a patch SLA clause.
Quick check
Does a customer contract force one SLA?
Only if its wording does. Read the clause for scope and the clock start, and align your internal table to it.
What if the dependency fix does not exist yet?
Switch to mitigation, record an exception with an owner and review date, and watch for the fix.
Sources
Last reviewed: 19 October 2026.
