Every organization will face a disruptive event. The question is not if — it is when, and whether you will be ready to respond, recover, and resume operations before the damage becomes existential.
Business Continuity (BC) is about keeping the business running during a disruption — operating in a degraded but functional state. Disaster Recovery (DR) is about restoring technology systems to normal operation after a failure. BC is the strategy; DR is one of its technical components.
Example: When a hurricane hits a bank's primary data center, Business Continuity means customers can still conduct transactions through alternate channels. Disaster Recovery means the primary data center is rebuilt and restored to normal operations.
| Metric | Definition | Example |
|---|---|---|
| RTO (Recovery Time Objective) | Maximum tolerable time for a system to be restored after failure | "Core banking must be restored within 4 hours" |
| RPO (Recovery Point Objective) | Maximum tolerable data loss measured in time (how old can restored data be?) | "No more than 1 hour of transaction data can be lost" |
| MTD (Maximum Tolerable Downtime) | Maximum time a business process can be disrupted before threatening survival | "If payroll is down >48 hours, employees cannot be paid on time" |
| MTTR (Mean Time To Recovery) | Average time it actually takes to restore a system historically | Last 5 major incidents averaged 2.3 hours MTTR |
Critical relationship: RTO must always be ≤ MTD. If your RTO is 4 hours but your MTD is 2 hours, your recovery plan will fail to prevent an existential impact.
A BIA is the systematic process of identifying critical business functions and determining the impact of their disruption over time. BIA outputs include: prioritized list of critical processes, RTO/RPO for each, interdependency mapping, and financial/operational impact curves.
ISO 22301:2019 is the international standard for Business Continuity Management Systems. It follows the PDCA (Plan-Do-Check-Act) management system model:
Define scope, context, and objectives. Perform BIA. Conduct risk assessment. Establish continuity strategies. Write and approve the BC Plan.
Execute the BC Plan. Conduct training and awareness. Establish communication procedures. Test the plan through exercises.
Conduct internal audits. Review performance against objectives. Management reviews the program effectiveness. Post-exercise reviews refine plans.
Implement improvements based on audit findings, exercise lessons learned, and changes in the business. BC planning is a living program, not a document-on-a-shelf.
ISO 22301 certification is increasingly required by major enterprise customers and regulated industries (financial services, healthcare, critical infrastructure). It demonstrates mature BC capabilities to external stakeholders.
A professional BIA follows a structured methodology:
Identify all business processes. Interview process owners using structured questionnaires. Document process dependencies (upstream/downstream, technology, people, facilities).
For each process, calculate impact of disruption over time across dimensions: financial (lost revenue, recovery costs), operational (inability to serve customers), regulatory (compliance obligations), reputational (customer/stakeholder trust).
Based on impact curves, determine the maximum tolerable downtime (MTD) for each process. Set RTO to be within MTD. Set RPO based on acceptable data loss for each process category.
Rank processes by criticality. Tier 1 (life/safety, regulatory): RTO <4h. Tier 2 (core business): RTO 4–24h. Tier 3 (important): RTO 24–72h. Tier 4 (supporting): RTO 72h+.
For each criticality tier, design appropriate recovery strategies (hot site, warm site, cold site, cloud failover, manual workarounds). Strategies must achieve the defined RTO/RPO.
DR strategies are selected based on RTO, RPO, and cost. They exist on a spectrum from lowest cost/longest RTO to highest cost/shortest RTO:
| Strategy | RTO Range | RPO Range | Cost | Description |
|---|---|---|---|---|
| Cold Site | Days to weeks | Hours to days | Low | Physical space and basic infrastructure; nothing pre-configured. Fastest manual approach. |
| Warm Site | Hours to days | Hours | Medium | Pre-configured hardware; data restored from backup on activation. Balance of cost and recovery speed. |
| Hot Site | Minutes to hours | Minutes | High | Fully operational duplicate environment with near-real-time data replication. Most expensive; fastest. |
| Cloud Failover | Minutes | Minutes to seconds | Variable | Active-active or active-passive cloud architecture. Increasing first choice due to elasticity and pay-per-use model. |
| Manual Workaround | Immediate | N/A (no IT dependency) | Negligible | Documented manual processes that bypass technology. Essential for critical processes with no IT failover. |
The 3-2-1 rule is the minimum standard for resilient data backup:
The production data plus at minimum two backups. This protects against single and even dual backup failures.
Store backups on at least two different types of storage (disk + cloud, disk + tape). Protects against media-specific failures.
At least one backup must be in a geographically separate location. Protects against site-level disasters (fire, flood, ransomware affecting all local copies).
With ransomware now targeting backup systems, the 3-2-1 rule has evolved: +1 Immutable or air-gapped copy (cannot be modified or encrypted by ransomware); +0 Errors — backups are verified with zero restore errors. Organizations relying on unverified backups discover corruption only when they need them most.
A mature BC Plan contains these essential sections:
What triggers plan activation? Who has authority to declare a disaster? What thresholds (system downtime duration, personnel unavailability) trigger escalation?
Named roles with primary and alternate contacts. Decision authority matrix. Communication cascade procedures. Executive notification requirements.
Step-by-step recovery procedures for each critical system. Vendor contacts for emergency support. System dependencies and recovery sequence (order matters — can't restore application before database).
Employee notification procedures. Customer/stakeholder communication templates. Media/PR response. Regulatory notification if required. Communication when normal channels are unavailable.
Plans that are never tested are fictional. Annual full exercise minimum. Quarterly tabletops. Component tests (backup restore, failover to DR site) monthly. Document test results and remediate gaps.
The often-forgotten section — how do you return from the DR site to the primary site without causing another disruption? Defined failback procedures prevent recovery creating a second incident.
You are conducting a Business Impact Analysis (BIA) for an e-commerce platform that processes 8,000 orders per day at an average value of $85. Calculate RTO, RPO, and MTD for each critical business function and justify your targets to the business.