Remediation SLAs and Vulnerability Exceptions Guide

Most vulnerability programmes do not fail at finding flaws, they fail at closing them on time, and at the quiet pile of "temporary" exceptions that never expire. A remediation service level agreement (SLA) turns a prioritised finding into a dated obligation with an owner, and an exception process decides what happens when that date cannot be met. This guide covers how to set remediation deadlines that hold up against regulatory and framework timelines, how to design a risk acceptance workflow with compensating controls and expiry, and how to measure whether either is working. It is written for vulnerability management leads, security risk managers and the IT and engineering owners who carry the tickets.

Key takeaways

Anchor SLAs to external clocks first. CISA KEV due dates, PCI DSS 6.3.3, Cyber Essentials and the Essential Eight already set deadlines for many assets; internal tiers should be equal or tighter.
Tier by exploitation and exposure, not CVSS alone. A known exploited flaw on an internet-facing service needs hours or days; a medium on an isolated workstation can wait for the monthly cycle.
An exception is a dated risk decision, not a ticket status. It needs a named risk owner at the right seniority, compensating controls that are verified, and an expiry no later than [90] days.
Remediation is not always the patch. When a flaw may already have leaked credentials, sessions or keys, the SLA is met only after those are rotated or revoked.
Measure the deadline, not the volume. Percentage remediated within SLA by tier, mean and median time to remediate, and the age of open exceptions tell you more than total vulnerabilities closed.

What a remediation SLA is, and where it stops

A remediation SLA is the maximum time allowed between a defined start event and verified closure of a vulnerability, set per severity tier and asset class. Three definitions decide whether the SLA means anything:

Start of the clock: choose one and write it down. Options are vendor release date (used by PCI DSS 6.3.3, Cyber Essentials and the Essential Eight, which all count "from release"), the date the finding first appears in your scanner, or the date a flaw is added to the CISA Known Exploited Vulnerabilities (KEV) catalog. Release date is the honest choice; first detection rewards slow scanning.
What counts as remediated: the fix is applied and confirmed by a rescan or configuration check, or the vulnerable component is removed. A mitigation (a WAF rule, a disabled feature) is not remediation; it is a compensating control and belongs in an exception.
What the SLA covers: operating systems, applications, firmware, container images, cloud configuration findings, code findings and exposed secrets all need deadlines.

The boundary with neighbouring practices is simple: the Vulnerability Prioritisation Guide decides which tier a finding is in, the Patch Management Guide covers how the fix is delivered, and this guide covers the deadline and what happens when it is missed.

External deadlines your SLAs must respect

Before writing internal tiers, list every external timeline that applies to any part of the estate. Internal SLAs that are looser than an applicable external one create a compliance gap by design.

Source	Applies to	Deadline	Notes
CISA BOD 22-01	US federal civilian information systems, including systems hosted by third parties for an agency	Two weeks for KEV entries with CVEs assigned from 2021 onwards; six months for CVEs assigned before 2021; CISA may set shorter dates	Each KEV entry carries its own dueDate. CVE-2025-53770 (SharePoint, ToolShell) was added on 20 July 2025 with a due date of 21 July 2025; CVE-2026-35273 (PeopleSoft) was added on 12 June 2026 and due on 15 June 2026
PCI DSS v4.0.1 Requirement 6.3.3	System components in the cardholder data environment and connected systems	Critical or high-security patches, as ranked under Requirement 6.3.1, within one month of release; all others within an appropriate timeframe set by the entity's risk assessment	The ranking process in 6.3.1 must exist and be documented, otherwise "critical" has no audit basis
UK Cyber Essentials (Requirements for IT infrastructure v3.2)	All in-scope devices and software	14 days of release where the update fixes a vulnerability with a CVSS v3 base score of 7 or above, the vendor calls it critical or high risk, or the vendor gives no severity	Unsupported software must be removed, or the device moved to a sub-set with no internet traffic. Automatic updates where possible
Essential Eight, Patch applications (ASD)	Australian government and organisations adopting the model	Online services: 48 hours where critical or an exploit exists, otherwise two weeks. Core applications (office suites, browsers, email clients, PDF software, security products): two weeks, or 48 hours at Maturity Level Three when critical or exploited. Other applications: one month at Levels Two and Three	Scanning: online services daily, core applications weekly, other applications fortnightly. Operating system patching follows a parallel structure
DORA RTS (Commission Delegated Regulation (EU) 2024/1774), Article 10	EU financial entities in scope of DORA	No fixed number of days: entities must set patch deadlines and escalation procedures for missed deadlines, and emergency patching procedures	Automated vulnerability scanning at least weekly for ICT assets supporting critical or important functions; every detected vulnerability recorded and monitored until resolved
NIS2 Directive, Article 21	Essential and important entities in EU member states	No fixed deadline in the Directive; vulnerability handling and disclosure is one of the required risk management measures	National transposition and sector rules may add detail. See the NIS2 Directive Guide

