Vulnerability SLA breach recovery
turn each breach into corrective signal
Vulnerability SLAs breach. The honest enterprise programme accepts that and runs a structured recovery loop after every breach event rather than treating the breach as a one-time incident that closes once the engineer ships the fix. Stabilise the breach, classify the cause against a canonical taxonomy, run the recovery against a plan, verify the fix, and file a post-mortem with a corrective action read against breach recurrence per cause class.
No credit card required. Free plan available forever.
The structured loop that turns a breach event into a programme-improvement signal
Vulnerability SLAs breach. The honest enterprise programme accepts that and runs a structured recovery loop after every breach event rather than treating the breach as a one-time incident that closes once the engineer ships the fix. The recovery loop covers the post-breach window from the moment the escalation page resolves through the closure of the finding, the verification of the fix, the filing of the recovery post-mortem, and the installation of a corrective action the programme reads against the breach-recurrence rate per cause class. The loop is the difference between a programme that absorbs breach events as cost and a programme that turns each breach into a corrective signal that bites the next cycle.
The workflow composes with the rest of the vulnerability SLA operating model. The vulnerability SLA management workflow is the upstream discipline that defines the policy by severity, assigns the SLA on every finding, and operates the clock across normal cycles. The vulnerability SLA breach escalation workflow is the routing discipline that fires when a finding crosses the threshold and carries the page to the right named approver. The recovery workflow is what happens after the escalation page resolves: how the recovery owner stabilises the breach, classifies the cause, runs the recovery plan, verifies the fix, and files the post-mortem with a corrective action. The three workflows form one continuous record on the finding: policy, escalation, recovery. Each workflow reads against the same engagement record rather than rebuilding a parallel register.
The five recovery phases the workflow runs after every breach event
The recovery loop is a defined five-phase sequence rather than an ad-hoc reaction. Each phase has a documented window, a named purpose, and named artefacts that land on the finding and survive into audit. The phase shape is the same on critical and high breaches as on medium and low breaches; the cadence inside each phase scales with severity.
Phase 1: Stabilise the breach event
Window. Within the first business day after the escalation page resolved (critical and high) or within the first week (medium and low).
Purpose. Stop the breach from compounding into a second breach event. The named owner of record acknowledges the breach in writing on the finding, confirms whether a compensating control is in place to cap residual exposure during recovery, and posts an initial recovery commitment with a target close date that is reachable rather than aspirational.
Artefacts on the finding. Recovery acknowledgement note on the finding, named recovery owner (the engineer or team accountable for the recovered close), compensating control status, initial recovery commitment date, and the activity log entry that links the recovery thread to the original breach event timestamp.
Phase 2: Document the breach cause classification
Window. Within five business days of the breach for critical and high; within ten business days for medium and low.
Purpose. Classify the breach against the canonical cause taxonomy so the programme can see the breach pattern across the queue rather than only the single event. The classification is a named field on the finding, not a freeform sentence; the taxonomy is the input to the corrective-action picture the next phase produces.
Artefacts on the finding. Named breach cause class on the finding (capacity shortfall, dependency block, scope drift, scanner-output quality, severity miscalibration, ownership routing gap, deployment-pipeline block, change-window miss, vendor patch unavailable, retest queue saturation, exception-register miss, intake-misclassification), the supporting narrative on the activity log, and the linked engagement scope or release-cadence context.
Phase 3: Run the recovery against a defined plan
Window. Across the recovery window the named owner committed to in Phase 1, with weekly check-ins on critical and high breaches.
Purpose. Execute the recovery against a plan that names the work, the dependencies, and the named blockers. The recovery plan reads as a checklist on the finding so progress is visible without a status meeting. Each step ticks off with a timestamp and an actor so the audit reads the recovery cadence rather than reconstructing it from chat threads.
Artefacts on the finding. Recovery plan checklist on the finding, per-step progress entries on the activity log, named blocker references where a step is waiting on a dependency, and the rolling recovery-burndown the engagement view surfaces to the named owner and the security lead.
Phase 4: Verify the recovered fix and close the loop
Window. Immediately after the named owner marks the fix shipped and within the documented retest SLA for the severity tier.
Purpose. Verification is part of the recovery, not a separate process. The retest runs against the same finding record so the recovery evidence and the proof-of-fix evidence travel together. Verification failure pushes the recovery back into Phase 3 with the failure note attached rather than closing the finding optimistically.
Artefacts on the finding. Retest evidence attached to the finding through the retesting workflow, named verifier, verification timestamp, and the closure decision with the actor and the reason. Where verification fails, the recovery returns to Phase 3 with a new commitment date and the failure mode recorded.
Phase 5: File the recovery post-mortem and the corrective action
Window. Within ten business days of closure for critical and high breaches; in the monthly recovery review for medium and low.
Purpose. A breach that closes without a post-mortem is a breach the programme is paying for twice. The post-mortem names the cause class, the root cause beyond the cause class, the corrective action the programme will install, the named owner of the corrective action, the target install date, and the success measure. The corrective action attaches to the engagement so the next breach against the same cause class reads against the same fix rather than reopening the same conversation.
Artefacts on the finding. Recovery post-mortem note attached to the finding, named corrective action with owner and install date, the success measure (closure rate, mean time to recover, breach-recurrence rate against the cause class), and the cross-link to other findings with the same cause class so the corrective action is read against the breach population rather than a single event.
Twelve breach cause classes that cover the bulk of SLA breaches in enterprise programmes
Breaches cluster around a recurring set of structural causes. A canonical taxonomy lets the recovery loop classify each breach against a fixed field rather than a freeform sentence, so the GRC team can read the cause distribution across the queue and the CISO can read the breach-recurrence rate per cause class as a leading indicator of whether the corrective actions are biting. Programmes that operate against the taxonomy tend to converge on six or seven dominant causes within the first two cycles; the long tail still gets recorded but the intervention picture follows the dominant causes.
| Cause class | What the class names |
|---|---|
| Capacity shortfall | The named owning team did not have the engineering or security capacity to land the fix inside the SLA window. The breach is a capacity-planning question, not a security workflow question. The corrective action runs against engineering staffing, on-call rota, or capacity reservation for security work rather than against the security process. |
| Dependency block | The fix was waiting on an upstream dependency (a vendor patch, a coordinated release, an architectural decision, an internal platform change). The breach is a coordination question. The corrective action runs against dependency mapping, vendor-relationship management, or platform-team handoff cadence rather than against the named owner who carried the finding. |
| Scope drift | The fix expanded during implementation as the team uncovered additional surfaces affected by the same vulnerability. The breach is a scoping question. The corrective action runs against intake scoping discipline (catching the broader scope at intake) and against finding-merge-and-supersede discipline (representing the expanded scope on one parent finding rather than three sprawling records). |
| Scanner-output quality | The fix was delayed because the scanner output was unclear about the affected version, the affected configuration, or the affected route. The breach is an evidence-quality question. The corrective action runs against scanner tuning, intake hygiene, and the data-quality discipline the workspace runs on each finding before it lands on the owner queue. |
| Severity miscalibration | The finding was triaged at a severity that did not match the deployed exposure; the SLA window applied was the wrong window for the actual risk. The breach is a calibration question. The corrective action runs against the severity policy, the CVSS calibration discipline at intake, and the named-reason override discipline so severity decisions are auditable. |
| Ownership routing gap | The finding lived in the unowned queue for part of the SLA window and only landed with a named owner late in the cycle. The breach is a routing question. The corrective action runs against the routing rules, the asset-ownership map, and the RBAC routing that pushes the new record to the right named person at intake. |
| Deployment-pipeline block | The fix shipped to the engineering team but stalled in the deployment pipeline (a flaky test suite, a code-freeze window, a release-train cadence, a staging environment outage). The breach is a delivery question. The corrective action runs against the pipeline owner rather than the security owner. |
| Change-window miss | The fix was ready but missed the change window the operational policy required. The breach is a scheduling question. The corrective action runs against the change-management cadence, the expedited-change pathway documentation, and the emergency-change pathway named-authority chain. |
| Vendor patch unavailable | The fix depended on a vendor-supplied patch that did not exist inside the SLA window. The breach is a vendor-relationship question. The corrective action runs against vendor-relationship cadence, the documented compensating-control discipline that covers the window between disclosure and patch availability, and the named compensating-control review before the SLA reads as breached. |
| Retest queue saturation | The fix shipped on time but the retest queue did not have the capacity to verify it inside the SLA window. The breach lives in the verification function rather than in the engineering function. The corrective action runs against retest capacity planning, scanner-comparison-and-diff cadence, and the awaiting-verification queue length surfaced as a separate operational metric. |
| Exception-register miss | The finding should have inherited an existing exception or compensating-control acceptance but the intake check missed the match. The breach is an intake-discipline question. The corrective action runs against the exception register match discipline at intake and the documented acceptance review the workflow runs before opening a new ticket. |
| Intake misclassification | The finding was opened against the wrong engagement, the wrong asset, or the wrong owning team at intake; the SLA started but the routing-correction time consumed most of the window. The breach is an intake-quality question. The corrective action runs against the intake-fields-required discipline and the named-reviewer cadence on finding-data-quality. |
Six recovery artefacts the workflow lands on the finding
A defensible recovery loop produces six concrete artefacts on the finding record rather than a chain of meeting minutes and chat threads. The artefacts make the recovery cadence readable from the queue and survive into audit fieldwork without needing the original operators to reconstruct the chronology from memory.
Breach acknowledgement on the finding
The named recovery owner posts a recovery acknowledgement note on the finding within the documented window. The note names the recovery owner, the compensating control where one is in place, and the initial recovery commitment date. The acknowledgement timestamps the start of the recovery clock on the activity log so the audit reads the recovery cadence rather than reconstructing it from email.
Breach cause class on a named field
The cause class is a single named field on the finding chosen from the canonical taxonomy rather than a freeform sentence. The classification is the input to the corrective-action picture the programme produces and the input to the breach-pattern review the GRC team runs on a quarterly cadence.
Recovery plan checklist on the finding
The recovery plan reads as a checklist on the finding with named steps, dependencies, and blockers. Each step ticks off with a timestamp and an actor on the activity log. The checklist replaces the recurring status meeting for the recovery cycle and lets the security lead read the recovery state from the queue rather than from chat.
Retest evidence attached through the retesting workflow
The retest runs against the same finding record through the retesting workflow. The retest evidence is attached to the finding through document management as a versioned artefact. The verification decision (passed, failed, partial) is captured on the finding with the named verifier and the timestamp; verification failure pushes the recovery back into the plan phase rather than closing optimistically.
Recovery post-mortem note
After closure, the recovery post-mortem documents the cause class, the root cause beyond the cause class, the corrective action the programme will install, the named owner of the corrective action, the target install date, and the success measure. The post-mortem attaches to the finding rather than living in a separate retrospective document so the audit reads the recovery loop on one continuous record.
Corrective action linked across the cause class
The corrective action attaches to the engagement so other findings with the same cause class read against the same fix. The cross-link is queryable through global search so the next recovery against the same cause class does not reopen the same conversation. The programme reads the recurrence rate of each cause class as a leading indicator of whether the corrective actions are working.
Seven failure modes that quietly break SLA breach recovery
Recovery failure usually looks like sensible defaults: the engineer ships the fix, the finding closes, the team moves on. The cost arrives a quarter later when the same cause class produces another breach, the audit reads a closed record with no recovery loop, and the GRC team has no breach-pattern view to brief leadership.
The breach closes silently and the recovery loop never runs
The escalation page resolves, the finding closes a week later, and no recovery post-mortem is filed. The programme has no record of why the SLA breached, no corrective action installed, and no defence against the same breach happening on the next finding against the same cause class. The fix is making the recovery loop a required phase: a finding that closes after a breach event without a recovery post-mortem stays on the open-recovery queue until the post-mortem lands.
Breach causes get logged as freeform sentences nobody can query
Each breach gets a "what happened" note on the finding that reads well on the single record and is useless across the queue. Three months later the programme cannot answer how many breaches were capacity shortfalls versus dependency blocks. The fix is the canonical cause-class taxonomy on a named field so the breach pattern is queryable; the freeform narrative still lives on the activity log but the named field is what the quarterly review reads.
The recovery plan lives in chat and the audit cannot reconstruct it
The recovery plan is a Slack thread the engineer and the security lead worked out on a Monday morning. The audit reads the finding three months later and sees a closed record with no plan, no checkpoints, and no cadence. The fix is recording the recovery plan as a checklist on the finding with named steps, named owners, and named blockers; the chat thread is the working medium but the checklist is the auditable artefact.
Verification is optimistic and the finding reopens within a quarter
The engineer marks the fix shipped, the named owner closes the finding the same day, and the next scanner cycle reopens it because the fix did not land in production or did not cover the full affected surface. The fix is making retest part of the recovery: the finding does not close until the retest passes; the verification decision is captured on the record with the named verifier and the failure mode.
The corrective action gets agreed and never installed
The post-mortem names a corrective action; the corrective action lives nowhere; the next breach against the same cause class reads the same conversation. The fix is attaching the corrective action to the engagement with a named owner, a target install date, and a success measure that the programme reads against the breach-recurrence rate per cause class on a recurring cadence.
Recovery cadence drifts into the audit-week scramble
Breaches accumulate across the quarter, the recovery loop never runs, and the audit fieldwork week becomes a reconstruction sprint where the team writes post-mortems for closed findings nobody can remember. The fix is running the recovery cadence weekly for critical and high breaches and monthly for medium and low so the audit reads the live record rather than the audit-week reconstruction.
Recurrent breaches against the same cause class never get aggregated
Each breach gets its own post-mortem; nobody reads the pattern across the queue; the programme keeps installing point-fixes against a systemic cause. The fix is the cross-link between findings sharing a cause class and the quarterly review that reads breach-recurrence per cause class as the leading indicator of whether the corrective actions are reducing the breach rate.
Six recovery metrics the workflow surfaces
The recovery loop produces six paired metrics that read against open-count or breach-count reporting. Each metric is queryable from the live record rather than reconstructed at the end of the quarter; the audit chain reads the same numbers the operating team reads on the weekly recovery review.
Mean time to recover (MTTR-Breach)
Elapsed time from the breach event timestamp to the closure timestamp. The figure is paired against the severity-band recovery target so the programme can read whether critical recoveries are landing inside the recovery SLA. MTTR-Breach is distinct from mean time to remediate (which runs from open to close); the recovery figure isolates the post-breach window.
Recovery acknowledgement latency
Elapsed time from the breach event timestamp to the recovery acknowledgement note. The figure reads whether the named recovery owner is engaging in the documented window or letting the breach age before the recovery loop starts.
Recovery post-mortem completion rate
Share of closed breached findings that have a filed recovery post-mortem within the documented window. The figure surfaces whether the recovery loop is operating as a discipline or being skipped under workload pressure.
Breach cause class distribution
Distribution of breach causes across the queue by cause class. The figure surfaces where the systemic gaps are: a quarter where 60 percent of breaches are capacity shortfalls reads differently than a quarter where 60 percent are dependency blocks. The intervention picture follows the cause distribution.
Breach recurrence per cause class
Rate of repeat breaches against the same cause class quarter over quarter. The figure is the leading indicator of whether the corrective actions installed in prior post-mortems are working. A cause class with a flat recurrence rate signals the installed corrective action is not biting.
Retest pass rate on recovered findings
Share of recovered findings whose retest passes on the first attempt. The figure surfaces verification quality and the engineering-team fix quality on the recovery path. A low rate signals optimistic closures and predicts reopens.
How vulnerability SLA breach recovery runs in SecPortal
The workflow rides on the feature surfaces the security programme already uses. The recovery acknowledgement, the cause classification, the recovery plan checklist, the retest evidence, the post-mortem note, and the corrective action all live on the finding record so the recovery loop reads from the queue rather than from chat. No bespoke integration is required for the workflow itself.
Findings management as the recovery record
Findings management holds the canonical record for every breached finding, with the cause class, the recovery acknowledgement, the recovery plan, the retest decision, and the post-mortem note attached to the same record the breach event was logged against.
Engagements as the corrective-action context
Engagement management holds the corrective action the post-mortem produces, so the next recovery against the same cause class reads against the existing fix rather than reopening the same conversation.
RBAC for the named recovery owner
Team management role-based access control names the recovery owner and the corrective-action owner on each record, with owner, admin, member, viewer, and billing roles available for the different recovery responsibilities.
Retesting for verification
Retesting workflows run the verification phase against the same finding record so the recovery evidence and the proof-of-fix evidence travel together; verification failure pushes the recovery back into the plan phase rather than closing the finding optimistically.
Scan-to-scan diff for verification evidence
Scan comparison and diff produces the before-and-after evidence the retest phase reads against, so the recovery closure is paired to a recorded scan result rather than to a self-attestation from the engineering team.
Finding overrides for compensating controls
Finding overrides hold the compensating-control acceptance during the recovery window, with the named approver, the documented rationale, and the expiry; recovery slipping past the compensating-control expiry re-escalates rather than rolling over silently.
Activity log as the recovery chronology
Activity log with CSV export captures every recovery step (acknowledgement, cause class, plan checkpoints, blocker references, verification decision, post-mortem note) so the audit reads the chronology rather than reconstructing it from chat.
Document management for evidence
Document management holds the retest evidence, the recovery plan attachments, and the post-mortem supporting material as versioned artefacts the finding cites rather than re-authored on the record.
Notifications for recovery cadence
Notifications and alerts push the recovery checkpoints to the named recovery owner, the security lead, and the corrective-action owner so the cadence runs without requiring a recurring status meeting.
Compliance tracking
Compliance tracking maps each recovery to ISO 27001 A.8.8 and A.5.27, SOC 2 CC4.1 and CC7.4, NIST SP 800-53 SI-2 and IR-4, NIST CSF 2.0 RS.MI and RC.RP, PCI DSS 6.3.3 and 12.10, CIS Controls v8.1 Safeguards 7.7 and 17.8, and DORA Articles 5, 9, 13, and 17.
AI reports for the recovery summary
AI reports produce the recovery summary, the cause-class distribution, the breach-recurrence rate per cause class, and the corrective-action installation status that the GRC team and the CISO read on the recurring cadence.
MFA on every recovery action
MFA enforcement with TOTP applies to every operator who takes a recovery action so the audit reads that the recovery owner, the corrective-action owner, and the named verifier authenticated with a second factor before posting the recovery decisions.
Audit frameworks that read against the workflow
Most enterprise audit and certification cycles expect documented evidence that the organisation runs a structured response when the remediation SLA is exceeded rather than closing the breach silently. The workflow produces the evidence those audits read against.
ISO 27001:2022
Annex A 8.8 (management of technical vulnerabilities) reads against the recovery workflow as evidence that the programme runs a documented response when the remediation SLA breaches rather than closing the breach without a corrective loop. Annex A 5.27 (learning from information security incidents) reads against the recovery post-mortem and the corrective action attached to the engagement. Clause 10.1 (continual improvement) reads against the breach-recurrence per cause class metric as the loop that demonstrates the corrective actions are biting. Clause 9 (performance evaluation) reads against the cause-class distribution and the recovery acknowledgement latency.
SOC 2 Trust Services Criteria
CC4.1 (monitoring activities) reads against the recovery cadence and the named recovery owner on each breached finding. CC4.2 (evaluation and communication of deficiencies) reads against the recovery post-mortem note and the corrective action attached to the engagement. CC7.4 (security incident response) reads against the breach acknowledgement, the recovery plan checklist, and the closure decision. CC5.1 (control activities) reads against the recovery checklist as the control the programme operates after a breach event.
NIST SP 800-53 Rev. 5
SI-2 (flaw remediation) reads against the recovery workflow as the documented process the organisation runs when the remediation cycle exceeds the planned window. CA-7 (continuous monitoring) reads against the breach-pattern review and the corrective-action installation. RA-7 (risk response) reads against the breach cause class and the named-reason override discipline. IR-4 (incident handling) reads against the breach acknowledgement and the recovery plan where the breach event is treated as a workflow incident.
NIST CSF 2.0
RS.MI (incident mitigation) reads against the recovery acknowledgement and the compensating-control status. RS.AN (incident analysis) reads against the cause class and the recovery post-mortem. RC.RP (recovery plan execution) reads against the recovery plan checklist on the finding. ID.IM (improvement) reads against the corrective action attached to the engagement and the breach-recurrence per cause class metric.
PCI DSS v4.0
Requirement 6.3.3 (resolution of security vulnerabilities) reads against the recovery cadence as the documented response when the resolution window is exceeded. Requirement 11.3 (vulnerability scanning) reads against the retest evidence attached through the retesting workflow as the proof of recovered closure. Requirement 12.10.5 (assessment and incident response) reads against the recovery post-mortem and the corrective action attached to the engagement.
CIS Controls v8.1
Safeguard 7.7 (remediation of detected vulnerabilities) reads against the documented recovery workflow as the response when the safeguard target is missed. Safeguard 17.4 (incident response process) reads against the breach acknowledgement and the recovery plan checklist. Safeguard 17.8 (post-incident reviews) reads against the recovery post-mortem and the corrective action attached to the engagement.
DORA (Digital Operational Resilience Act)
Article 5 (governance framework) reads against the named recovery owner and the named corrective-action owner. Article 9 (protection and prevention) reads against the breach cause class and the corrective-action installation. Article 17 (ICT-related incident management) reads against the breach acknowledgement, the recovery plan, and the post-mortem. Article 13 (learning and evolving) reads against the breach-recurrence per cause class as the loop the regulator expects the financial entity to demonstrate.
Where the workflow fits in the wider operating model
SLA breach recovery is the post-breach loop in the vulnerability operating model. The references below trace how the recovery record carries into the rest of the programme. Each adjacent workflow reads against the same finding record rather than rebuilding a parallel register.
SLA management upstream
The vulnerability SLA management workflow defines the policy and operates the clock; recovery is the loop that runs after the clock has been crossed.
SLA breach escalation
The vulnerability SLA breach escalation workflow is the routing chain that fires at threshold; recovery picks up after the page resolves and the recovery owner takes the record.
Exception management
The acceptance and exception management workflow holds the compensating-control acceptance the recovery acknowledgement reads against and the documented expiry that gates the recovery window.
Fix verification
The security finding fix verification workflow runs the retest phase of the recovery against the same finding record so the recovery and the verification evidence stay paired.
Reopen and regression handling
The reopen and regression handling workflow covers the case where a recovered finding regresses; the post-mortem reads against the regression as part of the breach cause analysis.
Leadership reporting
The security leadership reporting workflow reads the recovery metrics, the cause-class distribution, and the breach-recurrence rate against the CISO and board cadence.
Backlog management
The vulnerability backlog management workflow tracks the open-breach population the recovery workflow runs against and the recovery burndown across the operating week.
Remediation campaign management
The remediation campaign management workflow runs campaigns against breach cause classes that show repeat recurrence; the corrective-action installation reads against the campaign result.
Patch management coordination
The patch management coordination workflow covers the vendor-patch dependency cause class and the corrective action that runs against patch-coordination cadence.
Audiences that operate against this workflow
The workflow serves the operators and leaders responsible for the post-breach recovery cycle. Each audience reads the workflow with a slightly different lens.
Internal security teams
Internal security teams read the workflow as the operating discipline that turns breach events into corrective signal rather than absorbing them as undifferentiated overhead.
Vulnerability management teams
Vulnerability management teams read the workflow as the loop that pulls the breach population back into closure and keeps the open-breach queue from accumulating across the quarter.
AppSec teams
AppSec teams read the workflow as the recovery path for application-side breaches and the corrective-action loop that informs intake-discipline changes.
GRC and compliance teams
GRC and compliance teams read the workflow as the evidence chain ISO 27001 A.5.27 and A.8.8, SOC 2 CC4.1 and CC7.4, NIST SP 800-53 SI-2 and IR-4, PCI DSS 6.3.3 and 12.10, and DORA Articles 5 and 17 audits read against.
Security engineering teams
Security engineering teams read the workflow as the discipline that surfaces deployment-pipeline blocks, scanner-quality issues, and tooling gaps as named cause classes rather than as recurring complaints.
CISOs and security leaders
CISOs and security leaders read the workflow as the leading indicator of programme maturity: a programme that files post-mortems and tracks breach recurrence per cause class is a programme that learns rather than accumulating breach debt.
Security operations leaders
Security operations leaders read the workflow as the bridge between escalation handling and structural improvement, with the cause-class distribution informing where to fund tooling, capacity, and process work next.
Security program managers
Security program managers read the workflow as the recurring cadence that produces breach-pattern reporting and the corrective-action portfolio the programme tracks at quarterly review.
Honest scope
The workflow runs on the workspace record itself rather than as an external orchestration layer. SecPortal does not deploy code to fix the breach, does not enforce deployment pipelines, does not run vendor-patch coordination outside of the finding record, does not push to Jira, ServiceNow, Slack, Teams, PagerDuty, SIEM, SOAR, GRC, or ITSM platforms, does not call ticketing webhooks, does not run automated cause-class inference on the breach narrative, and does not generate corrective-action plans without a named human author. The platform holds the structured recovery record, the named ownership, the activity log, the retest evidence, the compensating-control acceptance, the post-mortem note, and the audit trail. The recovery cadence is operated by the security team and the named recovery owner; the workspace surfaces the cadence so the team does not run it from email.
The cause-class taxonomy named on this page is one defensible set; programmes that operate against a different vocabulary can adapt the taxonomy to the local operating model. The discipline that matters is the named field, the queryable distribution, and the breach-recurrence metric, not the specific labels.
Frequently asked questions
What is the vulnerability SLA breach recovery workflow?
The vulnerability SLA breach recovery workflow is the structured post-breach discipline the security programme runs after a vulnerability SLA breach event has been escalated. It covers the five recovery phases (stabilise the breach event, document the cause classification, run the recovery against a defined plan, verify the recovered fix, and file the post-mortem with a corrective action), the canonical breach cause taxonomy that classifies each event, the recovery artefacts that survive into audit, and the metrics that surface whether the recovery loop is operating as a discipline or being skipped. The workflow is the loop that turns a breach event from a one-time incident into a programme-improvement signal.
How is this different from vulnerability SLA management?
The vulnerability SLA management workflow is the upstream discipline that defines the SLA policy by severity, assigns the SLA on every finding, surfaces the SLA state on the live queue, and runs the policy across normal operations. The SLA breach recovery workflow is the downstream discipline that runs after the policy has been breached and the escalation page has resolved. The two pair together: SLA management is the discipline that prevents breaches, and SLA breach recovery is the discipline that handles the breaches that do occur and turns them into corrective signal.
How is this different from the SLA breach escalation workflow?
The vulnerability SLA breach escalation workflow is the routing discipline that fires when a finding crosses the SLA threshold: it carries the page to the right named approver by severity, records the breach event, and resolves once the approver acknowledges the page and a recovery commitment is in place. The recovery workflow is what happens after the escalation page resolves: how the recovery owner stabilises the breach, classifies the cause, runs a plan, verifies the fix, and files the post-mortem with a corrective action. Escalation is the page chain; recovery is the corrective loop. Both run against the same finding record so the audit chain stays continuous.
What does a defensible recovery acknowledgement look like?
A defensible recovery acknowledgement is a note on the finding within the documented window after the escalation page resolves. The note names the recovery owner (the engineer or team accountable for the recovered closure), the compensating control status (whether a temporary control caps residual exposure during the recovery), and the initial recovery commitment date (a date that is reachable rather than aspirational). The acknowledgement carries an activity log entry so the audit reads the recovery cadence rather than reconstructing it from chat or email.
Why does the breach cause taxonomy need to be a fixed field rather than a freeform sentence?
Freeform breach notes read well on a single record and are useless across the queue. Three months later the GRC team cannot answer how many breaches were capacity shortfalls versus dependency blocks versus retest-queue saturation. A canonical taxonomy on a named field makes the breach pattern queryable so the programme can read the cause distribution and decide which corrective actions to fund. The freeform narrative still lives on the activity log; the named field is what the quarterly breach-pattern review reads.
What goes into a recovery plan checklist on the finding?
A recovery plan checklist names the work the recovery owner is doing, the dependencies the work is waiting on, the blockers where a step is paused, and the cadence the security lead reads the checklist against. Each item ticks off with a timestamp and an actor on the activity log so the progress reads from the queue rather than from a status meeting. The checklist replaces the recurring breach-status meeting for routine recoveries and surfaces only the meaningful checkpoints (a blocker that needs leadership intervention, a dependency that slipped) to the standup.
How does verification fit into the recovery workflow?
Verification is part of the recovery, not a separate process. The retest runs against the same finding record through the retesting workflow so the recovery evidence and the proof-of-fix evidence travel together. The named verifier, the verification timestamp, and the verification decision (passed, failed, partial) land on the record. Verification failure pushes the recovery back into the recovery plan phase with the failure mode recorded rather than closing the finding optimistically and creating a reopen on the next scanner cycle.
What does a recovery post-mortem capture?
A recovery post-mortem captures the breach cause class on a named field, the root cause beyond the cause class as a short narrative, the corrective action the programme will install with a named owner and a target install date, and the success measure the programme reads against the corrective action (closure rate, mean time to recover, breach recurrence per cause class). The post-mortem attaches to the finding rather than living in a separate retrospective document so the audit reads the recovery loop on one continuous record. For critical and high breaches the post-mortem is filed within ten business days of closure; for medium and low it runs in the monthly recovery review.
How does the workflow prevent the same breach from recurring?
The corrective action attached to each post-mortem is read against the breach-recurrence per cause class metric. A cause class with a flat recurrence rate quarter over quarter signals the installed corrective action is not biting; the programme escalates the corrective action rather than installing another point-fix against the same systemic cause. The cross-link between findings sharing a cause class is queryable through global search so the next recovery against the same class reads against the same fix rather than reopening the same conversation.
Does the workflow require integration with engineering ticketing systems?
No. The workflow operates on the workspace record itself. The recovery acknowledgement, the recovery plan checklist, the retest evidence, the post-mortem note, and the corrective action all live on the finding record. Notifications surface the recovery state to the named owner and the security lead. The activity log captures the chronology. Teams that mirror recovery work into engineering tooling run those handoffs as separate disciplines downstream of the recovery loop. SecPortal does not ship native Jira, ServiceNow, Slack, Teams, PagerDuty, SIEM, or SOAR push connectors; the recovery workflow does not depend on them.
How does the workflow handle compensating controls during recovery?
A compensating control is the temporary control that caps residual exposure during the recovery window. The Phase 1 acknowledgement records whether a compensating control is in place, what the control is, who owns it, and when it expires. The finding overrides feature holds the compensating-control acceptance with the named approver and the documented expiry. If recovery slips past the compensating-control expiry, the workflow re-escalates rather than letting the control roll over silently. The defensible discipline is the named compensating-control review running on the same cadence as the recovery checkpoints.
How does the workflow read against breach-cause patterns at the portfolio level?
The cause-class distribution across the breach population is a quarterly view the GRC team reads to decide where the programme should invest the next corrective action. A quarter where 60 percent of breaches are capacity shortfalls reads differently than a quarter where 60 percent are dependency blocks; the intervention picture follows the cause distribution. Cross-engagement queries through global search produce the breach-pattern view across multiple engagements rather than only within one. The breach-recurrence per cause class metric over time surfaces whether the corrective actions installed in prior cycles are reducing the recurrence rate.
What roles operate against this workflow?
The named recovery owner is the engineer or team accountable for the recovered closure; this is usually the application owner or the platform owner the original finding was routed to. The security lead reads the recovery state across the queue and intervenes when a blocker needs escalation. The GRC owner reads the recovery post-mortems and the breach-pattern view to decide where the corrective actions should land. The CISO reads the recovery metrics and the breach-recurrence rate at the programme level. The corrective-action owner is named on the post-mortem and is on the hook for the install. Each role reads the same finding record under workspace RBAC.
How it works in SecPortal
A streamlined workflow from start to finish.
Stabilise the breach event
Within the first business day after the escalation page resolves on critical and high breaches (within the first week on medium and low), the named recovery owner posts a recovery acknowledgement on the finding, confirms the compensating control status, and posts an initial recovery commitment date that is reachable rather than aspirational. The acknowledgement stamps the recovery clock on the activity log.
Classify the breach cause against the canonical taxonomy
Within five business days for critical and high (ten for medium and low), the cause is classified on a named field chosen from the canonical taxonomy: capacity shortfall, dependency block, scope drift, scanner-output quality, severity miscalibration, ownership routing gap, deployment-pipeline block, change-window miss, vendor patch unavailable, retest queue saturation, exception-register miss, or intake misclassification. The classification is the input to the corrective-action picture the post-mortem produces.
Run the recovery against a defined plan checklist
The recovery plan reads as a checklist on the finding with named steps, dependencies, blockers, and named owners. Each step ticks off with a timestamp and an actor so the recovery cadence reads from the queue rather than from a status meeting. Weekly check-ins on critical and high; monthly on medium and low.
Verify the recovered fix through the retesting workflow
The retest runs against the same finding record so the recovery evidence and the proof-of-fix evidence travel together. The named verifier, the verification timestamp, and the verification decision land on the record. Verification failure pushes the recovery back into the plan phase rather than closing the finding optimistically.
File the recovery post-mortem and install the corrective action
Within ten business days of closure on critical and high (in the monthly recovery review on medium and low), the post-mortem captures the cause class, the root cause beyond the cause class, the corrective action with a named owner and target install date, and the success measure the programme reads against the breach-recurrence rate per cause class. The corrective action attaches to the engagement so the next recovery against the same cause class reads against the existing fix.
Read the recovery metrics on the recurring cadence
Six paired metrics surface on the live record: mean time to recover, recovery acknowledgement latency, post-mortem completion rate, breach cause class distribution, breach recurrence per cause class, and retest pass rate on recovered findings. The GRC team reads the metrics at quarterly review; the CISO reads them at the programme level; the security lead reads them in the weekly recovery cadence.
Features that power this workflow
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Verify fixes and track reopens on the same finding record
Scan-to-scan diff see what changed between any two executions
Finding overrides that survive every scan cycle
Every action recorded across the workspace
Document management for every security engagement
Notifications and alerts for the people who carry the work
Compliance tracking without a full GRC platform
AI-powered reports in seconds, not days
Collaborate across your entire team
Multi-factor authentication on every workspace
Run vulnerability SLA breach recovery as a structured loop
Recovery acknowledgement, cause classification, plan checklist, retest evidence, post-mortem note, and a corrective action read against breach recurrence per cause class. Start free.
No credit card required. Free plan available forever.