Fixed Patch SLAs vs Risk-Based Remediation Windows: Which Fixes the Right Things First

A fixed patch SLA that gives every "critical" 15 days and every "medium" 90 days is simple to audit, but it can leave an actively exploited medium on an internet-facing gateway open for three months while teams race to close criticals nobody is attacking. Risk-based remediation windows set the deadline from exploitation evidence, exposure and asset criticality instead of severity alone, which fixes the right things first but is harder to explain, automate and audit. This guide compares the two models: how each works, the threats each handles well or badly, how each fails in practice, the governance each needs, and the metrics that show which is working. It is written for vulnerability management leads, CISOs and auditors deciding whether to keep, replace or blend a severity-based SLA. Tier design and exception workflow detail sit in the Remediation SLAs and Vulnerability Exceptions Guide; this page is about choosing the model.

Key takeaways

• CVSS base scores measure severity, not risk. FIRST's CVSS v4.0 user guide says Base scores should not be used alone to assess risk, which is exactly what a severity-only SLA does.
• Fixed SLAs fail on exploited mediums and on volume. They spend effort evenly across findings, most of which will never be exploited, and give no fast lane to the few that are.
• Risk-based windows fail on governance, not maths. Opaque scores, unowned asset criticality and "the model said low" become new ways to defer work unless the rules are written down and audited.
• The best answer is usually a hybrid. Keep fixed outer deadlines that satisfy external rules, and let exploitation and exposure pull deadlines in, never push them out past the ceiling.
• Compare models on outcomes. Time to remediate KEV entries on exposed assets and exploited-vulnerability dwell time show which model protects you; percentage closed within SLA alone does not.

The short answer

Fixed SLAs suit small estates, organisations with little asset context, and environments where an auditor or contract demands a simple severity-to-days table. Risk-based windows suit larger estates with a reliable asset inventory, exposure data and a team that can maintain a scoring model. Most mature programmes run a hybrid: a fast lane driven by exploitation evidence (CISA Known Exploited Vulnerabilities, vendor or threat intelligence reports of exploitation), exposure modifiers that tighten deadlines for internet-facing and identity infrastructure, and severity-based outer limits that never exceed external obligations such as PCI DSS v4.0.1 Requirement 6.3.3 or Cyber Essentials.

How fixed SLAs work, and the threat they handle

A fixed SLA maps severity to days: for example critical 15 days, high 30, medium 90, low 180. The clock starts at vendor release or first detection, and every finding in a tier gets the same deadline whatever the asset. The model is built for one threat: the steady background of known flaws that attackers will eventually reach. Applied consistently, it shrinks the window across the whole estate, and it gives auditors, customers and regulators a table they can test.

Several external rules are themselves severity-based fixed windows, which is why fixed SLAs persist. Cyber Essentials (Requirements for IT Infrastructure v3.3, from April 2026) requires high-risk or critical updates to be installed within 14 days of release. PCI DSS v4.0.1 Requirement 6.3.3 sets one month for critical-vulnerability patches; high-risk ones must be fixed within a period the entity defines from its risk ranking. A fixed internal table that is equal to or tighter than these is easy to defend.

Where fixed SLAs fail

• Exploited mediums wait: a medium-rated authentication bypass on a VPN gateway that is being exploited still gets 90 days. Attackers chain such flaws (ATT&CK T1190 Exploit Public-Facing Application, T1133 External Remote Services) long before the deadline.
• Volume swamps the fast lane: FIRST's EPSS user guide notes that a severity-only policy can cover thousands of vulnerabilities, most of which will never be exploited. Teams work hard and still miss the few that matter.
• SLA gaming: the clock starts at first detection, so scanning less often delays the start; findings are split into new tickets to reset the clock; mitigations are recorded as fixes; or vendor severity is challenged to move a finding down a tier.
• Exception sprawl: when every critical has 15 days regardless of context, teams that cannot patch an isolated, low-value system raise an exception, and the exception register grows until nobody reviews it.
• Severity is stale: the base score is fixed at disclosure; when exploitation appears weeks later, nothing in the model moves the deadline.

How risk-based windows work, and the threat they handle

