Business continuity and disaster recovery (BCP and DR)

Sooner or later a system goes down. The cause might be a ransomware attack, a hardware fault, a fire in a data center, a botched migration, or a single mistyped command. For a regulated company the question is never whether disruption happens. It is how fast the business gets back to work, how much data it loses on the way, and whether anyone can prove the recovery worked before the worst day actually arrives. Two related disciplines answer that question. A business continuity plan (BCP) keeps the company operating through a disruption. A disaster recovery plan (DR) restores the IT systems and data that the business runs on.

These plans matter most for finance, healthcare, critical infrastructure, and SaaS providers, where downtime is not just lost revenue but a reportable incident and, increasingly, a breach of law. ISO 22301, the international standard for business continuity management, defines continuity as the capability to continue delivering products at acceptable predefined levels after a disruption.¹ That phrase, acceptable predefined levels, is the heart of it. Continuity is not about preventing every outage. It is about deciding in advance which processes must survive, how long they can be down, and how much data you can afford to lose, then engineering and rehearsing your way to those targets. This guide explains the difference between BCP and DR, the metrics that drive both, the recovery strategies that work, and why an untested plan is closer to a liability than an asset.

This guide is part of our security program work. We build and test these plans through governance, risk, and compliance, and they connect directly to the work we do on incident response.

BCP and DR: what is the difference

The two terms are used interchangeably, but they answer different questions and live at different levels of the organization. A business continuity plan looks at the whole company. It asks how the business keeps delivering its most important services when key systems, sites, suppliers, or people are unavailable. That includes manual workarounds, alternative premises, succession of responsibilities, customer communication, and the order in which functions come back. BCP is owned by the business, not only by IT.

A disaster recovery plan is narrower and technical. It asks how to restore IT systems, applications, and data after they fail or are destroyed. DR covers backups, failover, replication, rebuild runbooks, and the sequence for bringing infrastructure back online. DR is a component of business continuity, not a substitute for it. Restoring the database does no good if nobody decided how the call center keeps answering customers in the hours before that database is back. A regulated company needs both, and it needs them to reference each other.

Disaster recovery restores the systems. Business continuity keeps the company answering its customers while the systems are down.

Start with a business impact analysis

You cannot build a credible plan by guessing which systems matter. The starting point is a business impact analysis (BIA). A BIA works through every business process and asks what happens, hour by hour and day by day, if that process stops. It quantifies the operational, financial, legal, and reputational impact of disruption over time, and it identifies the dependencies each process relies on: applications, data, third parties, key staff, and facilities.

The BIA produces two things that everything else depends on. First, a prioritized list of critical processes, so that recovery effort and budget go where the damage accrues fastest. Second, the recovery objectives for each one. A payment system that costs the business heavily within minutes of going down gets a very different target than an internal reporting tool that can wait two days. Without a BIA, companies tend to protect what is loudest rather than what is most important, and they discover the gap only during a real incident. The BIA also feeds your broader risk assessment and risk management program, because continuity is one of the responses to risks you have chosen not to accept.

RTO and RPO: the two numbers that drive everything

Two metrics turn the BIA into engineering requirements. The recovery time objective (RTO) is the maximum acceptable time a system or process can be unavailable before the impact becomes unacceptable. It answers the question: how long can we be down? The recovery point objective (RPO) is the maximum amount of data, measured in time, that you can afford to lose. It answers: how far back can we afford to recover to? An RPO of one hour means you can tolerate losing up to one hour of data, which in turn means you must capture or replicate data at least every hour.

The shorter the RTO and RPO, the more the solution costs. Near-zero RPO needs continuous replication. Near-zero RTO needs hot standby infrastructure ready to take over. That is expensive, so you do not apply it everywhere. You set the targets per system, driven by the BIA, and you accept longer recovery for the systems that can tolerate it. The table below shows how that looks across tiers of system criticality. Treat the figures as illustrative tiers, not a standard.

The discipline is to set these numbers honestly. A business owner will always say the RTO should be zero. The BIA forces a real conversation about what each minute of downtime costs against what near-instant recovery costs to provision and maintain. The output is a defensible set of targets you can both design against and test against.

Recovery strategies that actually work

Once you have the targets, you choose the technical strategies that meet them. They range from simple backups to fully redundant infrastructure, and most companies use a mix matched to system tiers.

