--- # === IDENTITY === id: business/governance/business-continuity-planning/2026 canonical_question: "How do I build a Business Continuity Plan — BIA, RTO/RPO targets, crisis playbooks, and testing?" aliases: - "business continuity planning" - "BCP" - "business impact analysis" - "BIA" - "disaster recovery planning" - "ISO 22301" entity_type: concept domain: business > governance > Business Continuity Planning region: global jurisdiction: global temporal_scope: 2019-2026 # === VERIFICATION === last_verified: 2026-02-28 confidence: 0.91 version: 1.0 first_published: 2026-02-28 # === TEMPORAL VALIDITY === temporal_validity: status: stable last_breaking_change: 2019-10-01 next_review: 2026-08-27 change_sensitivity: low # === CONSTRAINTS === constraints: - "BCP requires a completed Business Impact Analysis (BIA) as its foundation — without BIA, RTO/RPO targets are arbitrary and recovery strategies may protect the wrong processes" - "RTO/RPO targets must be financially justified — setting aggressive targets (e.g., 1-hour RTO) without cost-benefit analysis leads to over-investment in low-impact processes" - "Plans that are not tested are unreliable — ISO 22301 requires regular exercises; untested plans fail at a significantly higher rate during actual disruptions" - "BCP covers operational continuity, not cyber incident response — cyber-specific playbooks require additional technical expertise (forensics, containment, eradication)" - "Prerequisite: the organization must have identified its critical business processes and dependencies before BCP development is meaningful" skip_this_unit_if: - condition: "User needs enterprise-wide risk identification and assessment, not operational continuity" use_instead: "business/governance/erm-framework/2026" - condition: "User needs to quantify cyber risk in financial terms" use_instead: "business/governance/cyber-risk-quantification/2026" inputs_needed: - key: "bcp_objective" question: "What is the user's business continuity objective?" type: choice options: - "Building a BCP from scratch (starting with BIA)" - "Setting RTO/RPO targets for critical processes" - "Developing crisis playbooks and communication plans" - "Testing and exercising existing BCP" # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/business/governance/business-continuity-planning/2026" suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-02-28)" # === RELATED UNITS === related_kos: related_to: - id: "business/governance/erm-framework/2026" label: "Enterprise Risk Management Framework" - id: "business/governance/cyber-risk-quantification/2026" label: "Cyber Risk Quantification" often_confused_with: - id: "business/governance/cyber-risk-quantification/2026" label: "CRQ (risk quantification vs. operational continuity)" depends_on: [] solves: [] alternative_to: [] # === SOURCES === sources: - id: src1 title: "ISO 22301 Business Continuity Guide" author: Complyance url: https://www.complyance.com/resources/iso-22301-business-continuity-guide type: official_docs published: 2025-01-01 reliability: high - id: src2 title: "How to Conduct a Business Impact Analysis (BIA) in ISO 22301" author: QMII url: https://www.qmii.com/how-to-conduct-a-business-impact-analysis-bia-in-iso-22301/ type: industry_report published: 2025-01-01 reliability: high - id: src3 title: "The Complete Guide to Create Your Business Continuity Plan" author: BCM Metrics url: https://bcmmetrics.com/blog/complete-guide-create-business-continuity-plan type: industry_report published: 2025-01-01 reliability: high - id: src4 title: "RTO vs RPO: Essential Business Continuity Metrics for 2025" author: TrustCloud url: https://www.trustcloud.ai/risk-management/mastering-rto-and-rpo-for-bulletproof-business-continuity/ type: technical_blog published: 2025-01-01 reliability: moderate_high - id: src5 title: "Business Impact Analysis Guide: BIA Components, RTO & RPO" author: Riskilience url: https://riskilience.com/business-impact-analysis/ type: industry_report published: 2025-01-01 reliability: high --- # Business Continuity Planning ## 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 (Business Continuity Management Systems), 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) for each. [src1] The plan encompasses crisis playbooks, communication protocols, recovery strategies, and regular testing exercises to validate readiness. [src3] ## Key Properties - **Business Impact Analysis (BIA)**: Identifies critical business processes, dependencies, and the financial/operational impact of their disruption over time — the foundational input for all BCP decisions [src2] - **RTO (Recovery Time Objective)**: Maximum acceptable time from disruption to restoration of service — measures recovery speed [src4] - **RPO (Recovery Point Objective)**: Maximum acceptable data loss measured in time — determines backup frequency (e.g., RPO of 1 hour means backups every hour) [src4] - **MTPD (Maximum Tolerable Period of Disruption)**: The absolute limit beyond which the organization's viability is threatened — RTO must be less than MTPD [src5] - **ISO 22301**: The international standard for Business Continuity Management Systems — provides a Plan-Do-Check-Act framework for BCP lifecycle management [src1] ## Constraints - BCP requires a completed BIA as its foundation — without understanding which processes are critical and their dependencies, recovery strategies target the wrong assets. [src2] - RTO/RPO targets must be financially justified — aggressive targets for non-critical processes waste resources. A 1-hour RTO for a non-revenue process may cost 10x more than a 24-hour RTO with negligible business impact difference. [src4] - Untested plans are unreliable — organizations that only create plans but never exercise them experience significantly longer recovery times during actual disruptions. ISO 22301 mandates regular exercises. [src1] - BCP addresses operational continuity, not all risk types — cyber incident response, crisis communications, and pandemic response may require specialized playbooks beyond standard BCP. [src3] - Supply chain dependencies are frequently underestimated — a robust internal BCP fails if critical vendors have no continuity capabilities. Assess third-party BCPs for key dependencies. [src5] ## Framework Selection Decision Tree ``` START — User needs resilience/continuity guidance ├── What is the primary need? │ ├── Ensure operations continue during/after disruption │ │ └── ✅ Business Continuity Planning (this unit) │ ├── Quantify risk in financial terms │ │ └── → Cyber Risk Quantification (FAIR) │ ├── Enterprise-wide risk identification │ │ └── → ERM Framework │ ├── IT-specific disaster recovery │ │ └── ✅ BCP (DR is a subset) — focus on RTO/RPO │ └── Crisis communication planning │ └── ✅ BCP crisis playbooks section (this unit) ├── Has a BIA been completed? │ ├── YES → Proceed to recovery strategy design │ └── NO → Start with BIA (Step 1) └── Regulatory requirement? ├── Financial services → BCP is usually mandatory (OCC, FCA, etc.) ├── Healthcare → HIPAA contingency planning requirements └── General → ISO 22301 certification (voluntary but increasingly expected) ``` ## Application Checklist ### Step 1: Conduct Business Impact Analysis (BIA) - **Inputs needed**: Process inventory, revenue data, dependency maps, stakeholder interviews - **Output**: Prioritized list of critical processes with MTPD, financial impact per hour/day of downtime, and dependency chains - **Constraint**: BIA must cover upstream and downstream dependencies — a process that appears non-critical may be a bottleneck for revenue-critical operations [src2] ### Step 2: Set RTO and RPO targets - **Inputs needed**: BIA results, cost-of-downtime analysis, technology capabilities - **Output**: RTO and RPO targets per critical process, validated against technical feasibility and budget - **Constraint**: RTO must always be less than MTPD. If technology cannot achieve the required RTO within budget, the business must accept the gap or increase investment. [src4] ### Step 3: Develop recovery strategies and crisis playbooks - **Inputs needed**: RTO/RPO targets, available recovery infrastructure, crisis team roster - **Output**: Documented recovery procedures per scenario, crisis communication templates, call trees, role assignments - **Constraint**: Playbooks must be scenario-specific (natural disaster, cyber incident, pandemic, supplier failure) — generic plans fail because they do not match real disruption characteristics [src3] ### Step 4: Test, exercise, and maintain - **Inputs needed**: BCP documentation, test schedule, exercise scenarios - **Output**: Test results, lessons learned, updated procedures and training - **Constraint**: Test at minimum annually; quarterly for critical processes. Use progressive exercise types: (1) tabletop → (2) functional → (3) full-scale simulation [src1] ## Anti-Patterns ### Wrong: Writing a BCP without a BIA Organization creates recovery procedures based on assumptions about which processes matter. During an actual disruption, the "wrong" processes are recovered first while revenue-critical operations wait. [src2] ### Correct: Always start with BIA Conduct a rigorous BIA to identify critical processes, dependencies, and financial impact before designing any recovery strategy. [src5] ### Wrong: Setting uniform RTO/RPO for all processes Every process gets the same 4-hour RTO regardless of criticality. This over-invests in non-critical processes and under-invests in critical ones. [src4] ### Correct: Tiered RTO/RPO based on BIA criticality Tier 1 (revenue-critical): 1-4 hour RTO. Tier 2 (important): 24-hour RTO. Tier 3 (supportive): 72-hour RTO. Each tier justified by cost-of-downtime analysis. [src4] ### Wrong: Creating a plan and never testing it BCP document sits on a shelf for three years. Contact information is outdated, recovery procedures no longer match the technology environment, and team members do not know their roles. [src1] ### Correct: Regular progressive exercises Start with annual tabletop exercises, advance to functional tests of specific recovery procedures, and conduct full-scale simulations for the most critical scenarios. Update plans after every exercise. [src3] ## Common Misconceptions - **Misconception**: BCP and disaster recovery (DR) are the same thing. **Reality**: DR is a subset of BCP focused on IT infrastructure recovery. BCP encompasses the entire organization — business processes, people, facilities, supply chain, and communications — not just technology. [src3] - **Misconception**: RTO is how long recovery takes. **Reality**: RTO is the maximum acceptable recovery time — the target, not the actual duration. Actual recovery time may be shorter or longer; testing validates whether the target is achievable. [src4] - **Misconception**: Once written, the BCP is done. **Reality**: BCP is a living program requiring ongoing maintenance. ISO 22301 mandates a Plan-Do-Check-Act cycle — plans must be updated when processes, technology, or the threat landscape change. [src1] ## Comparison with Similar Concepts | Concept | Key Difference | When to Use | |---|---|---| | Business Continuity Planning | Full operational continuity (processes, people, technology) | Organization-wide disruption preparedness | | Disaster Recovery (DR) | IT infrastructure recovery subset of BCP | Restoring technology systems and data | | Incident Response | Real-time response to active security incidents | During and immediately after a cyber event | | Crisis Management | Executive-level decision-making during crises | Strategic decisions and external communications | ## When This Matters Fetch this when a user asks about business continuity planning, BIA methodology, RTO/RPO target setting, crisis playbooks, ISO 22301, or testing/exercising continuity plans. Also relevant when someone is distinguishing BCP from disaster recovery or needs to justify BCP investment to leadership. ## Related Units - [Enterprise Risk Management Framework](/business/governance/erm-framework/2026) - [Cyber Risk Quantification](/business/governance/cyber-risk-quantification/2026)