Vulnerability Management SLAs: A Practitioner Guide

Most vulnerability management SLAs are aspirational and unmet. "Critical in 24 hours, high in 7 days, medium in 30" is the boilerplate you'll find copy-pasted across half the security policies online. Then the actual mean-time-to-remediate on critical findings runs into weeks, and everyone agrees not to look too hard.

This is the practitioner's version: what the SLAs are actually trying to express, what they should be, and how to set ones you can hit.

TL;DR

SLAs need two axes: severity of the finding and criticality of the asset.
A "critical CVE on a low-criticality lab host" and a "medium CVE on the production payment gateway" aren't the same urgency.
24/7/30 (24 hours / 7 days / 30 days for critical/high/medium) is industry standard but rarely realistic for everyone. Calibrate to what your team can actually deliver.
Track the SLA you can meet, not the SLA you wish you had. The gap is the conversation.

What a vulnerability management SLA actually is

It's a commitment to remediate findings within a stated timeframe based on their characteristics. Two parties:

Inside an organisation — security tells engineering "you'll fix critical findings within X."
Between an organisation and a customer / regulator — "we'll remediate critical findings within X before they materially affect you."

The first is internal discipline. The second is contractual. They're often written the same way but the consequences differ.

The standard table — and its problem

The boilerplate looks like this:

| Severity | Remediation SLA | |----------|------------------| | Critical | 24 hours | | High | 7 days | | Medium | 30 days | | Low | 90 days | | Informational | Best effort |

This is fine as a starting point. It breaks down because severity (a property of the finding) and risk (a function of finding × asset × exploitability) are different things. A CVSS 9.8 on an air-gapped backup host is not the same urgency as a CVSS 7.5 on the public payment API.

Two-axis SLAs

The more honest model adds asset criticality:

| | Critical asset | High asset | Standard asset | Low asset | |---|---|---|---|---| | Critical finding | 24 hours | 48 hours | 7 days | 14 days | | High finding | 48 hours | 7 days | 14 days | 30 days | | Medium finding | 14 days | 30 days | 60 days | 90 days | | Low finding | 30 days | 60 days | 90 days | Best effort |

What counts as a "critical asset" depends on the business — usually anything internet-facing, anything holding regulated data (PCI, PHI, PII), and anything supporting revenue-critical workflows.

The two-axis table is harder to communicate but more defensible. You're not arguing "this critical finding doesn't count" — you're arguing "this critical finding on this asset has a different urgency than the same finding on a different asset, and here's the published table that says so."

Defining severity consistently

Don't use the scanner's severity directly. Scanners vary in calibration; a "high" in Nuclei isn't the same as a "high" in Tenable. Establish your own mapping:

Internal severity: based on CVSS v3.1 base score
  Critical: 9.0–10.0
  High:     7.0–8.9
  Medium:   4.0–6.9
  Low:      0.1–3.9

Adjust the score based on environmental factors: is the affected service exposed externally? Is exploitation public? Is the asset behind compensating controls? CVSS environmental metrics formalise this, but a one-page internal scoring playbook usually beats the formal calculator for operational use.

When a Nuclei or Nmap finding comes in with a self-declared severity, treat it as an input — not the final answer.

Defining asset criticality

Score each asset (or tier of assets) once and reuse it:

Tier 1 — Critical
  - Production systems processing payments, PHI, or regulated data
  - Customer-facing authentication
  - Cryptographic key management

Tier 2 — High
  - Public-facing applications (not Tier 1)
  - Internal systems with broad employee access
  - CI/CD infrastructure

Tier 3 — Standard
  - Internal business applications
  - Development environments with prod-like data

Tier 4 — Low
  - Sandbox / lab systems
  - Ephemeral test environments
  - Documentation hosts

Tag every asset in your inventory with its tier. Tagging is the precondition for any meaningful SLA — without it, every finding's urgency is debated case-by-case.

What "meeting the SLA" means

Three states a finding can be in:

Remediated — fixed and verified. The vulnerability no longer exists.
Mitigated — compensating control deployed. The vulnerability technically exists but isn't exploitable in context (WAF rule, network segmentation, etc.).
Accepted — explicit decision to leave it open. Signed off by someone with authority, with an expiry date.