A risk-based model starts from the likelihood that a flaw will be exploited and the impact if it is exploited on this specific asset. It combines four signal groups:

• Exploitation evidence: the CISA KEV catalogue lists flaws with an assigned CVE, reliable evidence of active exploitation and clear remediation guidance. CISA says scanning, security research and public proof-of-concept code do not count as exploitation for KEV, and it advises non-federal organisations to write a requirement to immediately address KEV entries into their vulnerability management plans.
• Exploit likelihood: FIRST's Exploit Prediction Scoring System (EPSS) publishes, every day for every published CVE, a probability that it will be exploited in the wild within the next 30 days. FIRST is explicit that EPSS covers only the threat component and should never be treated as a risk score.
• Severity in context: CVSS v4.0 distinguishes CVSS-B (Base only), CVSS-BT (Base and Threat) and CVSS-BTE (Base, Threat and Environmental). Applying Threat and Environmental metrics is the consumer's job; providers usually publish only CVSS-B.
• Asset context: internet exposure, whether the asset is identity infrastructure or holds regulated data, compensating controls, and business criticality from the asset inventory.

CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) turns these into a decision with five decision points (exploitation status, technical impact, automatable, mission prevalence and public well-being impact) and four outcomes. Track and Track* are remediated within standard update timelines, Attend sooner than standard timelines, and Act as soon as possible. The threat a risk-based model handles best is the small set of flaws attackers are using right now against exposed systems. The Vulnerability Prioritisation Guide covers each signal in depth.

Where risk-based windows fail

• Opaque deferral: a proprietary score marks a finding "low risk" and nobody can explain why; work is deferred without a named decision.
• Stale or missing asset context: an internet-facing server recorded as internal, or a crown jewel database with no criticality tag, gets a long window. The model is only as good as the inventory.
• Low EPSS read as safe: FIRST notes EPSS is never zero; a low probability means lower threat, not no threat, and the probability across many low-scoring flaws on one host adds up.
• No ceiling: without an outer deadline, low-scored findings never come due, and the backlog ages into years.
• Breaking external rules: a model that gives a critical finding 60 days on a cardholder data system breaches PCI DSS 6.3.3 whatever the model thinks of the risk.
• Model drift: weights tuned once and never validated; new exploitation patterns or asset types are scored badly for months.

Threats and how each model responds

The credential row matters. In the ToolShell SharePoint exploitation, CVE-2025-53770 was added to KEV on 20 July 2025, and Microsoft stressed that patched servers also needed their ASP.NET machine keys rotated, because keys stolen before the patch let attackers forge trusted data later. Neither model closes that gap unless the definition of "remediated" includes rotation.

Decision criteria

1. Asset inventory quality: if you cannot say which assets are internet-facing, which are identity infrastructure and who owns each, a risk-based model will mis-score. Fix the inventory first and run fixed SLAs meanwhile.
2. External obligations: list every deadline that applies (PCI DSS, Cyber Essentials, Essential Eight, CISA BOD 22-01 for US federal systems, sector rules). These set ceilings any model must respect.
3. Backlog size: if open highs and criticals far exceed monthly remediation capacity, a fixed SLA is breached by design and risk-based ordering becomes necessary to decide what is breached.
4. Team capacity to run a model: a risk-based model needs someone to own the rules, data feeds and validation. Without that owner, a simple KEV fast lane on top of fixed SLAs delivers most of the benefit.
5. Audit appetite: auditors accept risk-based windows when the rules are written, reproducible and applied consistently, with records showing why each deadline was set.

Worked scenarios

Scenario 1: the exploited medium

A manufacturer runs a fixed SLA. A medium-rated flaw in its remote access gateway is added to KEV on a Friday. Under the fixed table it is due in 90 days. The team instead invokes an informal emergency process, but only because an analyst noticed the KEV feed. The review afterwards adds a written rule: any KEV entry on an internet-facing asset moves to the emergency tier with a deadline of days, and the vulnerability management tool alerts on KEV matches automatically. The fixed SLA stays for everything else. This is the cheapest useful step from fixed to hybrid.

Scenario 2: the deferred critical

