Cyber Incident Response Plan Template for UK Organisations

Key Takeaways

• A cyber incident response plan template gives you roles, contacts and first-hour actions before an attack, not during one.
• Notifiable personal data breaches must reach the ICO within 72 hours of becoming aware, and every breach must be recorded.
• The NCSC and UK law enforcement do not encourage paying ransoms, so decide your policy in advance.
• Test the plan with a tabletop exercise at least once a year and after major changes.
• Use the free interactive template on this page to complete, save, download and print your plan.

A cyber incident response plan template is a pre-written document that tells your organisation who does what, in what order, when a cyber attack or data breach is under way. A usable one covers contacts, severity levels, the first-hour actions, playbooks for likely incidents, notification decisions and a log. This guide explains each part and includes a free interactive cyber incident response plan template you can complete, save and print.

Most UK organisations do not struggle because they lack tools. They struggle because, at 7pm on a Friday with files encrypted, nobody knows who can authorise shutting down a server, who phones the insurer, or whether the ICO clock has started. A plan answers those questions while people are calm.

The advice below follows the NCSC incident management guidance and the ICO guide to personal data breaches, checked as at October 2026. It is written for SMEs and mid-market organisations that may not have a dedicated security team, and it reflects how incidents are typically handled by a managed IT provider such as NetMonkeys, a Microsoft Solutions Partner with offices in Manchester, Nottingham and London.

What is a cyber incident response plan?

A cyber incident response plan is a documented set of decisions, roles and steps that your organisation follows when a security incident is suspected or confirmed. It exists so that the first hours of an incident are run by process rather than improvisation.

How is it different from a business continuity or disaster recovery plan?

An incident response plan deals with the security event itself: detecting, containing, removing and learning from it. Business continuity keeps the organisation operating, and disaster recovery restores systems. The NCSC incident management guidance says incident response should be linked to disaster recovery, business continuity and crisis management plans, so the three documents should refer to each other rather than repeat each other.

• Incident response: who decides, what is contained, what evidence is kept, who must be told.
• Business continuity: how teams keep serving customers while systems are down.
• Disaster recovery: the order and method for restoring systems and data.

What counts as a cyber incident?

A cyber incident is any event that harms, or could harm, the confidentiality, integrity or availability of your systems or data. The NCSC process guidance groups incidents into seven categories: malicious code (including ransomware), denial of service, phishing, unauthorised access, insider activity, data breach and targeted attack. Your plan does not need seven separate documents. It needs one core plan and short playbooks for the few scenarios most likely to hit you.

Does a small organisation really need one?

Yes, and it can be short. The NCSC's central point is that good preparation is what lets you deal well with an incident, and that no security is perfect, so incidents should be expected. A two-page plan that is current and printed beats a forty-page document nobody can find. If you are starting from a low base, our guide to cybersecurity best practices covers the controls that make incidents less likely and less damaging.

↑ Back to Contents

What should a cyber incident response plan contain?

A basic plan should contain key contacts, escalation criteria, a simple process covering the whole lifecycle, a conference line and guidance on legal and regulatory involvement. That list comes from the NCSC guidance on response processes, and it is a sound minimum for any organisation.

What are the essential ingredients?

• Contact sheet: the response team or provider, IT, senior management, legal, communications, HR and your insurer. The NCSC advises at least two contact methods and two or more people or groups for each contact, because the person you need will sometimes be on holiday or unreachable.
• Escalation criteria: when an event becomes an incident, and who is told at each severity level, including named deputies.
• Lifecycle process: discovery through to close-down, ideally as one page.
• Out-of-band communication: a conference number and a channel that does not rely on the systems that may be compromised.
• Legal and regulatory triggers: when to involve legal advisers, HR and how evidence is captured.

What should you add once the basics are in place?

Quick checklists, tracking and post-incident forms, and playbooks for specific incident types. The NCSC suggests starting with the three to five most likely and highest-risk scenarios for your business and, at a minimum, covering the first few hours: who to contact, how to triage, initial containment and evidence retention.

What do you need to know about your own environment first?

You cannot contain what you cannot find. Before writing a word, list your critical systems, where personal data sits (including data held by suppliers), where backups live and who holds administrator rights. If you cannot answer those questions, a cyber security audit or a lighter cybersecurity assessment is a sensible first step, because the plan is only as accurate as that inventory.

↑ Back to Contents

Who should be on the incident response team?

