An incident response playbook NCA ECC assessors will accept has to do two things at once: show that incident management is defined and governed, and be usable by a tired team at three in the morning. These goals are compatible, but many playbooks serve only the first. This article gives a section-by-section structure you can use to draft a new playbook or audit an existing one.
The National Cybersecurity Authority's Essential Cybersecurity Controls (NCA ECC) include a cybersecurity incident and threat management domain. In substance it expects defined incident response plans, detection and classification of incidents, escalation, notification of the relevant authorities, and learning from incidents. We describe these expectations without control numbers here; map the structure below to the exact clauses in your own compliance register.
Start with the plan, then write scenario playbooks
A common error is writing one long document. Separate two layers:
- Incident response plan: the generic framework covering classification, roles, escalation, communications and notification, which applies to every incident.
- Scenario playbooks: short, action-oriented procedures for specific incident types, such as ransomware and data leakage.
Scenario playbooks should refer to the plan rather than repeat it. That keeps them short enough to follow under pressure and easier to keep current.
The playbook structure, section by section
1. Purpose, scope and trigger criteria
State what the playbook covers and, more importantly, when it starts. Triggers should be observable, not interpretive. For ransomware: encrypted files or ransom notes on any system, alerts for mass file modification, or confirmed loss of access to a critical system. For data leakage: confirmed or credibly suspected exposure of sensitive or personal data, including through a third party, a misdirected transfer or an external report.
Add a severity classification with clear thresholds tied to business impact, such as critical services affected, data categories involved and number of systems. Say who may declare an incident and who may change its severity.
2. Roles and decision rights
List roles by function, not by individual name: incident commander, technical lead, communications lead, legal and compliance lead, business owner of the affected service, and an executive sponsor. For each role, record primary and backup holders.
Then write down decision rights, because this is where real incidents stall. Name who can:
- isolate a production system or take a service offline;
- approve contact with an attacker or third parties;
- authorize external statements;
- decide to notify a regulator;
- declare the incident closed.
If a decision has no owner or has two, the playbook is incomplete.
3. Initial triage and verification
Give the first-hour checklist: confirm the trigger, record time of detection, open an incident record, assign the commander, and start a decision log. Include the questions that set scope: which systems and accounts, which data, whether the activity is ongoing, and whether backups are reachable.
4. Containment steps by scenario
This is the core of each scenario playbook. Write steps as numbered actions with an owner.
For ransomware, a typical sequence is:
- Isolate affected hosts from the network without powering them off, where evidence matters.
- Disable compromised accounts and revoke active sessions and tokens.
- Block known malicious indicators at the perimeter and endpoint tools.
- Protect backups by disconnecting or locking backup infrastructure.
- Identify the likely entry point and check for persistence before restoring anything.
For data leakage:
- Stop the exposure: revoke access, remove public links, block the transfer path.
- Identify the data involved and its classification.
- Preserve logs showing who accessed what, and when.
- Determine whether the cause is malicious, accidental or third-party related.
Each step needs a stated precondition and a note on business impact, so the commander can decide quickly.
5. Evidence handling
Assessors and legal counsel will both ask how evidence was preserved. Specify what to capture before containment alters it: volatile memory where feasible, disk images, relevant logs, email headers and network records. Define who collects, how items are labelled, where they are stored, and how chain of custody is recorded. If your team lacks forensic capacity, name the escalation path to specialist investigators in advance, not during the incident.
6. Escalation and communications
Provide an escalation matrix that links severity to who is informed and how fast. Include out-of-hours contact methods and a channel that does not depend on the compromised environment. Record internal communication rules: who briefs executives, how often, and what staff are told.
7. Regulatory and stakeholder notification
List every party that may need to be informed: the NCA where its requirements apply, your sectoral regulator, the data protection authority where personal data is involved, law enforcement, insurers, partners and customers. For each, record the trigger, the owner, the expected timing under the applicable rule, and the template. Confirm timing against current regulations and your sector rules rather than copying figures from another organization's playbook.
8. Recovery and return to service
Define restoration order based on service criticality, criteria for declaring systems clean, validation steps before reconnecting, and heightened monitoring afterward. Connect this to your business continuity arrangements so recovery targets are consistent.
9. Closure and lessons learned
Require a post-incident review with owners and deadlines for each action, and a rule that the plan and playbooks are updated as a result. A review that produces no changes is a finding in itself.
What a tabletop reveals
A playbook can look complete and still fail in use. A tabletop exercise tests it with a realistic scenario and asks participants to follow the document as written. Typical weaknesses it exposes:
- triggers that nobody can evaluate with the data available;
- decision rights that are unclear, or held by someone unreachable;
- containment steps that assume tools or access the team does not have;
- notification sections that name a role but not a person or template;
- contact lists that are out of date.
Run separate sessions for technical teams and for executives. Technical teams find gaps in steps and evidence; executives find gaps in decisions, authority and communications. Record every point where participants improvised or asked "who decides this?", and treat each as a defect to fix.
A quick audit checklist
- Is there a plan and separate scenario playbooks?
- Can a stranger tell exactly when each playbook starts?
- Does every key decision have one named owner and a backup?
- Are containment steps numbered, owned and realistic?
- Is evidence handling defined before containment?
- Is every notification obligation listed with trigger, owner and template?
- Has the document been exercised, and were the findings acted on?
How we can help
Our Incident Response Readiness & Tabletop Exercises service prepares your organization to respond, covering the incident response plan and playbooks, roles and escalation, regulatory notification, and tabletop exercises for technical teams and executives. The work follows four stages: assess current capability and past incidents, plan the plan, roles and playbooks, exercise through a tabletop with technical teams and executives, and improve through lessons learned and plan updates. The deliverables are an IR plan and policy, a playbook set, a contact and escalation matrix, and an exercise report with improvements. It is delivered as a 4–8 week project, aligned to NCA ECC and SAMA CSF. If you want your playbooks tested against a structure like the one above, we would be glad to discuss it.
