- An incident response plan gives the team a decision framework when cognitive load is highest. Without one, every call about who does what and who can authorise what happens mid-incident, under pressure, with incomplete information.
- The six phases are Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. Each has distinct activities, owners, and outputs.
- UK GDPR requires ICO notification within 72 hours of becoming aware of a personal data breach. NIS2 requires an early warning to the competent authority within 24 hours. Both clocks run from when you become aware, not when the incident started.
- Playbooks are scenario-specific extensions of the IR plan covering ransomware, business email compromise, credential theft, data breach, and supply chain compromise as a minimum.
- An untested plan is an assumption. Run a tabletop at least annually. Test backup recovery against your maximum tolerable downtime every quarter.
- The IR plan belongs in Phase 1 of your cybersecurity roadmap, before the programme is mature. You need a response capability before you need a fully built security programme.
What an incident response plan is for
A security incident puts the response team under simultaneous pressure from multiple directions: technical triage, legal exposure, executive escalation, potential ICO notification, customer communication, media risk, and business continuity decisions, all at once. The incident response plan does not remove that pressure. It removes the need to make structural decisions under it.
Who decides to isolate a compromised server? Who can authorise paying external forensics on a weekend? Who approves the customer email? Who contacts the ICO? Those questions have one right time to be answered: during planning, before the incident. A documented IR plan, tested by the team that will use it, converts those decisions into procedures. That is the return on investment.
The plan does not need to be long. A ten-page document that the IR team has read, rehearsed, and can locate without relying on the compromised systems is worth more than a 60-page document that lives in a SharePoint folder nobody has opened.
The six phases of incident response
The NIST incident response lifecycle divides response into four phases. Most IR practitioners extend this to six to give Containment and Eradication separate treatment, which is more useful operationally. The six phases below reflect standard practice for UK organisations.
Building the incident response team
The IR team is not a standing team that sits waiting for incidents. It is a list of named individuals with defined roles who are activated when the response process is triggered. For most UK organisations outside the enterprise segment, the same people carry multiple roles.
Every role needs a named primary and a named backup. Incidents do not schedule themselves around holiday calendars. The contact list must include personal mobile numbers and an out-of-hours escalation path that does not depend on corporate email, which may be compromised.
Your IR plan should include pre-identified contact details for: your cyber insurer's incident response hotline (available 24/7 for most policies), an external forensics firm if your internal team lacks the capability, your managed security provider if applicable, the NCSC's incident reporting service, and the ICO's breach notification portal. Identifying these contacts mid-incident wastes time and adds pressure you do not need.
Regulatory notification requirements
UK regulatory notification requirements are time-bound and run from when you become aware of the incident, not from when the incident began. A breach that has been running for three months before detection still triggers a 72-hour notification clock the moment you discover it. The plan must include a procedure for assessing whether a notification obligation has been triggered, and who is responsible for making that assessment and filing the report.
| Regulator | Trigger | Deadline | Who files | What's required |
|---|---|---|---|---|
| ICO | Personal data breach likely to result in risk to individuals | 72 hours | Data controller (DPO or nominated lead) | Nature of breach, categories and approximate number of records affected, likely consequences, measures taken or proposed. Can notify in phases if full information is not yet available. |
| NCSC / CA (NIS2) | Significant incident affecting network or information systems of an essential or important entity | 24 hours early warning; 72 hours full notification; 1 month final report | Named NIS2 point of contact | Early warning: significant incident, suspected malicious cause. Full notification: initial assessment, severity, indicators of compromise. Final report: root cause, actions taken, cross-border impact. |
| FCA / PRA | Operational incident that has or may have a significant adverse impact | As soon as reasonably practicable; no specific hour limit but regulators expect prompt notification | Compliance or nominated MLRO | Nature of incident, actual or potential impact, actions being taken. Follow-up reports as situation develops. |
The 72-hour window under UK GDPR is consistently misunderstood. It does not require a complete picture of the breach. Article 33(4) allows notification where full information is not available, with the instruction to provide additional information as it becomes available in phases. Waiting until the investigation is complete before notifying risks a regulatory finding of late notification. The DPO or nominated lead should make an initial assessment within the first few hours of an incident and file a holding notification if there is any possibility that personal data has been compromised.
Incident playbooks
A playbook is a scenario-specific checklist attached to the IR plan. Each playbook covers one incident type and records: the detection indicators that suggest this type of incident, the first five actions in the first 30 minutes, the containment steps in sequence, evidence preservation requirements, the regulatory notification checklist for this scenario, communication templates, and the recovery procedure.
Five playbooks cover the incidents most likely to affect UK organisations in 2025 and 2026:
| Incident type | Key detection indicators | Immediate containment priority | Notification trigger |
|---|---|---|---|
| Ransomware | Files with unknown extension, ransom note on desktop, EDR alert for mass file encryption, sudden spike in I/O activity | Isolate affected systems from the network immediately. Do not power off (preserves memory forensics). Identify the patient zero host before restoring from backup. | ICO if personal data encrypted or exfiltrated. NCSC if NIS2-scoped entity. Cyber insurer within hours. |
| Business Email Compromise | Fraudulent payment instruction received, supplier reports non-payment of invoice that was redirected, mail rule forwarding to external address, mailbox login from unusual geography | Freeze any pending payment instruction. Contact the receiving bank immediately to attempt recall. Identify the compromised mailbox and revoke all active sessions. | ICO if personal data was accessed in the mailbox. Notify finance team and executive immediately. Consider reporting to Action Fraud. |
| Credential Theft / Account Takeover | Password spray alert, impossible travel login alert, MFA fatigue reports from a user, unfamiliar OAuth app granted access to corporate data | Force password reset and revoke all active sessions for the compromised account. Check for persistence mechanisms: new mail rules, OAuth app grants, added recovery contacts, or new MFA methods. | ICO if compromised account had access to personal data. Review scope of data access before determining notification obligation. |
| Data Breach / Exfiltration | Large outbound data transfer alert, DLP alert for sensitive file upload, extortion email referencing company data, third-party reports receiving your customer data | Identify the exfiltration path and close it. Preserve logs before they rotate. Engage legal to assess privilege before conducting interviews. | ICO notification very likely if personal data confirmed. NIS2 notification if scoped entity. Affected individuals if high risk of harm. |
| Supply Chain Compromise | Notification from a software vendor of a compromised update, unusual behaviour from a trusted application, MSP reports unauthorised access via their tooling | Isolate affected systems. Suspend the supplier's access. Do not update the software further until the vendor confirms a clean build. Begin investigation of what the supplier had access to. | ICO if personal data was accessible via the supplier's access. Notify cyber insurer. NCSC if significant impact to critical services. |
Evidence preservation
Digital evidence collected during an incident has two purposes: informing the technical investigation and supporting potential legal or regulatory proceedings. The two have different standards. Evidence that is admissible in court or regulatory proceedings must be collected and handled in a way that demonstrates its integrity. Improvised evidence collection undermines both.
The plan should specify: who is authorised to collect forensic evidence, what tools are approved for collection, how evidence is stored and chain-of-custody documented, and at what point an external forensics firm should be engaged. For most UK organisations, that threshold is any incident with realistic potential for litigation, regulatory action, or criminal investigation.
Do not reimage or restore compromised systems before forensic capture of memory and disk images. The evidence is gone once the system is wiped. Engage your forensics contact before the decision to restore is made.
Communication during an incident
Communication failures during incidents are as damaging as technical failures. Two separate problems arise. Internal communication breaks down when the response team operates across too many channels simultaneously, people escalate to executives without a full picture, or the same update goes through different people with different framings. External communication goes wrong when someone speaks to the press, customers, or regulators without authorisation.
Internal communication
Designate one channel for incident response coordination and one for executive updates. Keep them separate. The coordination channel is for technical detail; the executive channel is for impact and decisions. Appoint the scribe to provide timed updates to the coordination channel. The Communications Lead synthesises these into executive briefings at defined intervals, not on demand.
External communication
Pre-approved communication templates in the plan save time and prevent errors. Templates should exist for: customer notification (personal data breach), supplier notification (if the incident affects the supply chain), press holding statement, and ICO notification. Templates are not scripts, they are starting points. Legal review before release is required for anything that goes outside the organisation.
The question is never whether to communicate during an incident. It is how to communicate accurately, within the appropriate window, to the right people, without making the legal position worse.
Testing the plan
An untested IR plan is a document. A tested IR plan is a capability. The difference is significant when a real incident occurs at 2am on a Friday.
Tabletop exercises
A tabletop exercise walks the IR team through a realistic incident scenario without any real systems being affected. A facilitator presents a scenario (ransomware has encrypted your file server, it is a Saturday morning, and the on-call IT person has just called it in). The team works through their decisions in real time: who do you call, what do you isolate, when do you notify the ICO, who tells the CEO, do you pay the ransom?
Tabletops surface the decisions that have not been made in advance, the contacts that are missing from the list, and the authority gaps where nobody knows who can approve what. They take half a day and are the most cost-effective security investment available. Run one annually as a minimum. Update the IR plan within two weeks of each exercise with the findings.
Technical simulations
A technical simulation tests specific response procedures against real systems in a controlled environment. Restore a system from backup and time it against your maximum tolerable downtime. Run a simulated phishing campaign and test the detection and escalation procedure. Validate that your EDR tooling actually triggers the alert you expect it to when a known malicious tool is executed on an endpoint. Technical simulations confirm that the tools work as expected and that the team knows how to use them under pressure.
Backup recovery tests
Test backup recovery quarterly. Not verifying that the backup exists, but actually restoring a system or dataset from backup and confirming that it works. Validate the recovery time against your maximum tolerable downtime. If the restore takes eight hours and your MTD is four hours, you have a gap that needs resolving before an incident, not during one.
Keeping the plan current
An IR plan that is not updated becomes a liability. It contains outdated contact numbers, references systems that no longer exist, and assigns roles to people who left the organisation. A plan that the team knows is out of date will not be followed under pressure.
Review the plan on three triggers: after every incident (within two weeks), after every tabletop exercise (within two weeks), and annually as part of the broader security programme review. The annual review checks that all contacts are current, that the regulatory notification requirements reflect current legislation, that the asset inventory referenced in the plan matches the actual environment, and that any organisational changes (new systems, new business units, new suppliers) are reflected.
Assign the plan a named owner with a defined review date. When that date passes without a review, the plan is overdue. Treat it with the same governance discipline as your cybersecurity roadmap.
The incident response plan is a Phase 1 deliverable in your cybersecurity roadmap. It should exist and be tested before your broader security programme is mature, because you need a response capability before you need a complete security programme. If you do not yet have a documented IR plan, treat it as the highest priority item in your security backlog, ahead of tooling, ahead of policy, ahead of training. You can improve everything else while the plan is in place. You cannot improve your response to an incident that happens before the plan exists.
