Business Continuity and Disaster Recovery Guide

Most continuity plans are written for a building fire or a data centre outage, then fail when the disruption is a cyber attack, a cloud region failure or the loss of a supplier or identity provider that every system depends on. Business continuity (BC) keeps critical services running during disruption; disaster recovery (DR) restores the technology behind them. This guide covers the business impact analysis, RTO, RPO and maximum tolerable downtime, continuity strategies, DR architectures from backup and restore to multi-site active-active, plan activation, crisis communications, testing, and the dependencies on identity and third parties that plans most often miss. It draws on ISO 22301:2019, NIST SP 800-34 Rev. 1 and the AWS DR whitepaper, and is written for continuity managers, infrastructure and security teams, and the executives who own recovery decisions.

Key takeaways

• Start from services, not systems. The business impact analysis sets how long each critical service can be down and how much data it can lose; DR architecture follows from those numbers.
• RTO must sit inside maximum tolerable downtime. NIST SP 800-34 says the RTO "must normally be shorter than the MTD", leaving time for decisions, validation and manual workarounds.
• Pick the cheapest DR pattern that meets the target. Backup and restore, pilot light, warm standby and multi-site active-active trade cost and complexity for recovery time; most estates need a mix.
• Identity and suppliers are shared dependencies. If the identity provider, management plane or a key supplier is down or compromised, every recovery plan that assumes them fails at once.
• Untested plans are assumptions. Scale exercises from tabletop to full failover with the system's impact, and measure achieved recovery times against targets.

Business continuity, disaster recovery and the plan family

ISO 22301:2019 (Security and resilience: Business continuity management systems: Requirements) defines a management system for business continuity: policy, BIA and risk assessment, strategies and solutions, plans, exercising and improvement, with certification available. Its clause 8 holds the operational core: 8.2 BIA and risk assessment, 8.3 strategies and solutions, 8.4 plans and procedures, 8.5 exercise programme and 8.6 evaluation. ISO has flagged the 2019 edition for revision and a 2024 amendment added climate action changes. NIST SP 800-34 Rev. 1 is the most detailed public guide to IT contingency planning and distinguishes the plans that make up a continuity capability.

NIST's seven-step process ties them together: contingency planning policy, BIA, preventive controls, contingency strategies, the ISCP, testing, training and exercises, and plan maintenance. Incident response contains and investigates; BC and DR keep the business going and restore it. See the Incident Response Guide.

Business impact analysis and recovery objectives

BIAs usually go wrong by asking system owners how fast they would like systems back. NIST SP 800-34 defines three steps: determine mission and business processes and recovery criticality, identify resource requirements, and identify recovery priorities for system resources.

• Interview by service: for each critical business service (take payments, ship orders, dispense medicines), record impact over time (1 hour, 4 hours, 1 day, 3 days, 1 week) across financial, customer, regulatory, safety and reputational dimensions.
• Find the tolerance point: the time at which impact becomes unacceptable is the MTD for that service. Get it signed off by the business owner, not IT.
• Map the dependencies: people, sites, applications, data, identity services, networks and suppliers that the service needs, including the ones nobody owns, such as DNS, certificates and the secrets vault.
• Derive system targets: each supporting system's RTO and RPO come from the most demanding service that depends on it.

A worked example: if order taking has an MTD of 24 hours, the order platform might have an RTO of 8 hours, leaving time for activation decisions, data validation and catching up the backlog. If losing more than 15 minutes of orders cannot be reconstructed from payment provider records, the RPO is 15 minutes, and nightly backups cannot meet it.

Continuity strategies

• People: cross-training, documented deputies and remote working. Name at least two people for each critical recovery task.
• Premises: alternate workplaces or work-area recovery contracts for functions that cannot work remotely.
• Manual workarounds: paper or spreadsheet processes that keep a service running at reduced capacity, with a defined way to re-enter the data afterwards. Often the cheapest way to stretch the MTD.
• Technology: the DR architecture below, plus spare endpoints or a rapid reimaging capability for when the endpoint estate itself is lost.
• Information: backups that an attacker cannot delete, offline copies of plans, contact lists and network diagrams. See the Backup Security and Immutable Backup Guide.
• Suppliers: contractual recovery commitments, second sources for critical inputs, and exit plans for concentrated providers.

Disaster recovery architectures

