Preparation: IR Plans, Playbooks & Tabletop Exercises
Preparation is the first phase of PICERL, and it determines how every later phase performs under pressure. A plan written calmly, months before an incident, is what keeps a team from improvising during one.
Why Preparation Determines Everything Downstream
Every other PICERL phase assumes something got built before the incident started: authority, tooling, and a way to talk to each other. Skip preparation and each of those has to be improvised live.
- No clear authority: nobody knows who can approve isolating a production server, so containment stalls waiting for a decision.
- No comms plan: responders default to the same compromised email or chat system the attacker may already be reading.
- No evidence tooling ready: forensic images get taken late or incorrectly, and chain of custody breaks before it starts.
- No shared playbook: two responders take contradictory actions on the same host because neither knew what the other was doing.
None of these failures happen because a team lacks skill. They happen because nobody prepared the conditions for that skill to work.
Building an Incident Response Plan
An Incident Response Plan (IRP) is the governing document for how an organization handles incidents. It defines structure, not step-by-step technical actions.
| IRP Component | What It Defines |
|---|---|
| Scope and Authority | Which systems and business units the plan covers, and who has the authority to declare an incident and direct response actions. |
| Classification Criteria | How incidents get categorized by severity or type, so responders and leadership agree on what "critical" actually means. |
| Communication Plan | Who gets notified, in what order, through which channel, including out-of-band options if primary systems are compromised. |
| Roles / RACI | Who is Responsible, Accountable, Consulted, and Informed at each stage, across IR, legal, PR, and executive leadership. |
| Tool and Access Inventory | Which tools responders use for detection, forensics, and containment, and what access each role has pre-approved. |
| Review Cadence | How often the plan gets tested and updated, and what triggers an off-cycle review (a major incident, a new business unit, a tooling change). |
Playbooks vs the IR Plan
The IRP and a playbook answer different questions. The IRP answers "how does this organization run incident response." A playbook answers "what do we do for this specific kind of incident."
| Dimension | IR Plan (IRP) | Playbook |
|---|---|---|
| Scope | Org-wide, applies to every incident | Specific to one incident type |
| Content | Roles, authority, escalation, communication | Step-by-step technical and procedural actions |
| Change frequency | Rarely changes | Changes often as TTPs and tooling evolve |
| Owner | IR leadership / CISO function | IR analysts and detection engineers closest to the threat |
Common playbook types:
- Ransomware playbook: isolation steps, backup verification, decision points on paying or not paying.
- Phishing playbook: mailbox search and purge, credential reset, sender blocking, user notification.
- DDoS playbook: traffic scrubbing activation, upstream provider contact, service failover.
- Insider threat playbook: HR and legal involvement thresholds, access revocation sequencing, evidence preservation.
Tooling and the Jump Bag
The jump bag is the physical or virtual kit a responder grabs the moment an incident is declared. If it isn't ready before the call comes in, it isn't ready.
- Forensic imaging tools / write blockers: hardware or software to capture disk and memory images without altering the original evidence.
- Out-of-band communication device: a phone, satellite device, or separate messaging channel that doesn't depend on potentially compromised infrastructure.
- Pre-authorized EDR / SIEM access: credentials and permissions already provisioned, not requested mid-incident.
- External IR retainer contact info: phone numbers and activation procedure for a third-party IR firm, if one is on retainer.
- Evidence chain-of-custody forms: templates ready to fill in on the spot, not drafted from memory during a live incident.
- Portable storage: wiped, encrypted drives for evidence collection, kept separate from production storage.
Every item on this list exists to remove a delay. A responder digging for credentials or a blank custody form is a responder not yet responding.
Tabletop Exercises and Readiness Testing
A plan that has never been tested is a theory. Tabletop exercises and live-fire exercises test it in different ways.
| Exercise Type | Format | Best For |
|---|---|---|
| Tabletop Exercise | Discussion-based. Team talks through a scenario step by step, no live systems touched. | Testing plan logic, roles, and decision points cheaply and often. |
| Live-Fire / Purple Team Exercise | Simulated attack executed against real or lab systems, with defenders responding in real time. | Validating detection coverage and actual technical response, not just the plan on paper. |
Running a tabletop follows a consistent flow:
Key Takeaways
- Preparation determines how every later PICERL phase performs, since it builds the authority, tooling, and comms a live incident depends on.
- An IRP defines org-wide scope, authority, classification, communication, roles, tooling, and review cadence.
- Playbooks are per-incident-type runbooks that sit underneath the IRP and change far more often as TTPs evolve.
- Common playbooks cover ransomware, phishing, DDoS, and insider threat scenarios, each with its own decision points.
- The jump bag exists to remove delay: imaging tools, out-of-band comms, pre-authorized access, and custody forms all need to be ready before the call comes in.
- Tabletop exercises test plan logic cheaply and often; live-fire exercises validate real technical response. Both feed gaps back into the plan.
Knowledge Check
Click an answer to reveal the explanation.
A new analyst asks why their organization has both an IR plan and a separate ransomware playbook. What's the best explanation?
An incident is declared at 2 a.m. The on-call responder needs to image a compromised laptop but has to wait 40 minutes for someone to locate a write blocker and grant SIEM access. What does this delay indicate?
A team runs a tabletop exercise and finds the scenario resolved smoothly with no confusion at any step. What should the team conclude?