Disaster recovery planning: Steps, strategies & testing

Disaster recovery planning is the process of preparing an organisation to restore critical IT systems, data, and operations after a disruption, whether caused by a cyberattack, hardware failure, natural disaster, or supplier outage. A disaster recovery plan (DRP) defines which systems to recover, in what priority order, and within what timeframes, expressed as Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) anchored to a business impact analysis (BIA). The result is a documented, tested, and maintained plan that an organisation can actually execute under pressure, not just present to an auditor.

The rest of this guide unpacks what a defensible disaster recovery planning process looks like, the recovery objectives and strategies that shape it, the regulatory bar regulated sectors now face, and where most plans quietly break.

What is disaster recovery planning?

Disaster recovery planning is the structured process of preparing to restore IT systems, applications, and data after a disruption. It defines which systems matter most, the order in which they are recovered, the maximum tolerable downtime and data loss for each, and the people and procedures that execute the recovery. The output is a documented, tested, and maintained plan.

That definition sounds tidy. In practice, disaster recovery (DR) planning is where abstract risk appetite collides with concrete dependency chains: the database that three customer-facing services silently rely on, the authentication system without which nothing else comes back, the backup that restores in eighteen hours when the business assumed four. The NIST SP 800-34 Rev. 1 contingency planning guide frames recovery in three phases (Notification/Activation, Recovery, Reconstitution), a useful reminder that getting systems running is not the same as returning to steady-state operations.

DR sits inside a wider resilience picture. It is one discipline among several, and confusing them is a common source of plans that look complete on paper but leave gaps in execution.

You can read about our learning from Disaster Recovery Journal (DRJ) Spring 2026

Disaster recovery vs. business continuity vs. incident response

These three terms get used interchangeably, and the conflation causes real operational confusion when an incident is live. They answer different questions.

Disaster recovery answers: how do we get the technology back? Business continuity is the broader, holistic process. It begins with a business impact analysis, informs the development of business continuity plans and recovery strategies, and helps the organization keep critical operations running during and after a disruption. Incident response handles immediate detection and containment of an event, whether a ransomware intrusion or a failed change. DR restores the systems once the bleeding has stopped.

ISO 22301:2019 Clause 8.4 frames continuity plans and procedures within a wider business continuity management system, with DR as the ICT-recovery component. The ICT readiness standard ISO/IEC 27031 deals specifically with the technical layer that DR planning operationalises. None of these disciplines retire the others. A mature program runs all three in concert, and the difference between business continuity and disaster recovery is worth getting straight before you write a line of plan.

Read our blog on what is business continuity

Why disaster recovery planning matters

The case for DR planning is not theoretical. It rests on the measurable cost of downtime, a regulatory bar that has risen sharply in financial services, and a dependency complexity that turns a single vendor's bad update into a global outage. Recent events have made all three concrete.

Real example of downtime cost

The July 2024 CrowdStrike outage is the clearest recent example. A faulty sensor update sent 8.5 million Windows machines into boot loops simultaneously. Organisations with tested, documented recovery runbooks restored operations within hours. Those without them were still manually reimaging machines days later - not because the fix was complex, but because no one had documented the recovery procedure in advance.

The cascade was global. Airlines issued ground stops. Hospitals reverted to paper records. Banks and pharmacies lost service. Fortune 500 companies absorbed an estimated $5.4 billion in direct losses. The practitioner takeaway is uncomfortable: the firms that recovered fastest were not the ones with the best documents. They were the ones whose recovery runbooks accounted for the case where the endpoint itself cannot reach a management server, because their teams had walked that sequence before.

The firms with the best documents on the morning of the 19th still spent days dispatching staff to hand-fix laptops in airport terminals.

Regulatory and breach pressure

Regulators have stopped accepting documented-but-untested recovery. Financial regulators across the EU, UK, and Australia now expect firms to demonstrate recovery within defined tolerances under severe but plausible disruption, not merely to own a binder.

The breach data reinforces the financial case. The global average cost of a data breach in 2025 was $4.44 million according to IBM and the Ponemon Institute. And practitioners themselves rank the threat clearly: in the BCI Horizon Scan Report 2025, cyber security was the top long-term concern for 63.6% of business continuity professionals over a five-to-ten-year horizon. Where a 1990s DR plan rehearsed flood and fire, a 2026 plan has to rehearse a ransomware-driven full-environment rebuild.

