How to Use Risk-Based SLAs for Vulnerability Management

Most vulnerability SLAs start as a severity table. Critical in seven days, high in thirty, medium in ninety, low whenever.

It is simple. It is also one of the reasons teams miss SLAs constantly. When thousands of findings are labeled critical, a seven-day deadline for all of them isn't a commitment anyone can keep. And a moderate-severity vulnerability under active exploitation on an internet-facing system gets thirty days or more.

Risk-based SLAs fix that by setting response expectations from the factors that actually drive risk.

The inputs

A practical risk-based SLA model uses a few inputs teams can actually obtain.

Exploitation. Is the vulnerability known to be exploited, for example listed in CISA KEV or reported by trusted threat intelligence? Is there public exploit code? A high EPSS score?

Exposure. Is the affected asset reachable from the internet, from internal networks broadly, or only from a restricted set of systems?

Business impact. How critical is the asset? Does it handle sensitive data, support revenue, provide identity services, or hold deployment credentials?

Available mitigations. Is a fix available? Are there effective compensating controls in place?

Severity still matters, but as one input among these, not the only one.

A sample structure

Here is one way to translate those inputs into tiers. The timelines are illustrative; set your own based on capacity and risk tolerance.

Tier 1 — emergency. Known exploited and internet-facing, or known exploited on a high-impact asset. Expectation: mitigate or fix within days.

Tier 2 — urgent. Known exploited on internal assets; high likelihood of exploitation on exposed or high-impact assets. Expectation: fix within a couple of weeks.

Tier 3 — standard. High severity without exploitation evidence on exposed assets, or likely exploitation on internal assets. Expectation: fix within a normal monthly cycle.

Tier 4 — routine. Everything else. Expectation: fix through regular maintenance or upgrade cycles.

Two features matter more than the exact numbers. Tier 1 should be small enough that meeting its deadline is realistic. And every tier should have a deadline; "routine" doesn't mean "never."

Mitigate versus fix

Some situations allow two clocks: one for mitigation and one for full remediation.

For a Tier 1 vulnerability without an available patch, the expectation might be a compensating control, such as a WAF rule, a network restriction, or a disabled feature, within days, and a full fix within a set period after the vendor releases one.

Be clear about what counts as mitigation. It should be specific, verified, and recorded with an owner. And it shouldn't quietly replace remediation.

Make the inputs reliable

Risk-based SLAs depend on data. If exposure or criticality information is missing, the model can't work properly.

Set defaults for unknowns. An asset with unknown exposure might be treated as internal; an asset with unknown criticality as medium. Then treat missing data as a finding of its own, so the defaults don't become permanent.

Compute tiers automatically

Tiers should be assigned by code, not chosen by hand. Pull exploitation data, exposure, and asset criticality from their sources, apply the rules, and set the due date. Recalculate when inputs change.

That last point is important. If a vulnerability is added to KEV, or a system becomes internet-facing, its tier and deadline should change automatically. Notify the owner when that happens.

Handle exceptions explicitly

Some findings won't meet their SLA for legitimate reasons. Route them through a defined exception process with an owner, a reason, compensating controls, and an expiry date. Don't let SLA misses accumulate silently.

Communicate the model

Engineers are more likely to meet SLAs they understand. Each finding should show its tier and the reasons for it: "Tier 1 because it is listed in KEV and the service is internet-facing." If someone disagrees, they should be able to challenge the inputs with evidence.

Explaining it to auditors

Some compliance frameworks reference severity-based timelines. Many also accept documented risk-based approaches. Keep severity visible as an input, document the model and its rationale, and show it is applied consistently. Evidence of faster response to exploited vulnerabilities is usually a stronger story than uniform deadlines nobody meets.

Reviewing the model

Look at outcomes regularly. Is Tier 1 volume manageable? Are SLAs being met? Have any exploited vulnerabilities landed in low tiers? Adjust thresholds based on evidence.

The point

Risk-based SLAs set realistic, defensible expectations. They concentrate urgency on the vulnerabilities most likely to cause harm and give everything else a clear, achievable path.