Two patterns stand out. First, the specific standards converge on a fast lane (48 hours to two weeks) for exploited or internet-facing flaws and a slow lane (around one month) for the rest. Second, DORA and NIS2 set no number but still expect you to have set, documented and escalated one.

Designing SLA tiers

A workable model has four or five tiers, defined by exploitation status and exposure as well as technical severity. CVSS base score alone is a poor driver: it measures how bad a flaw could be, not whether anyone is using it. Pair it with KEV membership, the FIRST Exploit Prediction Scoring System (EPSS, a daily probability that a CVE will be exploited in the next 30 days) and asset exposure. CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) maps cleanly onto tiers: its outcomes are Track and Track* (remediate within standard timelines), Attend (sooner than standard) and Act (as soon as possible).

Tier	Typical trigger	Internet-facing or critical asset	Internal asset	Exception approver
P0 Emergency (SSVC Act)	KEV listed or active exploitation reported, remote and unauthenticated, on an exposed service	48 hours, or the KEV due date if sooner	7 days	[CISO] only; no extension beyond 14 days without executive sign-off
P1 Critical (SSVC Attend)	CVSS 9.0 or above, or vendor critical, or high EPSS, with a reachable attack path	7 days	14 days	[CISO or deputy]
P2 High	CVSS 7.0 to 8.9, vendor high, or no vendor severity given	14 days	14 days (30 days only for assets outside Cyber Essentials and PCI DSS scope)	[Head of security risk]
P3 Medium	CVSS 4.0 to 6.9 without exploitation evidence	30 days	60 to 90 days	[Asset owner with security sign-off]
P4 Low	CVSS below 4.0, informational	Next routine cycle	Next routine cycle or 180 days	[Asset owner]

The values above are a starting point that satisfies the external timelines in the previous section: P2 at 14 days meets Cyber Essentials for in-scope devices, the P1 and P2 internal limits fit inside PCI DSS's one month, and P0 matches the Essential Eight 48 hour lane. Adjust the numbers, but check each change against that table.

Escalate, never de-escalate on age: when a finding is added to KEV or a public exploit appears, it moves to P0 and the clock restarts from that event with the shorter deadline, never a longer one.
Exposure modifiers: raise one tier for internet-facing services, identity infrastructure (domain controllers, identity providers, VPN and remote access gateways, privileged access tools) and systems holding regulated data; lower one tier only where a documented network control removes the attack path, and record that as a reason, not an assumption.
End of life: unsupported software has no patch to apply. NIST SP 800-53 SA-22 (Unsupported System Components) and Cyber Essentials both treat it as replace or isolate. Give it a decommission date and a standing exception, not a recurring SLA breach.
Non-scanner findings: exposed secrets found in code or logs should be revoked within hours, because the exposure is the incident; certificate expiry findings carry a deadline set by the expiry date, minus the time your renewal process needs. See the Secrets Management Guide and the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Small and large organisations

A small organisation with mostly SaaS and managed endpoints can run three tiers (14 days for high and critical, 48 hours for exploited, 30 days for the rest), lean on automatic updates, and treat Cyber Essentials as its baseline. A large enterprise needs maintenance groups: NIST SP 800-40 Rev. 4 recommends grouping assets with similar maintenance needs (for example, user workstations, internet-facing web tier, OT, legacy mainframe) and giving each group its own maintenance plan with timeframes. The SLA table then becomes a matrix of tier by maintenance group.

When remediation means more than patching

For flaws that disclose memory, bypass authentication or give code execution on a server that holds secrets, applying the patch closes the door but does not evict anyone already inside. The SLA definition of "remediated" must include credential hygiene for these classes.

