Incident response plan template: sections, playbooks and testing

Every business has an incident response plan. For most, it is “call the IT person and hope”. A written plan replaces that with decisions made in advance, when everyone is calm — which is the only time good decisions about incidents get made.

By Alex Martyushin, founder & risk consultant · Updated 30 October 2026 · 12 min read

What an incident response plan is

An incident response plan (IRP) is the agreed way your organisation handles a cyber security incident: who is in charge, what happens in the first hour, who is told and when, and how normal service is restored. A cyber security incident is any event that threatens the confidentiality, integrity or availability of your systems or data — ransomware, a compromised mailbox, fraudulent payment instructions, a website taken offline, a laptop left on a train.

This template covers all of those. If an incident involves personal data, the extra notification duties — regulators, individuals, timelines in different countries — are covered in detail in our data breach response plan. Treat that guide as the data breach playbook of this plan.

The plan does not replace prevention. The risks that make incidents likely — unpatched systems, weak authentication, untrained staff — belong in your cybersecurity risk assessment and risk register. The plan is what you do when prevention fails.

The incident response lifecycle

For years the standard reference was NIST SP 800-61 Revision 2 (2012), with its four phases. NIST replaced it in April 2025 with SP 800-61 Revision 3, which describes incident response through the six functions of the NIST Cybersecurity Framework 2.0. The UK’s National Cyber Security Centre (NCSC) publishes incident management guidance for organisations of all sizes along similar lines. The table maps the two NIST views onto what a small team actually does.

Incident response plan template: the ten sections

Copy these headings into a document. Replace bracketed text. Aim for four to eight pages plus playbooks.

1. Purpose and scope

This plan sets out how [organisation] responds to cyber security incidents affecting its systems, data, staff and customers, including systems run for us by [IT provider, key SaaS vendors]. It is owned by [role] and approved by [CEO / board].

2. Definitions and severity levels

Define “event”, “incident” and “data breach” in one line each, and include the severity table from the next section. State who can declare an incident and set its severity — usually anyone on the response team, with the incident lead confirming.

3. Roles and deputies

Name the incident lead, decision-maker, technical lead, communications lead, legal and privacy lead, and scribe, each with a deputy. The section below explains each role.

4. Contact list

Keep it out of band — printed and on phones — because email may be down or watched by the attacker. Include the response team, IT and security providers, cyber insurer’s incident line and policy number, legal counsel, bank fraud team, key SaaS vendors’ security contacts, regulators and law enforcement reporting routes.

5. Response phases

One short paragraph per phase: how incidents are reported internally, the first-hour checklist, containment principles (isolate rather than switch off; preserve evidence), recovery criteria and the post-incident review.

6. Playbooks

One page per likely incident type. Six starting playbooks are below.

7. Communications

Who may speak externally, approval of statements, internal updates, holding statements prepared in advance, and alternative channels if email or chat is compromised.

8. Legal and regulatory reporting

Which regulators, customers, insurers and authorities must be told, by whom, and within what time. See the deadlines table below.

9. Evidence and decision log

Who keeps the timeline; how logs, images and emails are preserved; how each decision is recorded with time, decision, reason and decision-maker.

10. Testing, training and review

Exercise schedule, who attends, when the contact list is checked, and the rule that the plan is reviewed after every significant incident.

Severity levels

Severity drives everything else: who is woken up, who is told and how fast. Keep it to four levels and define them by consequence, not by technical detail.

Link the levels to your business impact analysis: an incident that threatens an activity close to its maximum tolerable downtime is at least high severity, whatever its technical cause.

Roles in the incident response team

• Incident lead — runs the response, sets priorities and update times, owns the decision log. Not necessarily the most technical person; the most organised.
• Decision-maker — usually the CEO or managing director. Approves spending, shutdowns, external statements, notifications and any decision about an extortion demand.
• Technical lead — containment, evidence, recovery; coordinates the IT provider and any forensic firm.
• Communications lead — staff, customer and media messages; customer service scripts.
• Legal and privacy lead — notification decisions, contracts, regulator contact. Often external counsel, possibly from your insurer’s panel.
• Scribe — keeps the timeline and decisions in real time.

In a 30-person business, three people may cover all six roles. That is fine, provided everyone knows which hat they are wearing and each role has a named deputy.

Six incident playbooks to start with

A playbook is one page: how you recognise the incident, the first actions, who to call and when it is over. These six cover the incidents small and mid-sized businesses most often face.

1. Ransomware

