- 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 Revision 3 (April 2025) now places incident response inside the NIST Cybersecurity Framework 2.0. For day-to-day procedures, most teams still work through six operational steps, from Preparation to Post-Incident Activity. Skipping the 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.
- Notification deadlines depend on where you operate and whose data is affected: 72 hours to the regulator under UK and EU GDPR, three working days in Brazil, and four business days for a material incident at a US-listed company. One incident can start several clocks at once, so the plan should list every regime that applies to you.
- 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 is
Most 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. Before an incident, it should settle who can take a production system offline, who approves external statements, who contacts the regulator, who briefs the board and who decides whether to pay a ransom. The technical steps follow from those answers. When a real incident response goes wrong, the cause is more often process and communication than a technical gap.
Incident response documentation usually comes in three layers. An incident response policy is short and sets the rules: who holds authority, what staff must report and what the organisation requires. The plan, which this guide covers, explains how you activate a response, coordinate it, escalate, communicate and recover. Playbooks hold the actions for one type of incident, such as ransomware or a supplier outage. Keep detailed technical procedures in the playbooks, or the plan grows too long to use in a crisis.
The six phases of incident response
NIST Special Publication 800-61 is the most widely used reference for incident response. Revision 2 (2012) described a four-phase lifecycle: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. Revision 3, published in April 2025, replaces it. It places incident response inside the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond and Recover) and treats preparation and improvement as continuous risk management rather than one-off phases.
For operational procedures, most practitioners still work through the six steps below, with containment and eradication handled separately. They apply across incident types, from a compromised email account to a full ransomware deployment.
Eight steps to build the plan
Each step below produces something you can point to. If a step has no output yet, that part of the plan does not exist.
Assembled, the plan document usually runs in this order:
- Purpose, scope and the plan owner
- Roles, deputies and decision rights
- Severity levels and escalation
- The first-hour checklist
- Communication and notification procedures, including the notification matrix
- Playbooks, or a list of them with where each is kept
- Recovery priorities and the handoff to disaster recovery and business continuity
- Closure criteria and the post-incident review
- Appendices: the contact sheet, the critical supplier register, message templates and a blank decision log
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.
| Level | Examples | Response target | Who is told |
|---|---|---|---|
| P1 Critical | Ransomware spreading; confirmed theft of personal or sensitive data; a critical service down; compromise of an administrator account or the identity system | Immediately, at any hour | Incident lead, executive sponsor, legal and data protection lead; board briefed the same day |
| P2 High | Compromise confirmed but contained to one system or account; suspected data exposure under investigation; an incident at a critical supplier that affects you | Within 1 hour, at any hour | Incident lead and technical lead; data protection lead if personal data may be involved |
| P3 Medium | Malware caught on one device; a phishing click where the password was reset at once; a policy breach with no sign of harm | Within 4 working hours | Security or IT team; incident lead informed |
These are illustrative internal targets, not legal deadlines. Severity can go up or down as evidence comes in; record each change and the reason in the decision log. Whether a regulator must be told is a separate test against each law's own threshold. A P3 can still be a reportable personal data breach, for example an email containing health information sent to the wrong person.
A first-hour checklist
The first hour sets up everything that follows. Treat this list as things to start, not a strict sequence. Containment may need to happen in the first few minutes, while evidence preservation and the notification assessment run alongside it, and some items will take well over an hour to finish. Skip what does not apply to the incident in front of you; the incident lead's job is to make sure every item that does apply has an owner.
- Start the decision log: when the incident was spotted, who reported it and what they saw
- Appoint the incident lead and confirm who deputises
- Assign a first severity level, knowing it may change
- Move the response team to the out-of-band channel if email, chat or single sign-on could be compromised, and confirm each person's identity there
- Contain without destroying evidence: disconnect affected systems from the network rather than powering them off or wiping them
- Preserve logs that overwrite quickly, such as firewall, VPN, identity provider, email audit and endpoint detection logs
- Protect the backups: confirm they are offline or immutable, and cut the backup system's network access if it may be compromised
- Call your cyber insurer's incident line and legal counsel; many policies require you to notify them before you engage outside responders
- If personal data may be involved, record the time you became aware and start the notification assessment
- Brief the executive sponsor: what is known, what is not, what has been done and when the next update is due
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 five cover the scenarios most 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. Establish whether data was copied out before encryption, because many ransomware groups now steal data as well, which changes both the notification assessment and the extortion risk. Restore into a known-clean environment, not onto systems that may still hold attacker tooling. Engage legal counsel and cyber insurer before any external communication or payment decision. Determine whether a breach notification is triggered (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 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. Then reset the password, revoke active sessions and refresh tokens, and check the registered MFA methods, because attackers often add their own; where compromise is suspected, remove them and have the user register again. Identify whether any other accounts were involved, whether forwarding or inbox 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.
Personal data breach
A personal data breach is wider than theft. It covers personal data sent to the wrong person, a lost or stolen laptop, records altered or deleted without authority, and data made unavailable, for example when ransomware encrypts the only copy. Scope the affected data: what categories, how many individuals, what time period. Assess the risk to individuals. Determine whether you must notify a data protection regulator, and which one. Under UK and EU GDPR the notification must reach the regulator within 72 hours of becoming aware; other countries set different clocks, summarised below. 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; regulators expect this documentation.
Account compromise
Before returning the account to use, reset the password, revoke all active sessions and refresh tokens, and remove and re-register the MFA methods where compromise is suspected. A password reset on its own may leave existing sessions working. 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 and privileged role assignments, OAuth consent grants to connected applications, changes to federation settings or trusted domains, and 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.
Supplier breach or outage
Some of the most disruptive incidents start outside your network. Your managed service provider is breached, a cloud platform goes down for two days, or a faulty update from a security vendor takes out your laptops, as the CrowdStrike update did to millions of Windows machines on 19 July 2024. When ransomware hit the Synnovis pathology service in June 2024, London NHS trusts that relied on it postponed thousands of appointments and operations. You cannot investigate systems you do not own and you may never see their logs, so this playbook is about the decisions you control. For each critical supplier it answers three questions: how will we know, what do we switch off, and how do we keep operating?
Confirm the incident through a contact you already hold, not a number or link in the alert itself; attackers impersonate suppliers. Then establish whether the supplier has been breached or is down but uncompromised, because the two call for different action.
If the supplier has been breached and has access into your environment, decide early whether to cut it. Disable its remote access tools and VPN accounts, suspend integrations and API connections, and rotate any passwords or keys it holds. An MSP's remote management tool reaches every machine it manages, so treat a breached MSP as a possible breach of your own network. Work out what data the supplier holds or processes for you and whether any of it is personal data.
If the supplier is down but there is no sign of compromise, cutting its access gains you little and can slow its recovery and yours. Keep the connection, watch it, and move to the workaround you agreed in advance (a manual process, a second supplier, or a reduced service). In either case, tell staff what changes for them.
Ask the supplier, in writing, what happened and when, which of your systems and data are affected, and what indicators of compromise you should look for. Log each request and each answer. Under UK and EU GDPR a processor must tell you about a personal data breach without undue delay, but the decision to report to the regulator stays with you as the controller, and your 72 hours run from when you become aware of the breach. The supplier's report usually starts that clock, but a news report, a customer complaint or your own monitoring can start it sooner, so assess straight away and record when and how you first learned of it. Brazil's LGPD splits the duty the same way. If the supplier is slow to share detail, report on time with what you know and follow up. Our supply chain security guide covers the contract terms and access controls that make this playbook easier to run.
If you are a supplier yourself, the same applies in reverse. Your customer contracts and data processing agreements may set notification deadlines shorter than any regulator's. Put those deadlines, the customer contacts and the person who decides what to tell customers into the plan.
Regulatory and contractual notification
Notification duties depend on where you operate, where the affected people live and which sector you are in. An incident that touches customers in several countries can start several clocks at once, each with its own regulator, threshold and deadline. Containing the incident does not remove any of them. Your notification matrix from step 3 lists every regime that could apply. When an incident happens, work through these questions for each one:
- Which laws, regulators and contracts apply, given where you operate, whose data is involved and which sector you are in?
- What type of incident is it: a personal data breach, a disruption to a regulated service, or both?
- Does it meet the regime's threshold? Most only require a report above a set level of risk or impact.
- When did you become aware? Most deadlines run from that moment, so record it.
- Who must be told (a regulator, affected individuals, customers, your insurer), who decides, who files and through which channel?
- What is the deadline, and what follow-up reports are due after the first one?
The UK rules below show how this works in practice, followed by a summary for other major jurisdictions.
A controller must report a personal data breach to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. The ICO treats you as aware once you have a reasonable degree of certainty that a security incident has led to personal data being compromised, not when the full scope is known. If you report after 72 hours, you must give reasons for the delay.
Where a breach is likely to result in a high risk to individuals, you must also tell those individuals without undue delay. That is a separate, higher threshold. Record every personal data breach, including those you decide not to report, with your assessment and reasoning. ICO investigations examine whether the organisation had a reasonable process, not just whether the outcome was correct.
Operators of essential services in sectors such as energy, transport, health, water and digital infrastructure must notify their competent authority without undue delay, and no later than 72 hours after becoming aware, of an incident with a significant impact on the service they provide. Relevant digital service providers (online marketplaces, online search engines and cloud computing services) report substantial-impact incidents to the ICO on the same timeline. The Cyber Security and Resilience Bill, currently before Parliament, would extend the regime to managed service providers and data centres and introduce a 24-hour initial notification followed by a full report within 72 hours. NIS reporting operates alongside, not instead of, UK GDPR notification where personal data is involved.
FCA and PRA regulated firms already have to tell their regulator about material operational incidents. FCA PS26/2, with matching PRA and Bank of England rules, introduces a single operational incident and third-party reporting regime from 18 March 2027, with staged reports for incidents that meet defined thresholds. Build those thresholds and timelines into your notification matrix now.
Outside the UK
The main regimes elsewhere, in brief. Each has its own threshold for what counts as reportable, and several apply only to certain sectors or company sizes. Our article on breach notification deadlines by country covers each one in more detail, with links to the official sources.
| Regime | Who reports to whom | Deadline |
|---|---|---|
| EU GDPR | Controller to the lead or local supervisory authority; individuals if the risk is high | 72 hours from awareness, where feasible |
| EU NIS2 | Essential and important entities to the national CSIRT or competent authority | Early warning in 24 hours, notification in 72 hours, final report within one month |
| EU DORA | Financial entities to their financial supervisor, for major ICT-related incidents | 4 hours from classification as major (24 hours from awareness at most), then 72 hours, then one month |
| US states | Organisations to affected residents, and often the state attorney general | Varies by state; Colorado, Florida and Washington set 30 days |
| US HIPAA | Covered entities to individuals, HHS and, above 500 residents of a state, the media | 60 days from discovery; breaches under 500 people logged and reported to HHS yearly |
| US SEC | Listed companies to investors on Form 8-K, for material incidents | Four business days from deciding the incident is material, a decision that must be made without unreasonable delay |
| Brazil LGPD | Controller to the ANPD and affected individuals | Three working days (double for small processing agents) |
| Australia | Organisations to the OAIC and individuals; businesses with turnover of A$3 million or more to the ASD for ransomware payments | Data breaches as soon as practicable; ransomware payments within 72 hours |
| India | Most organisations to CERT-In, for listed cyber incidents | Six hours from becoming aware |
| Canada | Private-sector organisations to the Privacy Commissioner and individuals | As soon as feasible, where there is a real risk of significant harm |
Work out in advance which EU supervisory authority leads for you, if any, and record it in the plan. In the US, also consider reporting attacks to CISA and the FBI's IC3, and check whether your sector has its own mandatory reporting rules.
Organisations frequently delay notifying the regulator while trying to establish the full scope of a breach. Under GDPR, the 72-hour window starts once you have a reasonable degree of certainty that a breach has occurred, not when you can confirm its full scope. Notify within the window with what you know, and submit supplementary information as the investigation progresses. Regulators, the ICO among them, treat late notification as an aggravating factor in enforcement decisions. Shorter clocks, such as Brazil's three working days, leave even less room to wait.
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.
Tabletop exercises tend to expose the same gaps: 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.
Run at least one exercise where the incident starts at a supplier: your MSP reports a breach late on a Friday, or your main cloud platform is unavailable for two days. Most plans have never been tested against this. It shows who has the authority to cut a supplier's access, how long the manual workaround really lasts, and what you tell customers before the supplier has given you answers.
Measure each exercise against the plan's own targets: how long it took to declare the incident, to reach the decision-makers, to decide on notification and to get the out-of-band channel working. Record every gap as a corrective action with an owner and a due date, and check those actions at the start of the next exercise.
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 perform. Update it, or it describes an organisation that no longer exists. Name an owner for the plan, review it at least annually, and update it after major system or supplier changes, acquisitions, changes in regulatory scope, and every exercise or real incident.
Backup access is not verified. The most important part 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. Until you have restored from a backup under realistic conditions, you do not know whether it will work.
Assuming the supplier will tell you. Many supplier contracts say little about breach notification, and a supplier in the middle of its own incident is slow to share detail. Check the notification clause for each critical supplier, agree a named contact on both sides, and plan to act on partial information. If you wait for the supplier's full report, your own 72 hours may run out first.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile