Vulnerability SLA breach escalation
from missed deadline to audit-ready trail
Every honest vulnerability programme breaches its SLA on some findings. The difference between a programme that survives audit and a programme that fails is whether each breach lands as a governed event on the finding with a named approver, a recorded decision class, a replacement deadline, and a defensible trail of what happened next. Run breach escalation on the engagement record so the chain is automatic, the decisions are constrained, and the evidence does not depend on memory.
No credit card required. Free plan available forever.
Run vulnerability SLA breach escalation on the engagement record
Every honest vulnerability programme breaches its SLA on some findings. Capacity changes, vendor patches slip, scope shifts, owners leave. The difference between a programme that survives an audit and a programme that fails is not whether SLAs ever breach. It is whether each breach lands as a governed event on the finding, with a named approver acknowledgement, a recorded decision class, a replacement deadline, and an audit-readable trail of what happened next. Breaches that drop into chat or a side spreadsheet are the invisible-now-visible-later failure mode that auditors find on every engagement that depends on memory rather than the record.
This is the breach-and-escalation slice of the vulnerability SLA programme. For the policy and timer layer that runs before breach, read the vulnerability SLA management workflow. For the deferred-risk path that sits alongside the SLA, read the vulnerability acceptance and exception management workflow. For the broader status workflow that follows a finding from open to verified close, read the remediation tracking workflow. For the prioritisation logic that decides which severity a finding earns in the first place, read the operational vulnerability prioritisation workflow and the long-form vulnerability prioritisation framework. For the leadership reporting cadence that consumes the breach metrics, read the security leadership reporting workflow. For analysis of how breached findings age into risk debt over time, read the aging findings research and the patch cycle vs remediation SLA mismatch research. For the post-breach population shape that names the cohort dynamics, the five exit routes, and the time-since-breach distribution leadership should read alongside the escalation cadence, see the SLA breach aging distribution research.
Escalation ladder by severity and residual context
The chain below is a defensible starting point for most enterprise vulnerability programmes. Each tier names a routing target and the underlying authority decision the breach has to surface. Tune the chain to your role structure and the regulatory expectations that apply, then record it on the engagement record so the right approver is paged automatically rather than guessed at breach. Residual-severity overrides route to the residual tier so compensating controls do not waste senior approver attention.
| Breach class | Routing and acknowledgement | Why the chain reaches this authority |
|---|---|---|
| Critical breach (CVSS 9.0 to 10.0 or KEV-tagged) | Engagement lead, application owner, and CISO or designated senior approver within the same business day. The breach event is recorded on the finding with timestamp, breached-by margin in hours, and the approver who acknowledged the page. | Critical breaches carry direct exploitation risk, regulatory reporting risk, and board-level reputation risk. The approver chain has to reach an authority who can fund an out-of-band remediation, accept the residual risk under a documented exception, or trigger a parallel incident response track if exploitation is suspected. |
| High breach (CVSS 7.0 to 8.9) | Application owner and security lead together, with the engagement lead copied. Acknowledgement required within two business days. A second escalation fires automatically if no plan is committed within five business days. | High breaches indicate the planned release cycle missed the finding. The approver chain has to surface why the fix slipped, the new committed date, and whether a temporary compensating control covers the residual exposure until the fix lands. |
| Medium breach (CVSS 4.0 to 6.9) | Application owner with the security lead reviewing in the weekly queue. Bulk-reviewed in the recurring SLA stand-up rather than paged individually unless the breach margin is meaningful or the finding pattern repeats. | Medium breaches accumulate as risk debt rather than as an immediate event. The approver chain has to decide whether to extend the SLA on the specific finding with documented rationale or to escalate the breach pattern into a capacity conversation with engineering. |
| Low and informational breach | Application owner with quarterly programme review. No individual page; surfaced in the quarterly SLA programme report and in aging buckets so the long tail does not silently fill the queue. | Low and informational breaches almost never carry immediate risk, but unmanaged they undermine the credibility of the SLA programme. The approver chain has to keep them visible without burning attention that the higher tiers need. |
| Exception override (residual-severity ladder) | When compensating controls demonstrably reduce the residual severity below the original CVSS tier, escalation routes to the residual approver tier rather than the original. A residual-medium with a critical original CVSS goes to the application owner, not the CISO, but the exception register records the residual logic and the named approver of the override. | Residual-severity escalation prevents alert fatigue at the senior tier and respects the compensating-control logic the programme already records. The exception register is the audit-readable evidence that the override is governed rather than informal. |
What a breach event has to record
A breach event is six fields on the finding, not a one-line status flip. Each field is the line an auditor reads when the assessor asks how the organisation governs missed remediation deadlines. Missing any one of the six is the gap that breaks the audit trail and the gap that turns leadership reporting into estimation.
Breach timestamp
The exact moment the target close date passed without closure. The timestamp is the audit anchor that ISO 27001 Annex A 8.8 and SOC 2 CC7.x evidence reads first; a breach without a recorded timestamp is a breach without evidence.
Breach margin
How many hours or days past the SLA the breach is, recalculated on every page until closure or formal extension. Margin is the line that turns a one-line breach event into a trended programme metric.
Named approver acknowledgement
The approver in the escalation chain who confirmed the breach has been seen, with their role recorded at the time of acknowledgement. Approver acknowledgement is the difference between an alert that fired and an escalation that was governed.
Decision class
Whether the breach drives accelerated remediation, an SLA extension with documented rationale, a documented exception, an incident-response handoff if exploitation is suspected, or asset retirement. Decision class is what the audit reads when it asks how each breach was resolved.
New committed date or exception expiry
The replacement deadline the approver agreed to: an accelerated close-by date for emergency remediation, a new SLA target for an extended plan, or an exception expiry that triggers re-evaluation. The committed date is what the next review checks against rather than the original breached date.
Communication record
Who was notified outside the platform (engineering manager, business stakeholder, security committee), with the channel and the date. Communication record is what the audit reads when it asks how the organisation knew the breach happened.
Six failure modes that break breach escalation
Every breach programme that fails an audit fails for one of the same reasons. Each mode below is invisible at the time and visible later at the next assessment, post-incident review, or programme deep dive. Naming the modes upfront makes them recoverable; ignoring them turns a working SLA into a programme that reports a comfortable number leadership cannot trust.
Escalation lands in chat instead of on the finding
When the engagement lead chases an owner in Slack or email at breach, the trail is invisible six months later. Auditors cannot read it, replacement engagement leads cannot reconstruct it, and the security committee gets a verbal summary instead of an evidence-backed view. Breach has to land as a record event on the finding so the trail survives a personnel change.
Every breach pages the CISO
When a programme escalates every breach to the same senior approver, alert fatigue sets in fast. The CISO stops reading the page, the page becomes background noise, and the next real critical disappears in the volume. The escalation ladder has to match severity and residual context, not single-route every breach to the same authority.
No SLA extension path
Programmes without a documented SLA extension mechanism either let breaches sit forever in breached-and-overdue or quietly close findings without remediation. Both options break the audit trail. An explicit extension with named approver, rationale, new target date, and review cadence is the only path that survives audit scrutiny.
Exception register is parallel to the SLA queue
When exceptions live in a side spreadsheet rather than on the finding, escalation cannot read whether a breach was already covered by an exception under review. The result is escalation noise on findings the programme had already governed. The exception register has to sit on the finding so escalation logic respects the residual decision.
No re-breach handling
When an extended SLA breaches a second time, the programme often treats it as a fresh breach rather than as evidence of structural delay. A second breach on the same finding has to escalate one tier higher than the first because the underlying capacity, ownership, or scope problem did not get solved by the extension.
Breach metrics report on volume only
Reporting that counts breaches without breach margin, severity mix, or repeat rate hides the worst signals. Five small breaches and one massive breach show the same count. Reporting has to surface margin, severity distribution, and repeat rate so the leadership view reflects real programme strain rather than total volume.
Six fields every escalation policy has to record
A defensible breach escalation policy is six concrete fields on the engagement record, not a paragraph 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. The fields compose with the SLA policy itself so escalation is the natural continuation of the engagement-recorded SLA, not a parallel process.
Escalation chain by severity and residual
The named approvers for each severity tier and each residual-severity override. The chain is recorded on the engagement record so every finding inherits the same rules at logging time rather than being routed ad hoc at breach. The chain references roles in team management RBAC so the right authority is paged even when the named approver is on leave.
Page channel and SLA
How the approver is paged (in-product notification, email, or webhook to a downstream notification system), and how fast acknowledgement is expected (same business day for critical, two business days for high, weekly review for medium and lower). The page SLA has its own clock so an unacknowledged page escalates one tier higher.
Decision-class catalogue
The set of permitted decisions an approver can record against a breach: accelerated remediation, SLA extension, formal exception, incident-response handoff, asset retirement, or downgrade-on-compensating-control. Constraining the catalogue makes audit comparisons possible across breaches and over time.
Re-breach escalation rule
The rule that pushes a second or third breach on the same finding one tier higher in the chain. Re-breach rules prevent the same finding sitting in a quiet extend-and-extend loop and surface the underlying capacity or ownership problem early.
Communication template by audience
The pre-written communications that go to engineering management, security committee, board risk committee, and (for hosted clients) the branded portal at breach. Templates keep the language defensible across breaches and across people; the variable fields fill from the live finding record rather than retyping each time.
Closure evidence requirement
What proof is needed before a breached finding can be closed: retest evidence, configuration diff, code change reference, recorded exception, or asset retirement. The requirement is named on the engagement record so the owner knows what to attach. Closure without evidence is not closure under any breach programme worth defending.
Breach escalation checklist
Before findings open under an SLA on a new engagement, and at every quarterly programme review, the security 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 escalation chain is recorded on the engagement record before findings open under SLA.
- Each severity tier names a primary approver, a deputy, and a page channel.
- Residual severity routes escalation to the residual tier, not the original CVSS tier.
- Breach events record timestamp, breach margin, decision class, and named approver acknowledgement.
- KEV-tagged findings escalate at the next tier higher than their base CVSS class.
- Exception register is on the finding so escalation respects the residual decision.
- SLA extensions carry a new target date, rationale, named approver, and review cadence.
- Re-breach on the same finding escalates one tier higher than the first breach.
- Communication templates for engineering, security committee, and board are prewritten.
- Breach reports surface margin distribution and repeat rate, not just count.
- Activity log captures every breach event, escalation, extension, and closure for the audit trail.
- The branded client portal mirrors breach state where the workspace has external stakeholders.
How breach escalation looks in SecPortal
Breach escalation is one workflow stitched into four feature surfaces: the findings record, the engagement record, team management for the approver chain, and notifications for the page itself. The work at each stage is the same work the platform already supports for everyday findings operations; the breach layer just makes the event, decision class, and approver acknowledgement explicit.
Chain on the engagement
The escalation chain is recorded on the engagement record itself. Every finding logged against the engagement inherits the chain, the severity-to-routing mapping, and the page channel so the right approver is paged automatically rather than guessed at breach.
Breach event on the finding
When a target close date passes without closure, the breach lands as a record event on the finding with timestamp, breach margin, severity tier, and the inherited escalation chain. The event is queryable, exportable, and auditable rather than a colour change in the queue.
Notification by severity
Notifications fire to the named approver in the chain when the breach event records. Critical and high-tier pages reach the approver same business day; medium and lower-tier breaches surface in the weekly queue. The page itself carries the breach margin and the decision-class catalogue rather than only a finding link.
RBAC drives the chain
Team management with role-based access controls which approver receives which severity tier, so escalation lands on the authority level the residual risk warrants. Deputy approvers cover leave and rotation without breaking the chain. Role-level routing also means personnel changes do not silently break the escalation flow on existing engagements.
Decision class on the breach
The approver records the decision against the breach event: accelerated remediation, SLA extension, formal exception, incident response handoff, asset retirement, or compensating-control downgrade. The decision becomes the next field on the finding so the audit trail reads sequentially from breach to resolution rather than reconstructed from comments.
Visible on the branded portal
For workspaces that engage external stakeholders, the branded client portal mirrors the breach state and the decision class so the external owner reads the same picture the internal owner reads. SLA evidence does not depend on a parallel email summary.
Breach reporting views the queue actually drives
Headline breach counts hide most of what leadership actually has to see. The six views below are the ones every meaningful breach programme settles on, and they all derive from the live findings record rather than a parallel spreadsheet assembled the week before the board pack.
Breach rate by severity
Percentage of findings that missed their SLA, broken out by severity and by quarter. Rising breach rate on mediums signals capacity pressure before criticals start slipping; that early signal is the difference between a planned capacity conversation and an emergency one.
Mean breach margin
Average days a breached finding sits past its SLA before resolution. Margin distinguishes a healthy programme that sometimes breaches by a day from a backlog programme where breaches age into weeks; the count alone cannot tell those apart.
Repeat-breach rate
Findings that breached more than once, segmented by severity. Repeat breaches are the leading signal of unresolved capacity, ownership, or scope problems; the re-breach rule pushes them one tier higher so the underlying problem surfaces rather than being absorbed by another extension.
Decision-class distribution
How approvers resolved breaches: percentage accelerated, percentage extended, percentage excepted, percentage retired, percentage handed off to incident response. Distribution patterns reveal where the programme genuinely cannot meet the SLA versus where exception cover is filling in for capacity.
KEV-tagged breach view
Breaches on findings tagged against the CISA Known Exploited Vulnerabilities catalogue are reported separately. KEV breaches carry live exploitation evidence; the programme cannot treat them as ordinary severity-tier breaches. A separate KEV view forces the programme to defend each one individually rather than rolling them into the headline.
Activity log export
Every breach event, escalation, approver acknowledgement, decision recording, extension, exception, and closure lands on the activity log with 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 breach trail behind the headline numbers.
What auditors expect from a breach escalation programme
SLA breach evidence shows up in audit reads on every assessment of the vulnerability management programme. The frameworks below all expect a documented timeline, evidence of enforcement, and evidence of governed response when the timeline is missed. A breach without governed escalation reads as a process gap; a governed breach reads as a working programme.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 8.8 (technical vulnerability management) and Clause 9.1 (monitoring, measurement, analysis, and evaluation) read for documented timelines plus enforcement evidence. A breach without governed escalation reads as a process gap. The activity log breach events, the escalation chain on the engagement record, and the exception register together produce the evidence the assessor expects to see when SLA performance falls below 100 percent (which it always does in any honest programme). |
| SOC 2 | Common Criteria CC7.1 and CC7.2 read for vulnerability detection and remediation on a defined timeline. CC9.x (risk mitigation) reads for documented decisions on residual risk. SOC 2 Type 2 audits read twelve months of escalation evidence rather than a snapshot, so the breach trail has to be continuous and tied to the SLA policy that was in force at the time of breach. |
| PCI DSS v4.0 | Requirement 6.3.3 reads for critical security vulnerabilities addressed within one month of applicable patch release. Requirement 11.3 reads for rescanning until pass. Requirement 12.10.2 reads for documented incident response when an exploited vulnerability triggers IR. Breach escalation that triggers an IR handoff has to record the handoff on the finding so the PCI assessor can trace the decision. |
| NIST SP 800-53 Rev. 5 | RA-5 (vulnerability monitoring and scanning) and SI-2 (flaw remediation) read for documented timelines and remediation evidence. CA-7 (continuous monitoring) reads for the escalation cycle. PM-15/PM-16 (programme management) reads for governance evidence at the programme level. The breach decision class and the approver acknowledgement together produce the line CA-7 reads when the assessor asks how the programme governs missed remediation deadlines. |
| 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). A KEV-tagged breach has to escalate at the next tier higher than the base CVSS class so the live exploitation signal is reflected in the escalation chain rather than treated as a normal severity-tier breach. |
| CISA CPGs v2.0 | Goal 2.O (known exploited vulnerabilities) reads for the same accelerated treatment as KEV. The cross-sector CPGs read for a governed programme that names accountability, decision authority, and review cadence; an SLA breach programme that records the named approver per tier, the decision class catalogue, and the re-breach rule directly satisfies the CPGs accountability expectation. |
Where breach escalation fits across the vulnerability lifecycle
Breach escalation composes with the rest of the vulnerability lifecycle on the same engagement record so the breach event, the decision class, and the replacement deadline stay connected to the finding that produced them and the audit trail that will eventually read them.
Upstream and adjacent
Breach escalation depends on the upstream vulnerability SLA management workflow for the policy and timer, on the exception management workflow for the deferred-risk side, on asset criticality scoring for the tier-tagging that drives residual severity, and on threat-intelligence-driven prioritisation for the live-exploitation signals (CISA KEV, EPSS) that change the escalation tier on breach.
Downstream and reporting
Breach evidence rolls up into security leadership reporting for the leadership cadence, into control mapping cross-framework crosswalks for the audit trail across regimes, and into audit evidence retention and disposal for the lifecycle of the breach record itself. When the breach class triggers an incident response handoff, the path forks into incident response and breach notification and regulator readiness.
Pair the workflow with the policy templates and the framework references
The breach escalation workflow is operational. The surrounding policy artefacts publish the chain as the firm rule and the framework references mandate the documented timelines. Pair this workflow with the vulnerability SLA policy template for the signed document that names the chain and the exception path, the vulnerability management policy template for the broader programme governance, the vulnerability management RACI matrix template for the named accountability per stage, the security exception register template for the deferred-risk record, and the remediation SLA calculator for defensible windows tied to PCI DSS, ISO 27001, SOC 2, and CISA KEV expectations. The framework references that mandate documented remediation timelines and governed escalation include ISO 27001 for Annex A 8.8 technical vulnerability management, SOC 2 for CC7.x and CC9.x risk mitigation, PCI DSS for requirement 6.3.3 patch timelines and 12.10.2 incident response, NIST SP 800-53 for RA-5 and SI-2 flaw remediation and CA-7 continuous monitoring, and CISA Cybersecurity Performance Goals for the cross-sector baseline that names accountability and governed escalation. For live-exploitation context that shapes the escalation tier, read the CISA KEV catalogue guide and the EPSS scoring guide.
Buyer and operator pairing
Vulnerability SLA breach escalation is the governance workflow vulnerability management teams run when the SLA programme meets reality, and the workflow internal security teams, AppSec teams, and GRC and compliance teams rely on for defensible audit evidence. CISOs and security operations leaders carry the approver role for residual-critical and KEV-tagged breaches; the documented chain protects them from being the single page point on every minor SLA miss. Product security teams and security engineering teams sit in the application-owner and decision-class tier and benefit from the constrained decision catalogue that prevents ad hoc resolution paths.
What good breach escalation feels like
Breach is a record event, not a Slack message
When the SLA breaches, the breach lands on the finding with timestamp, margin, severity tier, and the inherited escalation chain. The audit trail does not depend on memory or chat history; it depends on the events the platform recorded as the breach occurred.
The right authority gets paged
Critical and KEV-tagged breaches reach the senior approver. Medium and lower breaches surface in the weekly review. Residual-severity overrides route to the residual tier rather than the original tier so compensating controls do not waste senior approver attention.
Decisions are constrained and recorded
The approver records the decision class against the breach event from a constrained catalogue. Constrained decisions make audit comparisons possible across breaches and over time; ad hoc resolutions do not survive a multi-quarter assessment.
Reports surface margin and repeat rate
Breach reports headline breach rate, mean breach margin, repeat-breach rate, and decision-class distribution. Volume alone hides the worst signals; margin and repeat rate are the lines that distinguish a healthy programme from a backlog programme that shows a comfortable headline.
Vulnerability SLA breach escalation is the governance workflow that turns a missed remediation deadline into an audit-readable trail. Run it on the engagement record, and every breach carries the chain from page through acknowledgement, decision class, and closure that the firm, leadership, and the audit all expect.
Frequently asked questions about vulnerability SLA breach escalation
What is vulnerability SLA breach escalation?
Vulnerability SLA breach escalation is the governance workflow that fires when a finding misses its target close date. It covers who gets paged at breach, the decision class the approver can record (accelerated remediation, SLA extension, formal exception, incident-response handoff, asset retirement, or downgrade-on-compensating-control), the new committed date, the re-breach rule, and the communication record that goes out to the security committee or board. SecPortal runs the workflow on the engagement record so every breach event lands on the finding with timestamp, margin, named approver, decision class, and replacement deadline rather than as a Slack message that ages out.
How is breach escalation different from SLA management?
SLA management is the broader discipline that sets target close dates, surfaces runway on the queue, and reports closure rate over time. Breach escalation is the governance slice that activates when a finding misses its deadline. SLA management defines the policy. Breach escalation defines the response to the policy failing on a specific finding. The two workflows share the same engagement record so the breach event records against the same finding the SLA stamped on initial logging. Read the full SLA management workflow for the policy and timer layer, and read this page for the escalation chain, decision class catalogue, and audit-readable breach evidence that activate on miss.
Who should sit in the escalation chain?
A defensible chain names a primary approver and a deputy at each severity tier. Critical breaches reach a CISO or senior security approver authorised to fund out-of-band remediation or accept residual risk under documented exception. High breaches reach the application owner and the security lead together. Medium breaches reach the application owner with security lead review in the weekly queue. Low and informational breaches surface in the quarterly programme review. Residual-severity overrides route to the residual tier rather than the original tier so compensating controls do not waste the senior approver attention budget. The chain is recorded on the engagement record so the right authority is paged automatically rather than guessed at breach.
What decisions should the approver record at breach?
Constraining the decision catalogue makes audit comparisons possible across breaches and over time. The six common options are accelerated remediation (commit a faster fix and re-set the SLA target), SLA extension (new target date with rationale, named approver, and review cadence), formal exception (residual risk accepted under documented compensating control with expiry), incident response handoff (when active exploitation is suspected), asset retirement (when the affected system is being decommissioned), and downgrade on compensating control (residual severity reassessed and SLA tier adjusted). Other decisions are escalated outside the catalogue so they get explicit visibility.
How should KEV-tagged findings be treated?
KEV-tagged findings carry live exploitation evidence rather than theoretical CVSS severity, so the escalation tier reflects the exploitation context. A common policy is to treat KEV-tagged findings as one tier higher than their base CVSS class for both SLA target and escalation: a KEV-tagged high routes escalation as a critical. The CISA BOD 22-01 window for federal agencies and many enterprise programmes is roughly two weeks for KEV findings on internet-facing systems. SecPortal supports the KEV-aware tier through finding tags, the SLA policy on the engagement, and the escalation chain on the engagement record so the live exploitation signal drives the escalation tier rather than only the base CVSS class.
What about re-breach on the same finding?
A second or third breach on the same finding is evidence that the underlying capacity, ownership, or scope problem did not get solved by the first extension. The re-breach rule pushes the escalation one tier higher than the first breach: a high finding that already breached once and breached again escalates as a critical even though the base CVSS sits in the high tier. Re-breach handling prevents the same finding sitting in a quiet extend-and-extend loop. SecPortal records each breach event separately on the finding so the activity log shows the breach history and the re-breach escalation rule applies automatically.
When should breach escalation trigger incident response?
When the breach evidence shows active exploitation, suspected exploitation, or a credible exploitation indicator (anomalous activity logs, customer reports, threat intelligence) the breach escalates outside the SLA programme into the incident response workflow. The handoff is recorded on the finding so the audit can trace why an SLA breach became an incident. Read the incident response workflow and the breach notification and regulator readiness workflow for what runs from the handoff onward, including the multi-regulator clock register that activates when the incident class triggers regulatory disclosure.
How is breach evidence reported to leadership and the board?
Leadership reports headline four numbers: breach rate by severity, mean breach margin (how many days past SLA the breaches sit), repeat rate (how often the same finding breaches more than once), and exception coverage (how many breached findings sit under documented exception versus undocumented). The AI report generation engine produces the leadership narrative from the live findings record rather than a parallel spreadsheet, and the activity log exports to CSV for the audit committee or board pack appendix. Board-level reporting that counts breaches without margin or repeat rate hides the worst signals; the leadership view has to surface programme strain, not just volume.
Does SecPortal support automated approval routing?
SecPortal records the escalation chain on the engagement record and emits notifications when SLA state changes, including breach. Team management with role-based access controls which approver receives which severity tier, so escalation lands on the authority level the residual risk warrants. SecPortal does not automate downstream actions outside the platform; it is the operating record where the breach event lands, the approver acknowledgement is captured, the decision class is recorded, and the audit trail accumulates. Approver acknowledgement, decision selection, and replacement deadlines are human decisions captured on the finding rather than auto-applied.
How does SecPortal support vulnerability SLA breach escalation?
SecPortal records the SLA policy and the escalation chain on the engagement record, stamps target close dates on every finding, surfaces breach state on the dashboard and the branded client portal, routes notifications to the named approver by severity, captures the decision class and replacement deadline on the breach event, supports re-breach detection through the activity log, and exports the audit trail to CSV for ISO 27001, SOC 2, PCI DSS, and NIST evidence. SecPortal does not replace the security committee, the incident response runbook, or the regulator clocks; it makes governed escalation, defensible breach evidence, and audit-ready trail the path of least resistance.
How it works in SecPortal
A streamlined workflow from start to finish.
Record the escalation chain on the engagement
Before findings open under SLA, the engagement record carries the named approver and deputy for each severity tier, the residual-severity overrides, and the page channel per tier. Every finding logged inherits the chain so escalation routes automatically at breach rather than being decided ad hoc in the moment. RBAC in team management maps the chain to roles so leave and personnel changes do not silently break the flow.
Detect the breach as a record event
When a target close date passes without closure, the platform records a breach event on the finding with timestamp, breach margin in hours or days, severity tier, KEV-tag status if applicable, and the inherited escalation chain. The event is queryable, exportable, and auditable. The breach is no longer a colour change in the queue; it is a line on the record that the audit can read.
Page the right authority for the right tier
Notifications fire to the named approver in the chain. Critical and KEV-tagged breaches reach the senior approver same business day. High breaches reach the application owner and security lead together. Medium and lower breaches surface in the weekly queue. Residual-severity overrides route to the residual tier so compensating controls do not waste senior approver attention. Deputy approvers cover leave automatically.
Record the decision class against the breach
The approver selects from a constrained catalogue: accelerated remediation, SLA extension, formal exception, incident response handoff, asset retirement, or compensating-control downgrade. The decision class becomes the next field on the finding. Constrained decisions make audit comparisons possible across breaches and over time; ad hoc resolutions do not survive a multi-quarter assessment.
Capture the replacement deadline or expiry
Each decision carries a follow-up commitment: a new committed close date for accelerated remediation or SLA extension, an exception expiry for formal exception, an incident reference for handoff, or a retirement date for asset retirement. The committed date is what the next review checks against rather than the original breached date. Re-breach on the same finding pushes escalation one tier higher than the first breach.
Report breach evidence to leadership and the audit
AI report generation, the dashboard breach views, and the activity log export together produce breach evidence: breach rate by severity, mean breach margin, repeat-breach rate, decision-class distribution, and KEV-tagged breach trail. The CSV export covers the audit ask for ISO 27001 Annex A 8.8, SOC 2 CC7.x and CC9.x, PCI DSS 6.3.3 and 12.10.2, NIST SP 800-53 RA-5/SI-2/CA-7, and CISA BOD 22-01 alignment.
Features that power this workflow
Escalate SLA breaches as governed events, not as chat messages
Chain, breach event, decision class, replacement deadline, and audit-ready trail on one engagement record. Start free.
No credit card required. Free plan available forever.