Core components of a disaster recovery plan

A disaster recovery plan (DRP) is a formal document that defines how an organisation will restore critical systems, data, and operations after a disruption. It specifies recovery objectives (RTO and RPO), assigns roles and responsibilities, documents recovery procedures by system tier, and sets communication protocols for use during an active incident.

A workable plan is more than a backup schedule. It codifies recovery objectives, named roles, the asset and dependency map, and the communication procedures that hold during the chaos of an actual event. Strip any one of these out and the plan develops a blind spot that only surfaces mid-incident. Organisations that have outgrown backup-only tools can compare Datto alternatives for business continuity.

Read our step-by-step how to build an IT disaster recovery plan

Recovery objectives: RTO and RPO

Two numbers anchor every DR plan. The Recovery Time Objective (RTO) is the maximum tolerable downtime for a system before the impact becomes unacceptable. The Recovery Point Objective (RPO) is the maximum tolerable data loss, expressed as a window of time, which dictates how frequently you must replicate or back up.

These objectives are set per system tier, not globally. A customer-facing payment service and a back-office reporting tool do not warrant the same investment.

Regulators increasingly require these to be quantitative, not aspirational. DORA Article 11 requires financial entities to put response and recovery plans in place, and Article 12 sets expectations for backup policies with defined recovery methods. Setting an RTO you have never validated against a real restore is how firms discover, at the worst possible moment, that their objective was fiction.

Read our blog on what RTO and RPO actually mean for your recovery planning

RPO and RTO in disaster recovery planning

Recovery Time Objective and Recovery Point Objective are the two metrics that translate business tolerance into technical requirements. The section above introduced them at the component level. This section covers how to set, validate, and maintain them as the backbone of your disaster recovery planning process. For a full treatment of both metrics, see our guide to RTO and RPO meaning.

How to set RTO and RPO targets

RTO and RPO targets are derived from the business impact analysis, not from IT preference. The BIA quantifies what each hour of downtime costs for a given business function, and what each hour of data loss means in rework, regulatory exposure, or customer impact. Those numbers drive the targets.

The process: interview each process owner to establish maximum tolerable downtime (which becomes the RTO) and maximum tolerable data loss (which becomes the RPO). Then validate both against the actual recovery capability of the infrastructure. An RTO of one hour is meaningless if the restore process takes four.

Common mistakes when setting targets:

• Setting a single RTO for the entire organisation rather than per system tier. A reporting dashboard and a payment gateway do not warrant the same investment.
• Setting aspirational targets without testing. An untested RTO is a guess, and guesses fail under pressure.
• Ignoring dependency chains. A Tier 1 system that depends on a Tier 3 database inherits the Tier 3 recovery time unless you address the dependency.

RTO and RPO by industry

Different industries face different tolerance profiles driven by their regulatory environment, customer expectations, and operational characteristics. The table below shows typical targets, not universal rules, because the right target always comes from your own BIA.

The gap between documented targets and tested capability is where disasters become crises. The only way to close it is regular exercises and simulations that measure actual restore time against the stated objective.

Recovery teams, asset inventory, and communication plans

Objectives mean nothing without people who own them. A plan needs a defined DR team with clear role assignments, ideally on a RACI basis so that during an incident nobody is debating who declares a disaster or who authorises a failover.

The second pillar is an asset and dependency inventory that maps critical systems to the infrastructure, data stores, and third parties they rely on. The Ready.gov IT disaster recovery guidance treats this inventory and the supporting data backup plan as foundational, and rightly so: you cannot sequence a recovery you have not mapped.

Third, the plan must specify internal and external communication procedures, including activation and escalation triggers. The DRII Professional Practices cover plan development under Practice 6 and crisis communications under Practice 9. A recovery effort with no communications discipline produces a second crisis on top of the first, as customers and regulators alike demand answers nobody is coordinated to give. Our IT crisis management guide covers roles, escalation paths, and activation criteria for technology-driven disruptions.

Recovery procedures and runbooks

Recovery procedures are the step-by-step instructions for restoring each system in scope - specific enough that someone unfamiliar with the environment can execute them under pressure. A runbook for a critical database system should include the exact restoration sequence, authentication requirements, dependency check order, and validation steps to confirm recovery success. Generic guidance is not a recovery procedure. If the runbook requires interpretation, it will slow recovery at the worst possible moment.

The disaster recovery planning process, step by step