A software company adopts a risk-based model. A critical flaw on a build server is scored low because the server is tagged internal. In fact the server has a public IP for a vendor integration. The finding sits for four months. The fix is governance, not scoring: asset exposure tags are now derived from external attack surface scans rather than manual entry, every critical has a 30 day outer ceiling whatever its score, and any deferral beyond the ceiling needs a named risk owner. See the Risk-Based Vulnerability Management Guide for model validation.

Governance and exception controls

• Escalate, never de-escalate on age: new exploitation evidence moves a finding to a shorter deadline and restarts the clock; nothing moves it to a longer one.
• Outer ceilings in policy: write the maximum days per severity into the vulnerability management policy so a model cannot exceed them. The Vulnerability Management Policy Template has a starting point.
• Decision records: store the inputs (KEV status, EPSS value and date, SSVC outcome, exposure, criticality) with each deadline so an auditor can reproduce it.
• Clock definition: start from vendor release or KEV addition, not first detection, so infrequent scanning cannot delay the start.
• Exceptions are dated risk decisions: a named risk owner, verified compensating controls and an expiry. NIST SP 800-40 Rev. 4 describes accepting, mitigating, transferring or avoiding risk as the options when a patch cannot be applied.
• Validate the model: each quarter, check which exploited flaws in your estate the model scored low, and adjust.

Implementing a move from fixed to hybrid

1. Baseline current performance: measure time to remediate by severity and, separately, for KEV entries on exposed assets over the last 12 months.
2. Add the KEV fast lane first: subscribe the scanner or a script to the KEV feed, alert on matches, and set the emergency deadline in policy. This needs no scoring model.
3. Fix exposure and criticality data: tag internet-facing assets from external scans and identity infrastructure (identity providers, domain controllers, privileged access tools) as top tier.
4. Pilot risk-based windows on one business unit: run both models in parallel for a quarter, compare outcomes, and record cases where they disagree.
5. Write the rules and ceilings into policy: include escalation-only re-scoring and the external ceilings table.
6. Roll out by asset class: servers and network edge first, then endpoints, then cloud and container findings.
7. Keep a rollback: if exploited-vulnerability dwell time rises or the backlog of ceiling breaches grows, revert affected asset classes to fixed SLAs while the model or data is fixed.

Metrics to compare the two models

Wider programme metrics and reporting are in the Vulnerability Management Metrics.

Framework mapping

Common failure patterns

• Switching to risk-based without an inventory: the model inherits every error in exposure and criticality data.
• Keeping fixed SLAs with no fast lane: exploited mediums on edge devices wait for their severity tier.
• Letting the model push deadlines out past external rules: a compliance breach created by design.
• Counting mitigations as fixes: a WAF rule or disabled feature closes the ticket, the real fix never happens, and the exception that should exist does not.
• Closing on patch alone: where a flaw exposed credentials or keys, as in the ToolShell case, the finding is not remediated until they are rotated.

Practitioner checklist

• List every external remediation deadline that applies and treat each as a ceiling.
• Add a KEV fast lane with automatic alerting, whatever model you run.
• Start the clock at vendor release or KEV addition, not first detection.
• Tag internet-facing assets and identity infrastructure from discovery data, not manual entry.
• Write scoring rules down and store the inputs behind every deadline.
• Re-score on new exploitation evidence, escalation only.
• Give every exception an owner, compensating controls and an expiry.
• Require secret and key rotation for flaws that may have exposed credentials.
• Compare models on KEV time to remediate and exploited-vulnerability dwell time each quarter.

Standards and references

• CISA: Known Exploited Vulnerabilities
• CISA: Stakeholder-Specific Vulnerability Categorization
• FIRST: CVSS v4.0 User Guide
• FIRST: Exploit Prediction Scoring System
• FIRST: EPSS User Guide
• NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
• IASME: Changes to Cyber Essentials for April 2026 (Requirements for IT Infrastructure v3.3)
• PCI SSC FAQ: risk rankings and resolving vulnerabilities

Related NHI Mgmt Group resources: Vulnerability Management Guide, Vulnerability Prioritisation Guide, Remediation SLAs and Vulnerability Exceptions Guide, Patch Management Guide, Emergency Out-of-Band Patching Playbook.