Vulnerability Remediation SLAs: How to Build a Risk-Based Framework That Actually Gets Patched On Time
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most vulnerability management programs have SLAs that nobody meets. The SLAs are CVSS-based (patch Critical in 30 days, High in 60 days), produce thousands of items labeled Critical, and give IT teams no way to prioritize within the Critical bucket. Attackers do not care about CVSS scores. They care about exploit availability and target exposure. A risk-based SLA framework uses exploitability signals to reduce the Critical remediation queue to the handful of vulnerabilities that are actually being exploited, and structures clear escalation and exception processes so that the program produces measurable outcomes rather than unmeasured backlogs.
Why CVSS-Only SLAs Fail
CVSS (Common Vulnerability Scoring System) measures the theoretical severity of a vulnerability in isolation: the attack vector, complexity, privileges required, and impact if exploited. It does not measure whether exploitation is occurring in the real world, whether your specific asset configuration is vulnerable, or whether the vulnerable service is exposed to the internet or an air-gapped internal network.
The result: a CVSS 9.8 RCE vulnerability in a Java library that is deployed in a development laptop with no network connectivity is flagged at the same severity as the same CVE running on an internet-facing authentication API with active exploitation in the KEV catalog.
In practice, this means:
- Thousands of Critical findings compete for the same remediation queue
- IT teams cannot determine which patch to apply first without additional context that security teams have not provided
- High-CVSS vulnerabilities with no active exploit get patched before lower-CVSS vulnerabilities that are being actively exploited
- Remediation SLA compliance is measured by count of items resolved, not by risk reduction achieved
The fix is to add exploitability and exposure context to every finding before the SLA clock starts.
Building the Risk Score: CVSS + EPSS + KEV + Asset Tier
A practical risk score combines four inputs:
CVSS Base Score (0-10): The theoretical severity from NVD. Use as a starting filter, not the final priority.
EPSS Score (0-1): The Exploit Prediction Scoring System assigns each CVE a probability that it will be exploited in the wild within 30 days. An EPSS score above 0.10 (10%) puts a vulnerability in the top 2% of all CVEs by exploitation likelihood. Query EPSS via the FIRST API:
https://api.first.org/data/1.0/epss?cve=CVE-2024-XXXXX
CISA KEV Membership: If the CVE is in CISA's Known Exploited Vulnerabilities catalog, active exploitation is confirmed. This is a binary signal that overrides all other scoring and triggers emergency SLA tier assignment regardless of CVSS.
Asset Criticality Tier:
- Tier 1: Internet-facing, handles authentication, stores PII/regulated data, or is a Tier 0 AD asset
- Tier 2: Internal-facing, business-critical application, lateral movement stepping stone
- Tier 3: Internal, non-critical, limited blast radius
Combine the signals into a simple risk matrix:
| KEV? | EPSS > 0.10? | CVSS >= 7.0? | Asset Tier | Remediation SLA |
|---|---|---|---|---|
| Yes | Any | Any | Any | 24-72 hours (Emergency) |
| No | Yes | Any | 1 | 7 days |
| No | Yes | Any | 2-3 | 14 days |
| No | No | Yes (7-9.9) | 1 | 30 days |
| No | No | Yes (7-9.9) | 2-3 | 60 days |
| No | No | Any | Any | 90 days |
This framework produces a manageable emergency queue (typically 5-20 items at any given time in most environments) while still assigning deadlines to all findings.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Structuring the Exception Management Process
Every SLA framework needs an exception process. Systems that cannot be patched within SLA due to vendor support requirements, application compatibility testing requirements, or business continuity constraints are a reality. Without a formal exception process, teams either miss SLAs silently or apply patches without proper testing.
An exception requires:
- Documented reason: Why the vulnerability cannot be remediated within SLA (e.g., patch not yet released by vendor, no approved testing window for 30 days, dependent system incompatible with patched version)
- Compensating control: What risk-reducing measure is in place while the exception is active (e.g., WAF rule deployed, service isolated to internal network, monitoring rule created for exploitation indicators)
- Risk acceptance sign-off: The asset owner (business unit lead) and CISO (for Emergency and Critical exceptions) sign off, acknowledging the residual risk
- Expiry date: Maximum exception duration by SLA tier: Emergency exceptions: 7 days before escalation to CISO, Critical: 30 days, High: 60 days, Medium/Low: 90 days
Exceptions that expire without remediation automatically escalate to the next approval level. An automated reminder 7 days before expiry gives the asset owner time to either remediate or renew with updated justification.
Document all exceptions in your vulnerability management platform (Tenable, Qualys, Rapid7, etc.) against the finding. This creates an audit trail that demonstrates the organization is managing accepted risks deliberately rather than allowing findings to age silently.
Metrics That Prove the Program Is Working
SLA compliance rate (vulnerabilities remediated within SLA / total vulnerabilities with expired SLA) is the headline metric but not the only one that matters. Measure and report:
Mean Time to Remediate (MTTR) by tier: How long does it actually take to patch Emergency findings? Critical findings? Tracking MTTR by tier shows whether the SLA targets are realistic and whether specific asset owners are systematically behind.
Breach rate by asset tier: Which Tier 1 assets have the most SLA breaches? This surfaces systemic patching process failures in specific teams or application stacks.
Open critical vulnerability age distribution: A histogram of how long Critical findings have been open. A program where the median open Critical finding is 45 days old has a different risk profile than one where it is 8 days old.
Exploited-in-wild finding remediation rate: For KEV and EPSS > 0.10 findings specifically, what is the on-time remediation rate? This is the metric that maps directly to breach prevention.
Patch coverage rate: What percentage of assets have been scanned and have findings assigned? A 100% SLA compliance rate on 60% of assets is not a good program.
Report these metrics to the CISO monthly and to the business unit leaders quarterly. Metrics shown only to the security team produce less remediation urgency than metrics shown to the managers of the asset owners who are missing SLAs.
Implementing the SLA Framework in Tenable or Qualys
Most enterprise vulnerability management platforms support SLA tracking natively. Configuration steps for the most common platforms:
Tenable Vulnerability Management (formerly Tenable.io):
- Enable CISA KEV integration in Settings > Integrations > CISA KEV (assets with KEV CVEs get auto-tagged)
- Configure Asset Criticality Rating (ACR) in Lumin for each asset
- In Analysis > Vulnerabilities, create saved searches filtered by:
vpr.score >= 9ANDplugin.xref == "CISA-KEV"for the emergency tier - Set SLA tracking via the Dashboards > SLA Tracker widget with target days per severity tier
Qualys VMDR:
- Enable the QDS (Qualys Detection Score) which incorporates EPSS and real-time threat intelligence
- Tag critical assets in the Asset Inventory using Qualys Tags
- Create Dynamic Dashboards with SLA widgets configured per tag group
- Use Workflow Rules to auto-assign remediation tickets with due dates based on QDS + asset tag
Integration with ticketing systems (Jira, ServiceNow): For every vulnerability finding that triggers an SLA, automatically create a ticket with:
- CVE number and description
- CVSS score, EPSS score, KEV status
- Affected asset hostname and asset tier
- SLA due date (calculated from finding date + tier deadline)
- Link to vendor advisory or patch
- Compensating control recommendations for emergency findings
Automatic ticket creation removes the delay between detection and remediation team awareness, which accounts for a significant portion of MTTR.
The bottom line
A vulnerability remediation SLA framework that nobody meets is not a security control. Reduce the emergency queue to what is actually being exploited (KEV and EPSS > 0.10), size SLA tiers by exploitability and asset exposure rather than CVSS alone, build a formal exception process so accepted risk is visible rather than invisible, and report MTTR and breach rate to asset owners who have the authority to change it.
Frequently asked questions
How do you handle vendor-published patches that require extensive testing before deployment?
Build patch testing timelines into the SLA calculation. For application patches that require regression testing (database servers, ERP systems, authentication services), add a standard 10-day testing window to the SLA before the deployment deadline. For Emergency tier findings on these systems, parallel-track emergency testing in a staging environment while deploying compensating controls (WAF rules, network isolation, IDS signatures) to reduce exposure during the testing window. Document the testing timeline as part of the exception record if it extends beyond the SLA.
What is EPSS and how is it more useful than CVSS for prioritization?
EPSS (Exploit Prediction Scoring System) is a machine learning model maintained by FIRST.org that predicts the probability a CVE will be exploited in the wild within 30 days, based on technical characteristics of the vulnerability and real-world exploit code signals. While CVSS measures theoretical severity, EPSS measures actual exploitation likelihood. Studies show that EPSS-prioritized patching programs remediate 7x more exploited vulnerabilities per patch deployed compared to CVSS-prioritized programs, because EPSS concentrates attention on the 4% of vulnerabilities that are actually exploited.
How do you handle a vulnerability with no available patch from the vendor?
A zero-day or unpatched vulnerability with no vendor fix requires a compensating control approach: network segmentation to isolate the vulnerable service, WAF virtual patching rules for web application vulnerabilities, enhanced monitoring and alerting for exploitation indicators, temporary service disablement if the risk exceeds the business value, and escalation to executive leadership for risk acceptance. Document the finding as a formal risk acceptance with compensating controls, monitor for vendor patch availability weekly, and set a calendar reminder to re-evaluate the risk acceptance when the patch becomes available.
How do you track SLA performance for assets managed by third-party vendors or MSPs?
Include vulnerability remediation SLA requirements in vendor contracts or MSP service agreements, specifying the same tiered SLA structure applied to internally managed assets. Require vendors to report scan results and remediation status on a defined cadence. For externally managed assets you cannot scan directly, use external attack surface management (EASM) tools or request vendor-provided scan reports. Track vendor SLA performance as part of your third-party risk management program and include it in annual vendor reviews.
How do you handle a vulnerability that requires a vendor patch but the vendor has gone out of business or abandoned the product?
A vendor-abandoned vulnerability with no patch available requires a permanent compensating control strategy, not a remediation timeline. Document the finding as an accepted risk with the following mitigations: isolate the vulnerable system from network segments it does not need access to (micro-segmentation or firewall rules), enable enhanced monitoring and alerting on the system for exploitation indicators specific to the vulnerability, assess whether the system can be decommissioned or replaced with a supported alternative, and require executive risk acceptance with a defined review date. Add the system to a decommission roadmap if replacement is feasible within 12-24 months. Never issue an SLA for a patch that does not exist.
How do I get engineering teams to take vulnerability SLAs seriously without creating adversarial dynamics?
Frame SLAs as shared risk management, not a security team enforcement mechanism. Three practices that work: (1) Present vulnerability context in engineering terms: instead of 'CVSS 9.8 critical, SLA is 7 days,' present 'This vulnerability allows pre-auth RCE on this service, which is internet-facing, and working exploit code was published 3 days ago.' Engineers respond to concrete impact, not abstract scores. (2) Involve engineering leads in defining the SLA tiers: when teams participate in setting what 'critical' means and what 7 days requires, they own the commitment. (3) Track SLA compliance at the team level and report it to engineering leadership alongside deployment frequency and reliability metrics. Make vulnerability SLA compliance a delivery metric, not a security metric.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.