- An incident response plan is primarily a people and process document. It defines who makes decisions, in what order, with what authority. Technical steps fail without that structure.
- NIST SP 800-61 defines six phases: Preparation, Detection and Analysis, Containment, Eradication, Recovery, and Post-Incident Activity. Skipping post-incident review means the same mistakes repeat.
- Store the plan somewhere accessible when your systems are down or encrypted. Print a copy. A plan that lives only on the network is unavailable during the incidents it is designed for.
- UK GDPR requires ICO notification within 72 hours of becoming aware of a notifiable personal data breach. NIS2 requires a 24-hour early warning and 72-hour notification for significant incidents.
- Tabletop exercises consistently surface the same gaps: unclear escalation paths, an incomplete external contact list, and a communication approval chain too slow for a real incident.
- Every named role needs a backup. The plan that has one owner who is unreachable when the incident occurs is the plan that will not be followed.
What an incident response plan actually is
Most UK organisations treat incident response as something to work out when something goes wrong. The result is predictable: decisions made under pressure, by people who have never faced this situation, without a clear escalation path, defined communication protocol, or recovery sequence. Containment takes longer. Evidence is lost. Notifications are late. Costs multiply.
An incident response plan documents the process your organisation follows from the moment a security incident is detected through to restoration, legal compliance, and post-incident review. It defines who does what, in what order, with what authority, and who is told what and when.
The plan is a people and process document. Who makes the call to isolate a production system? Who approves external communications? Who contacts the ICO? Who briefs the board? Who decides whether to pay a ransom? Answer those questions before an incident. The technical steps follow from them. In real incident responses, failures of process and communication outpace technical gaps.
The six phases of incident response
NIST Special Publication 800-61 (Computer Security Incident Handling Guide) is the standard framework for incident response. It defines six phases that apply across incident types, from a compromised email account to a full ransomware deployment.
What your plan must contain
A plan that cannot be executed under pressure is not a plan. The following elements are the minimum for a functional document.
Playbooks for specific incident types
A generic plan covers structure. Playbooks cover scenarios. The plan tells people what process to follow; the playbook tells them what to do for this specific type of incident. Build playbooks for the incident types most relevant to your organisation. These four cover the majority of incidents UK organisations face.
Ransomware
Detection indicators (file extension changes, mass file access events, ransom notes appearing, backup deletion activity). Immediate isolation steps: disconnect affected systems from the network without powering them off where forensic preservation is required. Verify backup integrity and recovery point before proceeding. Engage legal counsel and cyber insurer before any external communication or payment decision. Determine ICO notification trigger (was personal data accessed or encrypted?). Establish a clean communications channel outside the affected environment. The ransom payment decision must be a structured process involving legal, insurance, and leadership, not a reactive call made under pressure.
Business email compromise and payment diversion
If a fraudulent payment instruction is discovered, contact the sending bank immediately. Many UK banks operate fraud recall processes that can recover funds within hours if contacted before the receiving account is drained. Preserve all email evidence including headers before resetting accounts. Identify whether any other accounts were involved, whether forwarding rules were set, and whether any OAuth applications were granted access. Notify affected parties such as suppliers or clients if their data or payments were involved.
Unauthorised personal data access or exfiltration
Scope the affected data: what categories, how many individuals, what time period. Assess the risk to individuals. Determine whether ICO notification is required under UK GDPR. If notification is required, it must reach the ICO within 72 hours of becoming aware. High-risk breaches require direct notification to affected individuals. Preserve the evidence chain. Document the decision-making process even for breaches you determine do not require notification; the ICO expects this documentation.
Account compromise
Reset credentials and force MFA re-enrolment before returning the account to use. Audit all actions taken by the compromised account during the window of compromise: emails sent, files accessed, permissions changed, rules created, applications authorised. Check for: email forwarding rules, new administrator accounts, OAuth application grants, and any changes to authentication or conditional access policies. A compromised account used to grant persistent access elsewhere is the most commonly missed element of account compromise recovery.
Regulatory notification obligations
UK organisations face notification obligations under multiple frameworks. Containing the incident does not remove them.
Any personal data breach likely to result in a risk to the rights and freedoms of individuals must be reported to the ICO within 72 hours of becoming aware. The 72-hour clock starts when the organisation has reasonable certainty a breach has occurred, not when the full scope is known.
High-risk breaches require direct notification to affected individuals without undue delay. Document your assessment and decision for every breach, including those below the notification threshold. ICO investigations examine whether the organisation had a reasonable process, not just whether the outcome was correct.
Essential and important entities under NIS2 must provide an early warning to the competent authority within 24 hours of becoming aware of a significant incident, a more detailed initial notification within 72 hours, and a final report within one month. A significant incident is one with severe operational impact or that affects other entities or sectors. NIS2 incident reporting operates alongside, not instead of, GDPR notification where personal data is involved.
Financial entities under DORA face a similar notification regime to NIS2, with specific ICT-related incident classification thresholds and reporting to financial supervisory authorities (the FCA in the UK, DNB in the Netherlands). DORA also requires post-incident reviews and major incident root cause analysis reporting. Financial entities should map their IR plan directly to DORA's classification criteria and timelines rather than treating them as a separate compliance workstream.
Organisations frequently delay ICO notification while trying to establish the full scope of a breach. The 72-hour obligation starts from when you have reasonable grounds to believe a breach has occurred, not from when you can confirm its full scope. Notify within the window with what you know, and submit supplementary information as the investigation progresses. Late notification is cited by the ICO as an aggravating factor in enforcement decisions.
Store the plan where it will be accessible
This point is mentioned consistently in post-incident reviews and consistently ignored in advance: if your incident response plan lives on SharePoint, in your email system, or on a network drive, it may be unavailable precisely when you need it.
A ransomware attack that encrypts file servers and cloud-synced drives also encrypts the incident response plan stored there. A plan that cannot be accessed during an incident is not a plan. Store a current copy offline, in print, and in a location known to all response team members. Include the external contact list in the printed version. Consider storing it with your cyber insurance documentation.
Testing the plan
An untested plan is a set of assumptions. Three levels of testing exist, each appropriate for different stages of programme maturity.
The most common findings from tabletop exercises: the escalation path is unclear when the primary contact is unavailable, the external contact list is incomplete or has outdated numbers, the communication approval chain has too many steps for a fast-moving incident, and team members do not know where the plan is stored.
Common mistakes
Single point of failure in ownership. A plan with one named owner who is unreachable during an incident defaults to improvisation. Every role needs a backup. The backup needs to know they are the backup.
The plan stops at containment. Many organisations document detection through containment and treat recovery as obvious. The recovery sequence, the monitoring requirements during recovery, and the conditions for returning systems to production all need to be explicit. Recovery without monitoring is an invitation for re-infection.
No communication template. Drafting customer, supplier, or media communications during an active incident, under legal scrutiny and time pressure, produces inconsistent and legally problematic output. Pre-drafted templates reviewed by legal counsel reduce both the time and risk involved.
The plan was never tested. A plan written once and filed away reflects the environment as it was when it was written. People, systems, suppliers, and regulatory obligations change. Test it, or you cannot know how your team will actually perform. Update it, or it describes an organisation that no longer exists.
Backup access is not verified. The most critical element of ransomware recovery is a backup that can be restored under time pressure to a usable state. Many organisations have backups they have never restored. A backup that has never been tested is an assumption, not a recovery capability.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years, including senior roles at Microsoft, ING, IPsoft, PPHE and more. View full profile