4.3.1. IR Planning, Playbooks, and Tabletop Exercises
💡 First Principle: A playbook converts analyst judgment into documented procedure for known threat scenarios — freeing cognitive resources during an incident for the genuinely novel decisions that can't be pre-scripted.
Incident Response Plan
The IR plan defines the overall framework: who is responsible for what, how incidents are classified and escalated, what external parties are notified and when, and how the organization communicates during an incident. It's the governance document that makes ad-hoc IR systematic.
Key IR plan components:
- Roles and responsibilities — IR Team Lead, analysts, legal, PR, executive sponsor, external IR retainer contact
- Incident classification — Severity levels (P1–P4) with criteria and response time expectations
- Communication protocols — Internal (encrypted channel separate from potentially compromised corporate email), external (customers, regulators, law enforcement, media)
- Legal and regulatory triggers — When must you notify regulators (GDPR 72-hour notification; SEC 4-day material incident disclosure)? When do you call law enforcement?
- Escalation paths — Clear criteria for escalating from Tier 1 to Tier 2 to Tier 3 to external IR firm
Policy, Plan, and Playbook. NIST SP 800-61 separates three layers. The IR policy is the executive mandate: it states what must be done, authorizes the team and defines what counts as an incident. The IR plan is the operational framework: how the response is organized, who plays which role and how the plan is maintained. A playbook (procedure) is the step-by-step runbook for one incident type. Review all three on a schedule and after major environment changes: a playbook written before cloud workloads, EDR and SOAR existed will miss cloud-specific investigation steps and leave available automation unused.
Preparation. The Preparation phase is everything done before an incident: writing and training on these documents, and equipping responders with a jump kit (forensic laptops, write blockers, evidence bags, spare media), out-of-band contact lists, and access to the logs and tools they will need.
Playbooks are step-by-step procedures for specific incident types:
| Playbook Type | Key Steps Defined |
|---|---|
| Phishing playbook | Isolate affected user; collect email headers; check other recipients; block sender/domain; reset credentials if clicked |
| Malware/ransomware playbook | Isolate infected system; identify patient zero; check for lateral spread; preserve evidence; begin eradication |
| Data breach playbook | Confirm data access; identify data type and volume; initiate legal hold; begin regulatory notification clock |
| Insider threat playbook | Preserve evidence (covertly if possible); coordinate with HR/legal; restrict access; document chain of custody |
| DDoS playbook | Identify attack type; activate upstream scrubbing; adjust rate limits; notify ISP; communicate status to stakeholders |
Tabletop Exercises walk the IR team through a simulated scenario in a discussion format — no systems are actually affected, but participants must articulate what they would do at each decision point. Benefits:
- Identifies gaps in playbooks (steps that don't work in practice)
- Reveals communication breakdowns (who calls who? when? using what?)
- Tests decision-making authority (who can authorize taking a production system offline?)
- Surfaces resource gaps (do we have enough forensic licenses? IR retainer engaged?)
- No operational risk — run complex scenarios impossible to simulate in live systems
Training — Analysts need both technical training (malware analysis, forensics, tool proficiency) and process training (playbook walkthrough, escalation procedures). Cross-training ensures coverage during vacations or simultaneous incidents.
Business Continuity (BC) and Disaster Recovery (DR) planning intersects with IR: when an incident disables critical systems, BC/DR procedures define how the organization continues operating (manual processes, backup sites, vendor failover) and recovers full functionality. IR focuses on security; BC/DR focuses on operational continuity. Both are needed.
⚠️ Exam Trap: Tabletop exercises and penetration tests serve different purposes. Tabletops test process and communication. Pen tests test technical defenses. Neither substitutes for the other. A common exam trap is presenting a scenario where an organization wants to "test their IR process" — tabletop is the correct answer; pen test tests defenses, not process.
Developing the Communication Plan
The IR plan says who does what. The communication plan says who says what, to whom, when, and how:
| Element | Purpose |
|---|---|
| Audiences | Executives, staff, customers, regulators, law enforcement, media |
| Designated spokesperson | A single media point of contact plus a backup; all outside inquiries route to them |
| Status statement | One approved, current statement that every spokesperson draws from, refreshed on a set schedule |
| Channels | Out-of-band options if corporate email or chat may be compromised |
| Approvals | Legal review before external statements or regulatory notices |
NIST recommends the single media contact, a maintained status statement, and reminding all staff how to handle media inquiries. Without them, a manager's social media post or a help desk answering a reporter becomes the organization's public statement.
Decisions Involving Outside Parties
- Legal counsel is engaged as soon as a breach of regulated data (such as customer PII) is suspected, not after the investigation ends: counsel directs privilege, evidence preservation and which notification clocks have started.
- Breach notification deadlines (GDPR gives 72 hours to the regulator; some state laws set comparable windows) run from awareness, not from the end of the investigation. Notify within the window with what is known, state that the investigation is ongoing, and update as facts develop; GDPR Article 33(4) expressly allows information to be provided in phases. Waiting for full certainty misses the deadline.
- Third-party compromise. If a vendor's credentials or connection are the suspected entry point and the vendor is still connected, cut that access first (containment), then notify the vendor and examine your own logs and their side of the compromise.
- Cyber insurance. Policies commonly require prompt notice (often within hours or days of discovery) and may require using the insurer's approved IR firms or its consent before certain costs, so notify the insurer early rather than after the incident is over.
- Paying a ransom is an executive decision made with legal counsel and, where appropriate, law enforcement. US Treasury OFAC advisories warn that paying a sanctioned party can create liability. A ransomware playbook therefore adds decision points a generic malware playbook lacks: whether to pay, backup viability and verification, and the reliability of any decryptor.
Defining Roles
Name one incident commander with authority to direct the response and settle disagreements. Supporting roles, such as technical leads for each system, a scribe keeping the incident log, and a liaison to executives, advise and inform, but they do not share command. Several senior people with equal authority is how responses stall.
Record who does what in a RACI matrix inside the IR plan: for each activity, who is Responsible, Accountable, Consulted and Informed across SOC, IR engineering, legal, HR and communications (RACI is a common governance convention rather than a NIST requirement). A decision authority matrix goes further and names who may approve high-impact actions, such as taking a production system offline or paying a ransom. A tabletop that shows nobody knows who can approve an outage has found this missing element.
Escalation
Escalation criteria say which events go straight to the IR lead, for example any unexplained privileged-account use, so a Tier 1 analyst can act at 2 a.m. without judging the incident alone. For unanswered pages, NIST describes repeating the contact, waiting a short time (perhaps 15 minutes), then escalating to a higher level and repeating until someone responds.
When the playbook pre-authorizes defined containment actions (isolating a host, disabling an account), the on-call analyst can act at 11 p.m. on a Friday without waiting for case-by-case executive approval; the on-call contact list and escalation path cover everything beyond that.
Performing Training: Tabletop vs. Simulation
NIST SP 800-84 describes tabletop exercises as discussion-based only: a facilitator presents a scenario and participants talk through roles and decisions, with no equipment or resources deployed. Functional (simulation) exercises have staff perform their duties in a simulated operational environment, such as isolating a host through EDR in a lab, restoring a server from backup, or activating a call tree. Tabletops find gaps in the plan cheaply; simulations prove people can carry it out.
A tabletop runs in a set order: (1) define the scenario and objectives, (2) walk participants through their response, (3) identify gaps and unclear decision points, (4) document findings and assign owned action items. NIST SP 800-84 frames the same flow as design, conduct and evaluate, ending in an after-action report with corrective actions.
Reflection Question: During a tabletop exercise simulating a ransomware attack, the IR team discovers that the step "notify legal counsel" in the playbook lists a phone number for an attorney who left the firm 18 months ago. What category of preparedness gap does this represent, and what process would prevent it from recurring?