How to Write an Incident Response Plan

An operational IR plan has seven components. Organizations that skip any of them discover the gap during an actual incident at the worst possible time.

First, the scope statement: what types of incidents does this plan cover? At minimum, document ransomware, data exfiltration, business email compromise, insider threat, and critical vulnerability exploitation. Each scenario type will require a separate playbook referenced from the main plan.

Second, severity classification. Define what constitutes a P1, P2, P3, and P4 incident — and make those definitions specific enough that two different analysts will reach the same classification for the same event. 'Critical system affected' is not a definition. 'Any incident affecting a system classified as Critical in the asset inventory, or any incident involving confirmed data exfiltration of regulated data' is.

Third, the IR team roster with backup contacts. Every role needs a primary and at least one backup. Include personal cell numbers — corporate email is often the first thing compromised in a serious incident.

Fourth, external contact list: cyber insurance carrier (with policy number and notification SLA), external IR retainer, outside legal counsel with privacy law expertise, and the FBI Cyber Division non-emergency line. These contacts must be in the plan because your communication systems may be unavailable when you need them.

Fifth, authority matrix: who can authorize network isolation? Who can authorize engaging external IR? Who can authorize ransom negotiation (answer: legal counsel and cyber insurance carrier, never security unilaterally)? Ambiguity about authority during an incident causes 30-minute delays that turn into hours.

Sixth, evidence handling procedures. What gets preserved, in what order, and how? Define log retention requirements, memory capture procedures, and chain-of-custody documentation before the incident — not during it.

Seventh, playbook index. The main IR plan should reference specific playbooks for each priority scenario. Playbooks are operational checklists; the main plan is the governance framework.

The most common failure mode in IR plans is unclear role definition. Every person in the IR process needs to know exactly what decisions they own, what they escalate, and who they report to.

The minimum viable IR command structure has four roles. The Incident Commander owns the incident from detection to closure. They make final decisions on containment strategy, external engagement, and communications. They do not perform technical analysis — their job is coordination and decision-making. In a small security team, this is typically the CISO or senior security manager.

The Technical Lead owns the investigation and containment execution. They direct the analyst team, interpret EDR and SIEM telemetry, and advise the Incident Commander on technical options and tradeoffs. In organizations with an active SOC, this is the SOC manager or lead analyst.

The Communications Lead owns all internal and external communications during the incident. They draft status updates to executive leadership, coordinate with legal and PR on any external statements, and manage stakeholder expectations. This role is frequently omitted from IR plans until the CEO starts calling analysts directly during an active incident.

The Scribe documents every action, decision, and timeline event in real time. This documentation becomes the foundation for the post-incident review and is often required by cyber insurance carriers and legal counsel. Assign this role explicitly — it will not happen organically.

For larger organizations, add a Legal/Compliance Liaison role to interpret regulatory notification obligations in real time and a Business Liaison to represent affected business units in containment decisions (particularly important when isolation would take down revenue-generating systems).

Playbooks are the operational layer of an IR plan. Each playbook covers one incident type and provides step-by-step procedural guidance specific to that scenario. The main IR plan defines the structure; playbooks define the actions.

Prioritize playbook development by threat likelihood for your industry and by potential impact severity. For most organizations, the first five playbooks to develop are: ransomware, business email compromise (BEC), credential compromise/account takeover, data exfiltration, and critical vulnerability exploitation.

Each playbook needs six sections. Detection: specific indicators that trigger this playbook and how to distinguish a true positive from a false positive. Triage: the first five actions an analyst takes within the first 15 minutes, in order. Containment: network isolation steps, account lockout procedures, and specific tools to use. Evidence Collection: what artifacts to preserve, in what format, before taking any remediation action. Eradication: how to confirm the threat actor is fully evicted before beginning recovery. Recovery: the sequence for bringing systems back online with enhanced monitoring.

Playbooks should be written at a level of specificity that a competent analyst who has never seen this incident type before can follow. If a playbook step says 'isolate the affected endpoint,' it is not a playbook — it is an outline. The step should say 'In the CrowdStrike Falcon console, navigate to Host Management, select the affected host, click Network Containment, select Full Containment, document the time and analyst name in the incident ticket.'

Review and update playbooks after every significant incident. The most valuable playbook updates come from steps that analysts skipped, misinterpreted, or found impossible to execute in the heat of an actual incident.

An IR plan that has never been tested has an unknown failure rate. The goal of testing is to discover those failures in a controlled environment rather than during an actual breach.

Tabletop exercises are the minimum testing cadence. Run a tabletop for each priority playbook scenario at least annually. A tabletop presents a simulated incident scenario to IR team members and walks through decision points: who gets notified, what containment actions are authorized, how communications are handled. Tabletops reveal gaps in role definition, authority ambiguity, and missing escalation contacts without requiring any technical execution.

Full simulation exercises go one step further: IR team members execute actual technical procedures against a simulated environment. They use production IR tools, pull real log data from a test system, and run through containment procedures. Simulations reveal gaps that tabletops miss — primarily tool access issues, credential management failures, and procedure steps that are theoretically correct but operationally unworkable.

Plan maintenance requires a designated owner. Assign one person responsibility for keeping the IR plan current: updating team rosters when people change roles, reviewing external contact information quarterly, and triggering playbook updates after incidents and after significant changes to the environment. Most IR plans become outdated within six months of publication because maintenance ownership was never assigned.

A working IR plan is specific enough that a responder can follow it at 2am without calling anyone for clarification. It defines authority clearly enough that containment decisions happen in minutes, not hours. It is tested at least annually against realistic scenarios. And it is maintained by a named owner who updates it after every incident and every significant change to the environment. If your current IR plan does not meet those criteria, it is a compliance document, not an operational tool.