The team should have a named incident lead with authority to make decisions, a technical lead, a communications lead, a legal or data protection contact and a senior sponsor who can approve major business decisions. In a small organisation one person may hold two roles, but every role should have a named deputy.

What does each role do?

Why does the NCSC stress a single coordinator?

The NCSC says a central coordinator must correlate all findings and plan actions, whoever is involved. Without one, three people reset the same passwords while nobody tells the customers. It also advises identifying who has authority to take decisions with major business impact and pre-authorising the technical team to take specific early containment actions where the risk justifies it. Write those pre-authorisations into the plan, for example isolating a single infected laptop without waiting for approval.

Where does an outsourced IT provider fit?

If you use a managed provider, they are normally the technical lead, but they should not be the only name on the plan. Confirm in writing what their out-of-hours cover includes, whether it extends to incident response or only to ordinary support, and who calls whom. Our guide to outsourced versus in-house IT explains where responsibilities usually sit, and a 24/7 IT helpdesk is often the first line that spots something wrong outside office hours.

For serious incidents, the NCSC recommends that UK organisations of any size use an NCSC-assured cyber incident response provider. Agree who that would be before you need them, and record the number on your contact sheet.

↑ Back to Contents

How do you rate the severity of a cyber incident?

Rate severity against three questions: is availability affected, has confidentiality been lost, and could integrity be compromised? The NCSC uses these three factors, and recommends a severity matrix so that response priority and escalation are set by agreed rules rather than by whoever shouts loudest.

What does a four-level matrix look like?

The NCSC's example uses four levels. The thresholds below are the NCSC's illustration, and the guidance says to adapt them, including any financial thresholds, to your own organisation.

How should you adapt it for a smaller organisation?

Percentages of staff are awkward when you have twelve people. Use plain descriptions instead: "no one can log in", "finance cannot process payments", "customer records may have been copied". Each level should name who is told, how fast, and who may stand the incident down.

What mistakes do organisations commonly make?

• Rating by technical complexity rather than business impact. A simple phishing compromise of a finance mailbox can outrank a noisy but harmless malware alert.
• Setting no re-rating rule. Severity should be reviewed as facts emerge, and the NCSC notes that actions should be re-prioritised and escalated or de-escalated as the situation changes.
• Forgetting data held by suppliers. Your obligations can follow the data, wherever it sits.

Our overview of common cybersecurity breaches helps when deciding which scenarios belong at which level.

↑ Back to Contents

What are the phases of cyber incident response?

A practical plan uses six phases: prepare, detect, contain, eradicate, recover and review. The NCSC describes the response itself as analyse, contain or mitigate, remediate or eradicate, and recover, with lessons learned afterwards. Both views describe the same cycle, and your template can use either.

Phase 1: How do you prepare?

Preparation is the work done before anything goes wrong: the plan, the contact sheet, tested backups, logging, pre-agreed authority and a list of critical systems. It is where most of the value sits. Preparation also includes controls that reduce the likelihood of an incident, such as the five technical themes in Cyber Essentials.

Phase 2: How do you detect and triage an incident?

Detection comes from monitoring alerts, user reports, supplier notifications or an external warning. Triage then answers three questions: what happened, how severe is it, and which category is it. Staff need a simple way to report something odd without fear of blame, because late reporting is a common reason small incidents become large ones. Endpoint detection and response, such as managed EDR, shortens the time between compromise and alert.

Phase 3: How do you contain an incident?

Containment limits the damage once it is safe to act. Typical actions are blocking malicious activity, isolating systems and resetting accounts. The NCSC advises weighing the consequences of each action and considering whether the attacker might react to it. Disconnecting a device from the network is usually safer than powering it off, because memory and logs may hold evidence, though your technical lead should confirm that for each case.

Phase 4: How do you eradicate the threat?

Eradication removes the attacker's access fully, often through coordinated actions so they cannot simply return through a second route. That means removing malware, closing the entry point, rotating credentials and revoking sessions. The NCSC suggests confirming success, possibly through a monitoring period, before moving on.

Phase 5: How do you recover?

Recovery returns systems to business as usual using clean systems and trusted data. Restore in the order of business priority, verify backups are not themselves infected, and keep extra monitoring in place. Remaining legal, regulatory and communications tasks are handled in this phase too.

Phase 6: How do you review what happened?

Hold a review within a few weeks. The NCSC suggests asking which security improvements could have prevented or detected the incident sooner, whether logs or data were missing, and whether the right people were empowered to decide. Record actions with owners and dates, and update the plan.

↑ Back to Contents

Who must you tell after a cyber incident, and when?

