Incident Response vs Disaster Recovery vs Business Continuity

Incident response contains an active threat, disaster recovery restores systems and data, and business continuity keeps the company trading while both happen. In a ransomware event all three activate, usually within the same hour, and they are three documents with three different owners: security owns the incident response plan, IT owns recovery with hard recovery time and recovery point numbers, and operations owns continuity. The contrarian part comes from the standard everyone cites and few read. In NIST SP 800-34 Rev 1, a disaster recovery plan is site-specific and "only addresses information system disruptions that require relocation," which means the document most companies call their DR plan is, in NIST's taxonomy, an information system contingency plan. That is not pedantry. It is why so many DR plans have nothing useful to say when the disruption is ransomware rather than a flood.

This guide gives the one-line distinction, the full taxonomy, who owns what, and what an auditor actually asks to see.

Key takeaways

• One line: incident response contains, disaster recovery restores, business continuity keeps the business operating. In a cyber event they run in that order and then simultaneously.
• NIST SP 800-34 Rev 1 defines eight plan types, not three, and separates continuity planning (the mission and business processes) from contingency planning (the information systems).
• A DRP under that definition is site-specific and applies to disruptions requiring relocation. Recovery of a system regardless of location is an information system contingency plan.
• RTO, RPO and MTD are the numbers that make a recovery plan testable, and they belong to the business process rather than to the server.
• NIST SP 800-61r3 tells you to synchronize the two: "Synchronize business continuity plans with incident response plans since incidents can undermine business resilience."

The distinction in one line each

Incident response answers "someone is in our environment, what do we do about it." Its work is detection, scoping, containment, eradication, evidence preservation, and the legal and notification sequence. It does not end when the threat is out. SP 800-61r3 puts Recover inside the response alongside Detect and Respond, so incident response stays open through restoration and through the validation that the restored environment can be trusted, and closes when the questions are answered.

Disaster recovery answers "the systems are down, how do we get them back." Its work is restoration order, dependencies, backup integrity, and the numbers that say how fast and how much data loss is acceptable.

Business continuity answers "we cannot use those systems today, how do we still serve customers and make payroll." Its work is manual workarounds, alternate channels, priority customers, and the decision about which business processes get resources first.

The dependency runs in that order. You cannot restore into a network you have not contained, which is the most common expensive mistake in ransomware recovery, and you cannot decide what to restore first without knowing which business processes matter most.

NIST's taxonomy has eight plans, not three

SP 800-34 Rev 1 exists partly because, in its own words, "universally accepted definitions for information system contingency planning and the related planning areas have not been available," which "leads to confusion regarding the actual scope and purpose of various types of plans." Its distinction is the useful one: continuity planning "normally applies to the mission/business itself" and its ability to continue critical functions during and after an event, while contingency planning "normally applies to information systems" and the steps needed to recover them. Cyber incident response planning, in the same document, is "a type of plan that normally focuses on detection, response, and recovery to a computer security incident or event."

Section 2.2 enumerates eight plan types, listed in alphabetical order rather than order of importance:

• The business continuity plan, which sustains mission and business processes during and after a disruption.
• The continuity of operations plan, which restores mission essential functions at an alternate site for up to 30 days.
• The crisis communications plan, which sets the procedures for internal and external communications and names the people authorized to speak publicly.
• The critical infrastructure protection plan, which is scoped to national infrastructure and key resources rather than to a single organization.
• The cyber incident response plan.
• The disaster recovery plan.
• The information system contingency plan.
• The occupant emergency plan, which covers physical threats to people in a facility.

Two of those definitions are worth reading carefully, because most companies have mislabeled one of their documents. A DRP "applies to major, usually physical disruptions to service that deny access to the primary facility infrastructure for an extended period," is "an information system-focused plan designed to restore operability of the target system, application, or computer facility infrastructure at an alternate site," and "only addresses information system disruptions that require relocation." An ISCP, by contrast, "provides established procedures for the assessment and recovery of a system following a system disruption" and "can be activated at the system's current location or at an alternate site."

For a cloud-hosted company, that distinction resolves the confusion quickly. You almost certainly do not have a facility to relocate from. What you have, or should have, is an ISCP by NIST's definition: restore this system, in this order, from this backup, to this state. Calling it a DR plan is harmless as long as everyone knows what is inside it. Calling it a DR plan and then writing it as though the risk is a flood is how a document ends up with a generator vendor's phone number and no restore order.

RTO, RPO and MTD, and where the numbers belong

The three numbers that make recovery testable come from the same document.

Maximum tolerable downtime is how long a business process can be unavailable before the consequences are unacceptable. Recovery time objective is the target for restoring the supporting system, and it has to be shorter than the MTD, because reprocessing and catch-up take time after the system is back. Recovery point objective is different in kind. In NIST's words, RPO "represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage," and unlike RTO it is not part of the MTD; it is "a factor of how much data loss the mission/business process can tolerate."

The failure we see most often is that these numbers get assigned to servers by the infrastructure team, in isolation from the business processes those servers support. An RTO belongs to "invoice customers" or "onboard a new patient," and it is set by the people who own that process. Numbers set the other way around produce a four-hour RTO on a system nobody needs for two days, and a two-day RTO on the one that stops revenue.

One ransomware-specific note. RPO assumes the backup is usable. If the attacker reached the backup repository, your effective recovery point is the last known-clean copy, which may be far older than your policy says. That is an argument for immutability and for testing restores, not for a lower number in the document.

