How to Create an Incident Response Plan

Every UK business will experience a cyber security incident at some point. This is not pessimism — it is a statistical reality supported by the UK Government's own data. The annual Cyber Security Breaches Survey consistently shows that a significant proportion of UK businesses identify breaches or attacks each year, and the true figure is likely higher given that many incidents go undetected. The question is not whether your business will face a security incident, but whether you will be prepared when it happens.

An incident response plan (IRP) is a documented, rehearsed set of procedures that your organisation follows when a cyber security incident occurs. It defines who does what, in what order, using which tools and communication channels. Without a plan, incident response degenerates into panic, confusion, and ad hoc decision-making — precisely the conditions that turn a manageable incident into a catastrophic breach.

This guide provides a practical framework for UK SMEs to create an effective incident response plan, covering preparation, detection, containment, eradication, recovery, and post-incident activities, with specific attention to UK regulatory requirements including UK GDPR, the ICO's breach notification obligations, and NCSC guidance.

Why Every UK Business Needs an Incident Response Plan

The benefits of having a documented, rehearsed incident response plan are well-established and measurable. Organisations with an IRP detect and contain breaches faster, reducing the financial impact significantly. They also demonstrate compliance with regulatory expectations, which can mitigate penalties in the event of an investigation.

Regulatory requirement. Under UK GDPR, organisations must be able to detect, report, and investigate personal data breaches. Article 33 requires notification to the ICO within 72 hours of becoming aware of a breach that is likely to result in a risk to individuals' rights and freedoms. Article 34 requires notification to affected individuals when the risk is high. Meeting these obligations is practically impossible without pre-planned procedures, designated responsibilities, and rehearsed communication channels.

Financial protection. Research consistently shows that organisations with an incident response plan and team reduce the average cost of a data breach by approximately £500,000 compared to those without. Faster detection and containment directly reduce the volume of data exposed, the duration of business disruption, and the cost of remediation.

Business continuity. An incident response plan is a business continuity document. When a ransomware attack encrypts your file server at 2am on a Saturday, the plan tells your team exactly what to do: who to call, what systems to isolate, how to communicate with staff and clients, and how to begin recovery. Without a plan, critical hours are wasted establishing these basics whilst the incident worsens.

The Six Phases of Incident Response

The NCSC and international frameworks such as NIST recommend a six-phase approach to incident response. Your plan should address each phase in detail.

Phase 1: Preparation

Preparation is everything you do before an incident occurs to ensure you can respond effectively. This includes establishing an incident response team with clearly defined roles and responsibilities, deploying monitoring and detection tools (SIEM, endpoint detection, network monitoring), documenting your IT infrastructure so that responders understand your environment, establishing communication channels that will work even if your primary systems are compromised, conducting regular training and tabletop exercises, and maintaining relationships with external specialists (forensics firms, legal counsel, public relations) who may be needed during a major incident.

Your incident response team should include, at minimum, an Incident Manager (who coordinates the overall response), a Technical Lead (who directs technical investigation and remediation), a Communications Lead (who manages internal and external communications), and a Compliance Lead (who ensures regulatory obligations are met, particularly ICO notification). For most UK SMEs, these roles may be filled by existing staff members as additional responsibilities rather than dedicated positions.

Phase 2: Detection and Analysis

Detection is the process of identifying that a security incident has occurred. Many incidents are detected through automated alerting from security tools, but others are reported by staff (phishing emails, suspicious behaviour), discovered during routine checks (unusual account activity, unexpected system changes), or reported by external parties (customers, partners, law enforcement, or security researchers).

Once a potential incident is detected, it must be analysed to determine its nature, scope, and severity. Is this a false alarm or a genuine incident? What systems are affected? What data may be at risk? Is the incident ongoing or historical? This analysis phase is critical because it determines the appropriate response. A phishing email that was reported but not clicked requires a different response from an active ransomware infection spreading across your network.

Phase 3: Containment

Containment aims to limit the damage and prevent the incident from spreading further. There are two types of containment: short-term and long-term.

Short-term containment takes immediate action to stop the incident from worsening. This might include isolating affected systems from the network (unplugging network cables or disabling switch ports), blocking malicious IP addresses at the firewall, disabling compromised user accounts, or redirecting traffic away from affected services. The priority is speed — stopping the bleeding before worrying about the wound.

Long-term containment implements more sustainable controls whilst you prepare for eradication. This might include deploying temporary network segmentation, increasing monitoring on potentially affected systems, implementing additional access controls, or standing up temporary replacement systems to maintain business operations during the investigation.

Important: during containment, preserve evidence. Do not rebuild or wipe affected systems until forensic evidence has been collected. This evidence may be needed for law enforcement investigation, ICO enquiries, insurance claims, or legal proceedings.

