Incident response (IR) and disaster recovery (DR) are two different plans for two different jobs. Incident response deals with the attack while it is happening: spotting it, containing it, removing the attacker. Disaster recovery brings systems and data back so the business can operate again. Most serious cyber incidents need both, and a third plan, business continuity, covers how you keep working in between.
This guide is written for UK decision-makers who must own these plans, buy support for them, or answer for them after an incident. It explains where the plans diverge, where they collide, and what to check before you rely on them.
TL;DR
- Incident response is the immediate reaction to a cyber attack. Disaster recovery is how systems are brought back up. Business continuity is how the organisation keeps operating meanwhile. The NCSC treats them as complementary, not alternatives.
- IR is event-focused (ransomware, phishing, a data breach). DR is broader and also covers floods, power cuts and hardware failure.
- A ransomware attack can trigger all three plans at once, so the hand-offs between them matter more than the documents themselves.
- Untested plans fail on missing contacts, unclear authority and wrong restoration order. Rehearse them.
- Recovery does not end the matter: UK organisations may still owe reports to the ICO, regulators and law enforcement.
Table of Contents
- The short answer: attack versus aftermath
- Incident response vs disaster recovery, side by side
- Where the two plans meet in a real attack
- Why DR alone does not answer a cyber attack
- Recovery order must follow the business, not the servers
- What UK organisations still owe after systems come back
- People are part of recovery
- How to test whether your plans work
- Choosing external incident response support
- Our perspective: keep the plans separate, make the hand-offs explicit
- How Zero Through can help
- FAQ
- Sources
The short answer: attack versus aftermath
Think of a fire in a building. Incident response is the fire brigade and the evacuation: stop it spreading, find out how it started, make sure it is out. Disaster recovery is the rebuild: restoring the rooms, the wiring and the records. Business continuity is where your staff work in the meantime.
The NCSC’s board guidance puts it plainly. An incident response plan covers the immediate response to a cyber attack. A business continuity plan addresses how the organisation continues to operate. A disaster recovery plan details how systems are brought back up. The NCSC uses ransomware, fire, flood and theft as examples where contingency plans, alternative sites and backups may all be relevant.
The Canadian Centre for Cyber Security draws the line by scope. An incident response plan is event-focused: it covers detecting, responding to and recovering from a specific security incident such as ransomware, phishing or a data breach. A disaster recovery plan is broader and restores IT infrastructure after cyber attacks, natural hazards, hardware failures or power outages.
So the practical distinction is this: IR contains and mitigates the threat, DR restores the technology and data needed for normal operations.
Incident response vs disaster recovery, side by side
| Incident response | Disaster recovery | Business continuity | |
|---|---|---|---|
| Main question | What is happening, and how do we stop it? | How do we get systems and data back? | How do we keep delivering essential services meanwhile? |
| Trigger | A detected or suspected security event | An outage or loss of systems, whatever the cause | Any disruption to normal operations |
| Typical events | Ransomware, phishing compromise, data breach | Cyber attack, flood, fire, power failure, hardware failure | All of these, plus loss of staff, sites or suppliers |
| Core activities | Triage, containment, forensics, eradication | Restoring from backups, rebuilding, validating systems | Workarounds, alternative sites, manual processes, communications |
| Success looks like | Attacker removed, harm limited, evidence preserved | Systems back within agreed recovery times, safely | Customers still served at an acceptable level |
| Who leads | Security team or external responder | IT operations | Senior management and operational owners |
The CISA Cyber Essentials toolkit makes the same separation: incident response and disaster recovery are separate plans, with incident response mainly protecting information assets and disaster recovery focusing on business continuity and efficient restoration of critical systems.
Where the two plans meet in a real attack
Take a ransomware infection at a UK firm with offices in three cities. The sequence rarely runs neatly in order.
- Detection and triage. Someone, or something, flags encrypted files or unusual activity. Incident response starts: who is the incident lead, what is affected, is the attacker still inside?
- Containment. Infected workstations or production servers are isolated. Public-facing services may be taken offline. CISA lists this kind of isolation as a core containment action.
- Continuity. While systems are down, the business needs manual processes, alternative sites or backup communications. Business continuity takes over the customer-facing problem.
- Eradication and recovery. Only when the threat is removed does it make sense to restore. Restore too early and you bring the attacker back with your data.
- Validation. Restored systems are tested for secure operation before going live.
- Reporting and review. Regulators, law enforcement and customers may need to be told, and the plans are updated with what you learned.
The trap sits at step 4. A disaster recovery plan written for a flood assumes the backups are clean and the threat is gone. A cyber attack breaks both assumptions. That is why the incident response team and the recovery team must agree when it is safe to start restoring.
Our own guidance on keeping UK services running during ransomware recovery goes deeper on that overlap.
Why DR alone does not answer a cyber attack
A disaster recovery plan is usually built around infrastructure: servers, databases, sites. It asks how fast each can be rebuilt. That is necessary, but a cyber attack adds questions the plan never asked.
- Is the backup itself compromised? Backups are not automatically a recovery capability. CISA stresses testing systems for secure operation after restoration.
- How did the attacker get in? If nobody answers this, restoration just resets the clock for a second attack.
- What was taken? Data theft may trigger legal duties that no restoration can fix.
- Who decides? Isolating a system or pulling a public service offline is a business decision with a cost. The NCSC’s advice is to pre-authorise who can make those calls, including out of hours, because decision quality deteriorates under pressure.
In the other direction, an incident response plan alone does not answer a flood or a failed storage array. It will tell you how to handle a security event, but not how to rebuild a data centre.
Recovery order must follow the business, not the servers
The NCSC’s Cyber Assessment Framework expects organisations to keep tested incident-management processes, prioritise essential functions, document alerts and decisions, define activation triggers and set recovery-time objectives for critical systems.
That has a consequence for multi-location businesses. Priorities should follow essential services and their dependencies, not whichever server looks most damaged. A payments function depends on applications, datasets and sometimes operational technology. If you restore the database before the identity system it relies on, the technical restore succeeds and the business still cannot trade.
A workable approach:
- List the five to ten services the business cannot do without, in the words of the people who run them.
- Map each to its applications, data, networks, suppliers and sites.
- Set a recovery-time objective per service, agreed by the business owner, not only by IT.
- Write the restoration order from that map and keep it with the DR plan.
The same logic applies to automated and AI-assisted workflows. If you run them, think through what happens when one fails mid-process; this set of recovery patterns for failed AI agent workflows is a useful reference for that design question.
What UK organisations still owe after systems come back
Restoring service is not the finish line. The NCSC response and recovery guide says formal reporting may be required to internal and external stakeholders, and that cyber attacks should be reported to law enforcement through Report Fraud or, in Scotland, Police Scotland on 101. It also gives 0300 123 2040 for reporting a live attack, described as available 24 hours a day, seven days a week.
On personal data, the ICO’s guide to personal data breaches says UK GDPR requires you to notify the ICO of certain breaches within 72 hours of becoming aware of them, where feasible, even if you do not yet have all the details. Whether a given incident meets the threshold depends on the facts, so your data protection officer or legal adviser should make that call. Regulated firms, such as financial services and healthcare providers, may have sector-regulator duties on top.
The NCSC also notes that outsourcing IT does not remove your own reporting responsibilities. If a provider runs your systems, your plan must still say who tells the regulator and when.
People are part of recovery
The word “disaster” covers more than cyber events, and the human side is easy to leave out of IT plans. UK government emergency-management guidance treats the effects on individuals, families and communities as a core part of both response and recovery, with NHS mental-health services part of the response.
The evidence for lasting effects is concrete. Public Health England’s study of flooding and health found poor mental health, depression and PTSD remained notably high a year after flooding among people whose homes were flooded. For an employer, the lesson is practical: build staff welfare, support routes and the possibility of prolonged absence into continuity planning. If an employee is struggling after a disaster or a serious incident, point them to their GP or your occupational health provider rather than improvising.
How to test whether your plans work
Documents do not reveal missing contacts, unclear hand-offs, unsafe restoration assumptions or communication failures. Exercises do. CISA recommends realistic simulations, sometimes called war-gaming, and assigned roles and responsibilities.
A useful annual programme for a mid-sized UK business:
- Tabletop exercise (half a day). Walk the leadership team through a ransomware scenario. Ask who isolates systems, who talks to the regulator, who speaks to customers.
- Restore test. Pick a critical system, restore it from backup into a clean environment and time it against the recovery objective.
- Contact check. Call every person and supplier on the incident list. Out-of-date numbers are the commonest finding.
- Dependency review. Redraw the service-to-system map after any significant change, such as a new site or cloud migration.
- Write-up. Record gaps, owners and dates, and re-test the fixes.
Prevention also shrinks the load on both plans. Regular vulnerability management closes the gaps attackers use, and an IT security audit shows where your plans and controls diverge from what you assume.
Choosing external incident response support
Many firms cannot staff incident response around the clock and look outside. Do not assume a managed monitoring service includes full response. The NCSC’s Cyber Incident Response technical standard expects providers to support containment, mitigation, remediation, eradication and recovery, and under its Level 2 standard to provide technical support to targets between 9am and 5pm, seven days a week.
Before you sign, ask any provider:
- Which locations and time zones do you cover, and who answers out of hours?
- What are the escalation steps from alert to named incident lead?
- Do you do forensics, or hand them off?
- Do you support eradication and recovery, or only detection and advice?
- How do you coordinate with our DR team on restoration order?
- Can you work with our regulatory duties, for example ICO notification timing?
Write the answers into the contract, not just the sales deck.
Our perspective: keep the plans separate, make the hand-offs explicit
We see the same pattern with multi-location clients. The incident response plan sits with security, the disaster recovery plan sits with IT operations, continuity sits with the business, and nobody owns the gaps between them. The first real incident then becomes the first time the three teams meet.
Our view is that you should not merge these into one vague playbook. Each has a different trigger, owner and measure of success. What you should do is define the hand-offs: who declares an incident, who says containment is complete, who authorises restoration, who confirms the restored system is safe. Those four decisions are where time and money are lost.
We also think findings should be explained in plain terms with a roadmap, not a generic checklist. A board cannot act on “improve resilience”, but it can act on “restore payments before reporting, here is the order and the owner”. That is how we approach our work: tailored to each client’s operations and industry, scalable as the business grows, and focused on structured improvement.
— Shirish
How Zero Through can help
If you need monitoring and response that scales across sites, our managed SOC services and MDR services are built around detecting and responding to threats quickly, with managed SIEM behind them for visibility. To test how your defences and plans hold up, we also run penetration testing. You can start from our global IT support page and tell us how many locations and regulated functions you run.
FAQ
Is incident response part of disaster recovery?
Some sources treat it as a subset, but the NCSC and CISA both describe separate plans with different aims. Incident response handles the attack itself, while disaster recovery restores systems. Keep them as distinct documents that refer to each other.
What is the difference between incident response and business continuity?
Incident response is about dealing with the security event. Business continuity is about keeping essential services running while that event, or any other disruption, is dealt with. In a ransomware case, one team contains the attack while another runs workarounds for customers.
Which plan do I need first?
If you have none, start with the essential services list and recovery objectives, because they feed all three plans. Then write incident response, since cyber attacks are the likeliest trigger, and link it to restoration. Exercise each one once written.
Who should I report a cyber attack to in the UK?
The NCSC guidance gives 0300 123 2040 for a live attack, and Report Fraud or Police Scotland on 101 for reporting to law enforcement. If personal data is involved, the ICO may need to hear from you within 72 hours of becoming aware. Your legal adviser or data protection officer should confirm what applies to your case.
Sources
- NCSC: Planning your response to cyber incidents
- Canadian Centre for Cyber Security: Improving cyber security resilience through emergency preparedness planning
- CISA: Cyber Essentials Toolkit, Chapter 6
- NCSC: Cyber Assessment Framework, principle D1
- NCSC: Response and Recovery Guide
- ICO: Personal data breaches, a guide
- NCSC: Cyber Incident Response Technical Standard, Level 2
- UK Government: Emergency management, human aspects guidance
- Public Health England: English National Study for Flooding and Health