Who owns which document

Security owns incident response, because containment decisions are security decisions and because the evidence and notification sequence has to survive later scrutiny.

IT or infrastructure owns system recovery, because the restore order and the dependency map live with the people who built them.

Operations, or the executive team in a smaller company, owns business continuity, because the choices are business choices: which customers get served first, which processes go manual, when to tell the market.

The seams are where it goes wrong, and they are predictable. Who declares that recovery may begin, meaning the environment is contained enough to restore into? Who decides that a workaround is now the operating mode rather than a stopgap? Who tells customers, and with what wording? Write those three handoffs into all three documents, identically. NIST SP 800-61r3 makes the same point as a recommendation: "Synchronize business continuity plans with incident response plans since incidents can undermine business resilience," and it observes that business continuity planners, who have deep expertise in minimizing operational disruption, can be genuinely valuable in planning responses to specific incident types.

What auditors actually look at

Under SOC 2, availability and incident-related criteria draw the assessor toward evidence that the plans exist, that they were tested, and that the test produced changes. What gets sampled is the artifact trail: the exercise record, the attendees, the findings, and whether anything was fixed. A plan with a version history and no exercise record is the pattern that generates a finding, and our guide to failing a SOC 2 covers how those exceptions get written up.

Under ISO 27001, the relevant Annex A controls are A.5.29, Information Security During Disruption, and A.5.30, ICT Readiness for Business Continuity. The pairing is the point: the standard asks both that security is maintained while you are disrupted, and that your technology is ready to support continuity requirements that the business has actually defined. An organization that has never done a business impact analysis cannot demonstrate the second one, because there is no defined requirement for readiness to be measured against.

The honest summary for a mid-market company: three documents, roughly thirty pages combined, with one exercise a year that crosses all three seams, will satisfy most assessors and, more importantly, will work.

When you do not need three documents

We sell this work, so weigh this accordingly.

A ten-person, fully cloud-hosted company with no regulated data does not need a separate business continuity plan, a DR plan and an IR plan. It needs one document with three sections and five phone numbers. Buying a three-document set at that size produces shelfware and an inflated sense of readiness.

If you have all three and have never exercised them together, do not commission a rewrite. Run one cross-functional exercise against what you have. The findings will be more valuable than the new documents, and the exercise record is the artifact an assessor wanted anyway.

And if your recovery numbers were set by infrastructure without a business impact analysis, fix that first. Better-written plans built on invented RTOs are worse than rough plans built on real ones, because they are more convincing.

Where Top Floor fits

We write and exercise the incident response half, and we work the seams into whatever recovery and continuity documents you already have rather than replacing them, because the handoffs are where incidents actually stall. Where the driver is certification, ISO 27001 work covers A.5.29 and A.5.30 as part of the wider ISMS rather than as standalone deliverables. And where the driver is an assessor asking for evidence that the plans were tested, our audit and assurance practice cares about the exercise record and the closed findings, which is the part that gets sampled.

How to decide this week

1. Open the document you call a DR plan and decide which NIST type it actually is. If it never mentions relocation, it is an information system contingency plan, and it should read like one.

2. Pick your three most revenue-critical business processes and ask their owners for an MTD. Compare it against the RTO your infrastructure team has assigned.

3. Find the sentence in any of your plans that says who authorizes recovery to begin. If it is absent, write it into all three.

4. Check whether your last exercise crossed a seam or stayed inside one team. Single-team exercises never find handoff failures.

5. Confirm your backups are immutable or offline, then schedule a restore test, because RPO on a compromised repository is fiction.

Frequently asked questions

Do we need separate incident response, disaster recovery and business continuity plans?

For most companies past roughly fifty people, yes, because the three have different owners, different triggers and different readers. Below that size, one document with three clearly separated sections is usually better than three thin ones, provided it names the handoffs: who declares containment sufficient for recovery to start, who authorizes a manual workaround as the operating mode, and who communicates externally. Assessors care that the capability exists and has been exercised, not that it arrived in three files.

What is the difference between a disaster recovery plan and an information system contingency plan?

Under NIST SP 800-34 Rev 1, a disaster recovery plan is site-specific: it addresses major disruptions that deny access to the primary facility and require moving operations to an alternate site. An information system contingency plan covers assessment and recovery of a system following a disruption regardless of location, and can be activated where the system already runs. Once a DRP has moved operations to an alternate site, each affected system then uses its own ISCP to restore and test. For a cloud-hosted company with no facility to evacuate, the document that matters is the ISCP even if everyone calls it DR.

Which plan activates first in a ransomware attack?

Incident response, and the order matters more than it sounds. Restoring into an environment the attacker still occupies hands them the rebuilt systems, so recovery waits for a containment decision from the incident side. Business continuity typically activates in parallel rather than afterwards, because the business needs a way to operate on day one while the other two are still working. The handoff to write down in advance is the containment-to-recovery one, since that is the decision most likely to be made under pressure by whoever happens to be in the room.

Who should own the business continuity plan?

Operations or the executive team, not IT. The decisions inside a continuity plan are business decisions: which customers are served first, which processes run manually, what is communicated and when. IT owns the systems that support those choices and therefore owns recovery, but a continuity plan written by the infrastructure team tends to describe restoring servers rather than serving customers. In a company small enough that these are the same three people, write the two sections separately anyway, because the questions are genuinely different.