Vulnerability Remediation SLA Policy Guide: Design, Codify, and Operationalise the Policy

Why a Vulnerability Remediation SLA Policy Is More Than a Document

Most organisations have an SLA document somewhere. It is usually a one-pager that lists four severity tiers and four target windows, signed off by the security director in a previous quarter, and stored in a folder almost nobody opens during day-to-day work. The document is not the policy. The policy is the rule the team applies on every finding, the timestamp on the record, the breach behaviour that fires when the window passes, the exception that lands on a register with an expiry, and the evidence that holds up when the auditor reads the trail. Documents that nobody operates are the most common cause of SLA breach reports that nobody trusts; policies that nobody can find on the finding record are the most common cause of audit findings against vulnerability management programmes.

The shift from document to policy is what separates programmes that report defensible SLA compliance from programmes that report numbers nobody can reconcile. The shift is operational, not editorial. The SLA target moves from the PDF onto the finding record. The confirmation timestamp moves from the analyst's memory to a field on the record. The breach behaviour moves from a verbal escalation in chat to a written escalation on the activity log. The accepted-risk exception moves from a director's email to a register with an expiry and a review trigger. The reporting moves from a quarterly slide that gets rebuilt every cycle to a running view that reads from the same record the team operates on.

The remainder of this guide is the structure that supports the operational shift. Each section is a part of the policy that needs an explicit decision, a written rule, and an operating mechanism. Programmes that skip the sections tend to find the gap during the first audit; the programmes that work through them tend to find that the policy stops being a document and starts being a rhythm.

Severity Tiers and Target Windows

The first decision is the tier set. The defensible starting point is the CVSS band, calibrated against the asset tier list and the regulatory regime. CVSS gives an objective seed; the calibration produces a defensible target. Anchoring on CVSS alone produces a policy that is hard to defend on findings where exploitability, exposure, or asset criticality push the actual risk up or down the band.

Tighter windows are appropriate for KEV-listed exploited vulnerabilities, internet-facing assets, and findings on systems that process regulated data; wider windows are appropriate for internal-only, fully mitigated, or low-data findings. The calibration lives on the policy, not in the analyst's judgement. A practical vulnerability SLA policy template is the starting artefact; the policy is the calibrated version your programme operates.

Clock Rules: Start, Pause, Resume, Stop

The clock rules decide whether the SLA reporting is trustworthy. The four rules are start, pause, resume, and stop. Each rule has a defined trigger, a recorded timestamp, and a written owner.

Base Severity, Residual Severity, and Overrides

Base CVSS captures the inherent severity of the vulnerability under the assumption that no compensating control is in place. Residual severity reflects the effect of controls that are already present: a WAF rule on the perimeter, network segmentation that limits blast radius, an upstream IAM policy that restricts the exploit precondition, a missing prerequisite the attacker would need. A mature SLA policy uses base severity to seed the tier and residual severity to adjust the target, with the adjustment written down.

The adjustment lives in three structured forms. A severity override changes the working severity for SLA purposes when the residual is materially different from the base. A false positive override removes a finding from the SLA when triage confirms it was not exploitable in context. An accepted-risk override moves the finding out of the active queue with an expiry and a review trigger. Each override has a recorded reason, an actor, and a timestamp. SecPortal supports the pattern through finding overrides, which preserves the decision across scan cycles so the next scan diff does not re-raise the same finding.

The override is not the same as the exception. The override changes how the SLA is computed for a specific finding for documented reasons (false positive, accepted residual, recalibrated severity). The exception, covered below, is the path for findings the programme has decided not to fix on the original timeline.

Exceptions and the Accepted-Risk Path

The policy collapses without an exception path. Programmes that try to force every finding to the same target time produce shadow workarounds: findings marked resolved without verification, findings closed and reopened on the next scan, findings reassigned to a different owner to reset the perceived clock. The exception path is the formal alternative.

A defensible exception record names the finding, the residual risk after compensating controls, the business justification, the named risk owner, the named approver, the expiry, and the review trigger. Findings that remain on the queue past the expiry without renewal return to the active SLA. The exception lives in an exception register that the programme owner reviews on a documented cadence (monthly for high-tier exceptions, quarterly for the rest). The security exception register template is one practical starting point for the register format.

Exception governance keeps the policy honest. When the exception count for a given tier rises faster than the burn-down, the signal is not that the policy is wrong; it is that the capacity is mismatched to the target or that a structural problem in the engineering organisation is absorbing the slack. The policy review then turns to either the target, the capacity, or the backlog rather than to a longer accepted-risk list.

The renewal cadence on the register is a deliberate cost decision rather than a calendar inheritance from the audit cycle. The exception renewal cadence economics research covers the four per-cycle cost components, the three avoided-cost components, the severity-banded cadence defaults, and the approver bandwidth constraint that bounds the design. Pair the SLA policy described here with that cadence model so the exception register stays current between audit cycles rather than scrambling to reconcile at fieldwork time.

Breach Behaviour and Escalation Rules