Phase 4: Eradication

Eradication removes the threat from your environment entirely. This goes beyond simply removing malware from an infected device — it means identifying and eliminating the root cause of the incident. If the attacker gained access through a phishing email, eradication includes identifying all compromised accounts and resetting credentials. If entry was through an unpatched vulnerability, eradication includes patching the vulnerability across all affected systems. If malware was involved, eradication includes scanning all systems for indicators of compromise and removing any persistence mechanisms the attacker may have established.

Phase 5: Recovery

Recovery is the process of restoring affected systems and services to normal operation. This must be done carefully and methodically to avoid reinfection. Restored systems should be monitored closely for any signs of residual compromise. Recovery activities include restoring data from verified clean backups, rebuilding compromised systems from known-good images, gradually reconnecting systems to the network whilst monitoring for anomalies, verifying that all systems are patched and hardened before returning to production, and communicating with staff about the return to normal operations and any changed procedures.

Phase 6: Post-Incident Review

The post-incident review (also known as a lessons-learned exercise) is arguably the most valuable phase, yet it is frequently skipped by businesses eager to move on after a stressful incident. Within two weeks of the incident's resolution, gather the incident response team for a structured review covering what happened (timeline, root cause, impact), what went well in the response, what could be improved, what changes to systems, processes, or training are needed, and what updates to the incident response plan are required.

Document the findings and assign actions with owners and deadlines. This documentation also supports UK GDPR compliance by demonstrating that your organisation learns from incidents and continuously improves its security posture.

UK Regulatory Requirements

ICO Breach Notification

Under UK GDPR Article 33, if a personal data breach is likely to result in a risk to individuals' rights and freedoms, you must notify the ICO within 72 hours of becoming aware of it. Your incident response plan should include a clear process for making this assessment and, if notification is required, a procedure for submitting the report through the ICO's online breach reporting tool. The notification must include the nature of the breach, categories and approximate numbers of individuals affected, likely consequences, and measures taken or proposed to address the breach.

If the breach is likely to result in a high risk to affected individuals (Article 34), you must also notify those individuals directly, without undue delay. Your plan should include template communications for this purpose, pre-approved by legal counsel, that can be customised quickly during an incident.

NCSC Reporting

Whilst not mandatory for most private sector organisations, the NCSC encourages businesses to report significant cyber incidents through their website. The NCSC can provide guidance and, for serious incidents, direct technical assistance. Include NCSC reporting as a step in your plan for incidents involving sophisticated threat actors, critical national infrastructure, or widespread impact.

Obligation	Trigger	Deadline	Method
ICO notification	Personal data breach with risk to individuals	72 hours	ICO online breach reporting tool
Individual notification	High risk to affected individuals	Without undue delay	Direct communication (email, letter)
NCSC reporting	Significant cyber incident (voluntary)	As soon as practical	NCSC website reporting form
Law enforcement	Criminal activity suspected	As soon as practical	Action Fraud or local police
Internal documentation	All incidents, regardless of severity	Throughout incident	Incident log and post-incident report

Testing Your Incident Response Plan

An untested plan is little better than no plan at all. Regular testing reveals gaps, builds confidence, and ensures that your team can execute the plan under pressure. The most effective testing method for UK SMEs is the tabletop exercise — a facilitated discussion where team members walk through a realistic scenario, discussing how they would respond at each stage.

Run tabletop exercises at least twice per year, using different scenarios each time. Examples include a ransomware attack that encrypts your file server and backup NAS, a phishing attack that compromises the managing director's email account, a data breach discovered through a customer complaint, a disgruntled former employee downloading client data before their account was disabled, and a supply chain compromise where a trusted software vendor's update contains malware.

After each exercise, update the plan based on the gaps and improvements identified. Document the exercise and its outcomes as evidence of your organisation's commitment to incident preparedness — valuable for demonstrating compliance to the ICO, auditors, and clients.

Getting Started: Your First Incident Response Plan

Creating your first incident response plan does not need to be an overwhelming project. Start with the essentials and build from there. Document your incident response team members and their contact details (including personal mobile numbers for out-of-hours incidents). Define severity levels and the response required for each. Create a simple flowchart showing the decision process from detection through to recovery. Include template communications for the ICO, affected individuals, staff, clients, and the media. List your critical systems and the order in which they should be recovered. Include contact details for external specialists: your managed IT provider, a forensics firm, legal counsel, and your cyber insurance provider.

Keep the plan concise and practical — a 10-page document that people will actually read and follow is far more valuable than a 100-page document that gathers dust on a shelf. Store copies of the plan in multiple locations, including at least one copy that is accessible even if your entire IT infrastructure is offline (a printed copy in a secure location, for example).