Business continuity and disaster recovery plans are often written as one document, filed once, and reviewed when the auditor asks. For a cloud-hosted company, that document tends to say "we run in multiple availability zones" and little else.
That is a statement about infrastructure, not a plan. A real plan answers different questions. Which parts of the business must keep working, and how quickly? What do people do when the identity provider is down, or the primary cloud region is unavailable, or a critical vendor stops responding? Who decides that this is a disaster, and what happens next?
This article covers the difference between the two plans, what the frameworks require, how to run a business impact analysis, how to map dependencies, what each plan should contain, and how to test them.
Two plans with different jobs
A business continuity plan keeps the business operating during a disruption. It covers people, processes, communication, and workarounds: how support keeps answering customers, how payroll still runs, how the team communicates if the usual chat tool is down.
A disaster recovery plan restores technology. It covers systems, data, and infrastructure: the order in which services are recovered, the runbooks for each, and the targets for how long recovery may take and how much data may be lost.
The disaster recovery plan sits inside the continuity effort. Recovering the platform is one part of keeping the business running, but not all of it. ISO 22301 is the standard for business continuity management systems if you want a full framework. NIST SP 800-34 Rev. 1 is a widely used guide to contingency planning for information systems.
What the frameworks require
ISO 27001:2022 Annex A 5.29 covers maintaining information security during disruption. Annex A 5.30 requires ICT readiness to be planned, implemented, maintained, and tested based on business continuity objectives. Annex A 8.14 covers redundancy of information processing facilities.
SOC 2 CC9.1 covers identifying and developing risk mitigation activities for business disruption. If availability is in scope, A1.2 covers recovery infrastructure and A1.3 covers testing recovery plan procedures. Should you include availability in your SOC 2 helps decide whether to add it.
The HIPAA Security Rule contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan, and lists testing and revision procedures and an applications and data criticality analysis as addressable.
NIST SP 800-53 Rev. 5 CP-2 covers the contingency plan and CP-4 its testing.
GDPR Article 32 includes the resilience of processing systems and the ability to restore access to personal data in a timely manner.
Start with a business impact analysis
The business impact analysis (BIA) is what turns a plan from a list of good intentions into a set of priorities. Without it, every system is equally important, which means none is.
For each business process or customer-facing service:
Describe it and name an owner. "Customers can sign in and use the product." "Support responds to tickets." "We can deploy a fix."
Assess the impact of disruption over time. What happens after one hour, one day, one week? Consider customer commitments, contractual service levels, regulatory duties, and revenue.
Set the maximum tolerable downtime. The point after which the impact becomes unacceptable.
Derive recovery objectives. A recovery time objective (RTO) and a recovery point objective (RPO) for the systems that support the process.
List dependencies. Systems, vendors, and people the process relies on.
HIPAA's applications and data criticality analysis is close to the same exercise, focused on the systems holding ePHI. Doing one BIA that covers both saves duplicate work.
Map your dependencies
The dependencies in the BIA are where most plans are weakest, because they reach outside your own infrastructure.
Cloud provider and region. Multiple availability zones protect against a data center failure, not against a regional outage or an account-level problem.
The identity provider. If it is unavailable, can anyone reach the systems needed to recover? This is where break-glass accounts matter.
Source control and CI/CD. If you recover by redeploying, the pipeline is a recovery dependency.
Communication tools. The incident and continuity team needs a way to talk that does not depend on the systems that are down.
Critical vendors. Payment processing, email delivery, customer support tools. Vendor tiering by data access covers how to identify which vendors are critical; for continuity, add a view of which ones you cannot operate without.
People. A system only one engineer knows how to recover is a dependency on that engineer's availability.
What each plan should contain
The business continuity plan:
Scope, and the processes covered, from the BIA
Who can activate the plan, and the criteria for doing so
Roles and deputies, with contact details held outside primary systems
Communication: internal updates, customer communication, regulators where relevant
Workarounds for each critical process when its systems are unavailable
How to stand down and return to normal operation
The disaster recovery plan:
Scenarios covered, such as region loss, account compromise, data corruption, or ransomware
Who declares a disaster and who leads recovery
Recovery order, derived from RTOs and dependencies
A runbook per system, specific enough that someone other than its author can follow it
Where backups and recovery credentials are, and how to reach them
How to verify that recovered systems are working and secure before reopening them to customers
How to fail back, if recovery happened somewhere temporary
Restoring data is one step in the recovery plan. Backup and restore testing covers how to make that step reliable and how to evidence it.
Testing the plans
An untested plan is an assumption. Testing ranges from a discussion to a full failover, and a mature program uses several kinds.
| Test type | What it tests | Typical evidence |
|---|---|---|
| Plan walkthrough | Whether the plan is current and roles are understood | Attendance, review notes, plan updates |
| Tabletop exercise | Decisions and communication in a scenario | After-action report with actions |
| Restore test | Whether data can be recovered within RPO and RTO | Restore record with timings and verification |
| Failover test | Whether a service runs from secondary infrastructure | Test plan, logs, measured recovery time |
| Full simulation | The whole recovery under realistic conditions | Detailed report and lessons learned |
A common pattern for smaller companies is a yearly tabletop with technical restore tests, and add failover tests as the product's availability commitments grow. Running a tabletop exercise covers how to design the discussion-based test. Whatever the mix, record the results, track actions to completion, and update the plans.
Keep the plans current
Plans decay as the business changes. Review them at least annually, and also when something material changes: a new region, a new critical vendor, a major architecture change, a reorganization. Review contact lists more often, since they go stale first.
Each review should leave a dated record: who reviewed, what changed, and who approved. That record, the BIA, the plans, and the test results are the core of what an auditor will ask for.
How TrustLynce helps
TrustLynce policy management keeps the continuity and recovery plans versioned, with approvals and acceptance tracked. Continuous monitoring runs control checks against the systems you connect and routes failures to their owners, so drift in recovery-related settings is raised between tests.