Vulnerability Remediation SLA: Timelines Teams Can Hit

A vulnerability remediation SLA is not a severity table with aggressive numbers. The problem is not choosing 15, 30, or 90 days. It is defining a clock that starts from trustworthy evidence, demands the right action, fits delivery capacity, and ends only when the outcome is verified.

Most weak SLAs fail quietly. The scanner starts a timer before anyone confirms the asset. A mitigation gets recorded as a fix. Exceptions pause the clock forever. Teams close tickets after deployment without checking the resulting state. Leadership sees a green percentage while exposed work ages outside the denominator.

A useful SLA is an operating agreement between security, service owners, change teams, and risk authorities. It should make broken promises visible early enough to change the outcome.

What is a vulnerability remediation SLA?

The SLA defines how quickly a confirmed condition must reach a named treatment outcome. It specifies scope, priority inputs, clock events, accountable roles, evidence for completion, exception rules, escalation, and reporting. The promised outcome may be immediate containment, durable remediation, a verified compensating control, or formal acceptance by an authorized risk owner.

Inside an organization, “service level agreement” can mean a policy target or internal service commitment rather than a contract. State which one you mean. A customer contract, regulatory requirement, internal standard, and engineering objective create different obligations even when they use the same number of days.

NIST does not hand every company a universal severity table. Its April 2022 enterprise patch management guidance defines a process that identifies, prioritizes, acquires, installs, and verifies patches. It asks organizations to build a strategy that fits mission and risk. Your clock has to live inside that operating system.

Which remediation deadlines do standards actually require?

Start with applicability, not a borrowed chart. PCI SSC published version 4.0.1 on June 11, 2024 and clarified that its 30 day installation requirement applies to critical vulnerabilities. The PCI DSS 4.0.1 change notice says the revision returned Requirement 6 language to that narrower scope. It does not establish a 30 day rule for every flaw on every company asset.

CISA uses different clocks for covered federal systems. A May 2025 federal evaluation guide states that agencies should remediate KEV entries from 2021 and earlier within six months under the original BOD 22-01 transition, and later KEV entries within two weeks. It also cites 15 days for critical and 30 days for high vulnerabilities on internet accessible systems under BOD 19-02. The CISA FISMA evaluation guide is a federal benchmark, not a private sector safe harbor.

Those numbers show why copying a generic severity matrix is careless. A rule may apply to a defined payment environment, a federal asset population, a customer contract, or an internal risk class. Document the source beside each mandated clock. Use local risk and capacity to set the rest.

What changed for SLA design in 2026?

Exploitation probability remains dynamic. FIRST publishes a new EPSS probability for every scored CVE each day. That changing signal makes one deadline for every “high” or “critical” label a poor allocation rule.

A material development arrived June 15, 2026, when EPSS version 5 began publishing. FIRST warns that a time series crossing a model version boundary can shift because methodology changed, not because the vulnerability changed. The official EPSS version history is a reminder to store score, percentile, model version, and observation date when an SLA tier depends on forecast data.

The practical rule is simple. Confirmed recent exploitation should interrupt the normal queue. Forecast probability should help order everything else. Neither signal knows whether the affected code is present, reachable, important, or already protected in your environment.

When should the SLA clock start and stop?

Start the response clock when the program has enough evidence to create a real obligation against an owned asset. Record the first observation too, but do not let an unverified scanner event silently consume half the delivery window. If validation routinely takes days, give triage its own target and report that delay.

Use two clocks for urgent findings. The exposure clock measures time to a verified containment that interrupts the likely attack path. The durable remediation clock measures time to permanent correction and fresh verification. This keeps a firewall rule or disabled feature from pretending to be a patch, while still giving credit for reducing immediate exposure.

Stop a clock on evidence, not status. A package manager success message proves that a command ran. It does not prove the vulnerable version is gone, the service restarted, the route changed, or the application still works. Closure needs a new observation of the promised state plus a health check appropriate to the service.

How should risk based SLA tiers work?

Build lanes from conditions that change urgency. Confirmed exploitation, public reachability, identity privilege, sensitive data, service consequence, reliable controls, and safe change constraints all matter. CVSS describes technical severity. EPSS estimates observed exploitation probability. KEV records confirmed exploitation. Local evidence decides whether those facts apply here.

A sample internal model might look like this. Treat the numbers as a design exercise, not a standard:

• Emergency: confirmed exploitation with a reachable path. Contain within 24 hours, then deliver and verify permanent treatment within seven days when a safe fix exists.
• Priority: a KEV entry or high forecast likelihood on an exposed, privileged, or critical service. Contain within three days and verify durable treatment within 14 days.
• Accelerated: a reachable condition with serious consequence but no current exploitation evidence. Verify treatment within 30 days.
• Planned: limited exposure, lower consequence, or effective durable controls. Treat within 60 or 90 days, or at the next approved release with a written review date.

