---
title: "Incident response plan template"
canonical: https://www.grcmana.io/vault/templates/incident-response-plan
published: 2023-12-13
updated: 2026-10-17
author: "Harry West"
framework: "ISO 27001"
type: "Plan"
---

# Incident response plan template

## Key takeaways

An incident response plan is the playbook for a security incident: who leads, how events are assessed and contained, and who is told by when. ISO 27001 A.5.24 to A.5.27 expect documented incident procedures, and UK GDPR gives 72 hours to report a qualifying breach to the ICO. This Word template suits UK firms of 25 to 250 staff.

- **Required by** — ISO 27001:2022 controls A.5.24 to A.5.27; UK GDPR Articles 33 and 34 for personal data breaches
- **Approved by** — Management, including the severity tiers; the plan owner keeps contacts and steps current
- **Tested** — At least annually by tabletop exercise (common practice), and after significant change
- **Format** — Word, about 14 pages, with scenario cards and a plan management checklist

A laptop holding client data goes missing on a Friday evening. Who decides whether the ICO needs to know, and by when? An incident response plan answers that before it happens. This template gives a UK firm of 25 to 250 staff a ready-to-edit incident response plan in Word, mapped to ISO 27001 controls A.5.24 to A.5.27, with the UK notification clocks already laid out.

## What's in the template

One Word document, about 14 pages, version 1.0. It has four parts.

1. **The incident response plan.** The playbook itself: roles and deputies, how an event is reported, a four-tier severity matrix, the response phases from detection to lessons learned, evidence handling, communication, and when to hand over to your business continuity plan.
2. **Ready-to-use appendices.** An out-of-hours contact sheet, an incident log, a one-page severity matrix, a notification map for the ICO, FCA, DORA, client contracts and your insurer, four scenario quick cards (ransomware, a lost device, business email compromise and a supplier breach) and a post-incident review form.
3. **A getting-started guide and next steps.** Which sections to fill in first, what to leave as written, and where the plan sits beside your incident management policy and business continuity plan.
4. **A plan management checklist.** Approval, contact-list checks, the annual exercise and review dates: the records an auditor asks to see alongside the plan.

Every placeholder is in square brackets. You replace the names, numbers and systems, set your severity tiers, and the plan is ready for management approval.

