How to Create a Cyber Incident Response Plan
A step-by-step outline of what to actually put in an incident response plan, in what order, so you end up with something your team will genuinely use.
1. Start with roles, not technology
Before writing a single technical step, decide who your Incident Lead is, who has authority to make business-impact decisions (disconnecting a system, informing customers, paying a ransom), and who your technical lead is if that's a different person. Write down a backup for each role - incidents don't wait for someone to be back from holiday.
If you have a Data Protection Officer, legal adviser, or cyber insurer, name them here too, along with how to reach them out of hours.
2. Define severity before you need it
Not every incident deserves the same response. A single phishing email caught before anyone clicked it is not the same as ransomware spreading across your file server. Build a simple severity scale - even four levels is enough - based on factors like how many systems are affected, whether personal data is involved, and whether the threat is still active.
Deciding this in advance means that during an incident, someone can say 'this is a SEV 2' and everyone immediately knows roughly what that means for urgency and who needs to be told.
3. Write the lifecycle steps in plain language
For each stage - identification, containment, investigation, eradication, recovery, review - write short, concrete actions rather than abstract principles. 'Isolate the affected device from the network without switching it off' is useful. 'Ensure appropriate containment measures are implemented' is not.
Where a decision genuinely depends on circumstances (for example, whether to disconnect a system from the network or shut it down entirely), say so explicitly and explain the trade-off, rather than pretending there's always one right answer.
4. Build in a record-keeping mechanism
A plan tells people what to do; it doesn't record what actually happened. You need somewhere to log the incident timeline, decisions made, evidence collected, and communications sent - usually a structured workbook or spreadsheet rather than the plan document itself. This record matters for insurance claims, regulatory notifications, and the post-incident review.
5. Add scenario playbooks for your most likely incidents
A generic lifecycle is useful, but a phishing compromise and a lost phone need different immediate steps. Most SMEs are best served by playbooks for: phishing/compromised accounts, ransomware/malware, a suspected personal-data breach, business email compromise/payment fraud, and lost or stolen devices - these cover the large majority of incidents small businesses actually experience.
6. Don't forget communications and reporting
Decide in advance what an employee holding statement, a customer notification, and a management update look like, so nobody is drafting sensitive communications from scratch mid-incident. Also record your reporting obligations - insurer notification requirements, and when a personal-data breach may need to be assessed against UK GDPR.
Building this yourself vs. starting from a template
All of the above is genuinely buildable from scratch - it will just take a few days of focused work to get right, and it's easy to miss a step under time pressure. If you'd rather start from something already structured this way, our Cyber Incident Response Plan & Toolkit covers all six steps above out of the box, with the workbook, playbooks and communication templates already built.