• Signs: files renamed or unreadable, ransom note, mass alerts from endpoint protection.
• First actions: disconnect affected machines from the network (do not power them off); disable compromised accounts; protect backups by isolating them; call the insurer’s incident line before engaging vendors.
• Decisions: restore priorities from the BIA; whether any data was stolen as well as encrypted; any extortion contact handled only by the decision-maker with legal advice.
• Done when: systems restored from clean backups, the entry point closed and credentials reset. More in ransomware risk.

2. Business email compromise and payment fraud

• Signs: a supplier says they were not paid; changed bank details by email; unexpected mailbox rules forwarding mail.
• First actions: call your bank’s fraud team immediately to try to recall the payment; reset the mailbox password and revoke sessions; remove malicious forwarding rules; check other mailboxes for the same rules.
• Done when: access removed, affected counterparties warned, payment verification rule reinforced. See phishing risk for prevention.

3. Compromised user account

• Signs: logins from unusual locations, MFA prompts the user did not trigger, password reset emails.
• First actions: reset password, revoke sessions and tokens, re-enrol MFA; review what the account accessed and sent.
• Done when: access history reviewed and any data exposure assessed against the breach playbook.

4. Website or service outage (including denial of service)

• Signs: site unavailable or extremely slow; hosting or CDN alerts.
• First actions: confirm whether it is an attack or a failure; engage hosting or CDN provider support; switch on any available attack mitigation; post a status message.
• Done when: service restored within the RTO or a workaround in place; cause understood.

5. Lost or stolen device

• Signs: staff report it — make sure they know to do so immediately and without fear of blame.
• First actions: remote lock or wipe; revoke the device’s sessions; confirm whether it was encrypted.
• Done when: device wiped or recovered and a decision recorded on whether personal data was at risk.

6. Personal data breach

• Signs: any of the above where personal data may have been accessed, disclosed, altered or lost — or data sent to the wrong recipient.
• First actions: contain; start the breach assessment clock; involve the privacy lead.
• Done when: notification decisions made and recorded. Follow the data breach response plan for the 72-hour sequence and notification rules.

Communication rules

• One voice. Only the communications lead and decision-maker speak externally. Everyone else refers enquiries to them.
• Assume the attacker can read email. Use a pre-agreed alternative channel — phone, a separate messaging group — for response team discussion during serious incidents.
• Fixed update times. For example, every two hours for the team, twice a day for staff. Predictable updates reduce interruptions.
• Holding statements prepared in advance. A short customer notice and a staff message for an outage and for a data incident, approved before you need them.
• Facts only. Do not speculate about causes or attackers in public statements; say what you know, what you are doing and when you will update.

Reporting deadlines to build into the plan

Some notifications have hard clocks that start when you become aware of the incident, not when you finish investigating. Put the ones that apply to you in the plan with names against them.

Sector rules add more — financial services, healthcare (see our HIPAA guide), payment card data under PCI DSS, and operators of essential services. Check which apply to you with counsel when you write the plan, not during the incident.

How to test an incident response plan

1. Tabletop exercise (annually, 90 minutes). Walk the team through a realistic scenario — ransomware discovered at 7 am on a Monday — with new information injected every 15 minutes. The NCSC’s free “Exercise in a Box” provides ready-made scenarios for smaller organisations.
2. Technical tests (quarterly). Restore a system from backup and time it against the RTO; check that logs needed for an investigation actually exist and are kept long enough.
3. Contact check (quarterly). Call the numbers. Insurer lines and supplier contacts change.
4. After every real incident. A short review within two weeks: what happened, what worked, what did not, and which actions follow.

Linking the plan to your risk register

Incidents are evidence about your risks. Each post-incident review should ask three questions of the risk register: Was this risk on the register? Were its likelihood and impact scored realistically? Did the controls we listed actually work? Update the entries, add the actions with owners and due dates, and track indicators such as time to detect and time to contain as key risk indicators. Over time, the register and the plan improve each other.

Common mistakes

• The plan lives only on the network that has just been encrypted. Keep printed and offline copies.
• No deputies. Incidents ignore holiday rotas.
• Switching everything off. Powering down machines can destroy the evidence needed to understand the attack; isolate instead, unless advised otherwise.
• Calling vendors before the insurer. Many policies require you to use panel firms; costs from others may not be covered.
• Never rehearsed. A plan read for the first time during an incident adds to the confusion.
• No lessons recorded. If the review does not change a control, a register entry or the plan, the incident will happen again.