A Backup Is Not a Disaster Recovery Plan

A disaster recovery plan is a documented, executable method for restoring priority applications, infrastructure and data after a serious disruption. It identifies what must return first, who performs each action, which resources they need and how the organization will decide that recovery is complete.

The core definition remains valid, but the practical emphasis is sharper: possessing backup files is not the same as being able to resume service. A useful plan must account for compromised credentials, unavailable staff, damaged infrastructure, cloud dependencies and backups that have never been restored under realistic conditions.

What a disaster recovery plan covers

A DR plan concentrates on the technology required to support business operations. Its scope may include networks, identity services, servers, endpoints, databases, software-as-a-service platforms, cloud resources, operational technology and the data connecting those systems.

Disaster recovery is related to, but narrower than, business continuity. Business continuity determines how the organization will keep delivering essential products or services during disruption; disaster recovery restores the technology those operations depend on. The Ready.gov emergency-planning guidance therefore says an IT disaster recovery plan should be developed alongside the business continuity plan.

A backup policy is another component rather than a substitute. Backups describe what is copied, where copies are retained and how long they are kept. The recovery plan adds the activation decision, restoration order, technical procedures, communications, validation checks and transition back to normal operations.

An incident response plan also has a different job. It guides detection, containment, investigation and eradication during a cyber incident. The two plans meet when responders determine that affected services must be rebuilt or restored; recovery should not begin from a supposedly safe copy until the team has reasonable confidence that the destination and recovery material are clean.

RTO and RPO turn business needs into recovery targets

Two objectives define the plan’s basic tolerance for disruption. The recovery time objective (RTO) is the maximum intended interval before a system or process is restored to an acceptable level. The recovery point objective (RPO) identifies the point in time to which data must be recovered, effectively setting the tolerated window of data loss.

These are targets, not measurements of actual performance. If an order system has a four-hour RTO, the architecture, staffing and procedures must make restoration within that window plausible. If its RPO is 30 minutes, backup or replication frequency must support recovery to a point no more than approximately 30 minutes before the interruption.

Targets should follow a business impact analysis rather than an arbitrary desire for instant recovery. A short RTO or RPO generally requires more automation, capacity, geographic separation or operational coverage. Different services can have different objectives, and a plan should document dependencies that could prevent a high-priority application from meeting its target even when that application itself is available.

The minimum contents of an executable plan

A usable plan is written for a stressful situation in which normal communication channels or familiar administrators may be unavailable. It should give an appropriately skilled responder enough verified information to act without relying on one person’s memory.

Scope and activation criteria: name the systems and disruption scenarios covered, the conditions that trigger the plan and the person or role authorized to activate it.
Business priorities: list critical services in restoration order, with approved RTOs, RPOs and minimum acceptable operating levels.
Dependency map: record the identity, network, DNS, certificate, storage, application, vendor and facility dependencies required by each service.
Recovery resources: identify backup sets, system images, configuration files, infrastructure-as-code templates, licenses, replacement equipment and alternate processing locations.
Roles and communications: assign technical and business owners, deputies, escalation paths, vendor contacts and an out-of-band method for communicating if corporate systems are unavailable.
Runbooks: provide ordered restoration instructions, access requirements, expected results, rollback decisions and checks for data integrity and application function.
Reconstitution: define how restored services are validated, approved for use, monitored and eventually moved from temporary recovery arrangements to normal operations.

This structure aligns with the enduring planning discipline in NIST’s contingency-planning guide, which organizes the work around policy, business impact analysis, preventive controls, recovery strategies, plan development, exercises and maintenance. Although written for U.S. federal information systems, that sequence remains a useful framework for other organizations when adapted to their risks and obligations.

Backups must survive the same incident as production

A recovery copy is valuable only if responders can locate it, access it and restore it without reintroducing the original failure. The plan should identify protected copies of critical data and configuration material, their owners, retention rules, encryption-key dependencies and the credentials required to recover them.

Cyber incidents create a particular problem because attackers may seek accessible backup systems, stored credentials and administrative tools before disrupting production. The current CISA StopRansomware guide recommends offline, encrypted backups of critical data, regular tests of their availability and integrity, maintained system images and an exercised incident-response plan with offline access.

Cloud storage does not remove this requirement. Synchronized files can carry unwanted changes into another location, while a backup controlled through the same identity environment may become inaccessible with production. A plan should state which failure domains are separated, how privileged recovery access is protected and how cloud resources can be rebuilt if the normal management account is unavailable.

A test must demonstrate service recovery, not document review

Reading the plan in a meeting can expose missing contacts and unclear decisions, but it does not prove that restoration works. A technical exercise should recover selected services in an isolated environment, verify the restored data, test required integrations and compare elapsed time and recovered state with the approved RTO and RPO.

Exercises can increase in depth. A tabletop session walks decision-makers through a scenario; a component test restores a backup or rebuilds one system; a broader simulation validates several connected services and the handoffs between technical and business teams. Production failover may be appropriate for some architectures, but its operational risk should be assessed and controlled.

Record actual start and completion times, missing permissions, failed automation, undocumented dependencies and manual workarounds. Every finding needs an owner and due date, after which the affected procedure should be retested. A successful exercise produces evidence that a defined service was restored and accepted—not merely that the backup job reported success.

How to tell whether the plan is ready

A concise readiness review should be able to answer concrete questions without improvisation:

Which business services receive recovery priority, and who approved that order?
Are RTO and RPO defined for those services and supported by the current architecture?
Can responders reach the plan, credentials and contact details when normal identity and messaging systems are down?
Are protected recovery copies separated from the production failure domain?
Has the team restored representative systems and validated their data and dependencies?
Do test records show actual performance, unresolved gaps and accountable owners?
Is the plan reviewed after material changes to applications, vendors, infrastructure or staffing?

If these answers cannot be demonstrated, the organization has recovery intentions rather than a dependable recovery capability. The essential deliverable is not the document itself; it is a repeatable process that restores an agreed level of service with known data loss, responsible decision-makers and evidence from exercises.

A Backup Is Not a Recovery Plan: What Disaster Readiness Must Prove