Vulnerability remediation SLAs: how to set deadlines that reduce exposure

A vulnerability remediation service-level agreement, or SLA, defines how quickly a team must address a vulnerability, who owns the work, and what evidence counts as completion. It should also explain how the organization handles missed deadlines and exceptions.

Consider a finding marked “critical, due in 15 days.” Does completion mean deploying the patch, restarting the application, or verifying the fix across every affected system? Who acts if the next maintenance window falls after the deadline?

Those decisions belong in the agreement.

A useful remediation SLA gives the system owner work they can execute and gives security evidence it can verify. The model below explains how to define those commitments, including what to do when a permanent fix needs more time.

What should a vulnerability remediation SLA include?

Start with the affected asset and finding. A Common Vulnerabilities and Exposures identifier, or CVE, identifies a vulnerability. Your team still needs to establish where it applies and which action will address it.

Each remediation record should answer:

• Which assets and software versions are affected?

• What makes the finding urgent in this environment?

• Who owns the change, and when is it due?

• What treatment will the team apply, and how will it verify the result?

• Who can approve an exception, and when does that exception expire?

Make ownership specific enough that the person receiving the record can act. “Infrastructure” may identify a department, but it doesn't settle who schedules a restart or resolves a failed deployment.

For work spanning several teams, name one accountable remediation owner and record the dependencies separately. Moving a ticket between queues should preserve its original dates and history.

The recommendations in this article are an operating model to adapt to your environment. They are not a universal timetable or a substitute for applicable requirements.

A remediation SLA and MTTR answer different questions

An SLA defines the time allowed for an action. Mean time to remediate, or MTTR, measures how long completed remediation work took under a stated definition.

Keep those definitions separate when setting targets.

An industry average describes the organizations and findings included in a dataset. It doesn't establish how long your business should accept a particular exposure. Before using a benchmark, check its starting event, completion criteria, asset population, and reporting period. Also check whether it reports a mean or a median.

For your own reporting, define MTTR consistently. For example, you might measure elapsed time from the first confirmed applicable finding to verified closure, then calculate the average across findings closed during the reporting period.

That measure leaves unresolved findings outside the calculation. Report their age separately so an improving average cannot hide an aging backlog.

If you're investigating the delays behind those numbers, Vicarius's article on what slows critical vulnerability patching examines the handoffs and operational bottlenecks. An SLA should turn those dependencies into explicit responsibilities.

Separate exposure reduction from verified closure

A team may reduce exposure before it can complete a permanent fix. Your agreement should make that progress visible while keeping the remaining work open.

Use separate milestones for assessment, exposure reduction, and verified closure. Give exceptions their own review date.

This model distinguishes an untreated finding from one covered by a validated interim control. It also makes the remaining permanent-remediation work explicit.

Define each milestone before the work begins. If a mitigation satisfies an exposure-reduction target, record which assets it covers, how it works, and what limitations remain. Keep a separate deadline for permanent remediation whenever that work is still required.

How should you set remediation deadlines?

Assign deadlines using the affected environment, the available treatment, and applicable obligations. A severity score supplies part of that decision.

The Common Vulnerability Scoring System, or CVSS, distinguishes intrinsic vulnerability characteristics from threat and environmental factors. FIRST explains how those additional metrics refine the assessment in its CVSS v4.0 specification.

Before assigning urgency, establish whether an attacker can reach the vulnerable service, whether the affected feature is enabled, and what exploitation could allow. Consider the business process that depends on the system.

Then examine the treatment. A tested update and a configuration change may have different execution requirements. An interim control needs its own validation.

Set numeric targets in your policy for the resulting priority tiers. For each tier, specify the assessment deadline, the required treatment milestone, and the escalation path. State whether the clock uses calendar hours, calendar days, or business days.

Check that the execution plan fits the target. If patching depends on a maintenance window after the deadline, the owner needs an earlier decision about an emergency change, interim treatment, or approved exception.

Do not extend a deadline solely to make the compliance percentage look better. Record the risk decision and the operational constraint.

Define when each clock starts and stops

Write down the event that starts each SLA clock.

For an internal remediation target, that might be the first confirmed applicable finding on an asset. Keep the initial detection timestamp too, so time spent establishing applicability remains visible.

A contractual or regulatory obligation may use a different trigger. Track that requirement separately where necessary rather than replacing it with an internal convention.

Retain the timestamps for detection, applicability confirmation, owner assignment, treatment, and verification. Together, they show where time accumulated.

Specify how the policy handles duplicate findings, offline assets, and reopened vulnerabilities. Reassigning a ticket should not restart its clock.

For reopened findings, distinguish a failed original fix from a new occurrence. Preserve the earlier record and explain the relationship. Otherwise, a rollback can look like a fresh finding with a newly available deadline.

Reassess urgency when the evidence changes

Suppose a team initially identifies a vulnerable application on an internal system. It later discovers an externally reachable instance. The original priority decision needs review.

Define escalation triggers in advance. These can include new exploitation evidence, a change in reachability, or failure of an interim control. Name the person responsible for reassessing the finding and notifying the remediation owner.

The record should explain what changed, which action is now required, and whether the deadline changed. Retain the earlier decision so reviewers can reconstruct what the team knew at the time.