Building a plan that holds up follows a repeatable sequence. Here is the process mapped against established standards, so each step has a defensible source rather than vendor folklore.

1. Conduct a risk assessment to identify the threats most likely to disrupt your systems.
2. Run a business impact analysis to quantify downtime tolerance and map dependency chains.
3. Set RTO and RPO targets per system tier from the BIA outputs.
4. Select recovery strategies matched to each tier's objectives and budget.
5. Document the plan in language executable under stress, not just for an audit.
6. Test the plan through tabletop, simulation, and full failover exercises.
7. Maintain it by updating after every change, test, and real incident.

This maps closely to the seven-step contingency planning process in NIST SP 800-34.

Risk assessment and business impact analysis

The business impact analysis is the foundation, and it is non-negotiable. It identifies critical services, quantifies what losing each one costs per unit of time, and traces the dependency chains that determine recovery sequence. The BIA methodology feeds directly into your RTO/RPO targets and strategy selection. Skip it, and you are guessing.

The BIA step in NIST SP 800-34 (Section 3.2) and DRII Practice 3 both treat the BIA as the analytic engine of recovery planning. The inputs are interviews with process owners, system dependency data, and financial impact estimates. The analytic step is ranking services by criticality and tolerable downtime. The artifact is a prioritised list of services with recovery objectives attached. The decision it drives is where to spend the recovery budget.

Strategy selection, documentation, testing, and maintenance

With objectives set, you select recovery strategies tier by tier. The expensive options go to Tier 0; the cheap ones suffice for Tier 3. Then you document procedures clearly enough that someone other than the author can execute them at 3 a.m. under pressure.

The failure mode here is treating testing and maintenance as something to schedule later. They are not the tail of the process. They are where the plan either becomes real or stays theoretical, and they belong in the project plan from day one, with named owners and a cadence. The contingency planning lifecycle in NIST SP 800-34 explicitly bakes testing, training, and maintenance into the lifecycle rather than bolting them on.

Disaster recovery strategies compared

Choosing the right disaster recovery strategy means matching recovery speed to cost tolerance - and to the criticality of each system tier. There is no single right answer, only a right answer for each tier. Spend active-active money on a Tier 3 reporting system and you have wasted budget; run backup-and-restore on a Tier 0 payment service and you have an outage measured in hours when the business can tolerate minutes.

Backup-and-restore, pilot light, warm standby, and active-active

The four canonical strategies sit on a spectrum from cheapest-slowest to most-expensive-fastest.

The Ready.gov data backup guidance treats backup as the floor, not the ceiling. Backup alone is not disaster recovery: a backup that takes thirty hours to restore does not meet a four-hour RTO. The distinction between backup and DR trips up more programs than it should.

Cloud DR: DRaaS and multi-region approaches

Cloud has reshaped the cost curve. Disaster Recovery as a Service (DRaaS) shifts standby infrastructure from a capital expense you maintain to a consumption model you pay for largely when you fail over. Multi-region and hybrid-cloud designs reduce single-site and single-provider risk. The cloud disaster recovery options are now the default starting point for many mid-market teams.

But cloud DR is not immune to the failure it is meant to solve. The Microsoft Azure outages across 2023 and 2024 demonstrated this: a January 2023 faulty router configuration update disrupted compute, storage, and collaboration tools across multiple continents, and a July 2024 incident combined a DDoS attack with a regional power flicker into a chain reaction hitting Azure regions in North America, Europe, and Asia, with dependent SaaS platforms suffering secondary outages. The lesson is concentration risk. If your primary and your recovery both sit in one provider's footprint, a provider-level failure takes both. Spread the dependency, or accept the exposure consciously.

Industry-specific regulatory requirements

Regulated sectors face explicit, enforceable expectations for tested recovery, and the bar differs by jurisdiction and industry. The common thread across the major regimes is that documented recovery no longer satisfies anyone; recovery must be demonstrated.

Financial services: DORA, FCA, PRA, and APRA

Financial services carries the heaviest regulatory load, and four regimes dominate.

DORA Article 11 requires EU financial entities to maintain ICT business continuity and recovery plans and to test them, including against cyber-attack scenarios. The UK takes a tolerance-based approach: FCA PS21/3 requires firms to identify important business services and set impact tolerances under SYSC 15A.2, and the parallel PRA SS1/21 expects firms to remain within those tolerances through severe but plausible disruption. In Australia, APRA CPS 230, effective 1 July 2025, requires regulated entities to maintain critical operations within tolerance and to manage service-provider risk.