If personal data is affected, you must report a notifiable breach to the ICO without undue delay and no later than 72 hours after becoming aware of it. Beyond that, you may need to tell affected individuals, your insurer, the police, your regulator and customers, depending on what happened.

What is the ICO 72-hour rule?

According to the ICO guide to personal data breaches, you must report a notifiable breach within 72 hours of becoming aware, and explain any delay if you go beyond it. You do not need to report if the breach is unlikely to result in a risk to individuals' rights and freedoms, but you must document why. If you cannot establish all the facts in time, you can report in stages, provided the first notification is on time.

The ICO report should describe the breach, including the approximate number of people and records affected where possible, give a contact point such as your DPO, set out the likely consequences and describe the measures taken or proposed. Prepare these headings in advance.

When must you tell the people affected?

Where the breach is likely to result in a high risk to individuals, the ICO says you must tell them directly and without undue delay, in plain language, with a contact point, the likely consequences, the measures taken and practical advice such as resetting passwords.

Do you have to record breaches you do not report?

Yes. The ICO states that all personal data breaches must be recorded, whether or not they are reported, including the facts, the effects and the remedial action. The decision log in the template below serves this purpose.

Should you report to Action Fraud or the NCSC?

Report cyber crime to the police through Action Fraud. Its Action Fraud contact page states that organisations under a live cyber attack, which may be at risk of losing data, can call 0300 123 2040 at any time, 24 hours a day, while other reports can be made online or through web chat. The NCSC also directs UK organisations to its incident reporting routes through its NCSC ransomware guidance. Check the current routes at the time you report, as government reporting services are reorganised from time to time.

Who else might need to know?

• Your cyber insurer: many policies require prompt notification and may offer a response panel. Read the conditions before you spend money on recovery. See our guide to cyber insurance.
• Legal advisers: particularly where contracts, privilege or employee matters are involved.
• Sector regulators and funders: financial services, charities, health and public sector bodies may have their own reporting expectations. Confirm yours and record them in the plan.
• Customers and suppliers: contract terms may require notice within a set period.

The ICO also notes that some regimes use different deadlines, for example communications providers under PECR. If you are in a regulated sector, such as financial services, add those duties to the plan.

↑ Back to Contents

What are the decision points in a ransomware incident?

The main ransomware decision points are: isolate now or investigate first, whether backups are intact, whether to pay, whom to notify, and when it is safe to restore. Decide who owns each of these before an attack, because they will otherwise be made under pressure.

Should you pay the ransom?

The NCSC ransomware guidance says the NCSC and UK law enforcement do not encourage, endorse or condone paying ransoms. It warns that payment does not guarantee you will get your data back, may leave your systems infected, funds criminal groups and makes you more likely to be targeted again. Your plan should state that payment is a board-level decision, taken only after legal advice and with your response provider and insurer involved, and that nobody else may make contact with the attackers.

What should happen in the first hours?

1. Identify and isolate affected devices from the network without wiping them.
2. Confirm which backups are unaffected and keep them disconnected.
3. Move the response team to out-of-band communication.
4. Engage your incident response provider and notify your insurer.
5. Establish whether data was copied, because attackers often threaten to publish it, and start the ICO assessment.
6. Report to Action Fraud and the NCSC through their current routes.

How do you know it is safe to restore?

Restore only when you understand how the attacker got in and have closed that route, otherwise they may simply return. Rebuild or verify clean systems, restore in business-priority order and monitor closely. The NCSC stresses keeping a recent offline backup of your most important files. If your backups live in the same environment an attacker can reach, they are exposed too. Cloud-hosted estates deserve the same scrutiny, and a managed cloud provider can confirm what immutable or separated backup options exist.

What about phishing and account compromise?

Many ransomware incidents begin with a compromised account. Your playbook for a suspected phish should cover resetting the password, revoking active sessions, checking mailbox forwarding rules and reviewing sign-in activity. Our explainer on what phishing is and how to prevent it is useful for staff awareness material.

↑ Back to Contents

How should you handle evidence and communications?

Keep a careful record of decisions, actions taken and data captured, and communicate through pre-agreed channels with approved messages. The NCSC says this record matters to regulators and courts, particularly where a data breach or criminal activity is involved.

What evidence should you preserve?

• Logs from firewalls, servers, Microsoft 365 and endpoint tools, exported before retention windows overwrite them.
• Affected devices, left isolated rather than wiped, until the technical lead decides.
• Copies of phishing emails, ransom notes and attacker contact details.
• A timestamped list of who did what, kept in the decision log.

