Building an Incident Response Playbook from Zero

The IR plan is the document the auditor wants to see. The IR playbook is the document the on-call analyst actually opens at 02:43 AM when the EDR is screaming and they have to make decisions while half-asleep.

Most organizations have the plan and not the playbooks. Or they have a playbook that is 47 pages of policy language with no actionable steps. Or they have great playbooks for the wrong incident types — a beautiful APT-attribution playbook and nothing for the ransomware they actually got hit with.

This is the build-from-zero version: how to write a playbook that someone exhausted at 3 AM can execute correctly, what to put in it, what to leave out, and the structure that lets you produce 10 of them without duplicating work.

What a playbook actually is

A playbook is a procedure for one specific incident type — not a general guide to incident response. Each playbook covers one category: ransomware, BEC, credential compromise, insider misuse, DDoS, lost device, third-party breach, cloud misconfiguration, data exfiltration, malware-on-server. One playbook, one scenario, one decision tree.

Inside each playbook you have a structured sequence of steps mapped to the NIST 800-61 phases — Preparation, Detection & Analysis, Containment & Eradication & Recovery, Post-Incident. Each step names the role that owns it (RACI), the input it needs, the output it produces, and the decision point that determines the next step.

The output of a good playbook is a 1-page quick-reference for the on-call analyst plus a 5–10 page detailed procedure for the response team. The 1-page is for “I just got paged, what do I do.” The detailed version is for “we are 4 hours in, what is the comms cadence.”

The template — one playbook, eight sections

A playbook does not need 47 pages. It needs eight clearly-labeled sections that always appear in the same order so anyone on the team can find any piece in 10 seconds.

Section 1 — Scope and trigger

What this playbook is for. Two paragraphs maximum. Plain language.

Trigger: Any of the following indicators detected on an in-scope system:
  - File encryption activity (>50 files renamed with non-standard extension within 5 min)
  - Ransom note dropped (filename matches *README*, *DECRYPT*, *RESTORE*)
  - EDR alert with severity HIGH and category "ransomware"
  - Manual report from user (call to IT helpdesk, click on "report" button)

Scope: All Windows / macOS / Linux servers and workstations on the corporate domain
Out of scope: Customer-facing production systems (use ProdRansomware-Playbook)

The wrong way is “this playbook covers ransomware-like activity.” The right way is the explicit list of triggers and the explicit out-of-scope statement so the responder knows immediately whether they are in the right playbook.

Section 2 — Severity matrix

A 3×3 table. Severity drives every other decision (who gets paged, what comms cadence applies, what authority is needed).

The matrix is what stops “everything is a SEV-1” or “everything is a SEV-3” — both common failure modes that destroy the program’s credibility.

Section 3 — Roles (RACI for this incident)

A named role table specifically for this playbook. Not generic — for ransomware specifically, who does what.

Use named people in real playbooks (with phone numbers), not roles, because at 3 AM “the on-call SOC lead” requires a lookup. Update quarterly when people change.

Section 4 — Detection & Analysis steps

Numbered, executable steps. Each step has a Who, a What, and a Decision.

Step 1 — Validate the alert (5 min)
   Who: SOC analyst (first responder)
   What: Confirm the trigger is real, not a test or false positive
   Decision:
     - If false positive → close ticket, document, end
     - If confirmed → proceed to Step 2 and page IC

Step 2 — Initial scoping (10 min)
   Who: SOC analyst + IC
   What:
     - Identify affected hostname(s)
     - Identify affected user(s)
     - Pull EDR process tree for the encryption process
     - Check SIEM for same hash / IOCs on other hosts
     - Determine entry vector (email, RDP, supply-chain)
   Output: Initial scope statement (1–2 sentences)
   Decision: Severity assignment (use Section 2 matrix)

The pattern repeats. Every step has a time budget. Every step has a deliverable. Every step ends with a yes/no/escalate decision.

Section 5 — Containment, Eradication, Recovery

The operational core. Same numbered step structure as Section 4. This is where the playbook either holds together or falls apart.

A good containment step for ransomware:

Step 6 — Network isolation (within 15 min of confirmation)
   Who: IC authorizes, SOC executes via EDR console
   What: EDR-based network containment of affected host(s) — preserves the host alive (don't power off — kills memory evidence)
   Required before action:
     - Memory dump captured (use EDR live-response or LiME)
     - User communication sent ("your machine has been temporarily isolated, please leave it powered on")
   Anti-pattern: Pulling the power cable. This destroys volatile evidence and you cannot get it back.
   Reference: See "Containment Decisions Under Pressure" for the full trade-off discussion.

The “Anti-pattern” line is what saves you from a junior analyst doing the obviously-wrong thing because it feels right under stress.

Section 6 — Communications plan

Templates, not policy. Pre-written messages for each audience that the comms lead fills in and sends.

Template 1 — Initial executive notification (within 30 min of SEV-1 confirmation)
   To: CEO, CFO, CISO, CRO, GC, Head of Comms
   Subject: SEV-1 INCIDENT — Ransomware activity detected — [DATE TIME]
   Body:
     - What we know: [1–2 sentences]
     - What we don't know: [1–2 sentences]
     - What we are doing: [3–5 bullets]
     - Next update: [time, no more than 60 min out]
     - Bridge / Slack channel: [details]

Template 2 — Customer-facing notification (only after Legal + Comms approval)
   Subject: Important update regarding our systems
   Body: [PLACEHOLDER — must be customized; see Legal-approved template library]

Pre-written templates eliminate the 90-minute “what do we say?” debate that delays every uncoordinated response.

Section 7 — Decision trees

The 1–3 hard decisions that this incident type forces. Each rendered as a flowchart in text.

DECISION: Pay the ransom?
  → Default answer: No
  → Authority: CEO + Board (only)
  → Required inputs:
    - Confirmed backup recovery is impossible
    - Legal has reviewed sanctions list for threat actor (OFAC compliance)
    - Insurance carrier has been engaged
    - Law enforcement (FBI / NCA / equivalent) has been engaged
  → Constraints: Cannot pay if threat actor is OFAC-sanctioned
  → Time pressure: Threat actor deadlines are often negotiable; do not let them drive the decision

This is the section that prevents panicked Tuesday-night decisions from becoming Wednesday-morning regulatory disasters.

Section 8 — Post-incident requirements

The deliverables required to close the ticket. Without this, post-incident activity gets skipped.

Required for ticket closure:
  ☐ Lessons-learned meeting completed (within 14 days of recovery)
  ☐ Written incident report (template: IR-REPORT-TEMPLATE.docx)
  ☐ Evidence preserved per retention schedule (12 months minimum, 7 years for ransomware)
  ☐ MTTD, MTTC, MTTR captured and posted to metrics dashboard
  ☐ Detection rule updates pushed to SIEM (Sigma rules in detection-as-code repo)
  ☐ Playbook updated with anything new learned
  ☐ Regulatory notifications confirmed (if required)

The four playbooks every program needs first

Build these before anything else, in this order:

1. Phishing / BEC — by volume, this is what your team handles most. Get it right or burn out the SOC on the wrong work.
2. Ransomware — by severity, this is what kills companies. Get it right or be in the news.
3. Credential compromise / account takeover — the precursor to both of the above. Often the only incident where you can act before damage is done.
4. Lost or stolen device — the most procedural one, easy win to build confidence in the playbook format.

Once those four exist and have been tabletop-tested, add: insider misuse, DDoS, third-party breach, cloud misconfiguration, data exfiltration, malware on a server. Stop around 12–15 playbooks; beyond that you are creating maintenance burden without proportional value.

The anti-patterns that kill playbooks

The single biggest reason playbooks fail is they read like policy documents instead of operating procedures. Five specific anti-patterns to avoid:

1. Passive voice. “The affected system should be isolated” — by whom, how, when? Use active voice: “The IC instructs the SOC analyst to isolate the host via the EDR console within 15 minutes.”

2. Unbounded steps. “Investigate the alert” — that is not a step, it is a project. Every step needs a time budget and a deliverable.

3. No decision points. A playbook is decisions, not a checklist. If a step does not end with a yes/no/escalate decision, it is a description, not a procedure.

4. Role-not-person. “Notify the executive” — which executive? Phone or email? What number? Use named people with current contact details.

5. No tabletop. A playbook that has not been exercised in 90 days has decayed. The tooling has changed, the people have changed, the network has changed, the vendor contracts have changed. Tabletop quarterly minimum.

How to test a playbook

A tabletop is not a presentation. It is a structured exercise where the team executes the playbook against a synthetic scenario as if it were real.

Format:

• 2 hours, on the calendar quarterly
• Facilitator (not on the response team) reads a scenario in segments and injects new information every 15 minutes
• Team members open the playbook, execute the steps, and announce their decisions
• Scribe records: time-to-each-decision, every place the playbook was ambiguous or wrong, every place the team did not know what to do, every gap between playbook and reality
• 30 min debrief at the end: what is changing in the playbook based on this exercise

The output of every tabletop is a list of playbook changes due within 2 weeks. If a tabletop produces no playbook changes, either the playbook is perfect (rare) or the tabletop was too easy.

How this fits the rest of the program

Playbooks are one of three artifacts your IR program produces:

1. IR Plan — strategic, signed by executive, references the playbooks
2. Playbooks — tactical, owned by SOC, the actual operating procedures
3. Runbooks — technical, step-by-step tool usage (how to pull a memory dump, how to query the SIEM for hash X, how to isolate via EDR)

Playbooks reference runbooks for tooling specifics. The playbook says “isolate via EDR within 15 min.” The runbook says “in the EDR console, navigate to Hosts → search → click the host → Actions → Network Containment → confirm.”

Separating playbooks from runbooks keeps both maintainable. When the EDR vendor changes, you update one runbook and 12 playbooks still work. When the comms policy changes, you update the playbooks and the runbooks are unaffected.

What ECIH actually tests

The ECIH v3 exam expects you to know playbook structure as part of the Preparation phase. Expect:

• Order-of-content questions (“which section appears first in a well-structured playbook?”)
• Anti-pattern recognition (“which of the following is a bad playbook practice?”)
• Role definition questions (RACI specifics for IR)
• Decision-authority questions (who can authorize a ransom payment, who can take systems offline)
• Tabletop frequency and structure questions

The exam expects 1-year minimum evidence retention and quarterly tabletops as baseline. Memorize those numbers.

Next steps

If you want to drill the containment decisions your playbook will reference, Containment Decisions Under Pressure — Why Network Isolation Isn’t Always Right is the trade-off framework.

If your playbook ever calls for forensics (it should), Post-Incident Forensics vs Live Response is the decision matrix between live-response and dead-disk approaches.

If you need the malware triage step in your Detection & Analysis section, Malware Triage in 5 Minutes is the first-responder checklist.

And for the lifecycle that the whole playbook structure maps to, The NIST 800-61 Incident Response Lifecycle — Plain English is the foundation.