The incident response plan, built to work.

An incident response plan is the document your team reaches for on its worst day — the one that says who decides, who acts, who gets told, and in what order when a security incident lands. A good one turns chaos into a sequence; a bad one gathers dust until the day it is needed and then fails. This guide covers what an incident response plan contains, the phases it should follow, and how to keep it alive. It is the preparation half of cyber incident management.

Plan, response, and management

Three terms get used loosely, and the difference matters when an incident is live. The incident response plan is the artifact — the written playbook. Incident response is the technical work it directs: detect, contain, eradicate, recover. Incident management is the wider coordination around both — command, communication, legal and regulatory reporting, and post-incident review. A plan is only as good as the management discipline that exercises it, which is why it is worth reading this alongside cyber incident management.

The phases, aligned to NIST and ISO

You do not have to invent the structure. Two widely used frameworks describe the same shape. NIST SP 800-61 sets out four phases, and ISO/IEC 27035 describes a closely matching cycle. A practical version:

1. Preparation. Plans, roles, runbooks, tooling, and the profile work that tells you in advance which regulators bind you. The best time to learn your reporting obligations is not during the incident.
2. Detection and analysis. Recognize that something is happening, and establish scope, entry point, and impact well enough to make decisions.
3. Containment, eradication, and recovery. Stop the spread, remove the cause, and restore service safely and in a verified state.
4. Post-incident activity. A blameless review that turns the event into improved preparation — and, increasingly, a documented final report regulators expect anyway.

ISO/IEC 27035 frames the same arc as plan and prepare, detection and reporting, assessment and decision, response, and lessons learned. The labels differ; the loop — prepare, detect, decide, act, learn, feed back into prepare — does not.

What the plan must contain

A plan that is only a phase diagram will not help at 2am. The working document needs concrete, findable content:

• Scope and activation criteria — what counts as an incident, and who can declare one.
• Roles and responsibilities — incident manager, technical lead, communications, legal, and an executive sponsor, with named backups.
• A severity classification scheme — the tiers that decide escalation, and the point at which an event becomes a reportable major or significant incident.
• Runbooks for the scenarios you can foresee — ransomware, business email compromise, data exfiltration, third-party outage.
• A communication plan — internal, customer, and board messaging, with holding statements drafted in advance.
• Escalation and decision authority — who can approve containment that takes systems offline, and who signs off external statements.
• Regulatory reporting triggers and deadlines — the clocks that start on classification, mapped to the regimes that apply to you.
• A contact tree and on-call rota — including out-of-band channels for when your primary systems are the incident.
• Evidence handling and logging — how to preserve what the review and any regulator will need.
• Recovery and post-incident review — the criteria for declaring the incident closed, and the lessons-learned loop.

Where reporting fits in the plan

The most commonly under-built part of an incident response plan is the reporting logic. A plan that stops at recovery leaves the team improvising the paperwork that regulators put on the tightest clock of all. The plan should know, in advance, which regimes bind you and wire your severity classification straight to their deadlines: DORA's roughly four-hour initial notification, NIS2's 24-hour, 72-hour, and one-month sequence, and GDPR's 72-hour notification — each running from awareness or classification, not from when the incident began. This is the EU baseline; national transposition varies. It's informational, not legal advice — verify the specifics that bind you with qualified counsel.

This is the point where a plan on paper meets a system that can act on it. Polestead's CIIC maps your business profile to the regimes that apply and, on classification, produces the next-step plan, the clock schedule, and every regulator-ready report in parallel — so the reporting section of your plan is executed, not just described.

Templates, testing, and keeping it current

Start from a template — NIST, ISO/IEC 27035, or a sector CERT all publish structures — then make it yours; a generic plan lifted verbatim is a plan nobody in the room believes. Keep it alive with tabletop exercises that pressure-test the decisions and the contact tree, and update it after every real incident and every material change to your systems, people, or obligations.

One shift worth planning for explicitly: increasingly, the incident you have to manage did not happen on your systems at all — it happened at a vendor. Your visibility is second-hand and your containment options are contractual rather than technical, which changes the runbook. We cover that case in cyber risk response.