A useful SLA targets time to resolution, where resolution = remediated OR documented mitigation OR signed-off acceptance. "Time to fix" alone is too narrow; not every finding warrants a code change.

Acceptance isn't a get-out-of-jail-free card. A formal acceptance should include:

The specific finding (CVE + asset + URL / endpoint)
The risk justification
The mitigation in place
The owner
The re-evaluation date

When the re-evaluation date passes, the finding either gets remediated or re-accepted. This prevents "accepted in 2022, still accepted in 2026" rot.

Realistic SLA targets

For an internal team without a dedicated patching organisation:

| Tier | Critical | High | Medium | Low | |------|----------|------|--------|-----| | 1 — Critical | 7 days | 30 days | 60 days | Quarterly review | | 2 — High | 14 days | 30 days | 60 days | Quarterly review | | 3 — Standard | 30 days | 60 days | 90 days | Quarterly review | | 4 — Low | 60 days | 90 days | Quarterly review | Annual review |

For a regulated industry with mature operations:

| Tier | Critical | High | Medium | Low | |------|----------|------|--------|-----| | 1 — Critical | 24 hours | 7 days | 30 days | 90 days | | 2 — High | 48 hours | 14 days | 30 days | 90 days | | 3 — Standard | 7 days | 30 days | 60 days | 90 days | | 4 — Low | 14 days | 30 days | 90 days | Annual review |

Pick the version your team can actually hit. An SLA you miss 60% of the time is worse than a slightly slower SLA you hit 90% of the time.

How to actually hit them

A few practical patterns that move MTTR:

Make finding ownership automatic. Every asset has an owner. Findings auto-route to that owner. No triage queue, no "who fixes this".

Distinguish "ship a patch" from "deploy a patch". Most critical CVEs have vendor fixes available within hours. Your remediation pipeline is the rate-limiting step. If your bottleneck is the deployment process, your SLA target is really a deployment-velocity target in disguise.

Bake remediation time into capacity planning. Reserve a percentage of each team's sprint capacity for security findings. Without that reservation, security work loses every prioritisation argument to feature work.

Track noise separately. A finding count of 1,000 of which 950 are false positives is operationally different from 50 real findings. Filter aggressively. Tune the scanner. Accept and rule-out classes of false positives so they don't reappear.

Diff scans, don't full-scan. What changed since last week is far more actionable than the full current list. Modern scanners (and hosted ones) support diff-aware alerting. If yours doesn't, build it.

Reporting on SLAs

The dashboard should answer:

What's the current mean time to remediate (MTTR) by severity and tier?
What's currently overdue? (Finding count, age, owner.)
What's the trend? Week-over-week, month-over-month.
What's been accepted? How many findings, with what expiry dates?

Vanity metrics to avoid:

"Total findings closed this quarter" — doesn't differentiate noise from real work.
"Average CVSS score" — meaningless aggregate.
"Scan coverage percentage" — coverage matters but isn't an outcome.

Outcome metrics:

Critical-tier-1 MTTR. This is the number that matters most.
% of findings remediated within SLA. Should trend upward.
Number of accepted-overdue findings. Should trend toward zero.

When the SLA is wrong

If you're consistently missing the SLA, you have two choices: improve the operation, or change the SLA. Both are valid; the failure mode is doing neither.

Signs the SLA is wrong:

Findings frequently expire to acceptance because nobody had time to fix them.
A specific class of finding always misses (suggests a process problem, not a policy problem).
The team rolls their eyes when the SLA is mentioned.

Signs the operation is wrong:

The remediation work is straightforward but never gets prioritised.
Findings sit in queues with no owner.
The same vulnerabilities reappear after being "fixed".

Where hosted scanning helps

If you're managing this in-house with scattered tools, MTTR includes "find the finding". A hosted scanning service tightens that loop:

Findings arrive with consistent severity scoring.
PDF reports are deliverable to engineering / clients without reformatting.
Recurring scans mean the first time a finding appears, not its tenth re-scan, is when the SLA clock starts.

That last point is underrated. Without scan recurrence, your SLA clock effectively starts whenever someone remembered to scan — which is rarely "as soon as the vulnerability existed". Hosted recurring scans tighten the gap.

See VulnScanners for the runtime details.