About this program
A crisis is the moment your normal processes break. This 25-question check covers the decisions, comms and capabilities that determine whether you handle that moment well or badly. After each answer, expand the “Auditor’s view” for how to test the control, what evidence to collect, and the ideal response.
Controls (24)
-
When a major incident is declared, is there a single named decision-maker (often called Incident Commander) with authority to take the network offline, engage IR, and make ransom decisions?
MediumThis control requires designation of a single, named individual (Incident Commander or equivalent) who is empowered to make critical decisions during a declared major incident, including taking networks offline, authorizing incident response activities, and determining ransom payment positions. The Incident…
How to test + evidence
Risk: Without a single decision-maker, decisions are slow + contested under pressure. Tested = the IC has actually exercised the role.
Testing procedure: Inspect IR plan for named Incident Commander + deputy. Verify written authority levels (isolation, payment, comms approval). Confirm tabletop exercise within last 12 months exercised the role.
Evidence to collect: IR plan section naming IC + deputy Authority matrix document Tabletop after-action report Out-of-band contact details for IC + deputy
-
Are the criteria for declaring a major incident written down (so the call is consistent across responders and shifts)?
MediumThis control requires that the organization document explicit, measurable criteria for escalating an incident to 'major' status. Written thresholds—such as affected user count, data volume, system criticality, geographic scope, or potential regulatory impact—ensure that incident responders, regardless of shift or…
How to test + evidence
Risk: Inconsistent severity calls cause delayed response. Documented criteria let any responder make the call objectively.
Testing procedure: Inspect the severity matrix. Sample 5 historical incidents and verify severity classification was consistent with the matrix.
Evidence to collect: Severity matrix in IR plan Sample incident records with assigned severity Cross-shift consistency (handover docs)
-
Who has authority to authorise a ransom payment (or refuse one)? Has that decision been pre-discussed?
MediumThis control establishes a formal, documented decision authority for ransomware payment authorization, designating specific roles (e.g., CEO, CFO, General Counsel, Board Chair) empowered to approve or refuse payment demands. The authority matrix must be pre-defined and socialized before an incident…
How to test + evidence
Risk: Ransom decisions made under pressure are bad. Pre-discussed positions with counsel + insurer give the IC a clear framework.
Testing procedure: Inspect board minutes referencing ransom decision pre-authorisation. Verify counsel + insurer briefed on the position.
Evidence to collect: Board minutes documenting ransom position Letter from counsel on legal considerations Insurer engagement on coverage / requirements Tabletop transcript exercising the decision
-
Has the board / leadership team sat through a tabletop exercise involving a realistic crisis scenario in the last 12 months?
MediumThis control requires the organization's board of directors or executive leadership team to participate in a structured tabletop exercise simulating a realistic cybersecurity crisis, such as a ransomware attack, data breach, or critical system compromise, at least annually. The exercise…
How to test + evidence
Risk: Tabletops surface decision-making gaps no document review can. The exec team needs to make the hard calls before the live event.
Testing procedure: Inspect tabletop after-action report. Verify board/exec attendance + that decisions were actually exercised (not theoretical).
Evidence to collect: Tabletop attendance list Scenario brief used Post-exercise survey results Action tracker with closure status
-
Are out-of-band communications pre-arranged for use when email and chat are unavailable (Signal/WhatsApp groups, separate phones, alt mail)?
MediumOut-of-band (OOB) communication channels are pre-established alternate methods for critical personnel to communicate during incidents when primary systems (email, corporate chat, VoIP) are compromised, degraded, or unavailable. These channels typically include encrypted messaging apps (Signal, WhatsApp, Telegram), personal mobile devices…
How to test + evidence
Risk: Email is encrypted in many ransomware events. Pre-arranged OOB is the difference between coordinated response and chaos.
Testing procedure: Inspect OOB channel (Signal group, alt phone numbers). Verify membership current + tested in tabletop.
Evidence to collect: OOB channel screenshot or roster Alt-phone contact list Tabletop record showing OOB used
-
Is there a written internal communications plan (who tells employees what, when, via which channels)?
MediumA written internal communications plan specifies which messages are delivered to employees, by whom, through what channels, and under what timing conditions. This includes routine security updates, incident notifications, policy changes, training reminders, and executive communications. The plan assigns ownership…
How to test + evidence
Risk: Employees fill the silence with rumour. Pre-drafted internal comms in non-affected channels keep everyone aligned.
Testing procedure: Inspect internal comms templates. Verify they cover scenarios (suspended access, work-from-home, what to say to customers) + are stored OOB.
Evidence to collect: Internal comms templates Decision tree for what to communicate when Channel inventory (intranet, mail, alt-mail, SMS)
-
Is there a written external communications plan covering customers, partners, regulators and (if relevant) press?
MediumThis control requires a documented external communications plan that defines roles, responsibilities, messaging, approval workflows, and contact lists for communicating security incidents or significant events to external stakeholders including customers, business partners, regulatory bodies, and the media. The plan should…
How to test + evidence
Risk: External comms drive press perception + legal exposure. Drafting on the fly under press pressure produces the wrong words.
Testing procedure: Inspect external comms templates + approval workflow. Verify regulator notification windows are documented.
Evidence to collect: External comms templates per audience Approval workflow (legal + comms + exec) Regulator notification timeline (e.g. NIS2 24h, GDPR 72h) PR firm / counsel engagement
-
Do you have a status page or public communication channel that operates independently of your primary infrastructure?
MediumThis control requires organizations to maintain a status page or public communication channel (e.g., status.company.com, third-party status service, social media account) that is hosted separately from the primary production infrastructure and application stack. The communication channel must remain operational during…
How to test + evidence
Risk: Customers want answers; a status page is the cheapest, fastest channel. Co-located with affected systems = useless during an outage.
Testing procedure: Inspect status page hosting. Verify it can be updated when primary infrastructure is offline.
Evidence to collect: Status page URL + hosting account separation Authentication path independent of primary IDP Test update from OOB device
-
Is there a current responder roster (names, roles, phone numbers, after-hours contacts) maintained outside your primary IT systems?
MediumThis control requires the organization to maintain an up-to-date incident response contact roster that is stored and accessible independently of the primary IT infrastructure. The roster must include responder names, assigned roles, primary phone numbers, and after-hours emergency contact methods.…
How to test + evidence
Risk: Rosters in your primary wiki are inaccessible during the incident. Print + alt-cloud + tested = the only safe approach.
Testing procedure: Inspect the responder roster. Verify it is accessible OOB + reviewed within 90 days.
Evidence to collect: Printed roster + cloud copy on alt provider Last review date + reviewer After-hours contact details
-
For each critical role (Incident Commander, lead investigator, comms lead) is there a designated deputy if the primary is unavailable?
MediumThis control ensures that for every critical incident response role—such as Incident Commander, lead investigator, and communications lead—the organization has formally designated and documented a deputy who can assume responsibilities when the primary role-holder is unavailable due to leave, illness,…
How to test + evidence
Risk: Major incidents often happen when key people are on holiday. Deputies + cross-training make the plan resilient to absence.
Testing procedure: Inspect IR plan. Verify deputies are named for each critical role + have participated in tabletops.
Evidence to collect: IR plan with primary + deputy per role Cross-training records Tabletop with deputies playing the role
-
Do you have an external IR / forensics firm pre-engaged on retainer with a tested escalation path?
MediumThis control ensures the organization has a pre-established contractual relationship with an external incident response and digital forensics firm, including defined escalation procedures and communication channels that have been tested through tabletop exercises or simulations. The retainer agreement should specify…
How to test + evidence
Risk: IR firms saturate in major events. A retainer guarantees response; cold-calling at 2am does not.
Testing procedure: Inspect retainer contract. Verify 24/7 contact + last test call. Check insurance-mandated IR firm if applicable.
Evidence to collect: IR retainer contract Test call log Engagement runbook Insurance-linked IR confirmation if applicable
-
Have you pre-engaged legal counsel familiar with breach notification, regulatory engagement, and ransomware demand handling?
MediumThis control ensures the organization has identified, vetted, and formally retained legal counsel with demonstrated expertise in cybersecurity incident response, including breach notification requirements under applicable statutes (e.g., GDPR, state breach laws), regulatory coordination with agencies like CISA or sector…
How to test + evidence
Risk: Specialist breach counsel knows the privileged-comms playbook + regulatory pacing. General counsel learns on your incident.
Testing procedure: Inspect engagement letter with breach counsel. Verify scope covers breach notification, regulatory, ransom demand handling.
Evidence to collect: Breach counsel engagement letter Scope coverage matrix Tabletop with counsel engaged
-
Do you have written, scenario-specific playbooks (ransomware, data exfil, BEC, DDoS, supply-chain) — not just a generic IR plan?
MediumThis control requires the organization to maintain dedicated, scenario-specific incident response playbooks for high-impact threat patterns including ransomware, data exfiltration, business email compromise (BEC), distributed denial-of-service (DDoS), and supply-chain attacks. Unlike a generic IR plan that outlines broad phases and…
How to test + evidence
Risk: A generic plan rarely survives contact with a specific scenario. Scenario-specific playbooks make pre-decisions.
Testing procedure: Inspect playbook library. Verify coverage of top 5 scenarios + recent test of at least one.
Evidence to collect: Playbook library (ransomware, data exfil, BEC, DDoS, supply chain) Last review + reviewer per playbook Tabletop after-action report
-
If your IT systems are completely encrypted/inaccessible, can your responders still access the playbook (printed binder, separate cloud account, etc.)?
MediumThis control ensures that incident response playbooks and procedures remain accessible to responders even when primary IT systems are compromised, encrypted by ransomware, or otherwise unavailable. Organizations maintain offline or out-of-band copies of critical response documentation—such as printed binders, USB…
How to test + evidence
Risk: Wiki-only playbooks are inaccessible during the very event they're needed. Print + alt-cloud is the only safe pattern.
Testing procedure: Verify playbook accessibility OOB. Test by attempting to retrieve a playbook with primary IDP unavailable.
Evidence to collect: Printed playbook binder location Separate cloud account / personal Drive copy Test retrieval log
-
Is there a process for keeping a contemporaneous decision log during an incident (who decided what, when, why)?
MediumThis control requires the organization to maintain a timestamped, attributable log of all significant decisions made during security incident response, including who authorized each decision, the rationale, alternatives considered, and the context at the time. The log must be contemporaneous—recorded…
How to test + evidence
Risk: Decision logs are critical for legal defence + post-incident learning. Without them, what happened becomes contested narrative.
Testing procedure: Inspect decision log template. Sample real incident logs from the period — verify timestamps + decision rationales.
Evidence to collect: Decision log template Sample completed logs Scribe role assignment in IR plan
-
Are evidence preservation procedures documented (snapshots, log exports, custody chain) so forensics is possible afterwards?
MediumThis control ensures the organization has documented, repeatable procedures for preserving digital evidence during and after security incidents. It covers creating forensic images or snapshots of affected systems, exporting and securing relevant logs before rotation or deletion, and maintaining a…
How to test + evidence
Risk: Mishandled evidence loses court value + regulatory defensibility. Documented chain-of-custody is the bar.
Testing procedure: Inspect evidence preservation runbook. Verify chain-of-custody template + tested snapshot/export procedures.
Evidence to collect: Evidence preservation runbook Chain-of-custody template Sample preserved evidence with metadata
-
Do you know which regulators require notification, the timelines (e.g. 72 hours), and have a written escalation for that?
MediumThis control ensures the organization maintains a current, documented registry of all regulatory and contractual breach notification obligations, including specific timeframes (e.g., GDPR's 72-hour requirement, HIPAA's 60-day timeline, state breach laws' varying windows), and has established written escalation procedures to…
How to test + evidence
Risk: Regulatory clocks start at incident detection, not at convenience. Pre-briefed counsel + runbook hits the deadline reliably.
Testing procedure: Inspect regulator register + notification runbook. Verify timeline awareness (NIS2 24h, GDPR 72h, sector-specific).
Evidence to collect: Regulator register with applicable laws Notification runbook with timelines Pre-briefed counsel Tabletop exercising the notification path
-
Can you rapidly isolate a compromised network segment without taking down the entire business?
MediumThis control ensures the organization can perform rapid network segmentation to contain compromised systems or segments without causing business-wide outages. It relies on pre-defined network isolation procedures, software-defined networking (SDN) or VLAN controls, and segmentation architectures that separate critical business…
How to test + evidence
Risk: Whole-network shutdown causes business damage equal to the attack. Surgical isolation contains while business runs.
Testing procedure: Inspect network architecture + isolation runbook. Test isolation in a controlled exercise.
Evidence to collect: Network segmentation diagram Isolation runbook with timing Test record showing isolation worked + business continued elsewhere
-
During an active incident, do you have logging + EDR data centralised somewhere accessible (separate from the affected systems)?
MediumThis control ensures that security logs, endpoint detection and response (EDR) telemetry, and event data are replicated to a centralized logging infrastructure that remains operationally independent from production and endpoint systems. During an active incident, attackers frequently target logging systems…
How to test + evidence
Risk: On-prem SIEM is encrypted along with everything else in a ransomware event. Cloud-hosted is independent and accessible.
Testing procedure: Verify SIEM + EDR are on separate infrastructure from affected systems. Test access with primary IDP offline.
Evidence to collect: SIEM + EDR architecture diagram Authentication path independent of primary Retention period covering audit window
-
Do you have break-glass admin credentials accessible during an incident (sealed in a vault, separate from the affected identity provider)?
MediumBreak-glass (emergency) administrative credentials are pre-provisioned, highly privileged accounts stored offline and physically secured (e.g., in a tamper-evident envelope within a locked safe) to enable recovery when primary identity providers or authentication systems fail or are compromised. These credentials must…
How to test + evidence
Risk: When the IDP is compromised, you need authenticated access from outside. Break-glass + sealed creds is the only path.
Testing procedure: Inspect break-glass procedure. Verify credentials are sealed, separate from primary IDP, and access is alerted.
Evidence to collect: Break-glass procedure document Sealed credential storage location Alert log on break-glass usage Test record
-
Are your backups isolated from production credentials (separate cloud account, immutable, air-gapped)?
MediumBackup isolation ensures that backup data and the credentials required to access or delete backups are logically and physically separated from production systems. This separation is typically achieved through separate cloud accounts with distinct identity providers, immutable storage configurations (write-once-read-many),…
How to test + evidence
Risk: Compromised production credentials should not be able to destroy backups. Cross-account + immutability ensures this.
Testing procedure: Verify backups isolated from production credentials. Test deletion attempt from production-owned account.
Evidence to collect: Backup architecture Cross-account / immutability config Failed deletion test record
-
Do you have validated recovery time objectives (RTO) for your top critical systems?
MediumThis control validates that the organization has established, documented, and tested Recovery Time Objectives (RTO) for systems classified as mission-critical or business-essential. RTOs define the maximum acceptable downtime before unacceptable business impact occurs. Validated RTOs require formal approval from business…
How to test + evidence
Risk: Untested RTO is wishful thinking. Drill-validated RTO is what you can actually commit to.
Testing procedure: Inspect BIA + restore drill report. Verify actual time-to-restore vs documented RTO.
Evidence to collect: BIA with RTO per critical system Restore drill report Plans updated where RTO missed
-
Have you identified the top 5 systems that must come back first (and the dependencies between them)?
MediumThis control requires the organization to formally identify and document the top five critical systems that must be restored first following a disaster or major outage, along with their technical and operational dependencies. The prioritization is based on business impact…
How to test + evidence
Risk: Without priorities, recovery effort fragments. Documented sequence + dependencies turns chaos into orchestrated restoration.
Testing procedure: Inspect priority list + dependency map. Verify business owners signed off + dependencies mapped (not just "everything is critical").
Evidence to collect: Priority list with business owner sign-off Dependency map for top-10 systems Restoration sequence document
-
After previous incidents (or near-misses), are lessons documented and acted on?
MediumThis control ensures that organizations systematically capture lessons learned from security incidents and near-miss events, document them in a structured format, and implement corrective and preventive actions. The process typically involves post-incident review meetings, root cause analysis, documentation of findings…
How to test + evidence
Risk: Lessons closed and reflected in updated playbooks turn each incident into an improvement. Without action closure you fix the same issue six times.
Testing procedure: Inspect post-mortem template + completed examples. Verify actions are tracked to closure.
Evidence to collect: Post-mortem template Sample completed post-mortems Action tracker with closure status Plan updates reflecting learnings