Session and token disclosure: the CitrixBleed (CVE-2023-4966) incidents showed stolen session cookies staying valid after upgrade. Citrix told customers to terminate all active and persistent sessions after patching; at Comcast Xfinity, attackers accessed internal systems after the patch had been applied.
Key theft through code execution: in the ToolShell SharePoint exploitation, attackers read ASP.NET machine keys (ValidationKey and DecryptionKey). Microsoft and CISA advised rotating the keys and restarting IIS after updating, because the stolen keys remained valid.
Service accounts and integration secrets: an application server compromised before patching should be assumed to have leaked every credential it held: database accounts, API keys, cloud roles. Rotate them as part of closure.

For P0 and P1 findings in these classes, closure evidence must include session revocation and secret rotation. See the Zero-Day and Exploited Vulnerabilities Guide for the wider response.

Governing vulnerability exceptions

An exception is a formal decision to miss an SLA for a stated reason, for a stated period, with stated controls. NIST SP 800-40 Rev. 4 frames the possible responses as accept, mitigate, transfer or avoid, and notes that patching is the only response that removes the vulnerability without removing functionality. The NCSC describes deciding not to update as "a senior-level risk decision" to be recorded in the risk register.

Types of exception

Type	When it fits	Maximum duration	Required evidence
Extension	A fix exists but cannot be deployed in time (change freeze, vendor certification, testing failure)	One extension, no longer than the original SLA	Planned remediation date, change reference, interim mitigation
Mitigated risk acceptance	No fix exists yet, or the fix breaks a critical function	[90] days, renewable once with re-approval	Compensating controls, verified; detection in place
Long-term acceptance	End-of-life or vendor-locked systems (medical devices, OT, legacy ERP) awaiting replacement	Until the decommission date, reviewed every [6] months	Replacement project reference, isolation design reviewed by security architecture
False positive or not applicable	The vulnerable code path is absent or the finding is wrong	Permanent, but re-validated on version change	Technical evidence (version, configuration, vendor statement); this is a closure reason, not an exception

The request and approval workflow

Request before breach: the asset owner submits the exception before the SLA expires, naming the finding IDs, assets, business reason and proposed end date. Requests after the deadline are recorded as SLA breaches first.
Security assessment: the vulnerability team confirms the tier, exploitation status (KEV, EPSS, threat intelligence) and exposure, and states the residual risk with the proposed controls in place.
Compensating controls: the requester specifies controls that address the actual attack path, and security verifies them. A WAF rule is acceptable only if tested against the known exploit and its variants; the PeopleSoft exploitation reported in 2026 illustrates why, as Mandiant reported the group evading WAF rules by encoding a single character in the request path.
Approval at the right level: approval authority rises with tier, using the approver column in the SLA table. The approver must be accountable for the business service, not just the technology.
Register and expire: the exception is recorded in the risk register or exception register with an expiry date that the tooling enforces: when it expires the finding reverts to breached status automatically.
Review and renew or close: before expiry the owner either remediates, or requests a renewal with fresh evidence. Renewals beyond the first go to the next approval level.

NIST SP 800-40 Rev. 4 makes a useful design point: rather than treating whole asset types as permanent exceptions, create maintenance groups for them with their own plans and approved long-term mitigations, such as micro-segmentation. This turns a standing exception into a managed plan with its own metrics. For the general risk acceptance process across all security policies, see the Security Exceptions and Risk Acceptance Guide.

Compensating controls that work

Effective controls remove reachability (take the interface off the internet, restrict it to a management network, disable the vulnerable component), reduce what the asset can reach (segmentation, no standing privileged credentials, tightly scoped service accounts), raise detection for the specific exploit and post-exploitation behaviour, and shorten credential and session lifetimes while the exception stands.

Implementing SLAs and exceptions: a phased approach

Baseline (weeks 1 to 4): measure current time to remediate by severity and asset group from existing scanner and ticket data, with no targets yet. List every external timeline that applies (the table above). Confirm asset ownership coverage, since findings with no owner cannot have an SLA.
Define (weeks 4 to 8): draft tiers, start-of-clock rule, closure criteria and exception types. Agree them with IT operations, engineering and the risk function, and publish them in the vulnerability management policy. A ready-made structure is in the Vulnerability Management Policy Template, which is the companion to this guide.
Pilot (one quarter): run the SLAs in report-only mode for one or two maintenance groups. Track breaches without escalating. Use the data to adjust deadlines that are impossible and to find blockers such as change windows or missing test environments.
Enforce: switch on automatic ticket creation with due dates, escalation at 50, 75 and 100 per cent of the SLA, and exception expiry in the tooling. Report SLA compliance monthly to the risk committee.
Roll back or adjust: if enforcement causes unsafe rushed changes or outages, revert the affected group to report-only, record why, and fix the delivery problem (testing capacity, rollout rings) rather than lengthening the SLA silently. Any SLA change goes through the same approval as the policy.
Tighten: once a group meets its SLAs consistently for two quarters, move its deadlines towards the external fast lane.