Tested recovery, not just documented recovery, is the thread running through all four.

Manufacturing and critical infrastructure considerations

Manufacturing and critical infrastructure introduce constraints that pure IT shops rarely face. Operational technology and industrial control systems recover differently from corporate IT, often requiring a manual fallback to keep a physical process safe while systems come back. You cannot reboot a chemical reactor the way you reboot a web server.

Third-party and supply-chain dependency risk is acute here. The DP World Australia cyberattack in November 2023, which forced manual operations across four ports and stranded roughly 30,000 containers, illustrates how an IT compromise becomes a physical-logistics crisis when the recovery sequence has to respect real-world cargo flows. The ICT readiness guidance under ISO/IEC 27031 provides a useful baseline, but recovery sequencing in these environments is shaped first by physical-process safety, then by IT convenience. Mapping those critical dependencies before an incident is what makes a controlled shutdown possible at all.

Healthcare: HIPAA, patient safety, and clinical system recovery

Healthcare DR planning is shaped by two forces: regulatory requirements under HIPAA and the direct patient safety implications of system downtime. When an electronic health record system goes down, clinicians revert to paper, medication orders lose their safety checks, and lab results stop flowing. The Change Healthcare ransomware attack of February 2024 demonstrated the scale: a single vendor processing roughly half of US medical claims was compromised, affecting 190 million patient records and forcing pharmacies, hospitals, and insurers into manual workarounds for weeks.

DR plans in healthcare must account for clinical workflow continuity (not just system restore), data integrity for patient records where loss or corruption has direct safety consequences, and the regulatory reporting obligations that follow any breach involving protected health information. Testing should include clinical staff, not just IT, because the manual fallback procedures are as critical as the technical restore.

SaaS and technology: SLA-driven recovery in multi-tenant environments

SaaS providers face a DR challenge that most industries do not: a single outage affects every customer simultaneously, and recovery is measured against contractual SLAs that carry financial penalties. The architecture itself is the risk concentrator. A database failover that takes thirty minutes means thirty minutes of downtime for thousands of tenants.

DR planning for SaaS must address multi-region redundancy (active-active or warm standby, rarely backup-and-restore), automated failover that meets the SLA without human intervention at 3am, and customer communication protocols that trigger before support tickets flood in. The cloud disaster recovery guide covers the infrastructure patterns in detail. The business continuity layer on top of that, who communicates what to which customers and when, is equally important and more often neglected.

Keeping your DR plan current and tested

The gap between a documented plan and an executable one is where most recoveries fail. Closing it takes deliberate testing and disciplined maintenance, and it is the part of the lifecycle that gets cut first when budgets tighten. That is exactly backwards.

Testing types and frequency

Not all tests prove the same thing, and a program that runs only one type has a false sense of confidence. Three types serve distinct purposes:

• Tabletop exercises walk the team through a scenario verbally, testing decision-making, roles, and escalation, at low cost and low disruption.
• Simulations exercise specific recovery procedures against partial or isolated systems.
• Full failover tests actually cut over to the recovery environment, which is the only test that proves the recovery sequence end to end.

The critical point: test the recovery sequence, not just whether backups exist. Plenty of organizations confirm their backups run nightly and never confirm they can restore them in dependency order. DRII Practice 8 covers exercise and testing as a discipline, and regulated firms have no choice. DORA's testing obligations require testing at least annually, including cyber scenarios.

Return to CrowdStrike for the lesson. The firms that struggled most on 19 July 2024 were not short of documents. They were short of practice at the specific failure where the endpoint cannot reach the network to receive a fix, so the recovery had to happen by hand on each machine. A plan that exists on paper but whose recovery order nobody has rehearsed is a liability dressed up as preparedness.

See fortivs exercise and simulation module to keep plans updated.

Maintenance, post-incident review, and the human toll

A plan decays the moment it is written. Systems change. Vendors change. People leave. The maintenance discipline is to update after every significant change, after every test, and after every real incident, then feed the post-incident review back into the next revision. This is straightforward continuous-improvement loop logic, and it is where programs that look mature on a compliance dashboard quietly stagnate.

There is a human dimension regulators and boards underweight. The latest BCI horizon scan found that 35.8% of disruptions negatively impact staff morale, wellbeing, and mental health. A botched recovery does not just cost money; it burns out the people you need for the next one.