• The 3-2-1 rule is the baseline for backups: keep at least three copies of your data, on two different types of media, with one copy stored off-site. A modern extension, 3-2-1-1-0, adds one copy that is offline or immutable and zero errors after a verified restore test.
• Immutable and offline backups protect against ransomware. If a backup can be reached and encrypted from the production network, it is not a backup you can rely on. Air-gapped or write-once storage keeps a clean copy beyond the attacker's reach.
• Redundancy removes single points of failure inside the live environment: clustered servers, redundant power and network paths, and load balancing so that one component failing does not take the service down.
• Standby sites give you somewhere to run when the primary site is lost. A hot site is fully provisioned and near-instant. A warm site has infrastructure ready but needs data and configuration. A cold site is space and power only, and takes longest to bring up.
• Cloud and replication strategies use a second region or provider for failover, with synchronous replication for near-zero RPO or asynchronous replication where a small data loss window is acceptable and cheaper.

No single strategy is correct for the whole estate. Tier 1 systems may justify a hot standby site with synchronous replication, while Tier 4 systems are fine with a nightly backup. The strategy mix is an output of the RTO and RPO targets, not a vendor preference.

Building and maintaining the plan

A good plan is concrete, assigned, and rehearsed. It names people and roles, not just systems. It is short enough that someone can follow it under pressure, and it lives somewhere reachable even when the main systems are down. The following steps describe a workable build process.

1. 01
   Run the business impact analysis

   Identify critical processes and their dependencies, and quantify the impact of disruption over time. This produces your priorities and your recovery targets.
2. 02
   Set RTO and RPO per system

   For each critical system, agree the maximum downtime and the maximum tolerable data loss with the business owner, not just IT.
3. 03
   Choose recovery strategies

   Match each system to a strategy that meets its targets: backups, redundancy, standby site, or cloud failover. Cost the choices against the impact they avoid.
4. 04
   Write the procedures

   Document who declares an incident, who does what, the order systems are restored, how to fail over, and how the company communicates with staff, customers, and regulators.
5. 05
   Protect and separate the backups

   Store backups so they are not reachable from the same network or credentials as production, and keep an offline or immutable copy out of reach of the same attack.
6. 06
   Test, then maintain

   Rehearse the plan on a schedule, fix what breaks, and update RTO, RPO, contacts, and dependencies whenever the environment changes.

The maintenance loop matters as much as the build. Systems change, people leave, and suppliers are swapped, so a plan written eighteen months ago describes an environment that no longer exists. Continuity is a living program, not a document written once for an audit.

Why testing is mandatory, not optional

A plan that has never been tested is an assumption, not a capability. Testing comes in two main forms, and a mature program uses both. A tabletop exercise walks the response team through a realistic scenario in a meeting room. It checks that the plan is understood, that roles are clear, that decision authority is unambiguous, and that the contact lists are current. Tabletops are cheap, low-risk, and they surface most of the gaps in coordination and communication.

A live exercise, sometimes called a failover or restore test, actually executes the recovery. You restore a backup to a clean environment and confirm the data is intact and usable. You fail over to the standby site and measure how long it really takes against the RTO. Live tests are where comfortable assumptions die: the restore that takes far longer than expected, the backup that is missing a critical database, the runbook that references a server that was decommissioned. The NIST Cybersecurity Framework treats recovery planning and the testing of recovery activities as a core function, not an afterthought.² The point of testing is to fail in a controlled exercise instead of during a real outage.

The ransomware tie-in and the resilience regulators now require

Continuity and recovery are now the front line of ransomware defense. Modern ransomware crews deliberately hunt for and destroy backups before they trigger encryption, because they know an organization with a clean, tested restore can refuse to pay. Immutable, off-site, and offline backups, combined with a tested restore process and a rehearsed incident response plan, are what let a company recover without negotiating with criminals. Continuity planning and incident response are two halves of the same readiness.

Regulation has caught up with this reality. The NIS2 Directive (EU) 2022/2555 requires business continuity, including backup management and disaster recovery, as part of the baseline risk-management measures for essential and important entities. For the financial sector, DORA, Regulation (EU) 2022/2554, goes further and is explicit. It requires firms to maintain an ICT business continuity policy and ICT response and recovery plans, to set recovery objectives, and to test those plans, including scenario-based and, for major institutions, advanced testing. ISO 22301 and ISO/IEC 27001:2022 provide the recognized framework auditors expect to see behind those obligations. If you are scoping the financial-sector requirements, the DORA compliance checklist and our DORA compliance overview break them down, and NIS2 vs DORA explains where the two regimes diverge.

How Raptoric helps

We help regulated companies turn continuity from a binder into a tested capability. We run the business impact analysis, set realistic RTO and RPO targets with your business owners, design recovery strategies that fit your budget and risk, and write procedures people can actually follow under pressure. Then we test them, through tabletop and live exercises, and tie the program to your obligations under NIS2, DORA, and ISO 22301. We deliver this through governance, risk, and compliance and connect it to readiness work via incident response. Book a scoping call.