The plan is the "how". The "what" (the commitments, ownership and reporting duty your leadership signs up to) belongs in its companion, the [incident management policy](https://www.grcmana.io/vault/templates/incident-management-policy).

## What is an incident response plan?

An incident response plan is the playbook your team follows when a security incident happens: who leads, how an event is reported and assessed, how it is contained and recovered from, who is told and by when, and how the lessons feed back. It is written to be used under pressure, at 2am, by whoever is on call.

Auditors ask for one because ISO 27001 expects incidents to be handled according to documented procedures. Customers ask for one because their own regulators and insurers want to know who would tell them, and how fast, if your systems were breached.

Some firms call the same document an incident management plan. The name matters less than whether it works on the night.

### Plan or policy: which one do you need?

Most firms need both, because they do different jobs. The incident management policy is short and stable: leadership commits to managing incidents, names who owns the process and tells staff they must report. The incident response plan is operational, and it changes whenever your people, suppliers or systems change.

Keep them separate, so that updating a phone number doesn't need a board meeting.

|  | Incident management policy | Incident response plan |
| --- | --- | --- |
| The question it answers | What do we commit to, and who is accountable? | What exactly do we do, step by step, when it happens? |
| Who reads it | All staff, auditors and customers | The response team and their deputies |
| Length | Two to three pages | Ten to fifteen pages, plus appendices |
| Changes when | Leadership, scope or commitments change | People, suppliers, systems or regulators change |
| Approved by | Top management | Management approves the plan and its severity tiers; the owner keeps contacts and steps current |

### Which standards and regulators expect one

ISO 27001 sets out the incident controls, and UK law and your regulators set the clocks. Which rows apply to you depends on the data you hold, whether you are authorised by the FCA and who your clients are.

| Standard or regulator | What it asks for |
| --- | --- |
| ISO 27001:2022, control A.5.24 | Plan and prepare for managing incidents by defining, establishing and communicating incident management processes, roles and responsibilities. |
| ISO 27001:2022, control A.5.25 | Assess information security events and decide whether they are to be categorised as incidents. |
| ISO 27001:2022, control A.5.26 | Respond to incidents in accordance with documented procedures. |
| ISO 27001:2022, control A.5.27 | Use the knowledge gained from incidents to strengthen and improve your controls. |
| UK GDPR, Articles 33 and 34 | Report a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Tell the people affected without undue delay when the risk to them is high. Document every breach, whether you report it or not. |
| FCA (authorised firms) | SUP 15.3 requires a firm to notify the FCA immediately of matters with a serious regulatory impact, and its guidance includes any significant failure in systems or controls. |
| DORA (EU financial entities, and their ICT suppliers by contract) | An ICT-related incident management process, a way to classify incidents, and reporting of major ICT-related incidents to the competent authority. |
| Customer due diligence | Security questionnaires commonly ask whether you have a tested plan, when it was last exercised and how quickly you would notify the customer. |

For the depth on each control, see the guides to [A.5.24 incident management planning](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation), [A.5.25 assessing events](https://www.grcmana.io/vault/iso-27001/annex-a-5-25-assessment-and-decision-on-information-security-events), [A.5.26 responding to incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) and [A.5.27 learning from incidents](https://www.grcmana.io/vault/iso-27001/annex-a-5-27-learning-from-information-security-incidents). Evidence handling sits under [A.5.28](https://www.grcmana.io/vault/iso-27001/annex-a-5-28-collection-of-evidence), and the staff duty to report under [A.6.8](https://www.grcmana.io/vault/iso-27001/annex-a-6-8-information-security-event-reporting).

## How to create your incident response plan with this template

With the groundwork in place, this takes about a day of drafting, one management meeting and a half-day exercise. Without it, the plan will describe a firm that doesn't exist yet, so check the groundwork first.

### Before you start

A plan is only as good as what it points at. Check you have:

- **An asset register that marks what's critical.** Severity tiers are relative to it: "an outage of a critical system" means nothing until critical is defined. No register yet? Start with the [A.5.9 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-9-inventory-of-information-and-other-associated-assets).
- **A risk assessment.** Your top risks choose the scenarios the plan prepares for and rehearses. No risk assessment yet? Use the four scenario cards as written for now, and run one before the audit. The [clause 6.1 guide](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) covers it.
- **An owner, and an incident lead with a deputy.** Ideally your incident management policy names them. No policy yet? The plan can name them for now, but write the policy before the audit.
- **Your notification footprint.** Know whether you hold personal data as a controller or a processor, whether you are FCA-authorised, whether you supply EU financial entities that fall under DORA, and what your client contracts promise. Not sure of an answer? Write down what you know, mark the gaps, and close them before you map the clocks in step 3. The [A.5.31 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements) covers keeping that register.

If none of these exist yet, the job is bigger than one plan. That's the point where most firms bring in help.

**1. Name the team, and a deputy for every role** *(about 30 minutes)*

- **Do this:** put a name and a deputy against each role: incident lead, technical investigator, note-taker, and the reach-ins for legal or data protection, HR, communications and key suppliers.
- **The template:** lays out the roles with a one-line duty for each, and an out-of-hours contact sheet to fill in.
- **Watch for:** a team that only exists on weekdays. Keep the contact sheet somewhere that still works when email and chat are down.

If the lead and the deputy are on the same holiday, you have one role, not two.

**2. Set your severity tiers** *(1 to 2 hours)*

Next, decide what makes an incident a P1 rather than a P3, in tests a stressed person can apply without asking permission. The template gives you a four-tier matrix with example criteria and target response times. Your job is to tie each tier to your own critical systems, clients and data, then take the tiers to management, so the incident lead never waits for sign-off before acting.

> **Where most firms get stuck:** severity tiers written for an enterprise. "Major outage affecting more than 10,000 users" is no use to a 60-person firm. Write the criteria around the clients, systems and data you actually have, or every incident lands as a P3 and nothing escalates.

**3. Map your notification clocks** *(1 to 2 hours)*

- **Do this:** for each tier, record which clocks it may start: the ICO's 72 hours for a reportable personal data breach, any FCA notification, DORA reporting if you are in scope, your client contracts and your cyber insurer. Name who decides, and who sends.
- **The template:** includes a notification map and a decision route for personal data breaches, with the ICO clock running from when you become aware of the breach.
- **Watch for:** client contracts. They can promise faster notice than any regulator asks for, and nobody reads them until the incident. Pull the notification clauses from your largest contracts into the map.

> **Where most firms get stuck:** discovering the regulatory clock in the middle of the incident. By the time someone asks whether the ICO needs to know, a day has gone. Who decides, and on what test, belongs in the plan, not in the incident.

**4. Walk the playbook through your own systems** *(2 to 3 hours)*

Then work through the response phases (detect and report, assess, contain, eradicate, recover and review) for the estate you actually run. Where do your logs live, and who can read them? How do you isolate a laptop, revoke a session or lock a Microsoft 365 account? What evidence do you preserve before anyone starts rebuilding?

The template's scenario cards give the first moves for ransomware, a lost device, business email compromise and a supplier breach. Replace the generic steps with your own tools and the names of the people who will run them. If an incident outgrows IT, the plan should say when it escalates into your business continuity arrangements, which the [A.5.29 guide](https://www.grcmana.io/vault/iso-27001/annex-a-5-29-information-security-during-disruption) covers.

**5. Approve, publish and rehearse** *(one management meeting, then a half-day exercise)*

- **Do this:** take the plan and the severity tiers to management for approval, and set the next review date. Give the response team a copy they can reach offline, then run a tabletop exercise within three months.
- **The template:** includes a post-incident review form you can also use for the exercise, and a plan management checklist for the approval, contact checks and exercise dates.
- **Watch for:** a plan that has never been tested. The records that prove it works are covered in [How to use it so it holds up at audit](#how-to-use-it-so-it-holds-up-at-audit).

A plan that has never been tested is a draft with a signature on it.

### Do it yourself, or have us do it with you

|  | Do it yourself with the template | Do it with GRCMANA |
| --- | --- | --- |
| What you end up with | An approved incident response plan for your firm | This plan plus the incident management policy, severity tiers tied to your asset register, a notification map built from your regulators and contracts, and a first tabletop exercise run with your team |
| Your time | About a day plus a half-day exercise, if the groundwork is in place. Considerably more if it isn't | Agreed with you at the start, based on the groundwork you already have |
| Best if | The groundwork exists and someone on your team has handled a real incident before | Compliance landed on you alongside your day job, you have never run an incident, the audit date is fixed, or a client is asking how fast you would tell them |

Prefer the second column? [Talk to us about incident readiness](https://www.grcmana.io/contact).

## What does a good incident response plan look like?

Most incident response plans read well. Fewer survive their first real incident. Here is the difference.

### Weak and strong, side by side

| Section | Weak | Strong | Why the strong one works |
| --- | --- | --- | --- |
| Roles | "The IT team will respond to incidents." | "The \[COO\] leads incidents, with \[Head of Engineering\] as deputy. Contact details are in Appendix A, held offline and checked every quarter." | A named lead and deputy can be called at 2am. "The IT team" can't. |
| Severity | "Incidents will be prioritised according to their impact." | "P1: confirmed loss of client data, or an outage of a system marked critical in \[asset register\]. Response within \[30 minutes\], at any hour." | A stressed person can apply the test without asking permission. |
| Notification | "We will notify the relevant authorities as required." | "The \[DPO\] decides within \[24 hours\] of awareness whether a personal data breach is reportable to the ICO, and records the reasoning either way." | It names who decides and by when, inside the 72 hours, and leaves a record whether or not you report. |
| Containment | "Contain the incident as quickly as possible." | "For a compromised account: revoke sessions and reset credentials in \[identity provider\], then export the sign-in logs before changing anything else." | Concrete first moves, in the right order, with the evidence kept. |
| Lessons learned | "Lessons learned will be reviewed after incidents." | "Every P1 and P2 gets a review within \[10 working days\]. Actions have owners and dates, and are tracked to closure in \[register\]." | A.5.27 expects the knowledge to improve controls. A dated, owned action list shows that it did. |

### What an auditor checks in the first five minutes

Before reading the detail, most auditors check that:

1. **It's current.** It has a version, an approval date and a review date that hasn't passed.
2. **The people are real.** The named lead and deputies still work at the firm, and the contact numbers answer.
3. **It matches the log.** One or two entries in the incident log can be traced through the plan's phases.
4. **It has been tested.** There is an exercise record, with findings and closed actions.
5. **The clocks are there.** It shows how a personal data breach is assessed for ICO reporting, and who decides.
6. **It's genuinely yours.** It names your systems, suppliers and people, with no leftover template text.

If all six hold, the auditor moves on to the incident log with confidence. If one fails, they tend to sample harder.

### What good looks like at 25 staff and at 250

| Feature | Around 25 staff | Around 250 staff |
| --- | --- | --- |
| Response team | Three or four people, most roles held by directors | A named team with deputies, plus an out-of-hours rota |
| Incident lead | The founder, the COO or a fractional CISO | A security lead, with a duty manager out of hours |
| Detection | Alerts from Microsoft 365 or Google Workspace, endpoint protection and staff reports | A monitored service such as MDR, with a defined escalation route into the plan |
| Severity tiers | Three or four, written as plain tests | Four, with response targets and paging rules |
| Scenario cards | Two or three, for your top risks | Five or more, owned by the teams that run them |
| Exercises | One half-day tabletop a year | A tabletop a year plus a technical exercise, with leadership taking part |

The common mistake at 25 staff is a plan built for an enterprise security operations centre: twenty runbooks nobody will maintain. The common mistake at 250 is the reverse, a plan written when the firm had 40 people, naming a lead who left two years ago.

## How to use it so it holds up at audit

The plan is only half the evidence. An auditor tests whether it runs, and these are the records they usually ask for:

- **The approval record:** who approved this version and its severity tiers, and when.
- **The incident log:** every event and incident, including near-misses and false alarms, with dates, severity, decisions and closure.
- **The breach record:** every personal data breach, with its facts, effects and remedial action, whether you reported it to the ICO or not. UK GDPR requires this record.
- **Exercise records:** the scenario, who took part, the findings, and the actions with their closure dates.
- **Post-incident reviews:** what changed in your controls or the plan as a result.
- **Contact-list checks:** dated confirmations that the numbers still work.

**The most common reasons this plan fails audit:**

- It has never been tested, or the exercise findings were never closed.
- The named lead or deputy has left, and the contact list is out of date.
- The incident log is empty, which reads as a process nobody uses rather than a quiet year.
- Real incidents were handled outside the plan, so the log and the plan tell different stories.
- It was copied from a template and still describes tools and teams the firm doesn't have.

Each of these is cheaper to fix now than to explain in the audit room.

## Incident response plan questions

### What should an incident response plan include?

Named roles with deputies, a single route for reporting events, severity tiers with response targets, the response phases from detection to recovery, evidence handling, who must be notified and by when, and how lessons are captured. Practical appendices (a contact sheet, an incident log and scenario cards) make it usable under pressure.

### Is an incident response plan the same as an incident management plan?

In practice, yes. Both names describe the playbook a team follows when a security incident happens. What matters more is keeping the plan separate from the incident management policy, which sets leadership's commitments and ownership rather than the step-by-step response.

### What are the phases of incident response?

Most plans follow a cycle of preparation, detection and reporting, assessment, containment, eradication, recovery, and a post-incident review. The review feeds lessons back into preparation. A small firm can run every phase with a few named people, provided each phase has an owner.

### How often should an incident response plan be tested?

At least once a year is common practice, and again after a significant change such as a new incident lead, a new identity provider or an acquisition. A half-day tabletop exercise against a realistic scenario counts, as long as the findings are recorded and the actions closed.

### Does every personal data breach have to be reported to the ICO?

No. A breach must be reported only if it is likely to result in a risk to people's rights and freedoms. The ICO's guidance is to start a log anyway, and UK GDPR requires every breach to be documented. Record your reasoning when you decide not to report.

## Get the template

Start from a plan that already lays out the roles, severity tiers, response phases and UK notification clocks, written for a firm your size. Download the Word template, fill in your names and systems, and book the first exercise before the plan reaches a shelf.

*This template is a starting point to adapt to your organisation, not legal advice.*