Most patch SLA policies start the same way: someone copies “15 days for critical, 30 for high, 90 for medium” from a vendor whitepaper or a previous employer’s policy and pastes it into a security standard. Six months later an auditor asks why 40 percent of critical findings blew past day 15, and the honest answer is usually that the numbers were never tested against this organization’s patch cycles, change windows, or asset mix. A defensible SLA is not a table copied from somewhere else; it is a set of deadlines derived from your CVSS distribution, your exploit intelligence feed, your asset criticality tiers, and your change management calendar. This piece covers where the common numbers come from, how to map severity and exploit status to real deadlines, why asset classes need different clocks, where the clock should start, what an escalation ladder looks like when a deadline is missed, and what a working matrix looks like for a mid-size estate.
Where the 15/30/90-day numbers come from, and why copying them blindly fails
The 15/30/90 pattern traces back to sources copied without their context. NIST SP 800-40 Revision 4 recommends risk-based timeframes and avoids fixed day counts. PCI DSS Requirement 6.3.3 requires critical and high vulnerabilities on in-scope systems to be remediated within one month of patch availability, which is where a lot of “30 days for high” policies actually originate, not from CVSS-based reasoning. Insurance questionnaires and cloud shared-responsibility guides added a 15-day critical tier and a 90-day catch-all mostly because those are easy numbers to put on a form, not because they map to a specific threat model.
Copying these numbers unmodified fails for three reasons. First, they assume unlimited patching capacity: a team pushing updates to 200 endpoints per window will never close 3,000 medium findings in 90 days if that window only recurs monthly. Second, they ignore asset criticality: a 30-day SLA on a high-severity finding is too slow for an internet-facing VPN concentrator and needlessly fast for an internal file server behind layered segmentation. Third, they leave no room for regression testing; a team running core transaction processing may need five business days of testing before a kernel or database patch reaches production, and a blanket 15-day critical SLA does not allow for that.
Mapping severity and known-exploit status to internal deadlines
CVSS base score bands are a reasonable starting filter, not a policy by themselves: 9.0 to 10.0 is critical, 7.0 to 8.9 is high, 4.0 to 6.9 is medium, and 0.1 to 3.9 is low. Use the band to set the outer bound of a deadline, then tighten it with two additional signals: whether the CVE is listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and its EPSS score, which estimates the probability of exploitation in the wild within 30 days.
A workable mapping for internet-facing assets looks like this:
- Critical CVSS and KEV-listed: 72 hours
- Critical CVSS, not KEV-listed, EPSS above 0.10: 7 days
- Critical CVSS, not KEV-listed, EPSS below 0.10: 14 days
- High CVSS: 30 days
- Medium CVSS: 60 to 90 days
- Low CVSS: next scheduled patch cycle, no individual deadline tracked
The KEV and EPSS layer matters because CVSS alone both over- and under-prioritizes. A 9.8 CVSS deserialization bug in a component that is never exposed to the internet, with no known exploit code, can reasonably sit in the 14-day bucket. A 7.5 CVSS bug that CISA added to KEV last week because it is actively used in ransomware intrusions should not wait for its “high severity, 30 day” slot; it needs to move into the critical lane regardless of its base score.
Internal, non-internet-facing systems can generally run one tier looser, adding 7 to 14 days, if compensating controls such as network segmentation or a WAF rule are already documented and in place. Document the exception explicitly; do not simply widen the general policy to cover it.
Different clocks for servers, endpoints, network gear and OT systems
A single SLA number applied across every asset class produces a policy that endpoints cannot realistically hit, or one that is meaningless for network gear.
Servers, especially internet-facing ones, run the tightest clocks because they carry the most exposure. A critical, KEV-listed finding on a public-facing web server should trigger same-day or next-window patching regardless of what the general policy states.
Endpoints are bound by patch ring cadence, not by how fast IT could theoretically push an update. A typical rollout uses a pilot ring, roughly 1 to 5 percent of the fleet patched within 24 to 48 hours of release, a broad ring by day 7, and a final ring for high-risk or legacy machines by day 14 with active monitoring if it slips further. Set the SLA against the ring schedule, not the raw CVSS table, or every monthly cycle will register as a mass breach on day one.
Network gear, firewalls, switches, load balancers, usually cannot be patched without a maintenance window, and firmware updates often force a reboot that takes services down. Firmware SLAs read better in window units than in calendar days: “within the next two scheduled windows” is more honest, and more auditable, than “30 days” when the change board only approves network changes biweekly.
OT and ICS systems are where a literal calendar-day SLA actively causes harm. A PLC or SCADA historian frequently cannot be patched without a planned outage, and vendor-qualified firmware can lag the CVE by months. The realistic SLA for OT is a compensating-control SLA: isolate the segment, disable the vulnerable service or port, or deploy an inline virtual patch within the same window used for servers, then track the actual firmware update against the next planned outage with a real calendar date in the ticket, not “TBD.”
Where the SLA clock starts: discovery, disclosure or vendor release
This is the detail that unravels an SLA program in an audit, because three different start points produce three different numbers for the same finding.
Discovery-based: the clock starts when your scanner or team first detects the vulnerability. This is the fairest measure of your own team’s performance and the one most auditors accept, because it is directly observable in your ticketing system.
Disclosure-based: the clock starts on the CVE’s public disclosure date. This is what many vendor questionnaires and insurance forms actually ask about, and it can make a program look worse than it is if a feed import lagged, or better than it is if infrequent scanning left a vulnerability unnoticed for months.
Vendor-release-based: the clock starts when a patch becomes available. PCI DSS 6.3.3 uses this framing explicitly. It is the right clock for a narrow patch-application SLA, but the wrong one for a broader vulnerability management SLA, since a vulnerability can exist in an environment long before any vendor patch exists, and “no violation because no patch existed” is not a defensible answer to “were you exposed.”
The practical fix is to record all three timestamps on every finding: detected_at, disclosed_at, and patch_available_at, and use the discovery-based clock as the SLA of record while keeping the other two for context. Platforms built around a strict pipeline order, such as SITEY, an autonomous vulnerability management platform, log each of these as a separate timestamped event across discovery, validation and remediation rather than a single “found” field in one lifecycle record, which is what makes the discovery clock defensible months later instead of reconstructed from email threads.
Escalation ladder when a deadline is missed
An SLA without an escalation ladder is a suggestion. A workable ladder for a critical or high finding looks like this:
- T minus 3 days: automated reminder to the asset owner and their manager, ticket flagged amber.
- T plus 0, the deadline itself: ticket flagged red, breach recorded against both the finding and the owning team’s metric.
- T plus 7: escalation to the owner’s manager and the security team lead; the owner must provide a patch date within 5 business days or file a formal risk acceptance.
- T plus 14: escalation to the CISO or equivalent; a risk acceptance, if not already filed, becomes mandatory with a named approver and a hard expiry date, never “indefinite” or “pending review.”
- Risk acceptances expire on a fixed schedule, 90 days is a reasonable default for high and critical findings, forcing a re-look instead of a permanent exception nobody revisits.
Two things decide whether this ladder works or becomes another ignored dashboard. First, escalation has to fire from the same system that tracks the finding, not a spreadsheet updated manually once a week; by the time a manual tracker shows a breach, it is already stale. Second, assignment at intake has to be unambiguous: findings sitting in an unclaimed triage queue for several days burn a third of a 15-day critical SLA before the deadline starts to matter to anyone. A patch management workflow that routes a validated finding straight to the team that owns the affected asset, the way SITEY’s assignment step does, removes that dead period; whichever tool handles it, closing that gap is usually the single biggest lever against missed critical SLAs.
A sample SLA matrix for a mid-size estate
The table below is a starting matrix for an estate in the 500 to 5,000 asset range, with a monthly patch cycle for endpoints and a biweekly change window for servers and network gear. Treat it as a template to adjust against your own change calendar and capacity, not as a number to adopt unchanged.
| Severity | Internet-facing servers | Internal servers | Endpoints | Network / OT gear |
|---|---|---|---|---|
| Critical, KEV-listed | 72 hours | 7 days | Next ring, within 7 days | Compensating control in 72 hours; firmware at next window |
| Critical, not KEV-listed | 7 days | 14 days | 14 days | Compensating control in 14 days |
| High | 14 days | 30 days | Next ring, within 30 days | Next maintenance window |
| Medium | 30 days | 60 days | 90 days | Next two maintenance windows |
| Low | 90 days | Next patch cycle | Next patch cycle | Annual firmware cycle |
Whatever numbers your matrix ends up with, three things make it survive an audit: every deadline traces back to a documented criterion such as CVSS band, KEV status, or asset tier; the clock start is recorded per finding instead of assumed; and the escalation path is enforced by the ticketing system rather than by memory. Mapping each tier to the control it satisfies under ISO 27001, PCI DSS, SOC 2, GDPR, KVKK or BDDK also shortens the audit conversation; a compliance mapping layer that ties a finding directly to the control it closes turns “we have an SLA policy” into “here is the control, the finding, and the closure date.”
Closing the loop matters as much as hitting the date. A deadline met on paper because a patch job returned exit code 0 is not the same as a deadline met because the specific CVE no longer reproduces against the asset. Platforms that automate this last step, such as SITEY, re-run the original check through a dedicated retest and closure stage rather than trusting the patch command’s exit status, and only close the SLA clock once the finding is confirmed gone. Whether that verification is manual or automated, it belongs in the same record as the deadline, not a separate step someone might skip when the queue is long.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.