A breach is a trigger for a written action, not a failure state by itself. The standing options are explicit per tier so the engagement lead does not improvise the response in chat.

The four options are exhaustive at the policy level. Side-channel resolutions in chat that do not produce a record on the finding fall back into one of the four when the policy is applied. The vulnerability SLA breach escalation workflow is the operational form of the breach behaviour.

Ownership: Who Owns Each Step

An SLA policy without named owners produces breaches that nobody owns and escalations that nobody answers. The policy lists the role for each step rather than the person, so the policy survives organisational changes. The eight roles below cover most programmes.

• Triage owner. Validates the finding, confirms severity, sets the SLA target, assigns the remediation owner. Often the AppSec engineer or vulnerability management analyst.
• Remediation owner. Engineers the fix, ships the change, records the resolved-at timestamp with the proposed evidence. Often the application owner or platform owner of the affected asset.
• Verification owner. Confirms the fix actually closed the vulnerability, records the verified-at timestamp. Often the AppSec engineer who handled triage.
• Escalation approver. Signs off on extensions, accepts, and tier-driven escalations. Often the security director or the head of engineering.
• Risk owner. Signs off on accepted-risk exceptions with documented rationale and expiry. Often the business owner of the affected asset.
• Programme owner. Owns the policy itself, reviews the operating metrics, defends the budget, runs the periodic review. Often the head of vulnerability management or the security programme manager.
• Audit liaison. Produces the evidence pack on demand, reconciles the policy against the framework reads. Often GRC or compliance.
• Communications owner. Maintains the reporting cadence to leadership, the board, and where applicable, the customer reviewer. Often the CISO or the security programme manager.

The named roles map to RBAC on the platform that holds the work. SecPortal supports the ownership pattern through team management with four roles (owner, admin, member, viewer), where the workspace owner and admins handle policy administration and approvals, members operate the remediation and verification work, and viewers consume the reporting without write access.

Evidence the Policy Produces

The evidence pack is the part of the policy that holds up under audit, customer review, and board scrutiny. Six categories cover most read paths.

Framework Alignment

A well-designed SLA policy is read across frameworks rather than rewritten per audit. The policy is the single source; the framework read points to the relevant clauses.

Operating Metrics That Make the Policy Reportable

A policy without metrics is unevaluable. Six metric families hold up under leadership and audit review.

• SLA compliance by tier. Percentage of findings closed within the target window, per tier, per period. Trending the rate over multiple periods catches drift before it becomes systemic.
• Breach distribution. Count and severity of breaches in the period, grouped by application owner and asset tier. The distribution catches structural breaches that are masked by an aggregate compliance rate.
• Mean time to remediate by severity. Median and 90th percentile remediation duration per tier. Median is the operating signal; the 90th catches the long tail the median hides.
• Exception register state. Total count, expiry distribution, count of expired-but-not-renewed entries. A rising exception count without rising programme capacity is a structural signal, not a clerical one.
• Reopen rate. Findings reopened after being marked resolved or verified. A high reopen rate points to verification quality or fix completeness rather than the SLA itself.
• Capacity utilisation. Active findings per remediation owner and per application team. Pairs the SLA compliance rate with the underlying workload so leadership can read the capacity story alongside the compliance story.

The same metrics are the foundation of board reporting and customer assurance. The board reads a subset (often six to eight metrics across the policy and the broader programme); customers reading the security questionnaire read the policy, the operating metrics, and the audit evidence pack as a coherent set. The broader security programme KPIs and metrics framework covers the metric-design conventions.

Policy Review and Renewal

The policy is reviewed on three triggers. An annual scheduled review against the operating metrics, the regulatory landscape, the asset tier list, and the threat picture. An ad-hoc review when a material event shifts the assumptions: a KEV addition that affects a tier-zero asset, a regulator action in the sector, a new framework adoption, a major incident, a tool replacement, or a structural change in the engineering organisation. A continuous review through the operating metrics: if the critical-tier breach rate exceeds a threshold for two consecutive quarters, the policy is reviewed against the target or the underlying capacity rather than patched with a one-off exception list.

The renewal output is a versioned policy document, a list of changes from the previous version, the operating metrics that drove the change, and a re-approval by the named approver. The renewal lands in the same evidence path the auditor reads so the review history is reconstructible from the trail.

Common Failure Modes

Closing

A vulnerability remediation SLA policy is the part of the vulnerability management programme that turns a queue of confirmed findings into a calendar of accountable actions. The policy sits on the finding record, not in a PDF; the clock starts at confirmation, not discovery; pauses have an expiry; resolved is not the same as verified; breaches trigger one of four written actions; exceptions land on a register with an expiry; ownership is named per step; evidence is produced as a side effect of operating, not as a quarterly project. Programmes that operate the policy in this shape tend to report SLA compliance that reconciles to the audit, defend the budget with metrics leadership trusts, and renew customer assurance on better terms.

The substance of the policy is calibrated to the asset tier list, the regulatory regime, the engineering capacity, and the threat picture the programme operates against. The structure in this guide is the spine. The calibration is the work.

Frequently Asked Questions