Remediation SLAs: setting deadlines teams can meet

A remediation SLA is a promise between the security function and the teams that own systems: for this kind of risk, we expect a fix within this time. Done well, SLAs turn prioritization into predictable work and give everyone a shared definition of "late". Done badly — one severity-based table applied to every finding — they produce a permanently red dashboard, a culture of ignoring deadlines, and no reduction in the risks that matter.

This guide covers how to design SLAs that teams can meet: tying them to risk tiers, defining exactly when the clock starts and stops, handling missing patches, escalating breaches, and measuring compliance honestly.

Tie SLAs to risk tiers, not raw CVSS

The most common SLA table maps CVSS base severity to days: Critical in X, High in Y, and so on. It is simple, but it inherits every weakness of base scores described in risk-based prioritization: too many items at the top, no weight for exploitation, no asset context. The result is more "critical" work than any team can do on time.

Instead, attach SLAs to the priority tiers your VOC already computes — whether through a matrix of CVSS, EPSS, KEV and asset context, or through SSVC outcomes. The tier carries the risk judgment; the SLA only expresses urgency.

An example SLA matrix

The table below is an example, not a benchmark. Calibrate it against your change process and measured remediation capacity; an SLA nobody can meet is worse than a slower one that is consistently honoured.

Some organizations add an internet-facing modifier that halves the SLA for exposed assets, or a separate track for end-of-life software, which cannot be patched and must be upgraded or replaced.

External reference points

Your SLAs are yours to set, but a few external requirements are worth knowing because auditors and customers will compare against them:

• CISA BOD 22-01 requires US federal civilian agencies to remediate KEV entries by the dueDate listed in the catalog. When the directive launched, the timelines were two weeks for CVEs assigned in 2021 or later and six months for older ones. Even if it does not bind you, the KEV due date is a useful external benchmark for exploited vulnerabilities.
• PCI DSS v4.0 requirement 6.3.3 expects critical security patches and updates to be installed within one month of release for in-scope systems, and requirement 11.3 requires internal and external vulnerability scans at least once every three months.
• Contracts and cyber insurance increasingly include remediation expectations for known exploited vulnerabilities. Check what you have already promised.

When the clock starts

Define the start event precisely, because it determines both behaviour and metrics.

A pragmatic rule: start at first detection, restart at a tier upgrade (with the new, shorter SLA counted from the moment the finding moved up), and report the publication-to-detection gap separately as a scanning metric. Never restart the clock on a downgrade — keep the original, tighter deadline or the later of the two, and document which.

When the clock pauses

Pauses are where SLAs quietly lose their meaning. Allow as few as possible and make them visible:

• No fix available — pause only if a mitigation is in place, and only until the vendor's fix is released plus a short window.
• Approved exception — not a pause but a separate state with its own expiry; see exceptions and risk acceptance.
• Disputed finding — a short, bounded pause while an analyst validates a claimed false positive.

Anything else — waiting for a change window, waiting for another team — counts against the SLA. That is the point: the SLA measures the organization's ability to reduce risk, not any one team's diligence.

Writing the policy as code

Keeping the SLA policy in version control, in a machine-readable form, lets the ticketing integration and the metrics pipeline use the same definitions as the published policy.

# sla-policy.yaml — example values, not a standard
version: 3
effective: 2026-10-01
clock:
  start: first_detected
  on_tier_upgrade: restart_with_new_sla
  on_tier_downgrade: keep_original_due_date
tiers:
  P1: {remediate_days: 7,   mitigate_hours: 48, change_type: emergency}
  P2: {remediate_days: 30,  change_type: standard}
  P3: {remediate_days: 90,  change_type: standard}
  P4: {remediate_days: 180, change_type: routine}
modifiers:
  - when: {exposure: internet, tier: [P2, P3]}
    multiply: 0.5
pauses:
  allowed: [vendor_fix_pending_with_mitigation, false_positive_review]
  false_positive_review_max_days: 5
escalation:
  - at: due_date_minus_25_percent
    notify: [owner_team]
  - at: due_date
    notify: [owner_team_manager, voc_lead]
  - at: due_date_plus_7_days
    notify: [owning_executive, ciso]

Escalation that works

Escalation is how an SLA becomes more than a suggestion. Effective ladders share a few traits:

1. Warn before the breach. A reminder at 75% of the SLA gives owners time to act or request an exception.
2. Escalate to people who can reprioritize work. Notifying the engineer again does nothing; the manager who sets the team's priorities can.
3. Aggregate. Executives should see a short, monthly list of breaches per team — not individual emails for each finding.
4. Pair escalation with help. When a team is consistently late, the answer may be tooling (automated patching), capacity, or an architecture change, not more pressure.

Measuring SLA compliance

Report compliance per tier and per owning team, and include open items that are already late — not only closed ones.

• Closed within SLA: findings remediated before their due date, divided by findings closed in the period.
• Open past due: findings currently overdue, with their age beyond the due date.
• Exception rate: findings resolved by exception rather than remediation.

Measuring only closed findings rewards teams for closing easy items and leaving hard ones open. The metrics guide shows how to compute these with SQL, including percentile-based time to remediate.

Checklist

• SLAs attach to risk tiers, not raw CVSS severity.
• Start, restart and pause rules are written down and implemented in tooling.
• P1 has a pre-agreed emergency change path.
• Missing vendor fixes require a mitigation and a time-boxed exception.
• Escalation reaches someone who controls the team's priorities.
• Compliance is reported per tier and per team, including open overdue items.
• The policy is versioned and reviewed at least annually.

The next step is getting the work to the right people efficiently — see remediation workflow and ticketing.