Security Control Validation Runbook Template twelve sections that prove a deployed control still behaves as designed against a named scenario
A free, copy-ready per-control validation runbook template. Twelve structured sections covering runbook header and version control, control under test and design intent, validation scenario and signal pattern derived from BAS techniques or purple-team hypotheses or red-team after-action items or threat-intel reports, pre-validation state and prerequisites with an explicit execution gate, validation execution steps with time budgets, expected results and pass criteria with tolerance bands, observed results and evidence capture on the workspace document feature, pass and partial-pass and fail dispositions with named next actions, corrective action and finding creation procedure with severity SLA and verification cycle, validation record and audit evidence anchor cross-linked to the compliance tracking surface, validation cadence with five cadence bands and ten event-driven triggers, and runbook governance and review cadence. Aligned with ISO/IEC 27001 Clause 9.1 and 9.2 and Annex A 8.16 and A 8.34, SOC 2 CC4.1 and CC4.2, PCI DSS Requirement 10.4 and 11.5 and 12.10.5, NIST SP 800-53 CA-2 and CA-7, NIST CSF 2.0 DE.CM and PR.PT and ID.RA, NIS2 Article 21(2), and DORA Article 6 and 24. Built for internal security teams, AppSec, security engineering, security operations, vulnerability management, GRC, cloud security, security architects, and CISO-sponsored control assurance programmes that need a defensible alternative to vendor console screenshots as evidence the control still works.
Run the validation calendar on the live workspace, not on a side spreadsheet
SecPortal pairs every validation execution to an engagement record so the runbook version, the validator, the scenario, the disposition, the evidence pack, and the corrective action chain all live on one workspace with named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a control assurance check into a defensible runbook
A security control validation runbook is the per-control operational procedure that confirms a deployed control actually behaves as the design says it does, against a named scenario, with named telemetry and a named owner. It is not the control catalogue that lists what controls exist, and it is not the control documentation that names the design intent. It is the step-by-step procedure a validator runs at a cadence (or on event) to prove the control is alive, configured as expected, and producing the expected detection or prevention signal. Run alongside a breach and attack simulation programme for continuous coverage measurement and a penetration test programme for adversary-led path discovery, the per-control runbook becomes the operating record the audit and the regulator read against.
The twelve sections below cover the durable shape of one runbook against ISO/IEC 27001 Clause 9.1 and 9.2 and Annex A 8.16 and A 8.34, SOC 2 CC4.1 and CC4.2, PCI DSS Requirement 10.4 and 11.5 and 12.10.5, NIST SP 800-53 CA-2 and CA-7, NIST CSF 2.0 DE.CM and PR.PT and ID.RA, NIS2 Article 21(2), DORA Article 6 and 24, and the sector-specific overlays a regulated estate operates against. The package is not a substitute for the underlying control catalogue, the operational change-management process, the SOC live-monitoring surface, or the engineering teams that own the controls day to day. Pair it with the vulnerability management programme scorecard for the adjacent finding-side measurement, the security KPI dashboard template for the indicator layer that surfaces the validation programme into leadership reporting, the quarterly review template for the cadence vehicle that reads the validation portfolio into management review, the programme charter template that names the chartered authority the validation programme operates under, the security exception register template that holds the compensating control records for any deficiency that cannot close within the SLA window, the audit evidence retention policy template that classifies the validation records, and the security programme KPIs and metrics framework for the indicator selection that feeds the audit committee read. 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 control under test, the version, the validator, and the authority. A reviewer should be able to read in the first lines which control class the runbook covers, who owns the validation, who runs it, when it was last revised, and which framework expectations the validation evidences. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; the version control block is what makes the validation record traceable across audit cycles rather than a loose screenshot stack from the control vendor console.
Runbook title: {{RUNBOOK_TITLE}}
Runbook identifier (cross-referenced from the control catalogue and the validation calendar): {{RUNBOOK_IDENTIFIER}}
Control under test (the named control instance the runbook validates):
- Control identifier from the catalogue: {{CONTROL_IDENTIFIER}}
- Control class (one of: identity and access, endpoint and workload, network and perimeter, data protection, logging and detection, governance):
- {{CONTROL_CLASS}}
- Control tier (one of: tier-1 production-critical, tier-2 supporting, tier-3 administrative):
- {{CONTROL_TIER}}
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-validation lesson, post-incident lesson, vendor release change, platform migration, scope change, regulatory change, audit observation):
- {{REVISION_TRIGGER}}
Validation cadence band (one of: monthly, quarterly, semi-annual, annual, event-driven only):
- {{VALIDATION_CADENCE_BAND}}
- Next scheduled validation due date: {{NEXT_VALIDATION_DUE_DATE}}
- Event triggers that force re-validation regardless of cadence: {{EVENT_TRIGGER_LIST}}
Owner of the underlying control (the role responsible for the control operating as designed):
- Role: {{CONTROL_OWNER_ROLE}}
- Named person at time of publication: {{CONTROL_OWNER_NAME}}
Owner of the runbook (the role responsible for keeping the validation procedure current):
- Role: {{RUNBOOK_OWNER_ROLE}}
- Named person at time of publication: {{RUNBOOK_OWNER_NAME}}
- Runbook owner signature: {{RUNBOOK_OWNER_SIGNATURE}}
- Signature date: {{RUNBOOK_OWNER_SIGNATURE_DATE}}
Independent validator (the role authorised to execute the validation for tier-1 production-critical controls; left blank for tier-2 and tier-3 where the control owner self-validates with co-validator sign-off):
- Independent validator role: {{INDEPENDENT_VALIDATOR_ROLE}}
- Reason independent validation is required for this control: {{INDEPENDENT_VALIDATION_REASON}}
Co-validator (the role that signs off the validation outcome when the control owner self-validates):
- Co-validator role: {{CO_VALIDATOR_ROLE}}
Framework expectations evidenced by this runbook (ISO/IEC 27001 Clause 9.1 and 9.2; Annex A 8.16, A 8.34; SOC 2 CC4.1, CC4.2; PCI DSS Requirement 10.4, 11.5, 12.10.5; NIST SP 800-53 CA-2, CA-7; NIST CSF 2.0 DE.CM, PR.PT, ID.RA; NIS2 Article 21(2); DORA Article 6 and 24; sector overlays; internal policy):
- {{FRAMEWORK_EXPECTATIONS_LIST}}
Cross-references:
- Parent control catalogue entry: {{CONTROL_CATALOGUE_ENTRY_REFERENCE}}
- Parent control assurance programme charter: {{CONTROL_ASSURANCE_CHARTER_REFERENCE}}
- Linked BAS technique identifier (where the BAS platform exercises the same scenario): {{BAS_TECHNIQUE_IDENTIFIER}}
- Linked purple-team scenario reference (where a purple-team hypothesis fed this runbook): {{PURPLE_TEAM_SCENARIO_REFERENCE}}
- Linked red-team finding reference (where a red-team after-action item named the control): {{RED_TEAM_FINDING_REFERENCE}}
- 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. Control under test and design intent
Name the control under test and the design intent the runbook validates against. Validation that does not anchor to the documented design intent measures whatever the validator chooses to look at on the day, and the audit reading cannot reconcile the validation outcome to the control catalogue. This section restates the design intent in operational terms so the scenario in Section 3 and the pass criteria in Section 6 read against a stable target rather than against a moving interpretation.
Control name: {{CONTROL_NAME}}
Control description (one paragraph from the control catalogue):
{{CONTROL_DESCRIPTION}}
Design intent (the outcome the control is deployed to produce):
- Primary intent: {{PRIMARY_DESIGN_INTENT}}
- Secondary intent: {{SECONDARY_DESIGN_INTENT}}
- Out-of-scope intent (what the control is explicitly not designed to do; prevents validation drift into adjacent control space): {{OUT_OF_SCOPE_INTENT}}
Control configuration baseline (the configuration state the validator confirms is in place before exercising the scenario):
- Platform reference: {{PLATFORM_REFERENCE}}
- Configuration baseline reference (link to the as-designed configuration document or as-code repository): {{CONFIG_BASELINE_REFERENCE}}
- Baseline owner: {{CONFIG_BASELINE_OWNER}}
- Last baseline change reference: {{LAST_BASELINE_CHANGE_REFERENCE}}
Telemetry the control emits when functioning as designed (the durable signal the validator reads against):
- Primary telemetry channel: {{PRIMARY_TELEMETRY_CHANNEL}}
- Secondary telemetry channel: {{SECONDARY_TELEMETRY_CHANNEL}}
- Telemetry custodian (the role responsible for the telemetry channel health): {{TELEMETRY_CUSTODIAN_ROLE}}
Detection or prevention claim the control owner asserts:
- What the control prevents: {{PREVENTION_CLAIM}}
- What the control detects: {{DETECTION_CLAIM}}
- What the control alerts on: {{ALERT_CLAIM}}
- What the control logs without alerting: {{LOG_ONLY_CLAIM}}
Adjacent controls in the control fabric (controls the runbook does not test but that affect interpretation of the validation result):
- Upstream control 1: {{UPSTREAM_CONTROL_1}}
- Upstream control 2: {{UPSTREAM_CONTROL_2}}
- Downstream control 1: {{DOWNSTREAM_CONTROL_1}}
- Downstream control 2: {{DOWNSTREAM_CONTROL_2}}
Control owner attestation (signed at the point this runbook is published or after material design change):
- Control owner: {{CONTROL_OWNER_NAME}}
- Attestation statement: "The design intent above accurately represents the as-designed behaviour of the control on the platform reference above as of {{ATTESTATION_DATE}}."
- Signature: {{CONTROL_OWNER_ATTESTATION_SIGNATURE}}
3. Validation scenario and signal pattern
Name the scenario the runbook exercises and the signal pattern the validator looks for. Validation without an explicit scenario measures the absence of error rather than the presence of the designed behaviour, and the audit reading cannot reconstruct what was actually tested. The scenario block ties the runbook to a named adversary behaviour, configuration condition, or operational event so the validation produces a discrete observation rather than a vague all-clear.
Scenario class (one of: configuration conformance check, telemetry health check, prevention efficacy exercise, detection efficacy exercise, alert routing exercise, end-to-end response chain exercise, compensating control efficacy exercise, drift detection exercise):
- {{SCENARIO_CLASS}}
Scenario name (the named exercise the validator runs):
- {{SCENARIO_NAME}}
Scenario derivation source (one of: control design specification, BAS platform technique, purple-team hypothesis, red-team after-action item, threat-intel hypothesis, incident post-mortem action item, regulator expectation, audit observation):
- {{SCENARIO_DERIVATION_SOURCE}}
Reference to source artefact (the BAS technique identifier, the purple-team scenario reference, the red-team finding identifier, the incident reference, the threat-intel report reference, the regulator finding reference, the audit observation reference):
- {{SOURCE_ARTEFACT_REFERENCE}}
MITRE ATT&CK technique reference (where the scenario maps to a named technique; helpful for cross-runbook coverage analysis):
- Primary technique: {{ATTACK_TECHNIQUE_PRIMARY}}
- Secondary techniques: {{ATTACK_TECHNIQUE_SECONDARY_LIST}}
Scenario execution form (one of: tabletop walk-through, live execution against a non-production canary, live execution against a production canary cohort, live execution against the production estate under safe-mode constraints, automated execution via BAS platform under runbook control):
- {{SCENARIO_EXECUTION_FORM}}
Execution constraints (the explicit boundaries the validator operates within for safety):
- Affected estate scope: {{AFFECTED_ESTATE_SCOPE}}
- Forbidden execution targets: {{FORBIDDEN_EXECUTION_TARGETS}}
- Forbidden execution windows (named change-freeze windows the execution does not enter): {{FORBIDDEN_EXECUTION_WINDOWS}}
- Required safety side-effects (compensating telemetry the validator enables before execution): {{SAFETY_SIDE_EFFECTS_REQUIRED}}
Signal pattern the validator looks for (the durable observable the control should produce in response to the scenario):
- Primary signal: {{PRIMARY_SIGNAL}}
- Secondary signal: {{SECONDARY_SIGNAL}}
- Negative signal (signals that should not appear if the control is operating as designed): {{NEGATIVE_SIGNAL}}
- Time-window the signal should appear within: {{SIGNAL_TIME_WINDOW}}
Expected adjacent signal (signals that should appear on adjacent controls in the control fabric and that the validator notes without testing):
- Adjacent signal 1: {{ADJACENT_SIGNAL_1}}
- Adjacent signal 2: {{ADJACENT_SIGNAL_2}}
4. Pre-validation state and prerequisites
Confirm the pre-validation configuration state, the validator authority, the safety prerequisites, and the notification responsibilities before the scenario execution begins. Skipping the pre-validation state is the most common source of false-positive validation outcomes (the validation passes because the control was already exercised by an unrelated event) and false-negative outcomes (the validation fails because a precondition was not met and the control never got a chance to behave). The prerequisites block is what makes the validation reproducible.
Pre-validation configuration confirmation (the validator reads the as-designed configuration and confirms the deployed configuration matches before execution):
- As-designed configuration reference: {{AS_DESIGNED_CONFIG_REFERENCE}}
- Deployed configuration source of truth (admin console, infrastructure-as-code repository, configuration management database): {{DEPLOYED_CONFIG_SOURCE}}
- Configuration match check method: {{CONFIG_MATCH_CHECK_METHOD}}
- Match result: pass | drift detected | configuration source unreadable
Drift handling (when the deployed configuration does not match the as-designed configuration):
- Drift severity classification: minor | material | breach
- Drift finding creation: required for material and breach; optional for minor with note on the validation record
- Validation halt rule: validation halts on material and breach drift until the configuration is restored or the as-designed configuration is updated to reflect intentional change
Validator authority confirmation:
- Validator role authorised to run the scenario for this control class: {{VALIDATOR_AUTHORISED_ROLE}}
- Validator named at time of execution: {{VALIDATOR_NAME}}
- Independent validator check (tier-1 only): {{INDEPENDENT_VALIDATOR_CHECK}}
Pre-execution notifications:
- Telemetry custodian briefed that execution is starting: {{TELEMETRY_CUSTODIAN_BRIEFED}}
- On-call SOC role briefed that an authorised exercise is starting in scope: {{ON_CALL_SOC_BRIEFED}}
- Platform owner briefed: {{PLATFORM_OWNER_BRIEFED}}
- Change advisory board notified for production-scope execution: {{CAB_NOTIFIED}}
Rollback prerequisites:
- Rollback path documented before execution: {{ROLLBACK_PATH_DOCUMENTED}}
- Rollback owner: {{ROLLBACK_OWNER}}
- Rollback test conducted in non-production before this validation cycle: {{ROLLBACK_TEST_CONDUCTED}}
Time budget for the validation execution (the wall-clock window the validator operates within; longer-running scenarios document a phased execution):
- Total validation time budget: {{TOTAL_VALIDATION_TIME_BUDGET}}
- Pre-execution preparation budget: {{PRE_EXECUTION_BUDGET}}
- Execution budget: {{EXECUTION_BUDGET}}
- Observation budget: {{OBSERVATION_BUDGET}}
- Post-execution clean-up budget: {{POST_EXECUTION_BUDGET}}
Execution gate (the validator does not proceed unless each of the above has been confirmed; the activity log captures the gate as a checkpoint passed entry):
- Pre-validation state confirmed: pending | confirmed
- Validator authority confirmed: pending | confirmed
- Pre-execution notifications dispatched: pending | confirmed
- Rollback prerequisites confirmed: pending | confirmed
- Time budget accepted: pending | confirmed
5. Validation execution steps with time budgets
Walk the validator through the execution in named steps with a time budget per step. Without explicit steps the validator improvises the execution and the operating record loses the procedural advantage the runbook is designed to give. Each step produces a discrete activity log entry so the audit can read the execution chronologically rather than as a single after-the-fact summary.
Step 1 (target: within first {{STEP_1_BUDGET}} minutes) - Open the validation engagement record:
- Open a workspace engagement record naming the runbook identifier, the runbook version, the control under test, the scenario, the validator, the planned execution window, and the parent compliance evidence cycle reference.
- Attach the as-designed configuration reference, the deployed configuration source, and any source artefact references from Section 3.
- The activity log entry opens with the timestamp, the validator name, and the engagement record reference.
Step 2 (target: within next {{STEP_2_BUDGET}} minutes) - Pre-validation state confirmation:
- Execute the pre-validation gate from Section 4 against the deployed configuration and the notifications list.
- Record the gate outcome (each check pass or fail) on the engagement record.
- If any gate fails, halt the validation and route to corrective action per Section 9.
Step 3 (target: within next {{STEP_3_BUDGET}} minutes) - Scenario execution:
- Execute the scenario from Section 3 with the validator authority confirmed and the execution constraints respected.
- Capture the execution artefact (command sequence, BAS run identifier, tabletop discussion notes) to the engagement record document attachments.
- The activity log entry records the scenario execution start time, the named validator, and the scenario identifier.
Step 4 (target: within next {{STEP_4_BUDGET}} minutes) - Signal observation:
- Read the primary signal channel from Section 3 for the expected time window.
- Read the secondary signal channel.
- Confirm the negative signals are absent.
- Read the adjacent signal channels for the expected fabric effect.
- Capture each signal observation (or absence) on the engagement record with the source reference.
Step 5 (target: within next {{STEP_5_BUDGET}} minutes) - Cross-check against the pass criteria:
- Read the observed signal pattern against the pass criteria in Section 6.
- Assign the disposition from Section 8 (pass, partial-pass, fail).
- Capture the disposition rationale on the engagement record.
Step 6 (target: within next {{STEP_6_BUDGET}} minutes) - Post-execution clean-up:
- Restore any safety side-effects to baseline.
- Confirm the rollback prerequisites are not needed (if execution succeeded as expected).
- Notify the telemetry custodian, the on-call SOC role, and the platform owner that execution has completed.
- The activity log entry closes with the timestamp and the cumulative execution narrative.
Step 7 (target: within next {{STEP_7_BUDGET}} minutes) - Validation record creation:
- Move to Section 10 to capture the durable validation record.
- Move to Section 9 for any corrective actions raised by the disposition.
Execution exception handling:
- Scenario execution fails to start (platform unavailable, validator authority not confirmed, unexpected configuration state): halt at Step 3, raise an execution exception on the engagement record, route to runbook owner for re-scheduling.
- Scenario execution causes unexpected side-effect on the estate: halt immediately, invoke rollback per Section 4, raise a finding on the corrective action chain, notify the on-call SOC role.
- Telemetry channel unreadable during observation window: pause Step 4, escalate to the telemetry custodian, record the telemetry-channel finding on the corrective action chain.
6. Expected results and pass criteria
Name the pass criteria explicitly so the disposition is reproducible across validators and across cycles. Pass criteria that read as "the validator judges the control to be working" produce inconsistent dispositions across the portfolio and undermine the audit defensibility of the validation record. This section converts the design intent in Section 2 and the signal pattern in Section 3 into a discrete pass-or-not test the validator applies.
Pass criteria (all required for a full pass disposition):
- Configuration baseline match (Section 4 pre-validation state pass): required
- Primary signal observed within the expected time window (Section 3 signal pattern): required
- Secondary signal observed (where applicable; required when the design intent depends on the secondary signal): {{SECONDARY_SIGNAL_REQUIRED}}
- Negative signal absent throughout the observation window: required
- Adjacent fabric signals observed (where applicable; informational rather than required unless the runbook tests the fabric interaction): {{ADJACENT_SIGNALS_REQUIRED}}
- Telemetry channels healthy throughout the observation window: required
- No unexpected side-effect on the estate during execution: required
- Rollback prerequisites not invoked: required
Partial pass criteria (one or more required pass criteria failed but the failure is bounded and does not invalidate the underlying control):
- Configuration baseline drift detected but classified as minor: partial pass with drift note on the validation record
- Primary signal observed but outside the expected time window by less than the agreed tolerance: partial pass with timing note
- Secondary signal absent where secondary was marked optional: partial pass with absence note
- Adjacent fabric signal absent where adjacent was marked informational: pass (the runbook does not test the fabric)
- Telemetry channel intermittent but capturing the primary signal: partial pass with telemetry health finding raised on the corrective action chain
Fail criteria (any of the below results in a fail disposition):
- Configuration baseline drift classified as material or breach
- Primary signal not observed within the expected time window
- Negative signal observed during the observation window
- Telemetry channel unreadable during the primary signal window
- Unexpected side-effect on the estate caused by execution
- Rollback prerequisites invoked during the execution
Inconclusive criteria (the validation cannot reach a pass or fail because of an execution exception):
- Platform unavailable preventing scenario execution
- Validator authority not confirmed at execution time
- Telemetry custodian briefed but telemetry not provided in the observation window
- Change-freeze window collision aborting the execution
- Inconclusive validations are not pass; they are re-scheduled per the execution exception handling in Section 5
Tolerance bands (the runbook is explicit about what counts as on-target versus off-target so the validator does not negotiate the threshold during the disposition):
- Signal timing tolerance: {{SIGNAL_TIMING_TOLERANCE}}
- Signal completeness tolerance: {{SIGNAL_COMPLETENESS_TOLERANCE}}
- Configuration drift tolerance bands (minor, material, breach): {{DRIFT_TOLERANCE_BANDS}}
- Telemetry health tolerance bands: {{TELEMETRY_HEALTH_TOLERANCE_BANDS}}
7. Observed results and evidence capture
Capture the observed results on the validation engagement record with the source references so the audit can read the same evidence the validator read. Verbal pass-or-fail assertions without the underlying evidence are a recognisable audit deficiency; the engagement record carries the evidence as durable, time-stamped, named artefacts that survive the validator changing roles or leaving the firm.
Observed configuration state at execution time (paste or attach the source of truth view):
- Source: {{OBSERVED_CONFIG_SOURCE}}
- Snapshot reference: {{OBSERVED_CONFIG_SNAPSHOT_REFERENCE}}
- Snapshot timestamp: {{OBSERVED_CONFIG_TIMESTAMP}}
- Diff against as-designed baseline (where applicable): {{OBSERVED_CONFIG_DIFF}}
Observed primary signal (raw or summarised; the raw artefact lives as an attachment on the engagement record):
- Observation source: {{PRIMARY_SIGNAL_SOURCE}}
- Observation timestamp: {{PRIMARY_SIGNAL_TIMESTAMP}}
- Observation content (summary; the raw is attached): {{PRIMARY_SIGNAL_OBSERVATION}}
- Time-to-signal from scenario execution: {{TIME_TO_PRIMARY_SIGNAL}}
Observed secondary signal:
- Observation source: {{SECONDARY_SIGNAL_SOURCE}}
- Observation timestamp: {{SECONDARY_SIGNAL_TIMESTAMP}}
- Observation content: {{SECONDARY_SIGNAL_OBSERVATION}}
Observed negative signal status (the validator confirms absence; non-absence is captured as a fail):
- Negative signals checked: {{NEGATIVE_SIGNALS_CHECKED}}
- Negative signal observation outcome: {{NEGATIVE_SIGNAL_OUTCOME}}
Observed adjacent fabric signals (informational unless the runbook tests the fabric):
- Adjacent signal 1 observation: {{ADJACENT_SIGNAL_1_OBSERVATION}}
- Adjacent signal 2 observation: {{ADJACENT_SIGNAL_2_OBSERVATION}}
Telemetry channel health during the observation window:
- Primary telemetry channel health: healthy | degraded | unreadable
- Secondary telemetry channel health: healthy | degraded | unreadable
- Telemetry custodian note (where degraded or unreadable): {{TELEMETRY_CUSTODIAN_NOTE}}
Execution-side observations:
- Platform behaviour during execution: {{PLATFORM_BEHAVIOUR_DURING_EXECUTION}}
- Unexpected side-effect (where present): {{UNEXPECTED_SIDE_EFFECT_DESCRIPTION}}
- Rollback invoked: yes | no
- Rollback outcome (where invoked): {{ROLLBACK_OUTCOME}}
Evidence attachments held on the workspace document management feature:
- Scenario execution artefact: {{SCENARIO_EXECUTION_ARTEFACT_REFERENCE}}
- Primary signal raw capture: {{PRIMARY_SIGNAL_RAW_REFERENCE}}
- Secondary signal raw capture: {{SECONDARY_SIGNAL_RAW_REFERENCE}}
- Configuration snapshot raw: {{CONFIG_SNAPSHOT_RAW_REFERENCE}}
- Telemetry channel health export: {{TELEMETRY_HEALTH_EXPORT_REFERENCE}}
- Validator notes: {{VALIDATOR_NOTES_REFERENCE}}
Chain of custody:
- Captured by: {{EVIDENCE_CAPTURED_BY_ROLE}}
- Reviewed by (co-validator or sign-off role): {{EVIDENCE_REVIEWED_BY_ROLE}}
- Read access gated by: team-management role-based access plus multi-factor authentication
- Retention classification per the audit evidence retention policy: {{EVIDENCE_RETENTION_CLASSIFICATION}}
8. Pass, partial-pass, and fail dispositions
Assign the disposition explicitly with the rationale tied to the pass criteria in Section 6. The disposition is the discrete state that drives the corrective action chain in Section 9 and that the audit reads as the validation outcome of record. Vague dispositions ("the control mostly worked") undermine the operating discipline the runbook exists to enforce and produce an audit reading the firm cannot reconcile to the underlying evidence.
Disposition (one of: pass, partial-pass with note, partial-pass with finding raised, fail, inconclusive):
- Disposition: {{DISPOSITION}}
Disposition rationale (the named pass criteria from Section 6 against the observed results from Section 7):
- {{DISPOSITION_RATIONALE}}
Pass actions (where disposition is pass):
- Update the next scheduled validation due date per the cadence band in Section 11.
- Update the compliance tracking record with the pass evidence anchor.
- Close the validation engagement record with the pass disposition.
- No corrective action raised.
Partial-pass with note actions (where the partial-pass is bounded and does not require a finding):
- Capture the note on the engagement record explaining the bounded deviation.
- Update the next scheduled validation due date per the cadence band, optionally pulled forward to confirm the deviation does not regress.
- Update the compliance tracking record with the partial-pass evidence anchor and the note.
- Close the validation engagement record with the partial-pass disposition.
Partial-pass with finding actions (where the partial-pass surfaces a fixable underlying weakness):
- Raise a finding on findings-management with a CVSS-aligned severity, a named owner, a target close date, the rationale, and the cross-reference to the validation engagement record.
- Capture the finding identifier on the engagement record.
- Update the next scheduled validation due date pulled forward to verify the corrective action lands.
- Close the validation engagement record with the partial-pass disposition.
Fail actions:
- Raise a finding on findings-management with the appropriate severity, a named owner, a target close date, the rationale, and the cross-reference.
- Pull forward the next scheduled validation due date for a verification cycle once the corrective action lands.
- Brief the control owner and the runbook owner with the fail disposition and the corrective action chain.
- Brief the compliance owner with the fail disposition for inclusion in the next compliance evidence read.
- Close the validation engagement record with the fail disposition; the corrective action chain operates on the new finding rather than the validation record.
Inconclusive actions:
- Capture the execution exception cause on the engagement record.
- Re-schedule the validation per the execution exception handling in Section 5.
- Brief the runbook owner with the inconclusive disposition and the re-schedule plan.
- Close the validation engagement record with the inconclusive disposition.
Disposition discipline:
- The validator assigns the disposition.
- The co-validator (or independent validator for tier-1) reviews and confirms the disposition.
- The runbook owner reads every disposition into the runbook governance cycle in Section 12.
- The compliance owner reads pass, partial-pass, and fail dispositions into the next compliance evidence read.
- The audit committee reads the rolling disposition mix at the cadence in Section 12.
9. Corrective action and finding creation procedure
Convert partial-pass and fail dispositions into tracked findings rather than letting them remain as notes on the validation record. The corrective action chain is the bridge between the validation runbook and the wider remediation programme; without an explicit chain the validation produces evidence of the deficiency without a path to closure, and the next cycle reads the same deficiency again.
Finding creation rules:
- Every fail disposition produces a finding.
- Every partial-pass with material implication produces a finding.
- Every drift classified as material or breach produces a finding.
- Every telemetry health degradation that affected the validation produces a finding routed to the telemetry custodian.
- Every unexpected side-effect on the estate produces a finding routed to the platform owner.
Finding metadata (set when the finding is opened):
- Finding title (descriptive of the deficiency, not of the runbook): {{FINDING_TITLE}}
- Source: control validation runbook ({{RUNBOOK_IDENTIFIER}})
- Validation engagement record reference: {{VALIDATION_ENGAGEMENT_REFERENCE}}
- Control identifier: {{CONTROL_IDENTIFIER}}
- Severity band (use the CVSS-aligned severity model that the wider finding catalogue uses; tier-1 control fails default to high or critical pending review by the runbook owner): {{FINDING_SEVERITY}}
- Owner (named role responsible for the corrective action): {{FINDING_OWNER}}
- Target close date (driven by the severity SLA in the vulnerability remediation policy): {{FINDING_TARGET_CLOSE_DATE}}
- Cross-references: validation engagement record, control catalogue entry, BAS technique (where applicable), purple-team scenario (where applicable), incident reference (where the validation followed an incident), regulator finding (where the validation followed a regulator interaction)
Corrective action chain:
- The finding owner reads the finding and confirms acceptance of ownership within the SLA window.
- The finding owner proposes the corrective action.
- The runbook owner reviews the corrective action against the design intent in Section 2 and the underlying control catalogue entry.
- The corrective action executes on the affected platform with the change-management process the platform operates under.
- The validator (or a second validator for tier-1) runs a verification validation against the runbook once the corrective action lands.
- The verification validation closes the finding on a pass disposition, downgrades the finding severity on a partial-pass with note, or escalates the finding on a fail.
Escalation rules:
- A tier-1 control finding open beyond the SLA window escalates to the control owner, the runbook owner, and the security operations leader.
- A tier-1 control finding open beyond 1.5 times the SLA window escalates to the CISO.
- A tier-1 control finding open beyond 2 times the SLA window escalates to the executive sponsor and the next audit committee cadence reads the escalation.
- A material drift finding follows the same escalation cadence.
Compensating control rules:
- Where the corrective action cannot land within the SLA window, the runbook owner names a compensating control that the validation programme acknowledges for the interim window.
- The compensating control is captured on the workspace with a named owner, an effective date, an expiry date, and a re-validation requirement.
- The compensating control is observable as a record rather than as an informal arrangement; the audit reading reconciles the deficiency to the compensating control rather than to silence.
10. Validation record and audit evidence anchor
Capture the validation record in a durable shape that the auditor and the engineer can read against. The record is the single artefact the audit committee, the external assessor, and the regulator reach for; the runbook execution lives inside the record and the corrective action chain branches off it. Treat the record as a first-class evidence artefact rather than a byproduct of the validation work.
Validation record (one record per validation execution; lives as a versioned document on the workspace engagement record):
- Record identifier (system-assigned at engagement creation): {{VALIDATION_RECORD_IDENTIFIER}}
- Runbook identifier and version: {{RUNBOOK_IDENTIFIER_AND_VERSION}}
- Control identifier and version: {{CONTROL_IDENTIFIER_AND_VERSION}}
- Validation cycle reference (per the cadence band in Section 11): {{VALIDATION_CYCLE_REFERENCE}}
- Validator (named at execution time): {{VALIDATOR_NAME_AND_ROLE}}
- Independent validator (where applicable): {{INDEPENDENT_VALIDATOR_NAME_AND_ROLE}}
- Co-validator (where applicable): {{CO_VALIDATOR_NAME_AND_ROLE}}
- Execution start timestamp: {{EXECUTION_START_TIMESTAMP}}
- Execution end timestamp: {{EXECUTION_END_TIMESTAMP}}
- Disposition: {{DISPOSITION}}
- Disposition rationale: {{DISPOSITION_RATIONALE}}
- Corrective action references (each finding identifier raised by this validation): {{CORRECTIVE_ACTION_REFERENCES}}
- Compensating control references (where invoked): {{COMPENSATING_CONTROL_REFERENCES}}
- Evidence pack attachments references (per Section 7): {{EVIDENCE_PACK_REFERENCES}}
- Next scheduled validation due date: {{NEXT_VALIDATION_DUE_DATE}}
- Compliance evidence cycle this record feeds: {{COMPLIANCE_EVIDENCE_CYCLE_REFERENCE}}
Audit evidence anchor:
- Framework controls evidenced by this record (per Section 1 framework expectations): {{FRAMEWORK_CONTROLS_EVIDENCED}}
- Evidence anchor link in compliance-tracking: {{COMPLIANCE_TRACKING_EVIDENCE_ANCHOR}}
- Audit cycle the record is read into: {{AUDIT_CYCLE_REFERENCE}}
- Retention classification per the audit evidence retention policy: {{RETENTION_CLASSIFICATION}}
Record signature chain:
- Validator signature: {{VALIDATOR_SIGNATURE}}
- Co-validator or independent validator signature: {{CO_VALIDATOR_SIGNATURE}}
- Runbook owner acknowledgement signature: {{RUNBOOK_OWNER_ACKNOWLEDGEMENT_SIGNATURE}}
- Compliance owner acknowledgement (read into the next compliance evidence cycle): {{COMPLIANCE_OWNER_ACKNOWLEDGEMENT_SIGNATURE}}
Discoverability:
- Record searchable via workspace global search by runbook identifier, control identifier, validation cycle reference, and validator name.
- Record visible on the compliance-tracking surface as the evidence anchor for the framework controls in Section 1.
- Record linked from the control catalogue entry as the most recent validation outcome.
- Record linked from any finding raised by the disposition as the source-of-validation.
Disposition mix metrics produced from the records (rolling per cadence band):
- Pass rate per band per cycle.
- Partial-pass rate per band per cycle.
- Fail rate per band per cycle.
- Inconclusive rate per band per cycle.
- Average time-to-finding for fails and partial-pass-with-finding dispositions.
- Average corrective action SLA compliance for findings raised by validation.
- Drift detection rate (material and breach drift caught at the pre-validation gate as a share of validations executed).
11. Validation cadence and event-driven triggers
Set the cadence per control with explicit event-driven triggers so the validation programme catches change between scheduled cycles. Calendar-only cadence is always at least one interval behind the change it should catch; calendar plus event-driven triggers turn the runbook into a live assurance instrument rather than a periodic spot check.
Calendar cadence (the validation runs at this cadence regardless of other inputs):
- Cadence band (one of: Band 1 monthly, Band 2 quarterly, Band 3 semi-annual, Band 4 annual, Band 5 event-driven only): {{CADENCE_BAND}}
- Next scheduled validation due date: {{NEXT_VALIDATION_DUE_DATE}}
- Cadence rationale (why this control sits in this band):
- {{CADENCE_RATIONALE}}
- Re-banding triggers (events that move this control to a different band):
- {{REBANDING_TRIGGERS}}
Event-driven triggers (the validation runs out-of-cadence on any of the named events):
- Configuration change request closed in scope of the control: {{CONFIG_CHANGE_TRIGGER}}
- Vendor release that affects the control: {{VENDOR_RELEASE_TRIGGER}}
- Platform migration in scope of the control: {{PLATFORM_MIGRATION_TRIGGER}}
- Credential rotation in scope of the control: {{CREDENTIAL_ROTATION_TRIGGER}}
- Scope change touching the control (new asset class, new business unit, new region, new product): {{SCOPE_CHANGE_TRIGGER}}
- Incident in scope of the control: {{INCIDENT_TRIGGER}}
- BAS platform technique flag indicating coverage regression: {{BAS_FLAG_TRIGGER}}
- Purple-team scenario surfacing a new control-side hypothesis: {{PURPLE_TEAM_TRIGGER}}
- Red-team after-action item naming the control: {{RED_TEAM_TRIGGER}}
- Audit observation naming the control: {{AUDIT_OBSERVATION_TRIGGER}}
- Regulator interaction naming the control: {{REGULATOR_INTERACTION_TRIGGER}}
- Threat-intel report indicating the control scenario is in active exploitation: {{THREAT_INTEL_TRIGGER}}
Event-driven trigger handling rules:
- The validator opens an out-of-cadence validation engagement record naming the trigger.
- The scenario in Section 3 may be substituted by a trigger-specific scenario (for example a vendor-release validation that confirms the new vendor configuration matches the as-designed baseline).
- The disposition lands per Section 8 and feeds the corrective action chain per Section 9.
- The out-of-cadence validation does not reset the calendar cadence unless the runbook owner explicitly re-bands the control in Section 11.
Skip rules (the validation may not be skipped except under the named conditions):
- Tier-1 controls: validation may not be skipped; the runbook owner reschedules within the same calendar window if execution cannot proceed.
- Tier-2 controls: skip permitted with runbook owner sign-off and recorded reason; the skip is captured on the engagement record and read into the next governance cycle.
- Tier-3 controls: skip permitted with runbook owner sign-off; the skip is recorded.
Cadence observability:
- The validation calendar is visible to the validator, the runbook owner, the control owner, the compliance owner, and the audit committee through the workspace surfaces (engagement-management and notifications-and-alerts).
- The cadence overrun rate is a programme metric the audit committee reads at the cadence in Section 12.
- The event-driven trigger volume (validations that ran out-of-cadence) is a programme metric the audit committee reads.
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 metrics the leadership reads against the validation programme. Governance is what keeps the runbook a living document and the validation programme a continuous assurance instrument rather than a frozen file the next validator reads and discovers is out of date.
Standing review cadence:
- At least annual structured review per runbook even when no events have triggered intermediate revisions.
- Quarterly review of the runbook portfolio across control classes by the security operations leader, the security engineering leader, and the GRC operations leader.
- 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 of the runbook):
- Material change in the underlying control design (the control owner updates the as-designed configuration baseline).
- New control class addition that affects how this runbook anchors to the wider control fabric.
- New regulatory requirement applicable to the control class (the framework expectations in Section 1 expand).
- New BAS platform technique that the validation programme adopts as the scenario for this runbook.
- New purple-team hypothesis the runbook is asked to convert into a recurring assurance check.
- Red-team after-action item naming the runbook scenario as insufficient.
- Audit observation naming the runbook as the source of a control assurance gap.
- Recurrent partial-pass or fail disposition pattern across more than {{RECURRENT_FAIL_THRESHOLD}} consecutive cycles indicating the runbook does not match the control behaviour reliably.
- Telemetry channel change that affects the signal pattern in Section 3.
Revision pass procedure:
- The runbook owner drafts the revision against the trigger.
- The control owner reviews Section 2 (design intent) and signs the attestation.
- The telemetry custodian reviews Section 3 (signal pattern) and Section 7 (evidence capture).
- The compliance owner reviews Section 1 (framework expectations) and Section 10 (audit evidence anchor).
- The runbook owner signs the revision and publishes the new version with the effective date.
- The activity log captures the revision event with the named actor, the timestamp, and the revision trigger.
- The prior version is retained on document-management per the audit evidence retention classification.
- The next scheduled validation runs against the new version per the cadence band in Section 11.
Audit-readable artefacts per cycle:
- Runbook version with effective date and revision trigger record.
- Sign-off record (runbook owner, control owner, co-signers).
- Activity log entries for the revision event.
- Validation records produced under the version (per Section 10).
- Corrective action chain references for validations that produced findings (per Section 9).
Programme metrics the audit committee receives quarterly:
- Number of runbooks in the portfolio: {{RUNBOOKS_IN_PORTFOLIO}}
- Coverage of the in-scope control catalogue by runbook: {{CATALOGUE_COVERAGE_PERCENT}}
- 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}}
- Validation execution volume per band per quarter: {{VALIDATION_VOLUME_PER_BAND_QUARTER}}
- Cadence overrun rate per band: {{CADENCE_OVERRUN_RATE_PER_BAND}}
- Disposition mix per band per quarter: {{DISPOSITION_MIX_PER_BAND_QUARTER}}
- Number of findings raised by validation in the quarter: {{FINDINGS_RAISED_BY_VALIDATION_QUARTER}}
- Finding closure rate against SLA: {{FINDING_CLOSURE_RATE_QUARTER}}
- Drift detection rate at the pre-validation gate: {{DRIFT_DETECTION_RATE_QUARTER}}
- Event-driven trigger volume: {{EVENT_DRIVEN_TRIGGER_VOLUME_QUARTER}}
Annual programme metrics:
- Control catalogue coverage trend over the year.
- Average disposition mix shift over the year (improving, stable, regressing).
- Recurring failure pattern analysis at the runbook and control class level.
- Cross-framework evidence coverage produced by the validation programme.
- Notable lessons learned that landed in runbook revisions, control design changes, or wider programme adjustments.
Programme acknowledgement:
- The runbook portfolio is the live procedural backbone of the control assurance programme.
- The catalogue defines what controls exist, the design intent codifies what each control is supposed to do, the runbook codifies how the validation runs, the validation record codifies what happened, and the corrective action chain codifies what changes when validation does not pass.
- The five artefacts are kept in sync on one workspace so the audit read of control assurance and the operational read are the same record rather than two independently edited summaries that diverge between reporting cycles.
Seven failure modes the runbook has to design against
The validation programme fails the audit read and the operational 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 validation record defensible.
No per-control runbook at all
The firm relies on vendor console screenshots and the existence of the control as evidence the control works. There is no recurring procedure that proves each control still behaves as designed against the named scenario. The audit reading asks how the firm knows the production EDR ransomware rollback is enabled right now, and the answer collapses to a screenshot that may be six months stale. The fix is the twelve-section template above, instantiated per control with the Section 11 cadence assignment per tier band.
One generic validation procedure for every control
A single validation checklist tries to cover identity controls, endpoint controls, network controls, data controls, logging controls, and governance controls with the same steps. Under execution the procedure does not match the control under test and the validator improvises the scenario, which yields inconsistent dispositions and weakens the audit defensibility of the validation record. The fix is one runbook per control with the scenario in Section 3 derived from the design intent in Section 2 and the pass criteria in Section 6 set per control.
Validation owned by the control owner with no independent validator
Tier-1 production-critical controls are validated by the same role that owns and operates the control. The audit reads the validator as the same role and the independence evidence is missing. The fix is the independent validator role named in Section 1 for tier-1 controls, with the co-validator role named for tier-2 controls so the validation record carries the right level of independence for the control criticality.
Validation outcome not paired to corrective action
The validation produces a fail or partial-pass and the finding does not land on the finding ledger. The next cycle reads the same deficiency and the corrective action chain never operates. The fix is Section 9 as a first-class procedural section with explicit finding creation rules, severity assignment, owner assignment, SLA-driven target close dates, and a verification validation that closes the finding on a pass disposition.
Validation cadence anchored only on the calendar with no event-driven track
The runbook runs on a quarterly calendar and the configuration change that broke the control landed three weeks after the last validation. The next scheduled validation reads the failure thirteen weeks later, after the audit interval has already closed. The fix is the dual cadence in Section 11 with calendar bands plus the named event-driven triggers that force re-validation regardless of the calendar.
Validation record stored in a folder the auditor cannot read
The evidence lives in a personal drive, a wiki page, or a vendor tool the firm does not surface for the audit reading. The auditor asks for the validation evidence and the validator searches under pressure for the right artefact. The fix is workspace-resident document-management with role-gated access through team-management, multi-factor authentication, the activity log capturing every read, and the evidence anchor in Section 10 cross-linked to the compliance-tracking surface.
Runbook frozen at first publication
The runbook is published at programme launch and never revised. The control catalogue, the platform, the threat environment, and the framework expectation move underneath, and the validator reads steps that no longer apply. The fix is event-driven revision in Section 12: every material design change, vendor release, BAS adoption, purple-team adoption, red-team finding, audit observation, recurrent failure pattern, and telemetry channel change triggers a revision pass with a versioned re-publication and a captured activity log event.
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 per-control assurance 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 declared in-scope control catalogue.
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 review, and what is the structural reason for the overrun.
4.What is the disposition mix per cadence band per quarter (pass, partial-pass, fail, inconclusive), and how does it compare to the previous quarter.
5.How many findings did the validation programme raise in the quarter, and what is the closure rate against SLA at the runbook owner and security operations leader level.
6.What is the drift detection rate at the pre-validation gate as a share of validations executed.
7.What is the event-driven trigger volume in the quarter, and which classes of trigger contributed the largest share.
8.How many tier-1 controls executed below the named cadence in the quarter, and what is the structural cause.
9.Which controls have recurring partial-pass or fail dispositions across more than three consecutive cycles, and what is the runbook owner plan.
10.Which framework controls did the validation programme evidence in the quarter that the prior compliance evidence read did not anchor to durable validation records.
How the package pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs engagement records, document custody, and finding tracking on a workspace, the validation programme becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every validation execution to a versioned engagement record through engagement management, so the runbook identifier, the validator name, the scenario reference, the disposition, the evidence pack, and the framework anchor live alongside the rest of the engagement record rather than scattered across a chat channel, a wiki page, and a shared drive.
The document management feature holds the runbook itself, the evidence pack from Section 7, the validation record from Section 10, and every prior runbook version retained per the audit evidence retention policy. Access to each document is gated by role-based access control through team management and protected by multi-factor authentication. 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 pre-validation gate confirmation, the scenario execution, the signal observation, the disposition assignment, and the runbook revision events are all observable rather than asserted. The notifications and alerts feature dispatches the validation calendar reminders and the event-driven trigger pages to the validator, the runbook owner, and the control owner with the same audit trail.
Findings raised by partial-pass or fail dispositions live alongside vulnerability findings on the same workspace through findings management, each carrying a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement. The retesting workflows feature pairs the verification validation that closes the finding to the original validation record so the assurance chain reads as one continuous record rather than two disconnected artefacts. The finding overrides feature carries the compensating control record where the corrective action cannot land within the SLA window, with the eight-field decision chain that names the override author, the reviewer, the rationale, the expiry date, and the re-validation requirement. The compliance tracking feature maps the validation records to ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, NIS2, DORA, and the sector-specific overlays with CSV export, so when an auditor asks how the firm knows the EDR ransomware rollback, the identity provider conditional access, the WAF blocking ruleset, or the backup immutability is still active, the runbook version, the validation record, the disposition, the evidence pack, and the corrective action chain are one query against the same data. The AI report generation workflow produces a draft validation cycle summary and a leadership briefing from the same engagement data so the audit committee read of control assurance performance and the operational read are the same record rather than two independently edited documents that diverge between reporting cycles.
For the upstream programme charter the validation programme operates under, see the security program charter template. For the indicator layer that reads the validation portfolio into leadership reporting, see the security KPI dashboard template and the security programme KPIs and metrics framework. For the cadence vehicle that reads the validation portfolio into management review, see the quarterly review template. For the adjacent finding-side measurement of the vulnerability management programme, see the vulnerability management programme scorecard. For the upstream BAS programme that surfaces the coverage gaps the validation programme converts into named runbooks, see the breach and attack simulation explainer. For the parallel detection-engineering and SOC layer the validation programme reads against, see the managed detection and response explainer. For the compliance anchors the validation records feed, see the framework pages for ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, and NIST CSF 2.0. SecPortal does not execute the underlying controls, does not run the live SOC, does not ingest production telemetry into a SIEM, does not host a BAS attack library, does not replace the change-management process or the engineering teams that own the controls. The validators run the validation; the runbook codifies the procedure; SecPortal carries the durable workspace record the validation runs against and the audit reads after.