Define overrides. A reliable negative applicability test can remove a false match. A working control can change the treatment lane but should not erase the underlying condition. New exploitation evidence can accelerate a deadline. A service becoming public can do the same without any change to the CVE.

The risk based vulnerability management guide shows how to turn exploitation, reachability, impact, and controls into explainable action lanes without hiding the reasoning inside one score.

Can your teams actually meet the SLA?

Run capacity math before policy approval. Suppose evidence gates create 120 priority obligations a month. Service teams can deliver and verify 80 in the same period. The backlog grows by 40 every month. A 30 day promise is already false even if the starting queue is empty.

There are only a few honest responses. Reduce weak inflow through better validation. Remove recurring causes. Add safe delivery capacity. Use tested automation for repeatable changes. Cut exposure while permanent fixes wait. Narrow scope only through an authorized risk decision. Moving the clock or excluding overdue records from the report is not capacity management.

Break capacity down by platform and action type. A Windows workstation update, a database upgrade, and a network appliance change do not consume equal effort or risk. An enterprise average can hide a blocked platform with no safe window. The vulnerability backlog guide explains how arrival rate, verified exits, age, and blocked work reveal whether the queue is stable.

Who owns each part of the SLA?

Security validates evidence, assigns the decision lane, and keeps the clock honest. A service owner accepts the obligation and coordinates delivery. The change team executes within a safe window. A risk owner approves temporary exceptions. An executive sponsor resolves conflicts involving capacity, availability, or policy.

Name people or durable roles, not vague groups. “Infrastructure” cannot accept a due date. Record the accountable person, acceptance time, delivery team, blocker, and escalation owner. If responsibility changes, preserve the history and transfer time.

Separate accountability for a finding from authority over an asset. Security can demand urgent action without owning the production change. A platform team can execute a patch without owning risk acceptance. Making those distinctions visible prevents the SLA from becoming a blame mechanism.

What makes an SLA exception legitimate?

An exception is a time limited risk decision, not a comment on an overdue ticket. Require the affected scope, reason, residual exposure, temporary control, control test, accountable service owner, approving risk authority, expiry date, and permanent treatment plan. Reapprove after material changes.

Pause clocks only for written events that actually prevent the promised action, such as a vendor fix that does not exist. Waiting for an owner, a normal change window, or internal debate is elapsed risk time. Report it. Otherwise every operational weakness becomes a pause reason and the metric loses meaning.

Expired exceptions return to the active overdue population automatically. Do not create a fresh record with a fresh age. Leadership should see how much exposure remains under temporary control and how often the same system asks for another extension.

Which SLA metrics expose the truth?

Report compliance by decision lane and use the full eligible denominator. Pair the percentage with counts, age bands, and data coverage. Ninety five percent compliance can still hide five overdue public KEVs if the denominator includes thousands of routine findings.

Show median and upper percentile time to confirmation, owner acceptance, containment, durable correction, and verification. Include reopened work, failed verification, active exceptions, expired controls, and blocked days by cause. These measures point to process changes. A single mean time to remediate number does not.

Track forecast revisions too. Compare planned arrivals and capacity with actual results each month. If the priority queue repeatedly exceeds safe capacity, change the operating design. The policy should force that conversation before an attacker does.

Where should automation and AI assist?

Automate source updates, due date calculation, owner routing, stale evidence alerts, exception expiry, and verification collection when inputs are deterministic. Deep endpoint context with AI driven analysis can draft the priority rationale and exact remediation or verification steps for practitioner review.

Do not let generated text start, stop, or waive a clock without a controlled decision. Artemes keeps sourced facts, observed context, missing evidence, and reviewer action visible so an SLA record can be defended later. Human risk authority still matters.

Frequently asked questions about vulnerability remediation SLAs

Is 30 days the standard deadline for critical vulnerabilities?

No universal rule applies to every organization and asset. PCI DSS 4.0.1 uses a 30 day requirement for critical vulnerabilities in its scope. Other obligations and internal policies differ. Verify applicability with the responsible compliance or legal owner.

Should the clock start at discovery or confirmation?

Preserve discovery time, but start the remediation obligation when evidence confirms an affected, owned asset. Give triage a separate target so slow validation remains visible.

Does mitigation stop a remediation SLA?

It may stop a separate exposure clock if the control is verified. It should not close the durable remediation clock unless policy explicitly accepts mitigation as the final treatment and a risk authority approves it.

How often should SLA tiers be reviewed?

Review them at least annually and after a material incident, regulatory change, major platform shift, or repeated capacity failure. Threat inputs and local exposure should update continuously within the approved model.

The executive takeaway

Pull 20 records this week and reconstruct every clock. Confirm the start event, promised outcome, owner, pauses, exception authority, and closure evidence. Then compare monthly priority arrivals with verified capacity. If the math does not work, change inflow, exposure, or delivery resources before approving a stronger looking target.