Vulnerability SLA management
from policy to provable compliance
Findings without deadlines are findings nobody finishes. Run vulnerability SLA management on the engagement record so every finding carries a target close date by severity, every breach triggers a defined escalation, and every quarter produces audit-ready evidence of remediation performance. The SLA stops being a slide in a policy document and starts being a column on the queue.
No credit card required. Free plan available forever.
Run vulnerability SLA management on the engagement record
Most security programmes write a remediation SLA policy and never enforce it. The policy sits in a slide deck, the queue sits in a different tool, and the only time the two meet is at the quarterly review when an executive asks why critical findings closed in sixty days instead of seven. The cause is almost always the same: the SLA lives in a document rather than on the finding. SecPortal closes that gap by stamping the target close date on every finding driven by severity, surfacing the runway on the queue, escalating breach by severity to a named approver, and exporting the audit-ready evidence trail when ISO 27001, SOC 2, PCI DSS, or NIST asks for the proof.
This is the workflow view of SLA management. For the broader remediation lifecycle (open, in progress, awaiting retest, resolved), read the remediation tracking workflow. For deferred risk that legitimately sits outside the standard SLA, read the vulnerability acceptance and exception management workflow. For prioritisation logic that decides which severity a finding earns in the first place, read the vulnerability prioritisation framework and the operational vulnerability prioritisation workflow that captures CVSS, EPSS, KEV, asset tier, exposure, and compensating controls on every finding so the SLA tier inherits a defensible priority decision rather than a single-metric guess. For the categorisation primitive that decides the asset tier the SLA timer starts on, read the asset criticality scoring workflow. For analysis of how findings age past SLA into risk debt, read the research on aging pentest findings. For the calculator that produces defensible windows tied to PCI DSS, ISO 27001, SOC 2, and CISA KEV expectations, use the free remediation SLA calculator. For the signed policy document that publishes those windows as the firm rule, names the clock-start and stop-the-clock conditions, and defines the escalation ladder and exception path, copy the vulnerability SLA policy template. For the operational slice that lands inside the SLA runway when remediation requires coordination with an IT or infrastructure team, read the patch management coordination workflow which pairs patch decisions, maintenance windows, and post-patch rescan evidence to the finding without breaking the SLA evidence trail.
Default SLA tiers by severity
SLAs are the lever that turns a finding list into a programme. Without target close dates, severity is a label. The ladder below is a defensible starting point for most enterprise and consultancy programmes; tune the targets to your release cadence and the regulatory windows that apply, then record the policy on the engagement record so every finding inherits the same rules.
| Severity tier | Target close | When the tier applies |
|---|---|---|
| Critical (CVSS 9.0 to 10.0) | 7 days | Active exploitation risk, public exposure, no compensating control. The clock starts at confirmation and runs through weekends. Breach routes immediately to the engagement lead and the named senior approver. Critical SLAs are the headline metric in board reporting and the line PCI DSS, ISO 27001, and CISA KEV evidence packs read first. |
| High (CVSS 7.0 to 8.9) | 30 days | Significant impact mitigated by a control, requires authentication, or sits behind internal exposure. The window aligns with a normal release cycle, so engineering can slot the fix into the next planned deployment rather than treating it as out-of-band. Breach routes to the application owner and the security lead together. |
| Medium (CVSS 4.0 to 6.9) | 90 days | Material risk that can be addressed with normal release cadence. Tracked but does not interrupt the roadmap. Most remediation programmes ship medium fixes in batches; the SLA tier creates the deadline that keeps the batch from drifting into the next quarter. |
| Low (CVSS 0.1 to 3.9) | 180 days | Hardening or hygiene items. Bundled into a remediation sprint or shipped as a side effect of other work. Low SLAs are the tier most likely to age silently because they rarely escalate; surfacing them on the queue keeps the long tail visible. |
| Informational | Best effort | No directly exploitable risk. Tracked for context, often closed with an accepted-risk decision and a written rationale. Informational findings do not get an SLA breach state, but they do get a review cadence so the queue does not fill with stale records. |
Six failure modes that quietly break SLA programmes
Every SLA programme that fails an audit fails for one of the same reasons. The six modes below recur whenever the SLA lives somewhere other than the finding record itself. Each one is invisible at the time and visible at the next audit, retest, or post-incident review.
The SLA lives in a policy document, not on the finding
Many programmes have a documented SLA policy nobody applies in practice. The PDF says critical findings close in seven days; the queue shows criticals open for sixty. The fix is putting the SLA target on the finding itself so the runway is visible at a glance, not buried in a quarterly review.
Original severity drives the SLA, residual severity does not
A finding rated critical on its base CVSS but mitigated by a WAF rule or network segmentation may legitimately sit under a longer SLA. Treating original severity as the only signal forces unnecessary escalations on findings that compensating controls already neutralised, while ignoring findings whose residual is worse than their base score implies.
No clock pause for legitimate dependencies
A vendor patch, a scheduled retirement, or a third-party deployment window can legitimately pause the SLA clock. Without an explicit pause-and-resume mechanism, the clock either keeps running unfairly or quietly stops forever. The pause needs an expiry and a review trigger, not a verbal agreement.
Escalation happens in Slack, not on the record
When the SLA breaches and the engagement lead chases the owner in a side channel, the escalation is invisible six months later. Auditors cannot read it, leadership cannot trend it, and replacement engagement leads cannot reconstruct it. Escalation has to land on the finding so the trail survives.
Closure timestamps do not match the SLA evidence
A finding marked as resolved without a closure timestamp produces SLA reporting that is technically wrong but plausible. ISO 27001 and SOC 2 audits read the closure timestamp, not the resolution narrative. If the timestamp is missing or backfilled, the SLA evidence collapses.
The portal hides SLA state from the client
When the firm tracks SLAs internally but shows the client only an open-or-closed status, the client cannot see how much runway is left. The result is the recurring conversation where the client says "we did not realise this was urgent" and the firm says "the SLA was on the report." Surfacing the runway on the portal closes that gap.
Six fields every SLA policy has to record
A defensible SLA policy is six concrete fields on the engagement record, not an abstract sentence in a security policy document. Anything missing from the list below is a known gap in the audit trail rather than something a reviewer will spot in time.
Severity-to-target mapping
The lookup that converts severity tier to target close date. Either the headline pattern (7/30/90/180) or a tuned version aligned to release cadence and regulatory expectation. The mapping is on the engagement record, not in a Confluence page.
Clock-start trigger
The event that starts the SLA clock. Common triggers are first confirmation by the triager, finding promotion from unvalidated to validated, or first appearance in a delivered report. Different triggers produce different SLA evidence; the trigger is documented per programme.
Clock-pause rules
The conditions under which the clock pauses: vendor patch dependency with case reference, scheduled asset retirement with date, exception under review, scope dispute under resolution. Each pause carries an expiry so it cannot become permanent.
Escalation chain by severity
Who gets paged when a critical breaches; who gets paged when a high breaches; who gets paged when a medium breaches. Escalation is a record-level event on the finding rather than an out-of-band ping. The chain matches the residual severity, not just the original severity.
Reassessment cadence
The review interval at which open findings are checked against the SLA: weekly for criticals, biweekly for highs, monthly for mediums, quarterly for lows. The cadence drives the live queue rather than waiting for breach.
Closure evidence requirements
What proof is needed to close a finding under SLA: retest evidence, configuration diff, code change reference, or recorded exception. Closure without evidence is not closure under any SLA worth defending. The required evidence is named on the engagement so the owner knows what to attach.
Vulnerability SLA management checklist
Before any engagement opens new findings under the SLA, and at every quarterly review, the engagement lead and the remediation owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- The SLA policy is recorded on the engagement record, not in a side document.
- Severity-to-target mapping is consistent across every finding the engagement produces.
- CVSS 3.1 vectors drive severity, and severity drives the target close date.
- Each finding has a named remediation owner from the moment it is logged.
- The SLA timer counts down on the finding so the runway is visible on the queue.
- Approaching-breach state is a distinct signal, not just a colour change next to a date.
- Breaches escalate by severity to a named approver, recorded on the finding.
- Pause-and-resume events carry a reason, an expiry, and a review trigger.
- Closure timestamps match the SLA evidence the audit reads.
- Regressions reopen the original finding with the SLA resumed at the original window.
- The branded client portal shows SLA state alongside each finding.
- AI-generated reports include closure rate, MTTR, and breach rate by severity.
- The activity log exports the SLA evidence trail to CSV for ISO 27001, SOC 2, and PCI DSS audits.
- Quarterly review uses the report views, not a hand-built spreadsheet.
How SLA management looks in SecPortal
SLA management is one workflow stitched into four feature surfaces: the findings record, the engagement record, the branded client portal, and team management for escalation routing. The work that has to happen at each stage is the same work the platform already supports for everyday findings operations; the SLA layer just makes the deadline, breach event, and escalation chain explicit.
Policy on the engagement
The SLA policy is recorded on the engagement record itself, not in a side document. Every finding logged against the engagement inherits the severity-to-target mapping, the clock-start trigger, and the escalation chain so the SLA is enforced by default rather than reapplied each cycle.
Timer on every finding
Each finding stamps a target close date driven by the CVSS-derived severity and the engagement SLA policy. The runway is visible on the findings record, so anyone working the queue sees how much time is left before breach without opening a separate dashboard.
Queue ordered by runway
The dashboard segments findings by SLA state: in window, approaching breach, breached, and breached and overdue. Owners see their queue ordered by remaining runway rather than by creation date, so the work that is closest to slipping is the work the queue surfaces first.
Escalation by severity on breach
When the SLA breaches, escalation routes by severity. Role-based access in team management controls which approver receives which severity tier, so escalation lands on the authority level the residual risk warrants rather than flooding a single inbox.
Pause and resume with expiry
Vendor patch dependencies, scheduled retirements, and exceptions under review pause the clock as a deliberate event with an expiry. The pause records the reason and the review trigger so the clock cannot quietly stop forever. When the trigger fires, the clock resumes from where it stopped rather than restarting at zero.
Visible on the branded portal
The branded client portal shows SLA state alongside each finding so the client and the firm see the same picture. The runway, the breach state, and the exception status sit on the finding visibly, so neither side has to assemble the picture from the latest delivered report.
SLA reporting views the queue actually drives
The reports that drive SLA performance are not the static PDF that lands at the end of an engagement. They are the live views that owners, security leads, and auditors look at every week. The five below are the ones every meaningful SLA programme settles on, and they all derive from the live findings record rather than a parallel spreadsheet.
Closure rate by severity
Percentage of findings closed within their target window, broken out by severity tier. The headline metric leadership reads in board updates and the line ISO 27001 and SOC 2 audits expect to see trended over time.
Mean time to remediate
Average days from clock start to closure, by severity. MTTR is the trend metric the programme owner uses to demonstrate improvement and the metric a CISO presents to the risk committee when the programme is funded for another year.
Breach rate over time
Percentage of findings that miss their SLA, segmented by severity and by quarter. Breach rate is the leading indicator of programme strain; rising breach rate on mediums signals capacity pressure before criticals start slipping.
Exception register
Open exceptions with rationale, residual severity, expiry, and review cadence. The register pairs to vulnerability acceptance and exception management so paused-clock and excepted findings are visible rather than silently absent from the SLA picture.
Aging buckets
Open findings bucketed by days since clock start: under 30, 30 to 90, 90 to 180, and 180+. Aging buckets surface the long tail of unfixed findings that the headline metrics can hide. The 90+ bucket is where risk debt accumulates fastest.
Activity log export
Every status change, owner reassignment, escalation, pause, and closure event lands on the activity log with a timestamp. The CSV export is the audit evidence ISO 27001, SOC 2, PCI DSS, and NIST assessors expect to see when they ask for the SLA trail behind the headline numbers.
What auditors expect from a vulnerability SLA programme
Vulnerability SLA evidence shows up in audit reads whenever an external assessor reviews the security programme. The frameworks below all expect a documented policy plus enforcement evidence rather than a slide that names the targets without proving them.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 8.8 (technical vulnerability management) and Clause 9.1 (monitoring, measurement, analysis, and evaluation) expect documented timelines for remediation and evidence that the timelines are met or formally exceeded. SLA timers on findings, breach rate over time, and closure timestamps satisfy the evidence ask directly; a policy without enforcement evidence reads as a process gap. |
| SOC 2 | Common Criteria CC7.1 and CC7.2 expect the entity to detect and remediate vulnerabilities on a defined timeline. CC8.1 expects change controls including remediation tracking. SLA-driven remediation evidence with closure timestamps and named approvers is the artefact CC7.x and CC8.1 audits read. |
| PCI DSS | Requirement 6.3.3 expects critical security vulnerabilities to be addressed within one month of release of an applicable patch, and Requirement 11.3 expects rescanning until pass for in-scope systems. SLA tiers aligned to PCI windows, with closure timestamps and rescan evidence, produce the documentary trail the assessor expects. |
| NIST SP 800-53 | Control RA-5 (vulnerability scanning) and SI-2 (flaw remediation) expect documented timelines and evidence that vulnerabilities are remediated according to organisational risk assessment. SLA policy on the engagement, severity-driven targets, and breach evidence over time satisfy the control expectations. |
| CISA BOD 22-01 / KEV | Federal civilian executive branch agencies and any organisation aligning to the Known Exploited Vulnerabilities catalogue are expected to remediate KEV-listed vulnerabilities within tight windows (commonly two weeks for KEV findings on internet-facing systems). KEV-tagged findings can carry a tighter SLA than the base severity tier so the runway reflects the live exploitation context. |
Where SLA management fits across the vulnerability lifecycle
SLA management composes with the rest of the vulnerability lifecycle on the same engagement record so the deadlines, escalations, and closure evidence stay connected to the work that produced the finding and the work that will eventually retest it.
Upstream and adjacent
SLA management depends on scanner result triage promoting validated findings, on remediation tracking for the broader status workflow, and on vulnerability acceptance and exception management for the deferred-risk side that sits beside the SLA rather than against it. It feeds retesting because closure under SLA depends on retest evidence, and rolls up into vulnerability backlog management so per-finding SLA timers compose with the queue-level aging buckets and carry-over decisions the programme tracks cycle on cycle.
Programme and reporting
SLA evidence rolls up into the broader security testing programme and the pentest evidence management workflow, and feeds the security leadership reporting workflow where closure rate, MTTR, and breach rate become headline indicators on the weekly, monthly, and quarterly leadership cadences. The AI report generation engine produces the leadership and audit narratives from the live findings record rather than a parallel spreadsheet.
Pair the workflow with the long-form guides and the framework references
SLA management is operational; the surrounding guides explain the prioritisation logic that decides which severity a finding earns and the framework clauses that mandate documented timelines. Pair this workflow with the vulnerability prioritisation framework for the upstream severity decision logic, the vulnerability management programme guide for the broader programme context, and the aging pentest findings research for what unmanaged SLA breaches cost over time, and the MTTD vs MTTR research for how to pair detection-side latency against the same SLA windows so per-channel MTTD against scan cadence and intelligence ingestion sits next to per-severity MTTR against the framework anchors. The framework references that mandate documented remediation timelines include ISO 27001 for technical vulnerability management, SOC 2 for CC7.x and CC8.1 vulnerability monitoring, PCI DSS for requirement 6.3.3 patch timelines, and NIST SP 800-53 for RA-5 and SI-2 flaw remediation expectations.
Buyer and operator pairing
Vulnerability SLA management is the workflow dedicated vulnerability management teams run as the spine of the find-track-fix-verify loop, and the workflow internal security teams and AppSec teams run as the spine of their broader vulnerability programme. DevSecOps teams enforce SLA windows on findings produced by SAST, SCA, and authenticated DAST in the pipeline. vCISOs carry the approver role for residual-critical and residual-high breach decisions, and compliance consultants run the SLA workflow on behalf of clients who need ISO 27001 and SOC 2 audit evidence but do not yet operate a structured remediation programme.
What good vulnerability SLA management feels like
No invisible deadlines
Every finding carries a target close date driven by severity. The runway is on the queue, not in a side document. Owners see their work ordered by time remaining rather than by creation date, so the closest-to-slipping finding is the one the queue surfaces first.
Breach is a record event
When the SLA breaches, the breach lands on the finding record with a timestamp and an escalation routed by severity. The audit trail does not depend on memory or chat history; it depends on the events the platform recorded as the breach occurred.
Pauses cannot become permanent
Every clock pause carries an expiry and a review trigger. Vendor dependencies, scheduled retirements, and exceptions under review pause the clock deliberately. Pauses without an expiry are the most common path from a defensible SLA programme to a stale backlog the audit cannot defend; the platform does not allow them.
Evidence is derivative of the work
Closure rate, MTTR, breach rate, exception register, and aging buckets all derive from the live findings record. Nobody assembles the SLA evidence from a spreadsheet the week before the audit; the activity log export is the trail, and the AI report is the narrative.
Vulnerability SLA management is the discipline that turns a remediation policy into enforceable deadlines on each finding. Run it on the engagement record, and every SLA carries the audit trail from policy through stamp, breach, escalation, and closure that the firm and the audit both expect.
Frequently asked questions about vulnerability SLA management
What is vulnerability SLA management?
Vulnerability SLA management is the discipline that turns a remediation policy into enforceable deadlines on each finding. It covers the severity-to-target mapping, the events that start and pause the clock, the named owner per finding, the escalation chain on breach, the closure evidence requirements, and the reporting that proves SLA performance to leadership and auditors. SecPortal runs the workflow on the engagement record so every finding carries its target close date, the runway is visible on the queue, breach escalates by severity, and the activity log produces audit-ready evidence over time.
How is SLA management different from remediation tracking?
Remediation tracking is the broader workflow that follows a finding from open to verified close: owner assignment, status changes, retest pairing, regression handling, closure evidence. SLA management is the deadline-and-escalation slice within that workflow: the target close date driven by severity, the runway visible on the queue, the breach event recorded against the finding, the escalation chain, and the SLA evidence the audit reads. Both work on the same engagement record; SLA management is the time-bound contract that turns the broader remediation workflow into a measurable programme rather than a best-effort backlog.
What SLA targets should we use by severity?
A common starting point is critical within seven days, high within thirty, medium within ninety, low within one hundred eighty, and informational on best effort. Tune the targets to release cadence and the regulatory windows that apply (PCI DSS expects critical patches within thirty days of release, CISA BOD 22-01 expects KEV findings on internet-facing systems within roughly two weeks, ISO 27001 expects documented and met timelines). The policy lives on the engagement record, not in a separate slide deck.
Should the SLA clock pause for vendor patches and scheduled retirements?
Yes, as a deliberate event on the finding. A vendor patch dependency with a vendor case reference, a scheduled retirement with a confirmed date, an exception under review with a review trigger, and a scope dispute under resolution are all legitimate pause reasons. Each pause carries an expiry so it cannot become permanent. Pauses without an expiry are the most common path from a defensible SLA programme to a stale backlog the audit cannot defend.
How does SLA management handle compensating controls and residual severity?
A finding rated critical on base CVSS but mitigated by a compensating control (WAF rule, network segmentation, monitoring alert) may legitimately sit under a longer SLA. The exception workflow records the compensating control, the residual likelihood and impact, the named approver, and the review cadence. The finding stays on the queue with the residual SLA so it does not silently slip out of view, but it is not held to the original-severity window if compensating controls demonstrably reduce the residual exposure.
What happens when the SLA breaches?
Breach is a record-level event on the finding, not a Slack message. The platform marks the finding as breached, escalation routes by severity to the named approver, and the activity log records the breach event. From there, the breach either drives accelerated remediation, a documented exception, or an escalation to leadership. The trail of breach, escalation, and resolution stays on the engagement record so the audit can read what happened rather than reconstructing it from memory.
How is regression handled under the SLA?
When a previously closed finding reappears in a later scan or retest, the platform reopens the original finding with the regression noted and the SLA clock resumed at the original window. The history of close, regression, and re-close stays on a single record rather than forking into a new finding. Regression that creates a fresh record breaks the SLA trail and lets the original window quietly reset; pairing the regression to the original finding preserves both the SLA evidence and the auditability of the closure decision.
How should SLA performance be reported?
The reports leadership and auditors read are closure rate by severity, mean time to remediate by severity, breach rate over time, exception count and rationale, and the long tail of aging findings beyond ninety days. SecPortal generates these views from the live engagement record and exports the activity log to CSV when an auditor needs the evidence trail. The reports are derivative of the work, not parallel to it; nobody assembles the SLA evidence at the end of the quarter from a spreadsheet.
Should clients see SLA state on the branded portal?
Yes. SLA state is information the client needs alongside the finding itself. Hiding the runway on the portal creates the recurring conversation where the client says they did not realise the finding was urgent and the firm says the deadline was on the report. Surfacing the runway, the breach state, and the escalation status visibly gives the client and the firm the same view of the queue.
How does SecPortal support vulnerability SLA management?
SecPortal records the SLA policy on the engagement, stamps target close dates on every finding driven by severity, surfaces SLA state on the dashboard and the branded client portal, escalates breach by severity to the named approver, supports clock pauses with expiry and review triggers, and exports the activity log to CSV for ISO 27001, SOC 2, PCI DSS, and NIST evidence. SecPortal does not write the SLA policy for the firm; it makes audit-ready, time-bound vulnerability remediation the path of least resistance.
How it works in SecPortal
A streamlined workflow from start to finish.
Define the SLA policy by severity
A defensible SLA policy names target close dates per severity tier, the events that start the clock, the events that pause it, and the named owner of each tier. Tune the policy to your release cadence and risk tolerance, then record it on the engagement record so every finding inherits the same rules from day one. A policy that lives in a slide deck is a policy nobody enforces.
Assign owner and SLA on every finding
When a finding is logged, the platform stamps the severity, the CVSS 3.1 vector, and the target close date driven by the SLA policy. The remediation owner is named on the record, not implied. The SLA timer counts down on the finding so anyone reading the queue can see how much runway is left before breach.
Surface SLA state on the live queue
The dashboard segments findings by SLA state: in window, approaching breach, breached, and breached and overdue. Owners see their queue ordered by remaining runway rather than by creation date. The branded client portal mirrors the same view so the client and the firm read the same picture rather than reconciling two snapshots after the next steering meeting.
Route escalation on breach by severity
When the SLA breaches, escalation routes by severity. Critical breaches reach the engagement lead and a senior approver immediately. High breaches reach the application owner and the security lead. Medium and low breaches surface in the weekly review queue. Escalation is a deliberate event on the finding rather than a Slack message that ages out.
Track exceptions, regressions, and clock pauses
Some findings legitimately pause the SLA clock: a vendor patch dependency, a scheduled retirement, an exception under review. Each pause carries a reason, an expiry, and a review trigger so the clock cannot quietly stop forever. Regressions reopen the original finding with the SLA clock resumed at the original window so the audit trail does not fork into a new record.
Report SLA performance for audit and leadership
AI-generated reports, the activity log export, and the engagement record together produce SLA evidence: closure rate by severity, mean time to remediate, breach rate over time, and the rationale behind every exception. The CSV export covers the audit asks for ISO 27001, SOC 2, PCI DSS, and NIST. The leadership view covers the board ask for security programme performance.
Features that power this workflow
Run vulnerability SLAs as records, not as slides
Policy, timers, escalation, exceptions, and audit-ready reporting on one engagement record. Start free.
No credit card required. Free plan available forever.