Automation changes the maths on both cost and speed. Organizations using AI and automation extensively save nearly $1.9 million on breach costs compared with those that do not, per IBM's 2025 figures, and faster, more reliable recovery is a meaningful part of that gap.

From static plans to living resilience

A DR plan that lives in a static document and never gets tested fails when it is actually needed. The goal is the opposite: a plan that is built from a real business impact analysis, tested against the failure modes that actually occur, and maintained as systems and threats evolve. Documented recovery is the starting point. Demonstrated recovery is the destination, and the regulators, the breach data, and every named incident in this guide point the same way.

The practitioners who recover well are not the ones with the thickest binders. They are the ones who have walked the recovery sequence, found where it breaks, and fixed it before the real event. Treat the plan as a living process, not a compliance artefact, and connect it to the wider disaster recovery capability and the business continuity management program it sits within. Cascading failures, in particular, demand plans designed for cascading crises rather than single-point ones.

What disaster recovery planning covers: a definition for featured-snippet capture

Disaster recovery planning is the structured discipline of identifying critical IT systems and data, determining how quickly they must be restored after a disruption (RTO), how much data loss is tolerable (RPO), and documenting and testing the procedures that deliver that restoration. It produces a living plan that tells specific people exactly what to do, in what order, using what tools, when normal operations fail.

The key word is *planning*, not plan. The document is an artefact; the planning process is what makes it defensible. Organisations that treat DR as a one-time documentation exercise consistently underperform those that run regular exercises, update dependencies after system changes, and assign clear ownership to each recovery procedure.

A complete DR planning programme covers five things:

• Scope and criticality classification: which systems, applications, and data sets are in scope and how they are tiered by business impact
• Recovery objectives: RTO and RPO per tier, derived from BIA findings rather than estimated
• Recovery strategies: the technical approach (backup restore, warm standby, cloud failover, etc.) matched to each tier's objectives and cost constraints
• Documented procedures: step-by-step runbooks tested under realistic failure conditions, not theoretical walkthroughs
• Governance and maintenance: defined review cycles, ownership, and exercise cadence to keep the plan current as the environment changes

The disaster recovery planning process, aligned to ISO 22301 and NIST SP 800-34

The two most widely referenced frameworks for DR planning are ISO 22301:2019 (business continuity management systems) and NIST SP 800-34 Rev. 1 (contingency planning guide for federal information systems). They use different language but describe the same underlying logic.

ISO 22301:2019 Clause 8.4 requires organisations to establish continuity procedures that specify recovery priorities, resource requirements, and communication arrangements. NIST SP 800-34 Rev. 1 structures IT contingency planning across seven stages: policy, BIA, preventive controls, recovery strategies, plan development, training and testing, and plan maintenance. Together, they provide a practical checklist for any organisation building or auditing a DR programme.

Step 1: Establish scope and policy

Define which systems, data, and locations the DR plan covers. Align the scope to the organisation's overall business continuity policy (ISO 22301:2019 Clause 5.3). Without a clear scope, plans grow to cover everything and become unexecutable.

Step 2: Conduct the business impact analysis

The BIA is the foundation. It identifies critical business functions, maps the systems and data they depend on, and quantifies the financial, operational, and regulatory consequences of downtime at different durations. RTO and RPO targets emerge from BIA findings, not from IT preferences.

In most organisations, BIA data is scattered across spreadsheets, HR systems, IT asset registers, and application owners' heads. Platforms like Fortiv automate data collection by pulling from connected HR, IT asset management, and ERP systems, which significantly reduces the time between starting a BIA and having defensible outputs.

Step 3: Identify and assess risks

A risk assessment maps the threats that could trigger a DR event: ransomware, hardware failure, power loss, supplier outage, natural disaster. Each threat is assessed for likelihood and potential impact, feeding the prioritisation of preventive controls and informing which recovery strategies are cost-justified (NIST SP 800-34 Rev. 1, Section 2.2).

Step 4: Select recovery strategies

For each system tier, select the recovery approach that meets the BIA-derived RTO/RPO at acceptable cost. Strategy selection is covered in detail in the section below on DR approaches (hot, warm, cold, cloud-based).

Step 5: Develop plan documentation and runbooks

Document recovery procedures at a level of detail that allows someone unfamiliar with the system to execute them under stress. Runbooks should include step-by-step technical instructions, escalation paths, communication scripts, and decision trees for common failure variants. Generic "restore from backup" language is not a runbook.