• Fail over on the data plane: AWS advises using "only data plane operations as part of your failover operation" because data planes have higher availability goals. DNS failover driven by health checks is a data plane action; changing routing weights, scaling groups and restoring from backup are control plane actions that may be impaired in the same event. Pre-provision capacity rather than relying on scaling during a regional failure.
• Be careful with automatic failover: AWS notes automatic failover "should be used with caution" because a false alarm causes its own outage. Many organisations automate detection and keep a human decision for failover.
• Replication is not backup: active-active and synchronous replication copy corruption, deletion and encryption as faithfully as good data. Keep point-in-time, immutable backups behind every replicated tier.
• DR as a service (DRaaS): a provider replicates workloads and runs them on its infrastructure when invoked. It suits organisations without a second site, but test the provider's ability to start your workloads, and check how its own administrative access is secured.
• Endpoints and SaaS: cover laptops, collaboration suites and SaaS data, not only servers.

Where identity fits

Identity is the dependency most likely to take down every recovery plan at once. Microsoft's Entra resilience guidance puts it plainly: "When authentication is disrupted, because of the underlying component failures, your users won't access their applications."

• Identity provider outage: list every service that authenticates through the IdP, including the DR console, backup system, cloud consoles and the collaboration tools the crisis team plans to use. Agree what still works with cached sessions and tokens, and for how long.
• Reduce hybrid dependencies: Microsoft describes password hash synchronisation as "The simplest and most resilient hybrid authentication option" because it has no on-premises dependency during sign-in, notes that "Federation has a high number of on premises dependencies", and recommends enabling password hash sync alongside federation. Decide in advance who can switch authentication methods during an outage.
• Emergency access: keep cloud-only break-glass accounts that do not depend on federation, MFA services or on-premises directories, with credentials stored offline and every use alerted. See the Break-Glass Account Guide.
• Compromised identity plane: in a cyber attack the directory itself may be untrusted. Plans need a sequence for rebuilding or validating identity before restoring applications. See the Ransomware Response and Recovery Guide.
• Management plane as a weapon: device management, hypervisor and backup consoles can destroy as quickly as they recover. The Stryker cyberattack showed one hijacked administrator account using Microsoft Intune to wipe tens of thousands of devices, turning endpoint rebuild into the critical path.
• Non-human credentials in DR: replication jobs, failover scripts and DR environments run on service accounts, API keys and certificates. Confirm they exist and work in the recovery region, that the secrets vault is available there, and that certificates will not expire during a long outage. See the Identity Provider and SSO Security Guide.

Third-party and concentration dependencies

• Map critical suppliers to services: the BIA dependency map should show which suppliers each critical service needs, including software vendors whose updates run with high privilege. On 18 July 2024 a CrowdStrike update affected an estimated 8.5 million Windows devices, which Microsoft said was "less than one percent of all Windows machines", yet it caused what Microsoft called "broad economic and societal impacts".
• Plan for a supplier outage you cannot fix: a clearing house, payroll provider or cloud region may be down for days. The Change Healthcare breach disrupted claims and payments for healthcare providers that depended on a single intermediary; continuity plans needed alternate routes and cash flow measures, not only IT recovery.
• Contract for recovery: agree supplier RTO and RPO, notification times, participation in your exercises and evidence of their own testing. See the Cyber Insurance Guide.
• Financial sector regulation: DORA (Regulation (EU) 2022/2554) requires ICT business continuity policies, response and recovery plans, backup and restoration procedures, testing and ICT third-party risk management, and the UK regime requires impact tolerances for important business services. See the DORA Guide.

Activation, crisis management and communications

• Who may activate: name the roles with authority to declare a continuity event or invoke DR, with at least two deputies each. NIST SP 800-34 states that "A senior management official, such as the CIO, has the ultimate authority to activate the plan", while a management team activates and supervises contingency operations. Any authorised person should be able to activate without waiting for the most senior one.
• Activation criteria: write objective triggers: an outage expected to exceed a defined share of the RTO, loss of a site, confirmed destructive malware, or a critical supplier declaring an incident. Ambiguous criteria cost hours of debate.
• Crisis structure: a strategic crisis team (executives, legal, communications) sets priorities; tactical and operational teams run recovery. Keep decision logs from the first hour.
• Out-of-band communications: assume corporate email, chat and the phone system may be unavailable or monitored by an attacker. Pre-provision an independent channel, an offline contact list and a printed copy of the plan.
• Stakeholder messages: prepare holding statements for staff, customers, suppliers, regulators and media. Align regulatory notification clocks with the incident response plan.
• Stand-down: define who decides to return to normal operations and how data entered in workarounds is reconciled.

Testing and exercising

