Security fundamentals

What are business continuity and disaster recovery?

Business continuity (BC) is the plan to keep your business running through a disruption; disaster recovery (DR) is the subset focused on restoring IT systems and data. Both are shaped by a business impact analysis and by recovery targets called RTO and RPO.

Definition

Business continuity is the set of plans and procedures that keep essential business functions operating during and after a disruption. Disaster recovery is the part of that focused specifically on recovering IT systems, applications, and data.

Background

Both start from a business impact analysis (BIA) that identifies which functions are critical and how much downtime or data loss is tolerable. Two targets fall out of that: the Recovery Time Objective (RTO), how quickly a system must be back, and the Recovery Point Objective (RPO), how much recent data you can afford to lose. Plans document roles, alternates, backups, and recovery steps, and, crucially, they are tested. SOC 2, ISO 27001, and others expect this capability.

Why it matters

Outages, ransomware, and disasters happen. Whether they are a bad afternoon or an existential event depends on whether you planned and practiced. Recovery targets also drive real architecture decisions, like how often you back up and whether you run in more than one region.

Step by step

1. Run a business impact analysis to identify critical functions and tolerances.
2. Set RTO and RPO targets for each critical system.
3. Design backups and recovery to meet those targets.
4. Document the continuity and recovery plans, including roles and communication.
5. Test the plans (tabletop and technical restores) and fix what the tests reveal.
6. Review after tests, incidents, and major changes.

Examples

• A company sets a 4-hour RTO and 15-minute RPO for its core app, and validates it with a restore test each quarter.
• A ransomware tabletop reveals backups were never test-restored, which the team fixes before it matters.

Common mistakes

• Writing a plan and never testing whether backups actually restore.
• Setting RTO/RPO targets the architecture cannot actually meet.
• Treating DR as the whole of BC, and forgetting people, communication, and non-IT functions.

FAQ