Step 6: Train, test, and exercise

ISO 22301:2019 Clause 8.5 requires organisations to exercise and test continuity procedures. NIST SP 800-34 Rev. 1 Section 3.5 specifies tabletop exercises, functional exercises, and full-scale tests as progression points. Testing must cover realistic failure scenarios, not just the clean recovery path. The CrowdStrike outage of July 2024 illustrated this: organisations with well-documented plans still took days to recover because their runbooks had not rehearsed an endpoint agent preventing boot.

Step 7: Review and maintain

Plans degrade as systems change. ISO 22301:2019 Clause 9.1 requires organisations to monitor, measure, and evaluate the performance of their BCM system. In practice, this means reviewing DR plans after every major infrastructure change, after every exercise, and on a fixed annual cycle at minimum. Automated review reminders and plan expiry tracking, as offered in Fortiv's plan lifecycle management module, help ensure plans don't silently go stale.

Sources: ISO 22301:2019 Clauses 5.3, 8.4, 8.5, 9.1; NIST SP 800-34 Rev. 1 Sections 2.2, 3.5 (National Institute of Standards and Technology, 2010).

DR planning approaches compared: hot, warm, cold, and cloud-based

Choosing a recovery strategy is fundamentally a cost-versus-speed decision, applied per system tier. The four main approaches sit on a spectrum.

Hot site (active-active)

A hot site runs a fully synchronised, live duplicate of production infrastructure. Failover is near-instantaneous (seconds to low minutes). It is the most expensive approach and is typically reserved for Tier 1 systems where even minutes of downtime carry significant financial or regulatory consequences, such as payment processing, trading platforms, or core clinical systems.

RTO: seconds to minutes. RPO: near-zero (synchronous replication). Cost: highest.

Warm site (warm standby / pilot light)

A warm site keeps infrastructure provisioned and partially running but not at full production capacity. A pilot light variant maintains only the minimum core components live, with the remainder started on demand during a DR event. Failover typically requires minutes to low hours depending on the degree of pre-provisioning.

RTO: minutes to a few hours. RPO: minutes (asynchronous replication). Cost: moderate.

Cold site

A cold site provides physical space and basic infrastructure (power, network, racks) but no pre-provisioned systems. Recovery involves sourcing, configuring, and restoring hardware and software from scratch. Cold sites are rarely appropriate for Tier 1 or Tier 2 systems given modern RTOs, but remain cost-effective for archival or low-criticality workloads.

RTO: hours to days. RPO: hours (dependent on backup frequency). Cost: lowest.

Cloud-based DR and DRaaS

Cloud DR uses public cloud infrastructure (AWS, Azure, GCP) or a managed Disaster Recovery as a Service (DRaaS) provider to replicate workloads and enable rapid failover without maintaining physical secondary sites. Cloud approaches can deliver warm-standby economics at near-hot recovery speeds for many workload types, and are increasingly the default for organisations migrating away from on-premises data centres.

Key considerations for cloud DR include egress costs during large-scale failover events, latency implications for latency-sensitive applications, and ensuring DR runbooks account for cloud-specific failure modes (availability zone outages, IAM permission issues) rather than simply transposing on-premises procedures.

RTO: minutes to low hours (dependent on configuration). RPO: seconds to minutes. Cost: variable; pay-as-tested models can reduce idle costs significantly.

Matching strategy to tier: The output of this analysis should be a system-tier matrix where each tier has an assigned strategy, documented rationale, tested RTO/RPO evidence, and a named owner. If your DR plan does not include this matrix, it is a gap worth closing before the next audit.

Sources: NIST SP 800-34 Rev. 1 Section 3.4 (recovery strategy selection); ISO/IEC 27031:2011 Clause 8 (ICT readiness for business continuity).

Who owns disaster recovery planning: roles and responsibilities in enterprise teams

DR planning fails when ownership is assumed rather than assigned. In most organisations, responsibility is fragmented across IT, risk, and business functions, and no one is accountable end-to-end until something goes wrong.

Chief Information Officer or Chief Technology Officer

The CIO/CTO holds executive accountability for IT resilience and DR programme investment. They approve DR strategy, set recovery objectives at the organisational level, and are accountable to the board and regulators for the programme's maturity. In regulated firms, the CIO/CTO is typically the named individual responsible for technology risk under frameworks like DORA Article 5 (ICT risk management governance).

