Skip to content
All articles

BCP & DR: RTO, RPO, Tiering & Risk Assessment

Dean Jain

Dean Jain

Senior Staff Software Engineer · Enterprise AI, Data & Cloud Architect

· 7 min read

BCPDisaster RecoveryResilienceIT Management
---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
    DIS["💥 Disaster"]:::danger --> DR["🖥️ Disaster Recovery<br/>restore IT resources<br/>(servers, storage, networks, data)"]:::obs
    DR --> BC["🏢 Business Continuity<br/>keep the business operating<br/>(minimal / no downtime)"]:::good
    classDef danger fill:#FFB3B3,stroke:#D14545,stroke-width:2px,color:#0F172A
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
    classDef good fill:#BFEFC8,stroke:#3FA34D,stroke-width:2px,color:#0F172A

Figure 1: DR sits inside BC. Disaster recovery restores the IT resources; business continuity keeps the whole business operating.

“DR” and “BCP” get used interchangeably, and that conflation is exactly why so many continuity plans cover the servers and forget the business. They’re related but not the same. Disaster recovery restores IT resources servers, storage, networks, data. Business continuity is the bigger goal: keeping the business operating with minimal or no downtime. DR is a subset of BC. Get the relationship right, drive both off a risk assessment that tiers what matters, and make it measurable with RTO and RPO targets. Here’s the working model.

TL;DR

  • DR ≠ BC. Disaster recovery restores IT resources; business continuity keeps the whole business running. DR is the IT half of BC: necessary, not sufficient.
  • Risk drives everything. The lifecycle is identify, assess, plan, implement, monitor. You protect in proportion to risk, not uniformly.
  • Tier your functions. Tier 1 = mission-critical (recover in minutes/hours), Tier 2 = important (next increment), Tier 3 = non-essential (days/weeks). Tiering is how you decide what to save first.
  • Make it measurable with RTO and RPO. RTO is how fast you must be back. RPO is how much data loss you can tolerate. These targets turn “critical” into numbers.
  • It’s an ongoing process with people. A cross-functional DR team, senior-management support, and annual review/testing not a binder you write once.

1. DR vs BC, the distinction that matters

The objective of disaster planning is to create, document, test and update a continuity plan. It should allow timely recovery of critical operations, minimize losses, and satisfy whatever regulator you answer to. HIPAA is explicit about it: a contingency plan, a data backup plan and a disaster recovery plan are all required, not optional. Inside that, two things often blurred:

  • Disaster recovery addresses recovering key organizational resources primarily IT: servers, storage, networks, and data. Its ultimate goal is to restore the operations and resources critical to the business after a disaster. It’s the technical restoration.
  • Business continuity is the strategy that lets the business operate with minimal or no downtime. BC planning is granular. It covers how the business as a whole keeps functioning, meaning people, facilities, suppliers and customers, not just how the data center comes back.

So DR is the IT component of BC, and NIST treats the two as coordinate plans rather than one nested inside the other.

You can restore every server and still fail continuity, if staff can’t reach a building, suppliers are cut off, or customers can’t be served. That’s why disaster planning is an ongoing process requiring senior-management support not a one-time IT project. And it runs on the risk-management lifecycle. Identify risks and exposure, assess their impact, plan control strategies, implement them, then monitor continuously. Reduce the number and impact of threats; that’s the whole point.

2. Risk assessment: layers, tiering, and RTO/RPO

You can’t protect everything equally. So the plan starts with a risk assessment that determines how sensitive the organization is to any given event, and all potential disasters get considered, even the far-fetched ones. A useful way to organize the threats is five layers, widening from the world to the desk:

---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart TD
    L1["🌍 Layer 1 External<br/>nature, infrastructure (flood, storm, rail/air)"]:::warn
    L2["🏢 Layer 2 Local facility<br/>power, telecom, bomb threat, hazmat"]:::warn
    L3["💾 Layer 3 Information systems<br/>data loss → operational + legal damage"]:::danger
    L4["👥 Layer 4 Departments<br/>weekly crises blocking unit functions"]:::obs
    L5["🪑 Layer 5 Individual desk<br/>one person can't do their job"]:::obs
    L1 --> L2 --> L3 --> L4 --> L5
    classDef warn fill:#FFE6A8,stroke:#E0A106,stroke-width:2px,color:#0F172A
    classDef danger fill:#FFB3B3,stroke:#D14545,stroke-width:2px,color:#0F172A
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A

Figure 2: The five layers of DR risk from external/natural events down to a single person's work area. Information systems get their own layer because data loss reaches across the whole company.