If legal proceedings are possible, the NCSC advises engaging law enforcement and following evidential handling guidance. Record what data was captured and what was missing. Include evidence-retention steps in each playbook so the technical team does not have to remember them under stress.

How do you communicate during an incident?

Assume email and chat may be compromised. Agree a secondary channel, a conference line and a printed phone list. The NCSC recommends planning secure or alternative channels for sensitive incidents and outages of email, phone or network systems, holding regular update meetings and escalating serious incidents to senior management.

What should staff, customers and the media be told?

Tell staff what to do and what not to do, such as not switching devices back on and not discussing the incident on social media. Prepare holding statements in advance for customers and the press that say what you know, what you are doing and where to get updates, without speculating about cause or attackers. Only the communications lead issues them. Customer messages after a personal data breach should follow the content the ICO sets out for notifying individuals.

Who looks after the team?

Incidents run long. Plan shifts and handovers, and name someone responsible for the welfare of the people doing the work. Fatigue causes mistakes, and the NCSC lists staff wellbeing as part of the response alongside communications planning.

↑ Back to Contents

How do you test a cyber incident response plan?

Test the plan with a tabletop exercise: gather the response team, walk through a realistic scenario, and see whether the plan answers each question as it arises. A first exercise takes about an hour or two and routinely exposes missing phone numbers and unclear authority.

What does a simple tabletop exercise involve?

1. Pick a scenario from your likely risks, for example ransomware on a file server on a Friday evening.
2. Release facts in stages ("the finance team cannot open files", "a ransom note appears", "a supplier reports customer data posted online").
3. At each stage ask who decides, who is called and where it is written down.
4. Record gaps and assign owners and dates.
5. Update the plan and repeat at least annually and after major changes.

What does a worked example look like?

The following is an illustrative scenario with assumed facts, not a real case. A 60-person professional services firm finds, at 6.40pm, that its shared drive files have changed extension and a note demands payment.

What else should you test beyond the discussion?

• Backups: restore a sample of files and a full system, and record how long it takes.
• Contact details: call the numbers. Out-of-date lists are among the most common findings.
• Detection: confirm that alerts reach someone out of hours.
• Technical depth: larger organisations may add simulated attacks, which should be agreed with your provider and carefully scoped.

Review the plan at least annually and after any significant change, such as a new supplier, a cloud migration, a merger or a change of IT provider. If you are changing provider, our IT support handover checklist helps keep the plan's contact and access information accurate.

↑ Back to Contents

Where can I get a free cyber incident response plan template?

You can complete the free interactive cyber incident response plan template below, directly on this page. It has eight sections: plan control, response team and contacts, severity matrix, critical systems and data, a first-hour checklist, playbooks, a notification decision record and a decision and timeline log. You can save your answers in your browser, download the plan and print it.

How should you use the template?

1. Complete the plan control, contacts and severity sections first. They take the most thought and are used in every incident.
2. List your critical systems, data and backup locations with the people who run them.
3. Adapt the first-hour checklist and playbooks to your environment, removing steps that do not apply.
4. Print one copy for the incident lead and one for the deputy, and store a digital copy outside your main network.
5. Use the notification and timeline sections during a real incident or an exercise.

What does the template deliberately leave out?

It does not replace legal advice, your insurer's conditions or sector-specific rules. Your own regulator or funder may require notification beyond the ICO, so complete the sector regulator field. For organisations wanting independent help to build and test the plan, our small business cybersecurity service is a practical starting point.

The template follows the structure of the NCSC's plan ingredients, severity triage and response stages, and the ICO's reporting requirements, as at October 2026.

↑ Back to Contents

Conclusion: Is your cyber incident response plan ready?

A cyber incident response plan template only helps if it is completed, stored somewhere reachable and tested. Start with the contact sheet and the severity matrix, add the first-hour checklist, and run a tabletop exercise within a few weeks. Revisit the plan every year and whenever your systems, suppliers or people change.

• Name an incident lead and deputy, and pre-authorise early containment.
• Know the ICO 72-hour deadline and keep a record of every breach.
• Decide ransomware payment policy before an attack, not during one.
• Test restores and the plan itself at least once a year.

If you want help completing the plan, testing backups or running an exercise, our managed IT support team can work alongside yours. Speak to us through the NetMonkeys contact page, and see the cybersecurity framework guide for how the plan fits a wider programme.

↑ Back to Contents

Frequently Asked Questions (FAQs)

↑ Back to Contents