Vicarius's discussion of time-aware vulnerability prioritization provides further context for keeping those decisions tied to dated evidence.

If the evidence suggests compromise, involve incident response. Applying a patch addresses the vulnerable condition; it does not establish whether an attacker has already accessed the system.

Make exceptions expire

An exception records who accepted the remaining risk and under which conditions.

Require the requester to identify the affected assets and explain why the team cannot meet the deadline. Record the interim treatment, its validation evidence, and the exposure that remains.

The authorized risk owner should approve an expiration date or review trigger. The remediation owner needs a clear route to that decision.

Avoid explanations such as “business requirement” without detail. Name the constraint: an application dependency, an unresolved vendor issue, or a change that needs further testing.

At review, establish whether the reason still applies. Check whether a fix is now available and whether the interim control still covers the affected systems.

If an exception expires without a new decision, escalate it. Renewal should require an explicit review.

Agree on closure evidence before deployment

Define closure criteria while planning the work. That gives the owner a clear target and avoids a second debate after deployment.

NIST's enterprise patch-management guidance includes verification as part of the patch-management process. Installation is one stage of that process, alongside identifying and prioritizing the required updates. NIST SP 800-40 Rev. 4.

For a software update, closure evidence may include the installed version, completion of a required restart, and a fresh assessment. A configuration fix needs evidence that the setting changed and that the vulnerable condition no longer applies.

Check scope as well as success. If nine servers pass validation and one is offline, retain the unresolved server in the record. A mostly successful rollout should not close every affected asset.

Define the next action when validation fails. The owner may need to retry the update, investigate a dependency, or apply an approved interim treatment. Preserve the failed result so the next person can see what happened.

A remediation SLA template you can use

Complete the following record for each priority tier, then apply it to individual findings. The bracketed fields require your organization's decisions.

Scope: [Asset classes, environments, and finding types covered.]

Priority rule: [Evidence that places a finding in this tier, including conditions requiring escalation.]

Clock: [Starting event, calendar or business-time basis, and relevant time zone.]

Commitments: Assess within [duration]. Apply and validate the required treatment within [duration]. Complete verified closure by [deadline or policy rule].

Ownership: [Accountable remediation owner], with [security reviewer] responsible for checking the agreed evidence.

Closure evidence: [Required version, configuration, assessment, or control-validation records.]

Exception: [Authorized risk approver], [required justification], and [expiration or review trigger].

Escalation: [Recipient and action when ownership, treatment, or closure misses its target.]

Test the completed template against an overdue finding. If someone still needs to ask who approves the change or what closes the ticket, revise that field.

Example: a patch delayed by compatibility testing

Suppose an internet-facing application needs an update, but testing identifies a problem with a dependent service.

The remediation owner records the blocker and proposes a temporary access restriction. Security checks whether that restriction addresses the relevant exposure and covers every affected instance.

If it passes those checks, the team records the exposure-reduction milestone. The patch stays open under an approved exception with a named owner and deadline.

After deployment, the team confirms the installed version and validates the affected assets. It reviews whether the temporary restriction should remain.

This is an illustrative workflow. Access restrictions are not suitable for every vulnerability; the treatment must match the exploit conditions and operational requirements.

How Vicarius connects prioritization to remediation

Vicarius's approach to true remediation connects risk assessment with action on affected systems and validation of the result.

vScore combines CVSS, Exploit Prediction Scoring System (EPSS), and Known Exploited Vulnerabilities (KEV) signals with asset and business context to support prioritization.

The execution path depends on the finding. Within Vicarius's vulnerability remediation workflow, vPatch supports patch deployment on demand, on a schedule, or through policy rules. vScript supports custom remediation scripts for vulnerabilities and configuration issues.

vShield patchless protection provides a memory-level protection approach for supported applications when teams need protection before applying a patch.

For SLA design, connect those treatment decisions to evidence: the affected assets, the action taken, the validation result, and any remaining work. That keeps the agreement focused on reducing exposure.

Frequently asked questions

How many days should a critical vulnerability SLA allow?

Set the deadline using applicable obligations, exploitation evidence, asset exposure, business impact, and available treatment. A critical severity label alone does not define the right window. Your policy should specify numeric targets and conditions that trigger faster action.

Does mitigation count as SLA completion?

It depends on the agreement's completion criteria. A validated interim mitigation can satisfy an exposure-reduction milestone while permanent remediation remains open. Record the control's scope, its limitations, and the next review date.

Who approves a remediation SLA exception?

A risk owner with the authority defined in your policy should approve it. The remediation team supplies the technical evidence and proposed treatment. The approval identifies who accepts the remaining risk and for how long.

Which metrics should accompany SLA compliance?

Report unresolved finding age, time to validated treatment, expiring exceptions, and failed or reopened remediations. Define the measurement boundaries consistently so teams can compare results and identify where intervention is needed.

Put the agreement to work

Choose one overdue finding and follow it through your process. Identify its owner, the treatment decision, and the evidence required for closure.

Use that finding to frame a conversation about the remediation workflow your team needs.

Request a personalized vRx demo to explore Vicarius's approach to prioritization, patching, scripting, and patchless protection in the context of your environment.