The risk-assessment work itself runs in steps. Identify all critical functions and processes. Assess them to set priority by tier. Assign ownership to a recovery sub-team. Catalogue assets to aid recovery. Operate within approved risk tolerances, the organization’s risk appetite. Then monitor changes continuously and review annually. The output feeds straight into the plan.

The decision the assessment produces is tiering and tiering is the heart of the whole exercise, because it answers what do we save first?

TierCriticalityRecovery windowExample posture
Tier 1Mission-criticalMinutes to hoursMust come back almost immediately revenue/safety systems
Tier 2ImportantNext incremental periodRecovered after Tier 1 is stable
Tier 3Non-essentialDays to weeksThe org keeps running without these for a week or more

To make tiers measurable rather than adjectives, continuity practice adds two targets per function:

  • RTO, the Recovery Time Objective. how fast must it be back? The maximum tolerable downtime. Tier 1’s “minutes to hours” is an RTO.
  • RPO, the Recovery Point Objective. How much data loss is tolerable? The maximum age of data you can afford to lose, measured back from the incident which dictates how often you back up or replicate. An RPO of 5 minutes means near-continuous replication; an RPO of 24 hours means nightly backups suffice.

RTO and RPO turn “this is critical” into engineering requirements. A tight RTO buys hot sites and redundant independent sites. A tight RPO buys frequent replication. The cost scales with how aggressive the targets are which is precisely why you tier first and don’t give everything Tier 1 numbers.

3. Building the strategy and the people who run it

With risks tiered and RTO/RPO set, you develop the actual continuity strategy. Four questions, in order, carry you from requirements to a costed plan:

---
config:
  theme: dark
  fontSize: 17
  themeVariables:
    fontFamily: "Comic Sans MS, Comic Neue, Chalkboard SE, cursive"
---
flowchart LR
    A["📋 Recovery requirements<br/>(what must survive)"]:::gov --> B["🧰 Recovery options<br/>(hot site, replication, backups)"]:::server
    B --> C["⏱️ Availability time<br/>(can options hit the RTO?)"]:::obs
    C --> D["💰 Cost vs capability<br/>(is it worth it?)"]:::gate
    classDef gov fill:#E0D6F5,stroke:#9B7EDE,stroke-width:2px,color:#0F172A
    classDef server fill:#A8E6D0,stroke:#2FA37C,stroke-width:2px,color:#0F172A
    classDef obs fill:#AED6F1,stroke:#2E86C1,stroke-width:2px,color:#0F172A
    classDef gate fill:#D7C3F2,stroke:#8E5BD0,stroke-width:2px,color:#0F172A

Figure 3: The business-continuity strategy framework identify recovery requirements, find options, check they meet the availability targets, then weigh cost against capability.

  • Recovery requirements. What functions must survive, and to what RTO and RPO.
  • Recovery options. The candidate solutions: hot sites, redundant independent sites, replication, dedicated backup servers, secured networks.
  • Availability time. Can each option actually hit the required recovery window?
  • Cost against capability. Weigh each option’s protection against its cost, the same risk-versus-spend discipline as the rest of security.

Risk assessment methods split into qualitative, meaning the risk matrix, and quantitative, meaning fault tree, event tree and layer-of-protection analysis. Pick by the objective, the anticipated risk level, and the detail you need.

But the plan is only as good as the people who execute it.

The DR team is the core of any continuity effort, usually under a CIO or senior IT manager. It’s built from function-based sub-teams: management, business recovery, damage assessment, security, computer recovery and restoration, facilities, logistics, communications, applications, HR, and customer relations. Members must understand their business unit and how it connects to others. And the command structure has to be flexible enough to put the right people in the right place as the disaster evolves. Underpinning it all is a Business Continuity Management System. It anchors on mission, mission-critical functions, cost-effectiveness, protection of resources, disaster scenarios, and a defined RACI so everyone knows who’s responsible.

Why it matters: the most common continuity failure isn’t a bad backup it’s mistaking DR for BC. Restore every server and you’ve done disaster recovery; if staff, facilities, suppliers, and customers still can’t function, you’ve failed business continuity. The fix is a disciplined chain. Let risk assessment tell you what matters. Tier it so you know what to save first. Then pin RTO and RPO on each tier, so “critical” becomes a number you can engineer and budget against. Then staff it with a real cross-functional team and test it annually.

A continuity plan you’ve never rehearsed is a hypothesis, not a capability. Resilience is bought deliberately, in proportion to risk, before the disaster never improvised during it.

Further reading