IT and infrastructure leads

IT operations and infrastructure teams own the technical recovery procedures: backup configuration, replication monitoring, failover runbooks, and recovery environment maintenance. They are the primary authors and executors of system-level runbooks and are responsible for ensuring technical documentation stays current after changes.

Business continuity manager

The BCM manager coordinates the overall programme, ensuring DR plans align with the broader business continuity management system. They own the BIA process, facilitate DR exercises, and manage plan review cycles. In organisations using a platform like Fortiv, the BCM manager typically administers the plan lifecycle, exercise scheduling, and compliance mapping.

Information security / CISO function

The CISO or security team owns the intersection of DR planning and cybersecurity: ensuring that recovery environments are not themselves compromised, that backup integrity is verified, and that incident response and DR procedures are coordinated (not duplicated). Ransomware recovery, in particular, requires close coordination between IR and DR to avoid restoring from an infected baseline.

Application and business process owners

Each critical system or process should have a named business owner who is accountable for validating that the BIA-derived RTO/RPO for their area reflects actual business tolerance, reviewing runbooks for accuracy, and participating in tabletop exercises. Plans that are owned entirely by IT without business-owner sign-off routinely contain recovery sequences that do not match operational reality.

Data protection officer / legal and compliance

The DPO and compliance function own the regulatory obligations dimension: ensuring DR plans satisfy requirements under DORA, ISO 22301, HIPAA, or applicable sector regulations, and that data recovery procedures comply with data protection obligations (for example, ensuring personal data is not unintentionally replicated to non-compliant jurisdictions during a failover).

A common gap: Many organisations assign DR ownership to IT without formally engaging business process owners. The result is technically correct runbooks that recover systems in an order that does not reflect business priority, because no one with business context reviewed the recovery sequence.

Common gaps found during DR audits

DR audits consistently surface the same failure patterns, regardless of organisation size or sector. Understanding them in advance is more useful than discovering them under examiner pressure.

1. RTO and RPO targets not derived from a current BIA

The most pervasive gap: recovery objectives set years ago by IT, never validated against actual business impact data, and no longer reflective of current dependencies or revenue concentration. Regulators and auditors increasingly ask to see the BIA evidence behind each RTO/RPO pair.

2. Runbooks written at the wrong level of detail

Plans that say "restore database from backup" without specifying which backup, on what system, using what credentials, in what sequence, and with what validation checks are not executable. Under stress, at 3 a.m., a technician who was not involved in writing the plan will not be able to interpret an ambiguous instruction correctly.

3. Dependencies not mapped below the application layer

Application-level recovery sequences frequently fail because a shared service below them, an authentication system, a certificate authority, a secrets manager, was not included in the recovery scope. Dependency mapping needs to extend to infrastructure, network, and third-party services, not just named applications.

4. Backups tested for creation, not restoration

Organisations verify that backup jobs complete successfully but rarely test full restoration under realistic conditions (time pressure, cold environment, partial data). Backup jobs can succeed for months while the restore process is broken. NIST SP 800-34 Rev. 1 explicitly requires recovery testing that validates restoration, not just replication.

5. Plans not updated after infrastructure changes

A DR plan is accurate on the day it is written and degrades from that point. Cloud migrations, application upgrades, network reconfigurations, and new SaaS dependencies routinely invalidate existing runbooks. Without a process that links change management to DR plan review, plans drift from reality silently.

6. Exercise scope too narrow

Tabletop exercises that only test the "clean" recovery scenario, where all staff are available, all systems respond as expected, and the incident is a known type, do not build real recovery capability. Auditors under DORA and ISO 22301 increasingly expect evidence of exercises that test degraded conditions: loss of key personnel, partial infrastructure failure, and scenarios the organisation has not previously rehearsed.

7. No documented evidence of testing outcomes

Passing a DR exercise is not enough; the evidence must be documented and retained. Regulators expect to see exercise reports, findings logs, remediation tracking, and improvement timelines. Organisations that run exercises but do not document outcomes cannot demonstrate programme maturity during an examination.

Sources: NIST SP 800-34 Rev. 1 Sections 3.4, 3.5 (National Institute of Standards and Technology, 2010); ISO 22301:2019 Clauses 8.4, 8.5, 9.1; DORA Article 11 (Regulation (EU) 2022/2554).