Vulnerability Remediation Runbook Template one operational procedure for intake, triage, SLA, verification, exceptions, and cycle metrics
A free, copy-ready vulnerability remediation runbook template. Twelve structured sections covering runbook header and version control, cycle activation criteria, roles for the cycle, intake and source mapping with deduplication and canonical-asset binding, triage and classification with severity reclassification and routing, ownership handoff to engineering with acknowledgement discipline, SLA windows and clock-start with defensible stop-the-clock conditions, fix verification protocol with paired retest, closure record discipline, exception escalation path with residual-band approver authority, cycle metrics and leadership readout, and runbook governance and review cadence. Aligned with ISO/IEC 27001 Annex A 8.8 and Clause 8.3, SOC 2 CC7.1 and CC7.2, PCI DSS Requirement 6.3 and 11.3, NIST SP 800-53 RA-5, SI-2, and CA-5, NIST SP 800-40 Rev. 4, CISA Binding Operational Directive 22-01, HIPAA 164.308(a)(1)(ii)(B), NIS2 Article 21, and DORA Article 9.
Run the runbook against the live findings ledger, not against a separate spreadsheet
SecPortal carries every cycle, every routed finding, every SLA pause, every paired retest, every closure record, and every exception entry on one workspace so the audit read of remediation performance and the operational read are the same record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn vulnerability remediation into a defensible operating procedure
A vulnerability remediation runbook is the per-team-and-asset-class operational procedure the remediation team reads during the recurring cycle. It is not the vulnerability management policy (the programme charter the audit reads) and it is not the SLA policy (the severity-to-window contract leadership signs). It is the live procedure: how intake deduplicates and binds findings to canonical assets, how triage classifies and routes, how the named engineering owner acknowledges the handoff, how the SLA window operates against the live ledger, how the fix verification protocol pairs to a retest, how the closure record stamps the canonical asset, how the exception escalation routes findings that cannot close, and how the cycle metrics flow into the leadership readout.
The twelve sections below cover the durable shape of one runbook against ISO/IEC 27001 Annex A 8.8 and Clause 8.3, SOC 2 CC7.1 and CC7.2, PCI DSS Requirement 6.3 and 11.3, NIST SP 800-53 RA-5 and SI-2 and CA-5, NIST SP 800-40 Rev. 4, CISA Binding Operational Directive 22-01, HIPAA 164.308(a)(1)(ii)(B), NIS2 Article 21, DORA Article 9, and the sector-specific overlays a regulated estate operates against. The package is not a substitute for the parent policies or the cycle-by-cycle live operating record; it is the codified procedure the team executes against the policies and against the live record. Pair it with the vulnerability management policy template for the parent programme charter, the vulnerability remediation SLA policy template for the severity-to-window contract the runbook reads against, the vulnerability management RACI matrix template for the ownership map the routing rules read against, the per-finding remediation worksheet for the per-record companion that operates against each finding, the security exception register template for the destination of findings that cannot close in the window, and the vulnerability prioritisation matrix template for the asset-tier overlay the triage applies. Copy the section that fits your stage and paste the rest as you go.
Copy the full runbook package (all twelve sections) as one block.
1. Runbook header and version control
Open the runbook with the asset class boundary, the version, and the authority. A reviewer should be able to read in the first lines which asset-class lane the runbook covers, who owns it, when it was last revised, and which framework expectations the procedure evidences. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; this opening block is what makes the runbook traceable to the rest of the programme rather than a loose file on a shared drive.
Runbook title: {{RUNBOOK_TITLE}}
Runbook identifier: {{RUNBOOK_IDENTIFIER}}
Asset-class lane (one of: external internet-facing perimeter, authenticated production web applications, code repositories and dependency graph, cloud control plane and infrastructure, container images and Kubernetes workloads, endpoint and operating-system fleet):
- {{ASSET_CLASS_LANE}}
Sector overlay applied (where applicable: cardholder data systems for PCI, electronic protected health information systems for HIPAA, industrial control systems for OT, telecommunications, financial services, federal civilian):
- {{SECTOR_OVERLAY}}
Version: {{RUNBOOK_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Revision trigger that produced this version (one of: scheduled annual review, post-cycle lesson, SLA policy revision, new scanner or import source, asset model change, scanner upgrade, framework or regulatory update, audit observation):
- {{REVISION_TRIGGER}}
Owner (the role that runs the cycle for this asset class; signs the runbook at publication):
- Role: {{OWNER_ROLE}}
- Named person at time of publication: {{OWNER_NAME}}
- Signature: {{OWNER_SIGNATURE}}
- Signature date: {{OWNER_SIGNATURE_DATE}}
Co-owners (roles that share authority for sections of the runbook):
- AppSec or security engineering co-owner: {{APPSEC_CO_OWNER_ROLE}}
- Platform engineering co-owner: {{PLATFORM_ENGINEERING_CO_OWNER_ROLE}}
- GRC reviewer (signs the framework crosswalk in Section 9): {{GRC_REVIEWER_ROLE}}
- Communications co-owner (signs the engineering handoff messaging in Section 6): {{COMMUNICATIONS_CO_OWNER_ROLE}}
Framework expectations evidenced by this runbook (ISO/IEC 27001 Annex A 8.8 and Clause 8.3; SOC 2 CC7.1 and CC7.2; PCI DSS Requirement 6.3 and 11.3; NIST SP 800-53 RA-5, SI-2, CA-5; NIST SP 800-40 Rev. 4; CISA BOD 22-01; HIPAA 164.308(a)(1)(ii)(B); NIS2 Article 21; DORA Article 9; internal policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}
Cross-references:
- Parent vulnerability management policy version: {{VM_POLICY_VERSION}}
- Parent vulnerability SLA policy version: {{SLA_POLICY_VERSION}}
- Vulnerability management RACI matrix version: {{RACI_MATRIX_VERSION}}
- Per-finding remediation worksheet version: {{WORKSHEET_VERSION}}
- Security exception register reference: {{EXCEPTION_REGISTER_REFERENCE}}
- Audit evidence retention policy version: {{RETENTION_POLICY_VERSION}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: version, effective date, trigger, owner, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, owner {{PRIOR_OWNER_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, owner {{PRIOR_OWNER_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Cycle activation criteria
Name the conditions that open a remediation cycle for this asset class. A defensible runbook runs the cycle on an explicit cadence rather than reacting whenever someone notices the queue is growing. The activation block makes the cadence observable and gives the remediation lead a named decision point that lands on the activity log as the first state change of each cycle.
Cadence trigger (the standing cycle the runbook operates against):
- Primary cadence: {{PRIMARY_CADENCE}} (daily | weekly | biweekly | monthly)
- Cadence window (the operating hours the cycle runs against): {{CADENCE_WINDOW}}
- Cadence kickoff event (the discrete moment that opens the cycle each period; e.g. Monday 09:00 intake review): {{CADENCE_KICKOFF_EVENT}}
Event triggers (additional conditions that open an out-of-cadence cycle):
- Critical finding from a continuous monitoring scan: cycle opens within {{CRITICAL_FINDING_RESPONSE_HOURS}} hours.
- CISA KEV entry added with applicability to the asset class: cycle opens within {{KEV_RESPONSE_HOURS}} hours per CISA BOD 22-01 expectations.
- Zero-day or emergency advisory with named exploitation activity: cycle opens within {{ZERO_DAY_RESPONSE_HOURS}} hours.
- Third-party pentest report intake with a critical or high finding: cycle opens within {{PENTEST_INTAKE_RESPONSE_HOURS}} hours.
- Bulk import landing with more than {{BULK_IMPORT_VOLUME_TRIGGER}} new findings: cycle opens within {{BULK_IMPORT_RESPONSE_HOURS}} hours.
- Vulnerability disclosure programme submission with critical or high severity: cycle opens within {{VDP_RESPONSE_HOURS}} hours.
Activating role (the role that confirms a cycle activation; activation is a discrete decision recorded on the activity log):
- Primary remediation lead: {{PRIMARY_REMEDIATION_LEAD_ROLE}}
- Backup remediation lead (when the primary is unavailable): {{BACKUP_REMEDIATION_LEAD_ROLE}}
- Escalation path when both are unavailable: {{ESCALATION_PATH_ON_UNAVAILABILITY}}
Activation produces the following state on the workspace:
- New engagement record opened or existing record updated with the cycle reference attached.
- Activity log entry created with timestamp, named actor, and cycle reference.
- Notification dispatched to the triage analyst, the asset-owner contacts, and the engineering team leads per the contact tree in Section 3.
- Cycle scope captured at activation: the source list, the import windows in scope, the asset-class subset in scope, and the carry-over backlog from the previous cycle.
Stand-down criteria (the conditions that close an activation when the cycle proves to be empty or the activation event was a false trigger):
- {{STAND_DOWN_CRITERIA}}
- Stand-down produces an activity log entry and a brief stand-down note on the engagement record.
3. Roles for this cycle
Name the people who carry the remediation cycle for this asset class. Generic role labels (the security team, engineering) collapse when the queue is moving into the one person who happens to be online, and the cycle improvises ownership. Asset-class-specific role assignment is the discipline that keeps named accountability visible during the cycle and observable on the audit trail after.
Remediation lead (the role that runs the cycle; declares severity reclassifications; authorises the exception escalation path; signs the cycle closure record):
- Primary: {{REMEDIATION_LEAD_PRIMARY_ROLE}}
- Backup: {{REMEDIATION_LEAD_BACKUP_ROLE}}
- Authority limit (what the lead authorises alone versus what requires the sponsor): {{LEAD_AUTHORITY_LIMIT}}
Triage analyst (the role that reads each new finding, applies the deduplication rules, binds the finding to the canonical asset, and routes to the named engineering owner):
- Primary: {{TRIAGE_ANALYST_PRIMARY_ROLE}}
- Backup: {{TRIAGE_ANALYST_BACKUP_ROLE}}
Asset-owner contacts for this asset class (the named contacts who confirm asset ownership when the binding rule cannot resolve automatically):
- {{ASSET_OWNER_CONTACTS_LIST}}
Engineering team leads engaged by this runbook (the named teams that receive routed findings for this asset class):
- AppSec engineering team lead: {{APPSEC_ENGINEERING_LEAD}}
- Platform engineering team lead: {{PLATFORM_ENGINEERING_LEAD}}
- Cloud platform team lead: {{CLOUD_PLATFORM_LEAD}}
- Identity engineering team lead (for identity-related findings): {{IDENTITY_ENGINEERING_LEAD}}
- Container platform team lead (for container and Kubernetes findings): {{CONTAINER_PLATFORM_LEAD}}
- Endpoint engineering team lead (for endpoint and OS-fleet findings): {{ENDPOINT_ENGINEERING_LEAD}}
- Data engineering team lead (for data-store findings): {{DATA_ENGINEERING_LEAD}}
GRC reviewer (the role that confirms the framework crosswalk in Section 9 against the live cycle output and signs the audit-evidence trail):
- Primary: {{GRC_REVIEWER_PRIMARY_ROLE}}
- Backup: {{GRC_REVIEWER_BACKUP_ROLE}}
Executive escalation contacts (the named contacts the remediation lead reaches when authority above the lead limit is required; severity-banded):
- High severity escalation: {{EXEC_ESCALATION_HIGH}}
- Critical severity escalation: {{EXEC_ESCALATION_CRITICAL}}
- Board notification trigger for breached criticals: {{BOARD_NOTIFICATION_TRIGGER}}
Authority discipline (read at the start of the cycle):
- The remediation lead authorises stop-the-clock decisions; the triage analyst executes them on the activity log.
- The engineering team lead authorises the fix design; the remediation lead does not freelance the technical solution.
- The GRC reviewer confirms the framework evidence read; the remediation lead does not assert audit posture without that confirmation.
- The exception register approver authorises residual-risk acceptance; the remediation lead routes findings to the register rather than closing them informally.
- The sponsor or board contact authorises actions above the lead limit; the remediation lead does not improvise above its authority.
4. Intake and source mapping
Name the finding sources the cycle reads from, the canonical-asset binding rule per source, the deduplication discipline, and the source-of-truth precedence when sources disagree. Without explicit intake rules the same finding lives twice and the closure rate metric reads against a structurally inflated backlog. This is the section that protects every downstream metric from compounding errors.
Sources the cycle reads from (each named with intake path, owner of the path, and the cadence of the read):
1. In-product external scanning (the perimeter scan output across the verified-domain list):
- Intake path: continuous monitoring scan results on the engagement record for the perimeter scope.
- Path owner: {{EXTERNAL_INTAKE_OWNER}}
- Read cadence: every cycle, against the scan windows since the previous cycle.
2. In-product authenticated scanning (authenticated DAST output across the logged-in application surface):
- Intake path: continuous monitoring scan results on the engagement record for the authenticated scope.
- Path owner: {{AUTH_INTAKE_OWNER}}
- Read cadence: every cycle, against the scan windows since the previous cycle.
3. In-product code scanning (Semgrep SAST plus dependency SCA against connected GitHub, GitLab, or Bitbucket repositories under OAuth):
- Intake path: code scan results on the engagement record for the repository scope.
- Path owner: {{CODE_INTAKE_OWNER}}
- Read cadence: every cycle, against scans since the previous cycle.
4. Third-party scanner imports (Nessus, Burp Suite, CSV ingest covering Tenable, Rapid7, Wiz, or any custom scanner output):
- Intake path: bulk finding import on the engagement record with column mapping.
- Path owner: {{THIRD_PARTY_INTAKE_OWNER}}
- Read cadence: as scans complete, with a runbook-cycle reconciliation each cycle.
5. Pentest report intake (engagement records or bulk imports for findings from internal red team, partner pentest firm, retainer engagements, or one-off assessments):
- Intake path: engagement record entry or bulk import on the engagement record.
- Path owner: {{PENTEST_INTAKE_OWNER}}
- Read cadence: as reports land, with a runbook-cycle reconciliation each cycle.
6. Vulnerability disclosure programme submissions and bug bounty triage (external researcher submissions through the disclosure channel):
- Intake path: engagement record entry per submission, with the submitter relationship captured on the record.
- Path owner: {{VDP_INTAKE_OWNER}}
- Read cadence: as submissions land, with runbook-cycle triage within the activation window in Section 2.
Canonical-asset binding rule (read in this order per finding; the first rule that resolves the binding wins):
1. The engagement-record asset reference set at scan or import time.
2. The verified-domain match against the host or URL in the finding evidence.
3. The repository OAuth binding against the source-file path for code findings.
4. The bulk-import column mapping that pins the finding to an internal asset identifier.
5. Manual override by the triage analyst with the rationale captured on the activity log.
- If none of the above resolves, the finding goes to the unbound queue and the triage analyst escalates to the asset-owner contact list in Section 3.
Deduplication discipline:
- When two findings against the same canonical asset carry the same CWE and the same vulnerable component, the older record becomes the canonical entry and the newer record attaches as supporting evidence on the canonical record with the source label preserved.
- When the same finding is detected by both the in-product authenticated scanner and an imported Nessus scan, the in-product record becomes the canonical entry and the imported record attaches as supporting evidence on the canonical record.
- When the same finding is reported by both a pentest engagement and a scanner, the pentest record becomes the canonical entry where the pentester verified exploitation; the scanner record attaches as supporting evidence.
- The canonical record retains every contributing source label on the activity log so the audit trail reads the full evidence picture without double-counting on the cycle metrics.
Source-of-truth precedence when sources disagree on severity (the runbook reads in this order):
1. Pentester-confirmed exploitation evidence overrides scanner-asserted severity for the same finding.
2. CISA KEV designation overrides every other severity assertion for the same CVE.
3. In-product scanner CVSS 3.1 or CVSS 4.0 scoring is canonical when no contradicting evidence is present.
4. Third-party scanner severity attaches as supporting evidence; the canonical severity is set by the in-product scoring or the override.
5. Source-of-truth conflicts that the precedence does not resolve route to the remediation lead for a written override on the canonical record with the rationale captured on the activity log.
Intake completion criteria (closes the intake phase of the cycle):
- Every new finding from every source above has been processed against the binding and dedup rules.
- The unbound queue is either empty or escalated.
- The canonical asset list for the cycle has been published.
- The cycle backlog size has been captured on the engagement record with the prior-cycle delta noted.
5. Triage and classification
Walk the triage analyst through the per-finding decisions that turn the intake queue into the routed work list. This is the section where the runbook prevents drift between scanner-asserted severity and the operational severity the team works against. Every classification decision lands on the activity log so the audit reads against an observable history of severity rather than a reconstructed one.
Step 1 - Read the canonical record:
- Confirm the asset binding from Section 4 holds.
- Confirm the dedup rules have not pulled this finding into a parent record since intake.
- Read the source evidence on the canonical record.
Step 2 - Apply the severity classification rule:
- Read the source-emitted severity (CVSS 3.1 vector, CVSS 4.0 vector where present, vendor severity label, OWASP risk rating, or pentester assertion).
- Apply the source-of-truth precedence from Section 4.
- Confirm or override on the canonical record with the rationale captured on the activity log when the override changes the band (critical, high, medium, low, informational).
Step 3 - Apply the asset-tier overlay:
- Read the asset tier for the canonical asset (tier-one production, tier-two production, internal-only, non-production, lab, deprecated).
- Apply the asset-tier severity escalation rule from the SLA policy: a finding on a tier-one customer-facing asset reads at the next band up for SLA purposes; a finding on a deprecated asset reads at the next band down.
- Capture the asset-tier overlay decision on the canonical record.
Step 4 - Apply the exploitability and reachability overlay:
- Confirm or set the KEV status on the canonical record (CISA KEV catalogue lookup against the CVE identifier).
- Confirm or set the EPSS score band on the canonical record where the CVE has an EPSS score.
- Where the finding is from in-product code scanning and a reachability analysis ran, capture the reachable-versus-unreachable label on the canonical record.
- Where the exploitability overlay changes the operational severity (e.g. a high-CVSS finding on an unreachable code path drops to medium for SLA purposes), capture the overlay on the canonical record with the rationale on the activity log.
Step 5 - Routing decision:
- Read the routing matrix in this section to pick the named engineering team for the canonical asset and the finding class.
- Confirm the routed team lead from Section 3 is the current named owner; if the team has rotated, update the canonical record with the named handoff.
- Update the canonical record with the routing decision, the assigned named owner, the SLA window start time, and the SLA target close date.
Routing matrix (engineering team by asset-class lane and finding class; customise per organisation; populate this table at runbook publication):
- {{ASSET_LANE}}, application logic finding -> {{APPLICATION_LANE_OWNER}}
- {{ASSET_LANE}}, infrastructure finding -> {{INFRA_LANE_OWNER}}
- {{ASSET_LANE}}, identity finding -> {{IDENTITY_LANE_OWNER}}
- {{ASSET_LANE}}, dependency finding -> {{DEPENDENCY_LANE_OWNER}}
- {{ASSET_LANE}}, configuration finding -> {{CONFIG_LANE_OWNER}}
- {{ASSET_LANE}}, secret-management finding -> {{SECRETS_LANE_OWNER}}
- {{ASSET_LANE}}, TLS or transport finding -> {{TLS_LANE_OWNER}}
- {{ASSET_LANE}}, data-protection finding -> {{DATA_PROTECTION_LANE_OWNER}}
- {{ASSET_LANE}}, container or image finding -> {{CONTAINER_LANE_OWNER}}
Triage record output (captured at the end of the triage phase):
- Number of new findings triaged: {{TRIAGED_FINDING_COUNT}}
- Severity reclassifications applied: {{SEVERITY_RECLASSIFICATION_COUNT}}
- KEV designations applied: {{KEV_DESIGNATION_COUNT}}
- Findings routed to each engineering team: {{ROUTED_COUNT_PER_TEAM}}
- Findings escalated to the remediation lead for source-of-truth resolution: {{LEAD_ESCALATION_COUNT}}
- Findings sent to the unbound queue and escalated to asset-owner contacts: {{UNBOUND_ESCALATION_COUNT}}
6. Ownership handoff to engineering
Name the handoff message, the acknowledgement requirement, and the escalation path when the engineering owner does not acknowledge in the window. The handoff is the moment the finding leaves the security backlog and joins the engineering backlog; without explicit handoff discipline the finding sits in a no-team queue and ages past its SLA window while the security team assumes engineering is on it and engineering assumes security is still triaging.
Handoff message template (released by the triage analyst on the canonical record; copy attaches to the named engineering owner via the contact tree):
Subject: Vulnerability remediation routing: {{FINDING_TITLE}} on {{ASSET_REFERENCE}} (severity {{SEVERITY}})
Body:
The triage analyst has routed the following finding to your team for remediation:
- Finding title: {{FINDING_TITLE}}
- Finding identifier: {{FINDING_IDENTIFIER}}
- Canonical asset: {{ASSET_REFERENCE}}
- Asset tier: {{ASSET_TIER}}
- Source of finding: {{FINDING_SOURCE}}
- CVE identifier (where applicable): {{CVE_IDENTIFIER}}
- CWE identifier: {{CWE_IDENTIFIER}}
- Severity at routing: {{SEVERITY}}
- CVSS vector: {{CVSS_VECTOR}}
- KEV designation: {{KEV_DESIGNATION}}
- EPSS score band (where applicable): {{EPSS_SCORE_BAND}}
- SLA window: {{SLA_WINDOW}}
- SLA target close date: {{SLA_TARGET_CLOSE_DATE}}
- Remediation guidance reference (from the 300+ finding template library on the canonical record): {{REMEDIATION_TEMPLATE_REFERENCE}}
- Supporting evidence references: {{SUPPORTING_EVIDENCE_REFERENCES}}
Acknowledgement requirement:
- Acknowledge receipt and assigned engineer within {{ACKNOWLEDGEMENT_WINDOW_HOURS}} hours by updating the finding owner and the in-progress timestamp on the canonical record.
- If you cannot meet the SLA window, raise the exception path in Section 9 within {{EXCEPTION_RAISE_WINDOW_HOURS}} hours rather than waiting for the breach.
Escalation path when the acknowledgement window passes without a response:
- First escalation: the triage analyst escalates to the engineering team lead per the contact tree in Section 3.
- Second escalation: the remediation lead escalates to the engineering team lead's manager.
- Third escalation: the remediation lead invokes the executive escalation contact for the severity band from Section 3.
Handoff completion criteria:
- The named engineering owner is recorded on the canonical record.
- The acknowledgement timestamp is captured on the canonical record.
- The handoff event lands on the activity log with the named actor, the named owner, and the timestamp.
- The dashboard cycle metric in Section 11 reflects the routed-and-acknowledged count rather than just the routed count.
7. SLA windows and clock-start
Read the severity-to-window table from the SLA policy and operate against it cycle by cycle. The runbook is not the place to renegotiate SLA windows; it is the place to operationalise them. Three disciplines hold the line: the clock-start rule per source so the breach calculation is unambiguous, the defensible stop-the-clock conditions so every pause has audit-readable rationale, and the live activity-log capture so the SLA metric reads against reality rather than against a reconstructed spreadsheet.
Severity-to-window table (read from the SLA policy; populate per asset tier at runbook publication):
- Critical, tier-one asset: window {{CRITICAL_TIER1_WINDOW_HOURS}} hours
- Critical, tier-two asset: window {{CRITICAL_TIER2_WINDOW_HOURS}} hours
- High, tier-one asset: window {{HIGH_TIER1_WINDOW_DAYS}} days
- High, tier-two asset: window {{HIGH_TIER2_WINDOW_DAYS}} days
- Medium, tier-one asset: window {{MEDIUM_TIER1_WINDOW_DAYS}} days
- Medium, tier-two asset: window {{MEDIUM_TIER2_WINDOW_DAYS}} days
- Low and informational: window per policy or treated as backlog hygiene rather than SLA-bound
Clock-start rule per source (the event that starts the SLA clock for the finding):
- In-product external scan: scan completion timestamp on the engagement record.
- In-product authenticated scan: scan completion timestamp on the engagement record.
- In-product code scan: scan completion timestamp on the engagement record.
- Third-party scanner import: import-completion timestamp on the engagement record.
- Pentest engagement: engagement-record entry timestamp for the finding.
- Vulnerability disclosure programme submission: triage-validation timestamp on the engagement record after the submission has been confirmed in scope and reproducible.
- KEV addition for an existing CVE: KEV designation timestamp on the canonical record (the runbook does not restart the clock; it applies the KEV-specific SLA window from the SLA policy from this timestamp forward).
Defensible stop-the-clock conditions (pre-agreed in the SLA policy; the runbook applies them with the rationale captured on the activity log):
- Scope or evidence ambiguity that requires asset-owner clarification.
- Vendor-managed dependency that requires a vendor patch not yet available.
- Missing compensating control where the runbook routes to the architecture review rather than to a direct fix.
- Asset decommissioning decision in-flight where the planned decommissioning date is earlier than the SLA target close date.
- Pending change-window constraints for regulated production environments where the change-management policy requires advance notice.
Stop-the-clock discipline:
- Every pause writes to the activity log with a named actor, a reason from the list above, and an expected resume condition.
- The pause window contributes to the runbook cycle metrics in Section 11 as paused time rather than missing time so the SLA-bound closure rate stays honest.
- The remediation lead reviews the pause register at every cycle close to flag pauses that have outlived their resume condition.
Breach evidence trail (captured in real time):
- Every routed finding carries the SLA target close date on the canonical record.
- The activity log captures the in-progress timestamp, every pause and resume event, and the closure timestamp.
- The cycle dashboard reads breach percentage from the live ledger; the escalation ladder activates at named breach-percentage thresholds rather than at the leadership scheduler's discretion.
- The breach evidence is the activity log read of the finding, not a separately maintained spreadsheet.
Escalation ladder against breach percentage (read from the SLA policy; populate at runbook publication):
- Breach percentage above {{LADDER_TIER1_THRESHOLD}}%: notify the engineering team lead per Section 3.
- Breach percentage above {{LADDER_TIER2_THRESHOLD}}%: notify the engineering team lead's manager.
- Breach percentage above {{LADDER_TIER3_THRESHOLD}}%: invoke the executive escalation contact for the severity band.
- Breach percentage above {{LADDER_TIER4_THRESHOLD}}%: invoke the board notification trigger.
8. Fix verification protocol
Name the evidence type the runbook accepts per fix class and the paired retest discipline. Closure on an engineer's word reads as informal; closure with a paired retest and the evidence on the canonical record reads as auditable. This section keeps regression rates honest and gives the team a defensible answer when the auditor asks how a finding was verified closed.
Evidence type per fix class (the artefacts the canonical record carries before the finding moves to closed):
- Patch applied (vulnerable dependency upgraded, OS package updated, library version pinned):
- Required evidence: post-fix scan output confirming the vulnerable version is no longer present; dependency manifest diff showing the version transition; commit reference where the manifest changed.
- Verification owner: triage analyst confirms; engineering owner provides evidence.
- Configuration change (security setting toggled, default credential rotated, header added, ACL tightened):
- Required evidence: post-fix scan output confirming the configuration check passes; configuration-file diff showing the change; production-environment confirmation (deployment record or live check).
- Verification owner: triage analyst confirms; engineering owner provides evidence.
- Code fix (vulnerable logic removed, input sanitisation added, authorisation check added, output encoding added):
- Required evidence: code-scan output confirming the rule no longer fires on the relevant file; commit reference with the diff; production-deployment record; paired retest from the in-product authenticated scanner confirming the runtime symptom is gone.
- Verification owner: triage analyst confirms; engineering owner provides evidence.
- Asset decommissioning (the asset is removed from the canonical scope):
- Required evidence: asset-decommissioning record on the engagement record; confirmation that the asset is removed from the verified-domain list (for external scope), removed from the repository OAuth scope (for code scope), or removed from the authenticated-scan target list (for authenticated scope); residual-asset check confirming the asset no longer responds.
- Verification owner: triage analyst confirms; asset owner provides evidence.
- Compensating control applied where direct fix is not feasible (network restriction, monitoring intensification, access reduction, WAF rule, runtime detection):
- Required evidence: compensating control entry on the canonical record with the named owner, the effective date, the expiry date, and the review trigger; verification artefact (firewall rule confirmation, WAF rule live, monitoring rule active, access-reduction record).
- Verification owner: triage analyst confirms; control owner provides evidence; the finding routes to the security exception register with a finite expiry rather than closing as remediated.
Paired retest discipline:
- Every fix submitted for verification triggers a paired retest against the original finding.
- The retest uses the same source that originally detected the finding (in-product scanner, code scan, manual pentest verification) where feasible.
- The retest result lands on the canonical record paired to the original finding rather than creating a new disconnected record.
- A passing retest moves the finding to closed with the closure timestamp captured on the activity log.
- A failing retest moves the finding back to in-progress with the rationale captured on the activity log; the original SLA clock does not restart.
Rejection criteria (the cases where the triage analyst rejects a closure request):
- Evidence missing for the fix class above.
- Retest result is missing or inconclusive.
- Evidence references a different asset or a different finding than the canonical record.
- Engineering owner has bypassed the canonical record and closed the finding informally; the triage analyst reverses the closure and captures the discipline gap on the activity log.
Verification completion criteria:
- Evidence is on the canonical record per the fix-class table above.
- Retest result is paired to the original finding.
- The activity log carries the verification event with the named actor and the timestamp.
- The cycle dashboard reflects the verified-and-closed count rather than just the engineer-asserted-fixed count.
9. Closure record discipline
Name the conditions that move a finding from in-progress to closed and produce the closure record the audit reads. Without explicit closure criteria the finding either closes prematurely on an asserted fix or lingers past its useful life. The closure block is a discrete decision that ends the per-finding portion of the runbook execution and stamps the audit-readable trail.
Closure criteria (all required before a finding moves to closed):
- Fix verification from Section 8 has passed against the evidence type for the fix class.
- Paired retest result is captured on the canonical record.
- Activity log carries the in-progress timestamp, every pause and resume event, the verification timestamp, and the closure timestamp.
- Canonical record carries the named engineering owner, the named asset owner where applicable, the source label list, and the supporting evidence references.
- Severity at closure matches the severity at routing unless an override was captured during the cycle with the rationale on the activity log.
- Where the closure is via compensating control, the security exception register carries the finite-expiry entry and the canonical record links to the exception entry rather than reading as a clean remediation.
Closure record output (signed by the triage analyst on the canonical record):
- Finding identifier: {{FINDING_IDENTIFIER}}
- Canonical asset reference: {{ASSET_REFERENCE}}
- Source label list: {{SOURCE_LABELS}}
- Severity at routing: {{SEVERITY_AT_ROUTING}}
- Severity at closure: {{SEVERITY_AT_CLOSURE}}
- SLA target close date: {{SLA_TARGET_CLOSE_DATE}}
- Actual closure timestamp: {{ACTUAL_CLOSURE_TIMESTAMP}}
- SLA outcome (within window | breached by {{BREACH_HOURS}} hours | closed via exception register entry {{EXCEPTION_ENTRY_REFERENCE}}):
- Closure cause (one of: patch applied, configuration change, code fix, asset decommissioned, compensating control with exception register entry):
- Evidence references on the canonical record: {{EVIDENCE_REFERENCES}}
- Retest reference: {{RETEST_REFERENCE}}
- Closure activity log entry reference: {{CLOSURE_ACTIVITY_LOG_REFERENCE}}
Closure rejection (the conditions that block the closure):
- Missing evidence per Section 8.
- Missing retest per Section 8.
- Source-label list incomplete; the canonical record needs the supporting-source labels before the audit-evidence read holds.
- Closure cause mis-routed: a finding that should route to the exception register has been closed as remediated instead.
Closure-as-exception path (when the closure cause is a compensating control):
- The canonical record links to the named entry on the security exception register.
- The exception entry carries the residual risk summary, the named approver authority for the residual band, the expiry date, the review trigger, and the compensating control evidence.
- The cycle metrics in Section 11 read the closure as an exception rather than as a clean remediation so the SLA-bound clean-closure rate stays honest.
Post-closure obligations:
- The compliance tracking record is updated with the framework evidence the closure produced.
- The leadership cycle dashboard reads the closure against the cycle SLA-bound closure rate.
- The audit committee receives the closure summary on the next governance cadence per Section 12.
10. Exception escalation path
Name the conditions under which a finding cannot close in the SLA window and routes to the security exception register instead. The exception path is the discipline that prevents findings from drifting past the window without governance and prevents the runbook from manufacturing fake closures to keep the metrics clean.
Exception trigger conditions (the cases where the finding cannot close in the window and routes to the exception register):
- Vendor-managed dependency with no available patch in the SLA window.
- Architectural constraint that requires a redesign cycle longer than the SLA window.
- Asset decommissioning scheduled later than the SLA target close date.
- Regulated change-window constraint that requires advance notice exceeding the SLA window.
- Active business event constraint (peak season freeze, audit period freeze, customer-commitment freeze) confirmed by the sponsor.
- Compensating control accepted as the durable remediation rather than a fix.
Exception routing procedure:
- The engineering owner raises the exception request on the canonical record with the trigger condition above.
- The triage analyst confirms the trigger condition and the supporting evidence.
- The remediation lead routes the finding to the security exception register entry with the residual-risk band, the named approver authority for the residual band, the proposed expiry date, the proposed compensating control, and the proposed review trigger.
- The named approver (residual-band approver authority from the exception register: typically the application owner for residual-medium, the head of security for residual-high, the CISO or sponsor for residual-critical) signs the exception entry with the date.
- The canonical record links to the exception entry, the cycle dashboard reads the closure as an exception, and the audit-evidence trail carries both the original finding and the exception decision.
Compensating control discipline:
- Every exception entry that depends on a compensating control names the control with the named owner, the effective date, the expiry date, and the review trigger.
- The compensating control entry is observable on the workspace (firewall rule confirmation, WAF rule live, monitoring rule active, access-reduction record) rather than asserted in a comment.
- The compensating control owner receives a notification at the review trigger to confirm the control is still in place; failure to confirm reopens the original finding for remediation.
Exception review cadence:
- Every exception entry is reviewed at the expiry date or the review trigger, whichever comes first.
- The review either confirms the compensating control still applies and extends the expiry, confirms a direct fix is now feasible and reopens the original finding for remediation, or confirms the asset has been decommissioned and closes the exception entry.
- The review event lands on the activity log with the named actor and the decision.
Exception register handoff record:
- Canonical finding identifier: {{FINDING_IDENTIFIER}}
- Exception register entry identifier: {{EXCEPTION_REGISTER_ENTRY_IDENTIFIER}}
- Trigger condition (from the list above): {{TRIGGER_CONDITION}}
- Residual-risk band: {{RESIDUAL_RISK_BAND}}
- Named approver authority for the residual band: {{APPROVER_AUTHORITY_ROLE}}
- Approver signature and date: {{APPROVER_SIGNATURE_AND_DATE}}
- Compensating control reference: {{COMPENSATING_CONTROL_REFERENCE}}
- Expiry date: {{EXPIRY_DATE}}
- Review trigger: {{REVIEW_TRIGGER}}
- Activity log entry reference: {{ACTIVITY_LOG_ENTRY_REFERENCE}}
11. Cycle metrics and leadership readout
Name the metrics the cycle produces and the leadership cadence that reads them. Metrics drawn from a parallel spreadsheet drift from the operational reality between cycles; metrics drawn from the live ledger keep the leadership read and the operational read in sync. This is the section that turns the cycle into a programme rather than a series of isolated events.
Per-cycle metrics (produced from the live findings management ledger at cycle close):
- New findings ingested in the cycle (by source and severity): {{NEW_FINDINGS_BY_SOURCE_AND_SEVERITY}}
- Findings closed in the cycle (by severity): {{CLOSED_BY_SEVERITY}}
- Findings closed in the cycle within the SLA window (clean closure rate): {{CLEAN_CLOSURE_RATE_PERCENT}}
- Findings closed in the cycle via exception register entries (exception closure rate): {{EXCEPTION_CLOSURE_RATE_PERCENT}}
- Findings breached the SLA window in the cycle (by severity): {{BREACH_COUNT_BY_SEVERITY}}
- Mean time to remediate per severity band: {{MTTR_PER_SEVERITY_HOURS}}
- Backlog size at cycle close (by severity): {{BACKLOG_SIZE_BY_SEVERITY}}
- Backlog age distribution (bands of 0-7 days, 8-30 days, 31-90 days, 91-180 days, 180+ days): {{BACKLOG_AGE_DISTRIBUTION}}
- Cycle dashboard delta against prior cycle: {{CYCLE_DELTA}}
Per-cycle cohort metrics (slice the cycle output by engineering team, by asset tier, by source, by CWE class):
- SLA-bound closure rate by engineering team: {{CLOSURE_RATE_BY_TEAM}}
- SLA-bound closure rate by asset tier: {{CLOSURE_RATE_BY_TIER}}
- SLA-bound closure rate by source: {{CLOSURE_RATE_BY_SOURCE}}
- Most frequent CWE classes in the cycle: {{TOP_CWES_IN_CYCLE}}
Rolling metrics (read every cycle against the rolling 90-day, 180-day, and 365-day windows):
- Rolling SLA-bound closure rate: {{ROLLING_CLOSURE_RATE}}
- Rolling breach percentage: {{ROLLING_BREACH_PERCENT}}
- Rolling exception rate: {{ROLLING_EXCEPTION_RATE}}
- Rolling backlog age trend: {{ROLLING_BACKLOG_AGE_TREND}}
Leadership readout cadence:
- Operational cycle dashboard refreshes every cycle close.
- Engineering team leads receive the per-team cohort readout every cycle close per the contact tree in Section 3.
- Security leadership receives the rolling metric readout every {{LEADERSHIP_ROLLUP_CADENCE_WEEKS}} weeks.
- The audit committee receives the rolling metric readout, the framework evidence summary, and the runbook revision log every {{AUDIT_COMMITTEE_CADENCE_QUARTERS}} quarter.
- The board receives the security leadership escalation summary when the rolling breach percentage exceeds the board notification trigger from Section 7.
Discipline against fake metrics:
- The cycle metrics are produced from the live findings management ledger and the activity log; the runbook owner does not maintain a parallel spreadsheet that the leadership read draws from.
- The clean-closure rate is calculated against the SLA window and the closure timestamp on the canonical record rather than against an engineer-asserted fixed flag.
- The exception closure rate is calculated separately from the clean-closure rate so leadership reads the two separately rather than as one combined number.
- The breach evidence is the activity log read of the finding rather than a separately maintained breach register.
- The backlog age distribution reads against the source-emitted timestamp rather than the workspace-creation timestamp so reopened or imported findings carry their original age rather than the import date.
12. Runbook governance and review cadence
Name the cadence at which the runbook is reviewed, the triggers that move a review forward, the audit-readable artefacts produced per cycle, and the programme metrics the audit committee reads against the runbook portfolio. Governance is what keeps the runbook a living document rather than a frozen file the next operator reads under pressure and discovers is out of date.
Standing review cadence:
- At least annual structured review per runbook even when no cycles have triggered intermediate revisions.
- Quarterly review of the runbook portfolio across asset-class lanes by the vulnerability management lead, the security engineering lead, and the GRC reviewer.
- Annual review of the runbook portfolio by the audit committee against the framework expectations in Section 1.
Event-driven revision triggers (each event below triggers a revision pass and a versioned re-publication):
- Cycle retrospective surfaced a procedural gap (every cycle that names a gap triggers a revision pass).
- New scanner or import source added to the intake list in Section 4.
- SLA policy revision (the runbook reads from the SLA policy; every revision flows through).
- Asset model change (new asset tier added, asset ownership reorganised, new asset-class lane added).
- Framework or regulatory update applicable to the asset-class lane.
- Scanner upgrade or rule-pack revision that materially changes the source-emitted severity (see severity recalibration drift literature for the cross-generation reconciliation).
- Audit observation that names the runbook as deficient.
Revision pass procedure:
- The runbook owner drafts the revision against the trigger.
- The role co-owners review their sections (AppSec lead, platform engineering lead, GRC reviewer, communications co-owner).
- The remediation lead signs the revision and publishes the new version with effective date.
- The activity log captures the revision event.
- The prior version is retained on document management per the audit evidence retention policy.
- The next cycle reads against the new version.
Audit-readable artefacts per cycle:
- Runbook version with effective date.
- Revision trigger record.
- Sign-off record (owner, co-owners, sponsor).
- Activity log entries for the revision event.
- Cycle retrospectives and post-cycle metrics referenced by the revision.
Programme metrics the audit committee receives quarterly:
- Number of runbooks in the portfolio (target: one per asset-class lane plus sector overlays): {{RUNBOOKS_IN_PORTFOLIO}}
- Average runbook age since last revision: {{AVERAGE_RUNBOOK_AGE_DAYS}}
- Number of runbooks revised in the quarter: {{RUNBOOKS_REVISED_QUARTER}}
- Number of runbooks overdue for scheduled review: {{RUNBOOKS_OVERDUE_REVIEW}}
- Number of cycle retrospectives that triggered runbook revision in the quarter: {{RETROSPECTIVES_TRIGGERING_REVISION_QUARTER}}
- Rolling SLA-bound closure rate per runbook: {{CLOSURE_RATE_PER_RUNBOOK}}
- Rolling breach percentage per runbook: {{BREACH_PERCENT_PER_RUNBOOK}}
- Rolling exception rate per runbook: {{EXCEPTION_RATE_PER_RUNBOOK}}
Programme acknowledgement:
- The runbook portfolio is the live procedural backbone of the vulnerability management programme.
- The vulnerability management policy defines the shape, the SLA policy fixes the contract, the runbook codifies how the team executes, the per-finding worksheet operates against each record, and the exception register destinations the findings that cannot close.
- The five artefacts are kept in sync on one workspace so the audit read of vulnerability management performance and the operational read are the same record.
Seven failure modes the runbook has to design against
The remediation runbook fails the audit read and the live-cycle read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the runbook so the customisation does not weaken the discipline that makes the procedure defensible.
Single generic playbook covering every asset class
The firm has one remediation playbook that tries to walk every asset class through the same procedural shape. Under cycle pressure the team reads routing rules that do not match the lane in hand and improvises the lane-specific procedure on the day. The fix is one runbook per asset-class lane with explicit intake mapping in Section 4 and asset-class-specific routing in Section 5.
Runbook written by GRC for audit rather than by the remediation team for operation
A GRC function or an external consultant drafts the runbook to satisfy an audit requirement. The procedure does not match the tools, the access patterns, or the cadence the remediation team actually runs. The team reads the runbook once during onboarding and never references it again. The fix is named ownership in Section 1 tied to the role that actually runs the cycle for the asset class, with revision pass authority sitting with that role.
Deduplication and asset-binding rules left implicit
The runbook does not name the canonical-asset binding rule or the deduplication discipline. The same finding lives twice (once from the in-product authenticated scanner, once from an imported Nessus scan, once from a pentest), the closure rate metric reads against an inflated backlog, and the team spends each cycle reconciling the same evidence under three records. The fix is the explicit binding precedence and the explicit dedup discipline in Section 4 with the canonical-record activity log preserving every contributing source label.
Clock-start and stop-the-clock left ambiguous
The runbook reads against the SLA policy but does not name the clock-start event per source or the pre-agreed defensible stop-the-clock conditions. Each cycle the breach calculation becomes a renegotiation between security and engineering, and the SLA discipline collapses. The fix is the explicit clock-start rule per source and the pre-agreed defensible stop-the-clock conditions in Section 7, with live activity-log capture so the breach evidence is the live ledger rather than a reconstructed spreadsheet.
Fix verification treated as the engineer's word
The runbook accepts closure on an engineer-asserted fix without an evidence type or a paired retest. The closure record reads against an unverified claim and the regression rate climbs cycle on cycle. The fix is the per-fix-class evidence protocol in Section 8 with the paired retest discipline and the rejection criteria the triage analyst applies before the canonical record moves to closed.
Exception escalation absent or ad-hoc
The runbook has no defined exception path. Findings that cannot close in the SLA window either drift past the window without governance, or get closed informally on a compensating control with no exception register entry, or get reopened cycle after cycle without resolution. The fix is the exception routing procedure in Section 10 with the residual-band approver authority, the compensating-control discipline, the named expiry date, and the review trigger that keeps the exception observable.
Cycle metrics produced from a spreadsheet rather than from the live ledger
The runbook owner maintains a parallel spreadsheet that the leadership readout reads from. The spreadsheet drifts from the live findings management ledger and the activity log between cycles, the clean-closure rate reads optimistically because exception closures are counted as clean, and the leadership decision-making operates against a number disconnected from the operational reality. The fix is the metric discipline in Section 11: cycle metrics drawn from the live ledger and the activity log, with the clean-closure rate and the exception-closure rate calculated separately so the leadership read stays honest.
Ten questions the quarterly governance review has to answer
Operational review keeps the runbook portfolio current. Governance review answers whether the portfolio is delivering durable remediation capability or accumulating gaps the audit will read as procedure-on-paper. Run these ten questions at every quarterly review and capture the answers in the governance record on the workspace.
1.How many runbooks does the portfolio carry, and what is the coverage against the six base asset-class lanes plus the sector overlays applicable to the firm.
2.What is the average runbook age since last revision, and how does it compare to the previous quarter.
3.How many runbooks are overdue for scheduled annual review, and what is the structural reason for the overrun.
4.How many cycles in the rolling twelve months triggered a runbook revision, and what proportion of those revisions has now published.
5.What is the rolling SLA-bound clean-closure rate per runbook, and how does it compare to the previous quarter.
6.What is the rolling exception rate per runbook, and which exception entries have outlived their expiry date or review trigger.
7.What is the rolling breach percentage per runbook against the SLA windows, and how does the escalation ladder activate.
8.What is the backlog age distribution per runbook, and what proportion of the backlog is older than 180 days.
9.How many findings in the rolling twelve months were closed via compensating control rather than direct fix, and how many of those compensating controls have been re-verified at their review trigger.
10.Which runbook revisions in the period were triggered by an audit observation or a regulator interaction.
How the package pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs findings, retests, exceptions, and engagement records on a workspace, the runbook execution becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every cycle to a versioned engagement record through engagement management, so the cycle scope, the source list in scope, the asset-class subset, the carry-over backlog, and the cycle retrospective live alongside the rest of the engagement record rather than scattered across a chat channel, a wiki page, and a shared drive.
The findings management feature carries each finding through the runbook with a CVSS 3.1 vector, the named engineering owner, the source label list, the SLA target close date, the supporting evidence references, and the closure timestamp. The bulk finding import feature ingests Nessus, Burp Suite, and CSV output for third-party scanner reconciliation inside the cycle. The 300+ finding-template library carries pre-set CVSS 3.1 vectors and remediation guidance the engineering owner reads from the canonical record. The retesting workflow pairs every fix to the original finding so the paired retest discipline in Section 8 has a structural home rather than a manual cross-reference. The finding overrides feature captures severity reclassifications and source-of-truth resolutions with the reason, the creator, and the timestamp on the canonical record. The finding comments and collaboration surface holds the per-record discussion between the triage analyst and the engineering owner so the handoff in Section 6 lands on the canonical record rather than in chat.
The continuous monitoring feature runs scheduled scans on daily, weekly, biweekly, or monthly cadences so the cycle activation criteria in Section 2 read against a live cadence rather than against a one-off scan. The external scanning, authenticated scanning, and code scanning feeds are the in-product source paths the intake section reads from, and the verified domain list, the AES-256-GCM encrypted credential storage, and the GitHub, GitLab, and Bitbucket OAuth bindings make the canonical-asset binding rule in Section 4 evaluable against live workspace state rather than against a separate asset register.
The activity log captures the timestamped chain of state changes by user with 30, 90, or 365-day retention windows depending on the plan, so the cycle activation, the routing decisions, the handoff acknowledgements, the SLA pause and resume events, the fix verification, the closure records, the exception escalations, and the runbook revisions are all observable rather than asserted. The team management feature with role-based access control and multi-factor authentication gates the runbook authority surface; the notifications and alerts feature dispatches the handoff and escalation events against the contact tree in Section 3.
The compliance tracking feature maps each cycle to 21 framework templates including ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, and CIS Controls with CSV export, so when an auditor asks how the firm operationalises vulnerability remediation, the runbook version, the cycle execution record, the SLA-bound closure rate, the exception register entries, and the framework crosswalk are one query against the same data. The AI report generation workflow produces a draft cycle retrospective and a leadership summary from the same engagement data so the audit committee read of remediation performance and the operational read are the same record rather than two independently edited documents that diverge between reporting cycles. The document management feature holds the runbook itself, every prior version, the cycle retrospectives, and the governance review record under the audit evidence retention policy classification.