Topics in this domain
- Event vs Incident vs Breach
- Developing the Incident Response Plan
- Incident Response Team Roles and Authority
- Incident Classification and Severity Levels
- Incident Response Playbooks and Decision Trees
- Escalation and Communication Plans
- Business Impact Analysis
- RTO, RPO, MTD and Recovery Prioritisation
- Business Continuity Planning and Strategies
- Crisis Management and Continuity Governance
- Disaster Recovery Planning
- Recovery Sites: Hot, Warm and Cold
- Backup Strategies and Cloud DR
- Incident Response Training
- Testing Plans: Tabletop, Functional and Full Interruption
- Evaluating Exercises and Improving Readiness
- Security Event Detection and Monitoring Methods
- SIEM, the SOC and Event Correlation
- Threat Intelligence and Indicators of Compromise
- Incident Triage and Initial Investigation
- Evidence Preservation, Forensics and Chain of Custody
- Containment Strategies: Short-Term and Long-Term
- Making Containment Decisions
- Breach Notification and Regulatory Reporting
- External Communications: Customers, Media and Law Enforcement
- Eradication, Recovery and Return to Normal Operations
- Post-Incident Review and Root Cause Analysis
- Lessons Learned and Incident Trend Analysis
Incident Response Playbooks and Decision Trees
From plan to first moves
The incident response plan describes the overall approach. Under pressure, responders need something more concrete: for this type of incident, what do we do first, what do we check, and who decides the hard questions? That’s a playbook. Decision trees inside playbooks make difficult choices quick and consistent.
A ransomware playbook
- Confirm and declare: encryption or a ransom note confirmed; declare the incident Critical.
- Contain: isolate hosts and network segments, disable compromised accounts, protect the backups.
- Mobilise: the IR team, legal, communications, the cyber insurer and the IR retainer.
- Decision point: shut down services? Was data stolen? Notify? The executive sponsor decides, with advice.
- Recover from clean, verified backups, and watch for the attacker returning.
What a playbook contains
- Trigger: which alerts or reports start it.
- First actions: the first 15–60 minutes, step by step.
- Decision points, each with an owner and criteria.
- Communications: who to inform, when, using which templates.
- Evidence: what to preserve, and how.
- Recovery and closure: criteria for returning to normal.
Which playbooks first?
Prioritise by risk:
| Incident type | Why prioritise |
|---|---|
| Ransomware | High impact and very likely |
| Business email compromise | Common, with direct financial loss |
| Compromised account or credentials | The most common initial access |
| Data loss or exfiltration | Legal notification duties |
| Cloud misconfiguration exposure | Common and fast-moving |
A playbook can’t cover every situation. Responders still need judgement and the authority to deviate when the facts call for it.
Automation with guardrails
SOAR (security orchestration, automation and response) tools can run routine playbook steps: enriching alerts, blocking known-bad indicators, opening tickets. Humans decide high-impact actions such as shutting down services or notifying regulators. Automated containment needs limits and an override, or it can cause outages.
Example. The phishing playbook is partly automated. When a user reports a phish, SOAR pulls matching emails from all mailboxes and blocks the sender within minutes. Resetting passwords for users who clicked still needs analyst approval.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Document with step-by-step actions for one incident type | A playbook |
| Which playbooks to write first | The most likely and most damaging incident types |
| Benefit of decision trees | Fast, consistent decisions with clear owners |
| Role of SOAR | Automate routine response steps |
| How to keep playbooks effective | Test them in exercises and update them after use |
In short
- The plan sets the framework; playbooks give step-by-step actions for specific incident types such as ransomware, phishing, data loss or account compromise.
- Playbooks include triggers, first actions, containment options, decision points with owners, communication steps and recovery criteria.
- Decision trees make hard choices (shut down? notify? involve law enforcement?) quick and consistent.
- Playbooks are prioritised by risk: write them first for the most likely and most damaging incidents.
- Automation (SOAR) can run routine playbook steps, with humans deciding the high-impact ones.
- Playbooks are tested in exercises and updated after every real use.
Exam traps
- A playbook can't cover every situation; responders still need judgement and the authority to deviate.
- Untested playbooks fail on details: wrong contacts, missing access, outdated systems.
- Automating containment without guardrails can cause outages.
- Playbooks that ignore legal and communication steps leave the organisation exposed.
Slides
Click the slide and use the arrow keys. F toggles full screen.
A ransomware playbook