Incident response plan template
An incident response plan tells your team what to do in a cyber security incident: who leads, how serious it is, how to contain it, remove the cause and recover, who to tell, and what to learn afterwards. This free Word template has those sections, plus a personal data breach checklist and an incident log.
Running a company of 30 to 200 people? Documents like this are now worth money.
It's written for companies without a dedicated security team, where a response means a manager, an IT provider, an insurer and many urgent phone calls.
What's in the template
Cyber security incident response plan
| Company | |
|---|---|
| Plan owner | |
| Version and date | |
| Incident lead and deputy | |
| Offline copies kept | e.g. printed, and on phones |
1. Key contacts
At least two people for each role, and two ways to reach each of them.
| Who | Name | Phone and personal email | Call when |
|---|---|---|---|
| Incident lead | Every incident | ||
| IT lead or IT provider | Every incident | ||
| Senior management | High or critical | ||
| Legal adviser and data protection lead | Personal data involved | ||
| Cyber insurer | As your policy requires | ||
| Communications | Outsiders may notice | ||
| HR | Staff involved |
2. Severity levels
| Level | Examples (adapt to your business) | Escalate to | Response |
|---|---|---|---|
| Critical | Most staff can't work, or sensitive data stolen | Managing director at once | Invoke this plan and the DR plan |
| High | |||
| Medium | |||
| Low | One device infected and isolated | IT lead | Handle and log |
3. Response steps
| Stage | Actions | Who |
|---|---|---|
| Detect and report | Report anything odd at once, with the time | |
| Triage | Confirm it, set severity and type, open the log | |
| Contain | Isolate devices, disable accounts, block traffic | |
| Eradicate | Remove malware and access; fix the weakness used | |
| Recover | Restore from clean backups; watch for a return | |
| Communicate | One agreed message for each audience | |
| Review | Post-incident review; update this plan |
4. Personal data breach checklist (UK GDPR)
- Personal data lost, destroyed, altered, disclosed, accessed without authority or made unavailable?
- Assess the likely risk to people's rights and freedoms
- Risk likely: report to the ICO without undue delay and no later than 72 hours after becoming aware; give reasons if late
- Risk high: tell the people affected without undue delay
- Record every breach, its effects and the action taken, reported or not
- Consider telling your insurer, the police, and the NCSC if criminals caused it
5. Playbooks to write
- Ransomware
- Phishing and a compromised email account
- Lost or stolen laptop or phone
- Personal data sent to the wrong person
6. Incident log
| Date and time | What happened or was decided | By |
|---|---|---|
How to write an incident response plan
- Say what counts as an incident and how to report it. Monitoring tools, staff and outsiders such as suppliers all spot incidents; give everyone one route to the incident lead.
- Name the decision-makers, including who can take a core system offline and who decides when they're unavailable or it's out of hours.
- Set severity levels by the impact on availability, confidentiality and integrity, and say who is told at each level.
- Describe the stages: contain, eradicate, recover, review. Log every decision, because regulators or a court may later ask for it.
- Build in the reporting duties below, and plan how you'll communicate if email is down.
- Write short playbooks for the three to five incidents you're most likely to face, covering at least the first few hours, and rehearse them.
Reporting a personal data breach (UK)
When an incident involves personal data, UK GDPR adds deadlines. According to the ICO:
- A personal data breach is, broadly, a security incident that affects the confidentiality, integrity or availability of personal data, so it isn't only loss or theft.
- If a breach is likely to result in a risk to people's rights and freedoms, you must report it to the ICO without undue delay, and not later than 72 hours after becoming aware of it. If you take longer, you must give reasons.
- You can report in phases, sending further details without undue further delay.
- If the risk is high, you must also tell the people affected without undue delay.
- You must record every breach, including those you don't report, and should document why you decided not to.
GOV.UK's cyber incident reporting service doesn't share what you tell it with the ICO, so report to both where needed. Outside the UK, ask your legal adviser which other rules apply.
Example: a fictional 120-person recruitment agency
How a mailbox compromise might run under the plan.
| When | What happened |
|---|---|
| Day 1, 09:10 | A recruiter reports emails in her sent folder that she didn't write; the incident lead is called. |
| Day 1, 10:00 | Unauthorised access to a mailbox of candidate CVs; severity high. Password reset, sessions signed out, a forwarding rule to an outside address deleted. |
| Day 1, 14:00 | Logs show about 60 CVs forwarded, some with passport copies. The data protection lead rates the risk to those candidates as high. |
| Day 2 | Breach reported to the ICO, noting the investigation is continuing; insurer told. |
| Day 3 | Affected candidates told what happened and what to watch for; further details sent to the ICO. |
| Week 3 | Review: forwarding to outside addresses blocked for every mailbox; phishing training repeated. |
Common mistakes
- A plan that lives only on the network it protects.
- Nobody empowered to pull the plug, so containment waits for a meeting while the attacker spreads.
- Wiping machines before saving logs and evidence, which can leave you unable to show the ICO, your insurer or the police what happened.
- Waiting for the full picture before reporting a breach. The 72 hours run from when you become aware, and the ICO accepts reports in stages.
Frequently asked questions
What are the phases of incident response?
The four-phase model in NIST SP 800-61 Revision 2 (2012) is preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3 (2025) maps these onto the six functions of NIST's Cybersecurity Framework 2.0 (govern, identify, protect, detect, respond, recover) and says organisations should use whichever model suits them. NCSC describes the core response as analyse, contain, remediate and recover.
Do we have to report every cyber incident?
No. Under UK GDPR you report a personal data breach to the ICO only when it's likely to result in a risk to people's rights and freedoms, though you must record every breach. Other incidents may still need reporting under your contracts, sector rules or insurance policy.
This template is a starting point, not legal advice, so confirm your reporting duties with an adviser before you rely on it.
Sources
- ICO: Personal data breaches, a guide
- ICO: Report a breach
- NCSC: Incident management, cyber incident response processes
- NCSC: Prepare your people for a disruptive cyber incident
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- GOV.UK: Where to report a cyber incident