• Test what NIST lists: notification procedures, recovery on an alternate platform from backup media, internal and external connectivity, performance on alternate equipment, and restoration of normal operations.
• Use free exercise material: CISA Tabletop Exercise Packages include "template exercise objectives, scenarios, and discussion questions" and an after-action report template; the NCSC's Exercise in a Box offers free tabletop exercises on ransomware, phishing and supply chain scenarios.
• Exercise the hard scenarios: IdP unavailable, directory compromised, all endpoints wiped, cloud region lost, key supplier down for a week, and the crisis team without email.
• Close the loop: after-action report, owners, due dates and a retest of what failed.

Implementing BCDR: a phased approach

1. Set scope and governance: policy, executive sponsor, continuity manager, and the list of critical business services.
2. Run the BIA: agree MTD, RTO and RPO per service with business owners and map every dependency, including identity, DNS, certificates and suppliers.
3. Measure the gap: compare current recovery capability (from real restores, not vendor specifications) with targets.
4. Choose strategies and DR patterns: manual workarounds where cheap, DR architecture per tier, immutable backups for all tiers.
5. Write plans people can use: short role-based runbooks with decision points, held offline as well as online.
6. Exercise in rings: walkthroughs and tabletops first, then functional restores of lower-tier systems, then parallel tests and failover of critical systems in planned windows with a documented failback path.
7. Maintain: review plans after organisational and system changes and after every exercise or real event.

Decision guidance

• Choosing a DR pattern: backup and restore when the RTO is a day or more; pilot light for hours; warm standby when the service must take traffic within minutes; active-active only when downtime costs justify the engineering, and only with backups behind it.
• Cloud region versus cyber scenario: multi-region designs protect against infrastructure failure, not an attacker with administrative access to both regions. Cyber recovery needs isolated, immutable copies and separate credentials.
• Small organisations: focus on SaaS and cloud provider resilience settings, immutable backups, documented manual workarounds, a contact list on paper and an annual tabletop. Large organisations need a formal BCMS, tiered DR, supplier exercises and, in regulated sectors, evidence for supervisors.

Detection and measurement

• Monitor: backup job success and immutability status, replication lag against RPO, health checks on recovery endpoints, certificate and credential expiry in DR environments, and configuration drift between production and recovery.
• Achieved versus target RTO and RPO: per critical service, from the latest test, with the share of services meeting target.
• Exercise coverage: percentage of critical services exercised in the last 12 months, by exercise type.
• Action closure: after-action items closed within their due date.
• Plan currency: plans reviewed after the last relevant change; contact lists verified in the last quarter.
• MTTR: mean time to restore service after real incidents, trended over time.
• Supplier assurance: share of critical suppliers with agreed recovery objectives and evidence of testing.

Common failure patterns

• IT-defined recovery targets: RTOs set by what infrastructure can deliver rather than by what the business can tolerate, so nobody notices the gap until an outage.
• Plans that assume a single failure: designs for a lost data centre break when ransomware hits production, backups and identity together. The Jaguar Land Rover cyberattack halted global production and showed how long recovery runs when a cyber incident reaches manufacturing and supply chain systems at once.
• Recovery tools behind the failed component: DR consoles, runbooks and password vaults that sign in through the same IdP or sit on the same network as production.
• Replication mistaken for backup: encrypted or deleted data replicated faithfully to the recovery site.
• Never failing back: failover tested but failback not, leaving the organisation running on scaled-down infrastructure for weeks.
• Stale contacts: call trees full of leavers and unchecked numbers.

Framework mapping

Practitioner checklist

• Agree MTD, RTO and RPO per critical service with business owners, and check each RTO sits inside its MTD.
• Map every critical service to its systems, data, identity services, certificates and suppliers.
• Choose a DR pattern per tier and keep immutable, isolated backups behind every replicated system.
• Design failover to use data plane actions and pre-provisioned capacity.
• Keep cloud-only break-glass accounts and confirm DR consoles work when the IdP or on-premises directory is down.
• Name the roles that can activate the plan, with deputies and objective activation criteria.
• Pre-provision an out-of-band communication channel and offline copies of plans and contacts.
• Exercise every critical service at least annually, scaling to full failover and failback for high-impact systems.
• Agree recovery objectives and exercise participation with critical suppliers.
• Report achieved versus target recovery times and action closure to the executive sponsor.

Standards and references

• ISO: ISO 22301:2019 Business continuity management systems: Requirements
• NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
• AWS: Disaster Recovery of Workloads on AWS: Disaster recovery options in the cloud
• FCA: Operational resilience
• CISA: Tabletop Exercise Packages
• NCSC: Exercise in a Box
• Microsoft Learn: Build resilience in your hybrid authentication
• Microsoft: Helping our customers through the CrowdStrike outage

Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Backup Security and Immutable Backup Guide · Incident Response Guide · DORA Guide · Break-Glass Account Guide