SLA rule: a deadline should combine exploitation, exposure, business impact, patch availability, source confidence, and operational safety. Do not let a generic severity SLA override evidence.
Response SLA Matrix
Set timelines that match real risk, not score alone.
Use this page to choose practical target timelines for validation, patching, mitigation, SOC follow-up, exceptions, and monitoring.
Immediate
0-24hexploited, exposed, business-criticalUrgent
2-7dhigh confidence, reachable, fix pathPlanned
14-30dimportant but controlledWatch
Reviewuncertain, blocked, or low confidenceTimeline Defaults
Suggested targets by signal combination
0-24 hours
Patch or mitigate immediately
Use when KEV or confirmed exploitation overlaps with internet-facing, unauthenticated, ransomware-relevant, or business-critical exposure.
2-7 days
Urgent planned remediation
Use when exploit pressure is high, affected assets are confirmed, a fixed version exists, and emergency change risk is manageable.
7-14 days
Mitigate while patching is prepared
Use when the issue is serious but full remediation needs dependency testing, staged rollout, or maintenance-window planning.
14-30 days
Normal patch cycle
Use when severity is high but exposure is limited, exploitation is not confirmed, controls exist, and a standard patch window is safer.
Review date
Monitor or validate first
Use when source confidence is low, exposure is unknown, records are disputed, or patch guidance is still changing.
Time-boxed
Exception with expiry
Use when patching cannot meet target timelines. The exception needs owner, compensating controls, expiry, and trigger-based re-review.
Timeline Modifiers
Conditions that should speed up or slow down the target
Speed up
KEV, confirmed exploitation, public PoC, internet-facing reachability, unauthenticated access, ransomware relevance, critical business service, or no compensating control.
Slow down for validation
Low source confidence, disputed record, unclear affected version, unknown owner, unclear exposure, unsupported product, or conflicting vendor guidance.
Slow down for safety
High outage risk, fragile system, unavailable rollback, regulated downtime window, safety impact, OT constraints, or dependency uncertainty.
Do not slow down silently
If work misses the target, move it to Exception Register with compensating controls, residual risk, owner, and review date.
Operational Rules
Keep response timelines useful and fair
Start the clock after evidence
Do not start strict remediation SLAs until affected version, exposure, source confidence, and owner are reasonably validated.
Separate validation from remediation
Validation should move quickly even when patching needs a later window. Unknown exposure should not sit idle.
Track exceptions visibly
Missed timelines are not automatically failure if risk is accepted, controlled, and reviewed. Invisible exceptions are the real problem.
Require closure evidence
A timeline is only complete when Remediation Evidence proves the outcome and Action Tracker has the final state.
Copy Template
SLA assignment note
Target response: [0-24h / 2-7d / 7-14d / 14-30d / review date / exception expiry] Reason: [exploitation, exposure, business impact, patch availability, source confidence] Owner: [team/person]. Scope: [asset group/product/version] Required action: [validate / patch / mitigate / detect / accept / monitor] Evidence needed: [affected version, fixed version, exposure proof, telemetry, approval] Review trigger: [date, KEV change, PoC release, vendor update, exposure change]
Recommended next move: choose the target timeline, assign the owner in Action Tracker, and use Remediation Evidence before calling the work complete.