Detection and measurement

NIST SP 800-40 Rev. 4 warns that simple metrics such as total percentage patched are not actionable, and suggests weighting by asset and vulnerability importance, with measures such as the percentage of assets patched by their maintenance plan deadline and mean and median time to patch. It also notes that infrequent or unauthenticated scanning undercounts vulnerabilities and distorts results, so check scan coverage before trusting any SLA figure.

Metric	Definition	Why it matters
SLA compliance by tier	Findings closed within SLA divided by findings due in the period, per tier and maintenance group	The headline measure; report P0 and P1 separately so volume in P3 cannot hide misses
Mean and median time to remediate (MTTR)	From start-of-clock to verified closure	Median shows the typical case; a mean far above the median shows a long tail of stale findings
KEV exposure window	Days each KEV-listed finding was open past its KEV due date	Directly tied to BOD 22-01 and to real-world exploitation
Open exceptions and their age	Count by tier, with days since approval and days to expiry	Rising counts or many renewals show exceptions replacing remediation
Exceptions with verified controls	Percentage of active exceptions whose compensating controls were tested in the last [90] days	An unverified control is an assumption
Scan coverage	Assets scanned with credentials in the period divided by assets in inventory	An SLA on unscanned assets is meaningless

Log every SLA change, exception request, approval, renewal and expiry with the approver identity, and alert when an exception expires without action or a P0 finding passes 50 per cent of its SLA with no change ticket.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	ID.RA-01, ID.RA-06, PR.PS-02, GV.RM-02	Identify and record vulnerabilities; choose, track and communicate risk responses; maintain and remove software commensurate with risk; set risk appetite that bounds acceptance
NIST SP 800-53 Rev. 5	RA-5, SI-2, SI-2(3), CA-5, PM-4, RA-7, SA-22	Scanning; flaw remediation with organisation-defined time periods; time-to-remediate benchmarks; plans of action and milestones for open weaknesses; risk response; unsupported components
CIS Controls v8.1	Control 7, safeguards 7.2 and 7.7	Establish and maintain a risk-based remediation process; remediate detected vulnerabilities
ISO/IEC 27001:2022	Annex A 8.8 Management of technical vulnerabilities	Obtain information on vulnerabilities, evaluate exposure and take appropriate measures
MITRE ATT&CK	T1190 Exploit Public-Facing Application, T1133 External Remote Services, T1210 Exploitation of Remote Services	The techniques that short SLAs on exposed and remote-access services are meant to deny

Common failure patterns

SLAs looser than the rules that bind you: a 30 day "high" SLA on in-scope Cyber Essentials devices fails the 14 day requirement before anything else is measured.
Clock starts at detection with weekly or monthly scans: the reported time to remediate looks good while real exposure from vendor release is weeks longer.
Exceptions with no expiry: open-ended acceptances accumulate until the register is a list of the estate's worst systems with nobody accountable. Make expiry mandatory and enforced by tooling.
Compensating controls that are not tested: a WAF rule or "internal only" claim accepted on trust. Attackers bypassed WAF rules in the PeopleSoft campaign reported in 2026 by encoding one character.
Closing on patch when credentials leaked: tickets marked done after upgrade while stolen sessions or machine keys stay valid, as in CitrixBleed and ToolShell.
Approval by the requester's own team: the person who wants the delay approves it. Approval must sit with someone who owns the business risk, at a level matched to the tier.

Practitioner checklist

List every external remediation deadline that applies to any asset group and confirm internal SLAs are equal or tighter.
Write down the start-of-clock event and the closure evidence required for each tier.
Drive tiers from KEV status, EPSS or SSVC outcome and exposure, not CVSS alone.
Include secrets, certificates, cloud configuration and code findings in the SLA scope.
Require session revocation and secret rotation as closure evidence for credential-disclosing flaws.
Make every exception dated, owned, approved above the requester and enforced to expire in tooling.
Verify compensating controls against the real exploit, and re-verify every [90] days.
Report SLA compliance by tier, MTTR (mean and median), KEV exposure window and exception age monthly.

Remediation SLAs and Vulnerability Exceptions Guide: Setting Deadlines and Governing Exceptions