A vulnerability remediation SLA that nobody meets is worse than having no SLA at all. It trains engineering teams to treat the deadline column as decorative, and it hands auditors a document that looks like governance but predicts nothing about actual risk exposure. Most SLA tables fail for the same reason: they were copied from a vendor whitepaper or a compliance framework template instead of built from the throughput and backlog data of the team that has to hit them. This article walks through how to size an SLA against real capacity, where the clock should start and stop, and how to measure compliance without creating incentives to hide findings.
Why copied 15/30/90 day tables get ignored within a quarter
The standard table looks familiar: critical in 15 days, high in 30, medium in 90, low in 180. It shows up in security policy templates because it is defensible on paper and easy to cite during an audit. The problem is arithmetic, not intent. If continuous scanning surfaces 40 new critical findings a month across your estate and your patching team can realistically close 25 critical-severity tickets a month once you account on-call rotations, change windows, and testing time, the backlog grows by 15 every month regardless of how disciplined anyone is. Month one looks fine because the backlog started near zero. By month three, a third of open criticals are already past due, and by month six the SLA number is background noise that nobody references in daily standups.
This is why the first step in setting an SLA is not picking numbers, it is measuring current throughput. Pull the last two to three months of remediation data: how many findings were opened per severity tier, how many were closed, and what was the actual median and 90th-percentile time to close for each tier. If your realistic critical-closure rate is 20 per month and discovery is running at 35 per month, no deadline column fixes that. The gap has to be closed with either more remediation capacity, a lower true-positive rate through better triage, or a narrower definition of what counts as critical for SLA purposes. Setting the SLA before doing this math guarantees a table that gets ignored.
Inputs that shape a realistic SLA: severity, asset tier, exposure, team capacity
A defensible SLA is a function of at least four variables, not a single severity column. Treating CVSS base score as the only input is the most common design mistake, because it ignores exploitability, asset criticality, and where the asset sits on the network.
- Severity, but exploitability-adjusted. CVSS base score alone tells you how bad exploitation would be, not how likely it is. Cross-reference the CISA Known Exploited Vulnerabilities (KEV) catalog and an EPSS score if you have one. A CVSS 7.5 with confirmed in-the-wild exploitation should have a shorter SLA than a CVSS 9.1 with no known exploit code and a complex attack chain.
- Asset tier. The same CVE on an internet-facing payment gateway and on an isolated internal test VM is not the same risk. Tiering assets (internet-facing production, internal production, dev/test/isolated) before you set SLAs is a prerequisite, not an optional refinement. This depends on having an accurate, current asset inventory rather than a spreadsheet last updated at the previous audit.
- Network exposure and compensating controls. A finding behind a WAF rule that blocks the specific exploitation vector, or on a segment with no route from the internet, carries materially lower real-world risk than the same CVE on a flat, internet-reachable network. Document the compensating control and its confidence level before extending a deadline based on it.
- Team capacity and change management constraints. Patch windows, freeze periods around quarter-end or holiday traffic, and the number of engineers who can actually apply and validate a fix all cap your real throughput regardless of what the policy document says. An SLA that ignores an annual two-week code freeze will show a suspicious compliance dip every year at the same time.
A sample SLA matrix with rationale per cell
Below is a starting matrix built around three asset tiers and four severity bands. Treat the numbers as a template to adjust against your own throughput data, not as a standard to adopt unmodified.
| Severity | Tier 1: internet-facing / crown jewel | Tier 2: internal production | Tier 3: dev, test, isolated |
|---|---|---|---|
| Critical or KEV-listed | 7 days | 14 days | 30 days |
| High (CVSS 7.0-8.9) | 14 days | 30 days | 60 days |
| Medium (CVSS 4.0-6.9) | 30 days | 60 days | 120 days |
| Low (CVSS below 4.0) | 90 days | 180 days | next scheduled patch cycle |
The rationale behind each row matters more than the specific day counts. KEV-listed findings get pulled into the shortest column regardless of their raw CVSS score, because confirmed active exploitation changes the calculation independent of theoretical severity. Tools that ingest the KEV feed on a daily basis, such as SITEY, can re-flag an existing open finding the moment its CVE is added to the catalog and automatically shrink its SLA, rather than waiting for the next manual severity review cycle. The tier-1 column is deliberately tight because that is where exposure and business impact both peak. The tier-3 column is loose by design: a finding on an isolated dev box that will be rebuilt at the next sprint boundary does not deserve the same urgency as one on a system processing customer data, and pretending otherwise just burns engineering attention that should go to tier 1.
Clock rules: when it starts, when it pauses, when it resets
An SLA without explicit clock rules is unenforceable, because every disputed case becomes a negotiation. Three rules need to be written down before the first ticket is opened.
When the clock starts
Start the clock at validated detection, not at raw scan completion. If a scanner flags a finding on Monday but it sits in a triage queue until Thursday before an analyst or an automated validation step confirms it is a true positive and not a scanner artifact, the SLA should start Thursday. Starting it at scan time punishes teams for triage latency they may not control, and starting it only when a ticket is manually assigned invites people to delay assignment. Platforms that separate discovery from validation as distinct pipeline phases, the way SITEY’s AI validation and triage stage does, timestamp the clock at confirmed exploitability rather than at initial scan output, which keeps triage backlog from quietly eating into remediation time.
When it pauses
Define a short, closed list of valid pause reasons: an approved risk acceptance is in progress and awaiting sign-off, a vendor patch does not yet exist and a tracked compensating control is documented, or the fix falls inside a formally declared change freeze. Every pause needs a logged reason and an owner, otherwise “pause” becomes a way to stop the clock indefinitely. Route pause requests through the same approval mechanism you use for exceptions elsewhere in your process, so a pause carries the same accountability as a deadline extension would in any other operational workflow.
When it resets
Two events should reset the clock rather than simply extending it. First, regression: if a finding is marked resolved, disappears from a scan, and then reappears (the patch didn’t hold, or was rolled back), the clock restarts from zero rather than picking up where it left off, because the original fix failed and the risk was live again in the interim. Second, re-scoping: if an asset moves tiers (a dev server gets promoted to production), recalculate the SLA against the new tier from the date of the move. This is where a lifecycle model earns its keep. If you’re documenting these transitions manually in a spreadsheet, look at how a dedicated vulnerability lifecycle process tracks state changes, since ad hoc tracking is where reset logic quietly breaks down.
Measuring SLA compliance without punishing honest reporting
The fastest way to destroy the value of an SLA program is to measure it in a way that rewards teams for finding less, not fixing more. If a team’s headline metric is raw count of open vulnerabilities, the rational response is to scan less often, narrow scope, or argue down severity ratings, none of which reduce actual risk. Three adjustments keep the metric honest.
- Track SLA attainment rate, not raw open count. Attainment rate (percentage of findings closed within their assigned SLA window, measured per severity tier) normalizes for scanning volume. A team that finds and fixes 200 vulnerabilities a month with 90% attainment is outperforming one that finds 20 and hits 100%, because the second team is very likely under-scanning.
- Watch the aging distribution, not just the average. Mean time to remediate hides a bad tail. Report the count and age of findings that are more than double their SLA window past due, per tier. A handful of ancient breaches sitting at 400 days on a critical tier-1 asset is a bigger signal than a slightly elevated average.
- Verify closure before it counts. An SLA measured against ticket status is trivial to game by closing the ticket before confirming the underlying finding is actually gone. This is the single most common way compliance numbers get inflated without anyone technically lying. Systems that automatically re-test the specific finding against the live asset before allowing closure, rather than trusting a patch script’s exit code or an engineer’s checkbox, are structurally harder to game. SITEY’s retest and closure phase works this way: it re-runs the original detection logic against the asset before the finding is allowed to leave the open state, so the attainment number reflects verified fixes rather than closed tickets.
Publish the attainment rate and aging distribution somewhere the remediation teams themselves can see it in near real time, not only in a quarterly report to leadership. Teams that can watch their own number move are far less likely to feel like the SLA is a stick used only after the fact.
Renegotiating an SLA that is structurally unmeetable
Sometimes the math from the first section never closes, no matter how much triage discipline improves. Signs it is structural rather than a discipline problem: attainment sits below roughly 60% for two consecutive quarters despite individual engineers hitting their personal velocity targets, and the backlog age keeps climbing even during months with no major incidents pulling people away. At that point, renegotiating the SLA is the correct move, not a failure to enforce it.
Bring data, not a complaint, to whoever owns risk acceptance for the organization: the throughput numbers from the first section, the attainment trend, and a capacity model showing what closing the gap would require in headcount or tooling. Present two or three concrete options rather than a single ask. That might mean lengthening the SLA for tier-2 and tier-3 assets while holding tier-1 firm, investing in automated patch management to raise closure throughput without adding headcount, or reducing the scope of what gets scanned by decommissioning assets that no longer need to exist. Route the decision through the same approval mechanism used for other risk exceptions in the organization, so the revised SLA has the same standing as the original one and isn’t seen as a quiet retreat. An SLA that gets renegotiated openly, with data, stays credible. One that just gets silently ignored does not.
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.