Business Continuity Planning
How do I build a Business Continuity Plan — BIA, RTO/RPO targets, crisis playbooks, and testing?
Definition
Business Continuity Planning (BCP) is the process of creating systems and procedures to ensure an organization can continue operating during and after a disruption. Anchored by ISO 22301, BCP begins with a Business Impact Analysis (BIA) that identifies critical processes and their maximum tolerable downtime, then defines Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). [src1] The plan encompasses crisis playbooks, communication protocols, recovery strategies, and regular testing. [src3]
Key Properties
- BIA: Identifies critical processes, dependencies, and financial/operational impact of disruption [src2]
- RTO: Maximum acceptable time from disruption to service restoration [src4]
- RPO: Maximum acceptable data loss measured in time — determines backup frequency [src4]
- MTPD: Absolute limit beyond which viability is threatened — RTO must be less than MTPD [src5]
- ISO 22301: International standard for BCMS — Plan-Do-Check-Act lifecycle [src1]
Constraints
- BCP requires a completed BIA — without it, recovery strategies target the wrong assets. [src2]
- RTO/RPO must be financially justified — aggressive targets for non-critical processes waste resources. [src4]
- Untested plans are unreliable — ISO 22301 mandates regular exercises. [src1]
- BCP covers operational continuity, not cyber incident response specifically. [src3]
- Supply chain dependencies are frequently underestimated. [src5]
Framework Selection Decision Tree
START — User needs resilience/continuity guidance
├── What is the primary need?
│ ├── Ensure operations continue during disruption
│ │ └── ✅ Business Continuity Planning (this unit)
│ ├── Quantify risk in financial terms
│ │ └── → Cyber Risk Quantification
│ ├── Enterprise-wide risk identification
│ │ └── → ERM Framework
│ ├── IT disaster recovery
│ │ └── ✅ BCP (DR is a subset) — focus on RTO/RPO
│ └── Crisis communication
│ └── ✅ BCP crisis playbooks (this unit)
├── BIA completed?
│ ├── YES → Proceed to recovery strategy
│ └── NO → Start with BIA (Step 1)
└── Regulatory requirement?
├── Financial services → BCP usually mandatory
├── Healthcare → HIPAA contingency planning
└── General → ISO 22301 (voluntary but expected)
Application Checklist
Step 1: Conduct Business Impact Analysis
- Inputs needed: Process inventory, revenue data, dependency maps
- Output: Prioritized critical processes with MTPD and financial impact per hour/day
- Constraint: Must cover upstream and downstream dependencies [src2]
Step 2: Set RTO and RPO targets
- Inputs needed: BIA results, cost-of-downtime analysis, technology capabilities
- Output: RTO/RPO targets per critical process, validated against budget
- Constraint: RTO must be less than MTPD; if technology cannot achieve target, accept gap or invest [src4]
Step 3: Develop recovery strategies and playbooks
- Inputs needed: RTO/RPO targets, recovery infrastructure, crisis team roster
- Output: Scenario-specific playbooks, communication templates, call trees
- Constraint: Generic plans fail — playbooks must be scenario-specific [src3]
Step 4: Test, exercise, and maintain
- Inputs needed: BCP documentation, test schedule, exercise scenarios
- Output: Test results, lessons learned, updated procedures
- Constraint: Test annually minimum; quarterly for critical. Progressive: tabletop → functional → full-scale [src1]
Anti-Patterns
Wrong: BCP without BIA
Recovery procedures based on assumptions about process criticality. Wrong processes recovered first during actual disruptions. [src2]
Correct: Always start with BIA
Rigorous BIA identifies critical processes, dependencies, and financial impact before any recovery design. [src5]
Wrong: Uniform RTO/RPO for all processes
Every process gets 4-hour RTO regardless of criticality, wasting resources on low-impact processes. [src4]
Correct: Tiered targets based on BIA
Tier 1: 1-4h RTO. Tier 2: 24h. Tier 3: 72h. Each justified by cost-of-downtime analysis. [src4]
Wrong: Plan written but never tested
BCP on a shelf for years. Contacts outdated, procedures don't match current systems. [src1]
Correct: Regular progressive exercises
Annual tabletop, functional tests, full-scale simulations. Update plans after every exercise. [src3]
Common Misconceptions
Misconception: BCP and disaster recovery are the same thing.
Reality: DR is a subset of BCP focused on IT recovery. BCP covers the entire organization — processes, people, facilities, supply chain, and communications. [src3]
Misconception: RTO is how long recovery takes.
Reality: RTO is the maximum acceptable time — a target, not actual duration. Testing validates achievability. [src4]
Misconception: Once written, the BCP is done.
Reality: BCP is a living program. ISO 22301 mandates Plan-Do-Check-Act — plans must be updated as processes, technology, and threats change. [src1]
Comparison with Similar Concepts
| Concept | Key Difference | When to Use |
|---|---|---|
| BCP | Full operational continuity | Organization-wide disruption preparedness |
| Disaster Recovery | IT infrastructure recovery subset | Restoring technology and data |
| Incident Response | Real-time response to active incidents | During and immediately after a cyber event |
| Crisis Management | Executive-level decision-making | Strategic decisions and external communications |
When This Matters
Fetch this when a user asks about business continuity planning, BIA methodology, RTO/RPO targets, crisis playbooks, ISO 22301, or testing continuity plans.