Incident response plan template
An incident response plan is judged on one question: can someone follow it at 2am without you? This template keeps the plan short enough to be usable, with the severity matrix, call tree and regulatory clock on the first two pages.
Every field, explained
| Field | What to put in it |
|---|---|
| Section | The plan section — keep the whole plan under ten pages. |
| What it must contain | The minimum content for that section to be usable under pressure. |
| Owner | Named person accountable for keeping that section current. |
| Review cadence | How often it is reviewed and after which trigger events. |
| Evidence of use | What proves the section works — a tabletop, a real incident, a test call. |
Worked examples
- Section
- Severity matrix
- What it must contain
- P1–P4 definitions with concrete examples, response times and who can declare each level.
- Owner
- Head of IT
- Review cadence
- Annual + after any P1/P2
- Evidence of use
- Incident log showing severity applied consistently
- Section
- Roles and call tree
- What it must contain
- Incident manager, technical lead, comms lead, legal/DPO, deputy for each — with out-of-hours numbers.
- Owner
- Operations Director
- Review cadence
- Quarterly (people change)
- Evidence of use
- Dated test call record
- Section
- Regulatory and contractual notification
- What it must contain
- UK GDPR 72-hour ICO assessment and reporting steps, customer contract notification windows, cyber insurer notification.
- Owner
- DPO / Legal
- Review cadence
- Annual
- Evidence of use
- Tabletop decision record on whether to notify
- Section
- Lessons learned
- What it must contain
- Post-incident review template, corrective actions with owners, feedback into the risk register.
- Owner
- ISMS Manager
- Review cadence
- After every incident
- Evidence of use
- Closed corrective actions traceable to an incident
How to use it
- Write the severity matrix first — everything else keys off it.
- Name deputies for every role; incidents happen during annual leave.
- Put the notification clock on page one with the decision criteria, not buried in an annex.
- Run a two-hour tabletop within a month of publishing and record the actions it generates.
- Store the plan somewhere reachable when the network is down, and say where in the plan itself.
- Feed every incident's lessons back into the risk register and control set.
What auditors pick up
- A plan that has never been tested — no tabletop, no test call, no evidence.
- Contact details out of date, referencing people who have left.
- No link between incidents and corrective actions, so A.5.27 learning cannot be shown.
- The plan exists only on the file share that the ransomware would encrypt.
FAQ
How long should an SME incident response plan be?
Under ten pages. Long plans are not read during an incident. Depth belongs in runbooks referenced from the plan, not in the plan itself.
Do we have to report every incident to the ICO?
No. Under UK GDPR you must notify the ICO within 72 hours only where a personal data breach is likely to result in a risk to individuals' rights and freedoms. Record the assessment either way — the decision record is the evidence.
How often should we run a tabletop exercise?
At least annually, and after any significant change to the team or the estate. One realistic scenario, two hours, minuted, with actions tracked.
Related
Stop maintaining spreadsheets
Every template here exists as a live module inside ISO-STANDARD.app — owners, review dates, evidence links and audit trail included, with AI-generated remediation plans when something fails.
- Pre-loaded ISO 27001, 9001, 42001 and SOC 2 content
- Evidence vault with versioning
- Named owners and review reminders
- Export back to CSV any time