An incident response plan is the set of documents that tells your people what to do, in what order and who decides, when a cyber incident hits. The best ones are short and clear. The NCSC’s guidance says a basic plan needs key contacts, escalation criteria, a flowchart of the whole incident life-cycle, a conference line and notes on legal duties. This guide covers the steps, a template outline, the team, a worked example and how to keep the plan alive.
TL;DR
- A plan is a short, usable set of procedures: who does what, who decides, who you call and what order you work in.
- Six phases cover most plans: preparation, detection and identification, containment, eradication, recovery and post-incident review.
- Name at least two people per role and two ways to reach each, and agree who can decide out of hours.
- UK organizations must report certain personal data breaches to the ICO within 72 hours of becoming aware of them, where feasible, so build that clock into the plan.
- An untested plan is a guess. Run a tabletop exercise at least once a year and update the plan after every incident or exercise.
Table of Contents
- What an incident response plan is for
- The six incident response steps
- What an incident response plan template should include
- Who should be on the incident response team
- Fit the plan to your sector and your sites
- A worked example: Doncaster Council
- Test, maintain and update the plan
- How Zero Through can help
- FAQ
- Sources
What an incident response plan is for
A cyber incident response plan (IRP) is a collection of policies and procedures. It sets out the steps to follow when something goes wrong: ransomware, a compromised account, data theft, a supplier breach. Its job is not to prevent attacks. Its job is to shorten the time between “something looks wrong” and “the right people are doing the right things”.
The plan matters most when normal tools fail. If email and phones are down, a plan stored on the affected network is useless. Keep a copy that you can reach offline, and agree in advance how people will communicate.
Simple beats thorough. Guidance from the NCSC’s wider incident management collection favors plans people can actually follow, and long documents that nobody has read tend to fail on the day. Start with a basic plan and add detail as you test it.
The six incident response steps
Most UK public sector plans follow the same six-phase shape. Rochdale Borough Council’s cyber incident response plan is a clear published example, and the phases below follow it.
1. Preparation
This is where most of the value sits. You set policies, train people, deploy monitoring tools and keep readiness up with regular assessments. Preparation also means knowing your critical systems, so you know what to protect and restore first.
2. Detection and identification
You use tools such as SIEM, intrusion detection and prevention, endpoint detection and response (EDR) and firewall monitoring to spot indicators of compromise. Then you classify the incident by impact, scope and urgency. That classification decides who gets woken up.
3. Containment
Short-term containment stops the spread: isolating affected systems, disabling compromised accounts. Long-term containment keeps the business running while you prepare for full recovery.
4. Eradication
You remove the root cause. That means investigating how the incident happened and which vulnerabilities were exploited, so the attacker cannot simply return.
5. Recovery
You restore affected systems, guided by your business continuity plan, disaster recovery plan, recovery time and recovery point objectives, and how critical each system is. Validate before you reconnect: security scans, integrity checks, patch validation and user acceptance testing.
For serious attacks, the NCSC’s guidance on preparing for a highly disruptive incident adds that plans should cover how to rebuild systems securely, and that sustained recovery often means creating trusted environments from which services can be restored.
6. Post-incident review
Document the key events, confirm how the incident occurred, find gaps in controls and judge how well each phase worked, including communication, coordination and decision-making. Feed the lessons back into the plan.
Incident response and disaster recovery overlap but are not the same document. Our piece on incident response vs disaster recovery explains where one hands over to the other.
What an incident response plan template should include
A template is a starting point, not a finished plan. Aviva’s cyber incident response planning guide says its templates are best practice examples that should be tailored to your organization. Combining the NCSC and Aviva lists gives you this outline.
| Section | What goes in it |
|---|---|
| Purpose and objectives | What the plan covers and what a good outcome looks like |
| Response team and roles | Named people, deputies, decision authority |
| Key contacts | IR provider, IT, senior management, legal, PR, HR, insurer |
| Classification and severity matrix | How to rate an incident and what each rating triggers |
| Escalation criteria | Who is told, when, and who takes critical decisions |
| Incident flowchart | One page covering the full life-cycle |
| Communications | Internal, customer, regulator and media messages |
| Legal and regulatory guidance | When to involve legal, HR, regulators; evidence capture |
| Containment, remediation, recovery | Procedures per phase |
| Logs and forms | Incident log, situation report, lessons log |
The NCSC is specific about contacts: at least two contact methods and two or more people per role, plus at least one conference number that is always available. To strengthen the plan, it suggests adding checklists, forms for tracking the incident and for review, more technical detail by stage, and playbooks for particular incident types. Our guide to ransomware incident response is a good basis for the most common playbook.
The Department for Education’s response plan template adds a useful idea for any sector: a communication plan with sample messages, approved in advance and stored somewhere you can reach even when IT services fail.
Who should be on the incident response team
The team is a set of roles, not a set of job titles. The NCSC says organizations should settle who is responsible for operational response, technical recovery, legal and regulatory matters, decision-making and communications.
A typical team looks like this:
- Incident manager: leads the response and makes or escalates decisions. Rochdale’s plan gives this role to the head of ICT and digital.
- Deputy: takes over when the manager is unavailable.
- Technical lead and IT support: investigate, contain and recover.
- Data protection officer and senior information risk owner: judge whether personal data is involved and what must be reported.
- Communications: handle staff, customers, regulators and media.
- Finance, HR, legal and insurance: cover costs, people issues, legal duties and claims.
- A scribe: records every decision and action with times.
The NCSC also notes that key decisions, such as shutting down systems, invoking recovery plans or going public, must still be made if senior leaders are unavailable. That means delegated authority written into the plan, including out of hours. If you use an external provider, list them with the same contact detail as internal staff.
Fit the plan to your sector and your sites
A generic plan fails in specific ways. A law firm worries about client confidentiality and privilege. A retailer worries about point-of-sale and payment systems. A healthcare provider worries about patient safety and records. A manufacturer has operational technology that cannot simply be switched off. Adjust the severity matrix, the playbooks and the regulator contacts to match.
Global operations add another layer: different time zones, local regulators, and local reporting deadlines. The international standard ISO/IEC 27035-2:2023 is written to apply to any organization and says it can be adjusted to your type, size and risk. Its planning phase covers top management commitment, an incident management plan, an incident management team, relationships with outside bodies, technical support, and awareness and training. For a multi-site business, that means a shared global plan with local annexes for contacts and legal duties.
In the UK, the legal clock is concrete. The ICO’s guide to personal data breaches says certain breaches must be reported within 72 hours of becoming aware of them, where feasible, even if you lack full details. If the breach is likely to be high risk to individuals, you must also tell them without undue delay. Write both triggers into your escalation criteria, and name who makes the call.
A worked example: Doncaster Council
The Doncaster Council case study shows a plan doing its job. In 2016 the council was hit by TeslaCrypt ransomware. It had recently renewed its cyber incident handling plan after an executive steer, and the case study credits that, plus a whole-council approach in which staff understood their roles, for the prompt response.
The council took the network down, started its business continuity plans and completed a phased recovery by 11:30 pm. Two details are worth copying. First, it planned for communication when normal email and phones are unavailable, using floor walkers in offices to answer questions. Second, it posted staff at exits so equipment was not removed during the incident.
For the structure of a full written plan, Rochdale’s document is the more complete model. It defines the six phases above, a named team, tabletop and simulation testing, and a review annually or after significant incidents, major changes or new regulatory requirements.
Test, maintain and update the plan
The NCSC says plans often fail in practice and should be tested regularly, with a full exercise where possible. Its guidance on cyber exercise creation makes a key point: exercises stress test existing plans, they do not create them. Write the plan first.
There are two broad formats:
- Tabletop exercise: a discussion where the team talks through roles and responses to a scenario. Cheap and quick, and the right place to start.
- Live play exercise: people carry out their duties in a simulated incident, usually in real time. It takes more time and resources and needs key teams available.
The NCSC also publishes Exercise in a Box, a free tool that walks a facilitator and staff through a scenario and produces an end report with links to relevant advice.
After each exercise, record the observations, the lessons, the recommendations and who owns each one. Then change the plan. The DfE template sets a practical rhythm worth borrowing: an immediate debrief after a real incident, a formal review within two weeks, lessons logged and built into the plan, and contact details and escalation routes refreshed regularly. At minimum, review the whole plan yearly.
People are part of the plan too. Staff who recognize a phishing email or a suspicious login report faster, and fast reporting shortens everything else. A short cyber security awareness course for the wider workforce supports the detection step.
What we see in practice
Most plans we review are not wrong, they are unused. They sit in a shared drive, the contacts are out of date, and nobody has rehearsed the first hour. The first hour is where a response is won or lost, because that is when you decide what to isolate and who to tell.
We build plans around how an organization actually operates, including every site, time zone and regulator, rather than a generic checklist. Detection feeds the plan, so we link it to monitoring: a managed SOC and SIEM watching your estate gives your team the early signal the plan depends on, and a rehearsed plan gives that signal somewhere to go. We also explain findings in plain terms and leave a roadmap, so each exercise ends with specific improvements.
Our advice is simple. Name the people, test the plan, and connect it to the monitoring and testing that tells you where you are weakest.
Shirish
How Zero Through can help
A plan works best when detection, testing and response are joined up. Zero Through provides managed SOC services and managed SIEM services that watch your environment, and penetration testing and an IT security audit that show where your plan and controls are weakest. Our support is scalable and tailored to multi-location businesses in regulated sectors such as finance, healthcare, retail and law.
If you want a second pair of eyes on your plan or help building one, talk to us through Zero Through’s global IT support page. For wider context on buying this kind of service, see our buyer’s guide to cyber security managed services.
FAQ
What is the difference between an incident response plan and a template?
The plan is your organization’s actual procedures with real names, numbers and systems. A template is a blank structure to help you write it. Templates from insurers and government bodies are best practice examples, so tailor every section before you rely on it.
How long should an incident response plan be?
Short enough that people will follow it under pressure. Begin with the NCSC’s basics: contacts, escalation criteria, a one-page flowchart, a conference line and legal guidance. Then add checklists, forms and playbooks for specific incident types as you test.
How often should we test and update the plan?
Review it at least annually and after any significant incident, major change or new regulatory requirement. Run a tabletop exercise at least once a year, and refresh contact details more often, since people change roles and numbers go stale.
Who should own the plan?
One named owner, usually the head of IT or security, with sign-off from senior leadership. The Doncaster case study credits executive backing for keeping its plan current, so give the plan a senior sponsor who reviews test results.
Sources
- NCSC: Developing your IR plan
- Rochdale Borough Council: Cyber Incident Response Plan
- NCSC: Preparing for a highly disruptive cyber incident
- Aviva: Cyber Incident Response Planning
- DfE: Cyber Response Plan template
- ISO/IEC 27035-2:2023
- ICO: Personal data breaches, a guide
- Doncaster Council cyber security case study
- NCSC: Effective steps to cyber exercise creation
- Cyber Security Awareness Online
