Myth: A Disaster Recovery Plan Is an Incident Response Plan

Ask a small business whether it has an incident response plan and a common answer is: “Yes, we have disaster recovery.” It sounds reasonable. Both documents deal with bad days. But they answer different questions, and treating them as the same thing is a gap that tends to show up at the worst moment.

The myth

“We have a disaster recovery plan, so we have an incident response plan.”

The fact: a recovery plan helps you rebuild. An incident response plan helps you decide what is safe to rebuild, and how to stop the damage first.

Fact 1: Disaster recovery assumes you know what broke

Disaster recovery is built for outages: a failed server, a lost site, a bad update. The goal is to return systems to a known good state, and the plan usually starts with “what do we restore, and in what order?”

A security incident starts with a different question: is the attacker still in, and is what we are about to restore clean? If the recovery plan puts systems back into an environment where the attacker still holds valid credentials, a hidden mailbox rule or a consented app, the organization may simply be compromised again, this time on fresh servers.

Fact 2: Disaster recovery lives in one phase

Incident response is commonly described in six phases: preparation, detection, containment, eradication, recovery and lessons learned. A disaster recovery plan mostly covers one of them. The rest is often unwritten:

• Detection: who decides that something is an incident, and on what evidence?
• Containment: who can disable accounts, revoke sessions and isolate devices, and can they do it without waiting for a meeting?
• Eradication: how do you confirm that persistence is gone, not just the visible symptom?
• Lessons learned: who owns the fixes afterward?

Fact 3: Containment does not wait for the restore

A recovery plan is sequential by nature. Incident response runs in parallel. Once responders understand the problem, containment starts: revoke sessions, reset credentials, isolate affected systems. Evidence capture runs alongside it, not ahead of it. Holding off on containment to get a perfect forensic picture while an attacker keeps access is a bad trade.

The opposite habit is just as costly. A runbook that says “restore first, investigate later” can overwrite the records an investigation depends on, such as logs, disk state and message traces. A good plan names both steps and who owns each.

Fact 4: The hard questions are not only technical

Disaster recovery documents rarely cover the people side of a security incident. Who speaks to customers? Who talks to the insurer? Who decides whether to take a business system offline during trading hours? Questions about outside obligations are best settled with qualified advisers ahead of time, not improvised during an incident.

Where the two plans should meet

You do not need a second binder. You need a few explicit handoffs:

• A trigger that says when a suspected security event moves from the recovery runbook to the incident response lead.
• A rule that restores come from a point before the compromise, chosen together with whoever is investigating, not simply the most recent backup.
• A step to reset credentials and revoke tokens before restored systems reconnect.
• A note on what evidence to preserve before systems are rebuilt or wiped.

A five-minute self-check

Get your team in a room and answer these out loud:

• If ransomware hit tonight, who says “this is an incident”?
• Who can disable accounts without asking permission first?
• How would we choose a restore point?
• Where is the contact list if email is down?
• When did we last walk through the plan together?

If the answers are vague, that is useful information. It is far cheaper to find the gaps over coffee than during an incident.

Message us to talk through your incident response plan.