Business Continuity and Disaster Recovery Plan Template one document for the BIA, the recovery objectives per tier, the continuity strategy, the recovery procedures, the backup discipline, the exercise cadence, and the framework crosswalk
A free, copy-ready business continuity and disaster recovery (BCDR) plan template. Twelve structured sections covering plan purpose and authority, business impact analysis (BIA) and recovery objectives per tier with RTO, RPO, and MTPD, activation and named role mobilisation, continuity strategy and minimum acceptable service levels, recovery strategy and architecture per tier across hot-standby, warm-standby, cold-standby, and backup-and-restore patterns, backup and replication with the 3-2-1-1-0 immutability rule, per-system recovery runbook portfolio with dependency-respecting restore order and validation checks, communication plan with audience-specific cadence, vendor and third-party dependency management with fourth-party visibility, exercise programme across plan review, walk-through, tabletop, simulation, parallel test, and full interruption test, plan maintenance with material revision triggers, and document control with retention. Aligned with ISO 22301, ISO/IEC 27031, ISO/IEC 22313, NIST SP 800-34 Rev. 1, NIST SP 800-53 Rev. 5 CP family, SOC 2 CC7.5 and CC9.1, PCI DSS Requirement 12.10, HIPAA Security Rule 45 CFR 164.308(a)(7), NIS2 Article 21(2)(c), DORA Articles 11 and 12, and the CISA Cybersecurity Performance Goals immutable-backup and exercise expectations.
Run the BCDR programme against the live operating record, not against a separate document
SecPortal carries every signed plan version, every BIA artefact, every activation timeline, every exercise after-action, every recovery validation evidence record, and every decision register on one workspace so the audit committee read of continuity and recovery performance and the operational read are the same record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a continuity intent into a defensible BCDR plan
A business continuity and disaster recovery (BCDR) plan is the document a firm publishes so operations, engineering, security, legal, GRC, and the audit committee operate against the same continuity rules and recovery procedures. The twelve sections below cover the durable shape of the artefact across ISO 22301, ISO/IEC 27031, ISO/IEC 22313, NIST SP 800-34 Rev. 1, NIST SP 800-53 Rev. 5 CP family, SOC 2 CC7.5 and CC9.1, PCI DSS 12.10, HIPAA 45 CFR 164.308(a)(7), NIS2 Article 21(2)(c), DORA Articles 11 and 12, and the CISA Cybersecurity Performance Goals Goal 2.R immutable-backup and Goal 5.A exercise expectations. Copy the section that fits your stage and paste the rest as you go.
Copy the full plan (all twelve sections) as one block.
1. Plan purpose, scope, authority, and governance
Open the plan with the firm intent and the executive authority. A reviewer should know in the first paragraph which entity publishes the plan, which business estate is in scope, which executive authority signed it, and the standards and regulations the plan evidences. ISO 22301 Clause 5.2 expects documented business continuity policy with named authority; SOC 2 CC9.1 reads the policy in the same shape; NIS2 Article 21 and DORA Article 11 expect documented business continuity policy as part of the wider ICT risk-management framework.
Plan title: Business Continuity and Disaster Recovery (BCDR) Plan
Plan version: {{PLAN_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Purpose:
{{ENTITY_NAME}} operates business processes that customers, regulators, supervisory authorities, contractual counterparties, and the workforce depend on. This plan publishes the rules {{ENTITY_NAME}} operates against to keep essential business operations running during a disruption (the continuity half) and to restore IT systems, data, and services after a disruption (the recovery half).
Plain-language commitment:
{{PLAIN_LANGUAGE_COMMITMENT_PARAGRAPH}}
In scope:
- Business processes the entity runs as line-of-business operations: {{LINE_OF_BUSINESS_PROCESSES}}
- Customer-facing services operated as SaaS or hosted offerings: {{CUSTOMER_FACING_SERVICES}}
- Internal corporate functions whose disruption would affect line-of-business operations: {{INTERNAL_CORPORATE_FUNCTIONS}}
- Third-party SaaS and infrastructure providers whose disruption would affect in-scope operations: {{THIRD_PARTY_DEPENDENCIES}}
- Physical locations and alternate work arrangements: {{PHYSICAL_LOCATIONS}}
Out of scope:
- Discretionary internal projects with no documented business-process dependency.
- Marketing collateral and content websites with no transactional surface.
- One-off experimentation environments that do not enter the production lifecycle.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Standards and regulations the plan evidences:
- ISO 22301 (Business continuity management systems requirements)
- ISO/IEC 27031 (ICT readiness for business continuity)
- ISO/IEC 22313 (Business continuity management systems guidance)
- NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems)
- SOC 2 Trust Services Criteria CC7.5 and CC9.1
- PCI DSS Requirement 12.10 (incident and recovery elements)
- HIPAA Security Rule 45 CFR 164.308(a)(7) (Contingency Plan Standard)
- NIS2 Directive Article 21(2)(c) (business continuity, backup, crisis management)
- DORA Regulation Articles 11 and 12 (ICT business continuity policy and response and recovery plans)
- NIST SP 800-53 Rev. 5 CP-1 through CP-13 (Contingency Planning control family)
- CISA Cybersecurity Performance Goals Goal 2.R (immutable backups) and Goal 5.A (incident response plan)
Plan owner: {{PLAN_OWNER_ROLE_TITLE}}
Executive sponsor (signature authority): {{EXECUTIVE_SPONSOR_ROLE_TITLE}}
Approval date: {{APPROVAL_DATE}}
Governance vehicle:
- Quarterly BCDR governance review chaired by {{GOVERNANCE_CHAIR_ROLE}} with the standing roles named in Section 9.
- Annual board or audit-committee read of the programme summary, the exercise after-actions, and the residual risk position.
- Open-loop register maintained by the plan owner with named owners and target dates for every action item the governance review generates.
2. Business impact analysis (BIA) and recovery objectives
The BIA is the load-bearing section because every other rule in the plan reads against it. ISO 22301 Clause 8.2.2 expects the BIA to be the input to the continuity strategy and the recovery strategy; NIST SP 800-34 Section 3.2 names the BIA as the foundation of the contingency planning process. The BIA inventories business processes, ranks them by impact, names the MTPD per process, and assigns the RTO and the RPO per supporting system.
Business impact analysis (BIA) methodology and refresh:
The BIA is refreshed at least annually and at every material estate change (acquisition, divestiture, new product line, sector regulator scope change, third-party SaaS migration, major contractual commitment).
Tier definitions used across the plan:
- Tier 0 (critical): processes whose disruption breaches a regulator clock, breaches a contractual SLA inside hours, or causes financial impact above {{TIER_0_FINANCIAL_THRESHOLD}} per hour.
- Tier 1 (high): processes whose disruption causes financial impact above {{TIER_1_FINANCIAL_THRESHOLD}} per hour, customer-visible impact within the first day, or material brand-risk exposure.
- Tier 2 (medium): processes whose disruption is tolerable for {{TIER_2_TOLERABLE_DAYS}} business days with manual workarounds.
- Tier 3 (low): processes whose disruption is tolerable for {{TIER_3_TOLERABLE_WEEKS}} business weeks.
Recovery objectives per tier (the firm-wide defaults; per-process overrides live in the BIA workbook):
- Tier 0: RTO {{TIER_0_RTO}}, RPO {{TIER_0_RPO}}, MTPD {{TIER_0_MTPD}}.
- Tier 1: RTO {{TIER_1_RTO}}, RPO {{TIER_1_RPO}}, MTPD {{TIER_1_MTPD}}.
- Tier 2: RTO {{TIER_2_RTO}}, RPO {{TIER_2_RPO}}, MTPD {{TIER_2_MTPD}}.
- Tier 3: RTO {{TIER_3_RTO}}, RPO {{TIER_3_RPO}}, MTPD {{TIER_3_MTPD}}.
BIA workbook fields (one row per business process):
- Process name and process owner role
- Business function the process serves
- Supporting systems and the upstream cloud, infrastructure, identity, and data dependencies
- Data classes consumed and produced (paired to the data classification policy)
- Regulator clocks that fire on disruption (GDPR Article 33 notification, NIS2 Article 23 notification, DORA Article 19 reporting, SEC Item 1.05 material event, sector-specific clocks)
- Financial impact bands per hour, per day, and per week of disruption
- Reputational and contractual impact narrative
- Tier classification with a justification line
- Minimum acceptable service level during disruption
- Manual workaround viability and capacity
- RTO and RPO commitment with the recovery strategy reference into Section 5
BIA validation:
- Each tier classification is validated with the named line-of-business owner and the executive sponsor.
- Each RTO and RPO commitment is validated against the recovery strategy in Section 5 so the plan does not promise objectives the architecture cannot deliver.
- Each regulator clock and contractual SLA is validated with the regulator-liaison role and the legal authority.
Refresh cadence:
- Annual BIA refresh as part of the plan revision.
- Out-of-cycle BIA refresh for every material estate change.
- BIA review at every quarterly governance meeting to surface drift between the documented tier and the lived experience of the line-of-business owner.
3. Activation, declaration criteria, and named roles
Without explicit activation criteria and named roles, the disruption becomes a meeting about who decides. ISO 22301 Clause 8.4 expects activation procedures; NIST SP 800-34 Section 4.1 names the activation phase as the first contingency operation. The declaration authority and the standing roles convert the plan from a document into a procedure that fires under defined conditions with a named decider.
Activation criteria:
The plan activates when any one of the following is observed and confirmed by the declaration authority.
- A tier-zero system is unavailable or operating below its minimum acceptable service level for longer than {{TIER_ZERO_ACTIVATION_WINDOW}}.
- A tier-one system is unavailable for longer than {{TIER_ONE_ACTIVATION_WINDOW}}.
- A confirmed cyber incident affecting an in-scope system is escalated past containment into the recovery phase.
- A regulator clock fires on a disruption that is reasonably likely to exceed {{REGULATOR_CLOCK_DURATION}}.
- A physical-site event renders a primary work location uninhabitable for longer than {{SITE_EVENT_DURATION}}.
- An executive escalation from the line-of-business owner with a documented impact narrative.
Declaration authority:
- Primary: {{PRIMARY_DECLARATION_AUTHORITY_ROLE}}
- Delegate (when the primary is unavailable): {{DELEGATE_DECLARATION_AUTHORITY_ROLE}}
- Second delegate: {{SECOND_DELEGATE_DECLARATION_AUTHORITY_ROLE}}
- The declaration timestamp, the declarer identity, and the activation reason are captured on the activation timeline immediately.
Standing roles (mobilised on activation):
- BCDR coordinator: {{BCDR_COORDINATOR_ROLE}} (overall plan execution, governance reporting, after-action ownership).
- Disaster recovery technical lead: {{DR_TECHNICAL_LEAD_ROLE}} (recovery architecture, failover execution, restore validation).
- Business continuity lead: {{BC_LEAD_ROLE}} (workaround activation, alternate-location coordination, workforce communication).
- Crisis communications lead: {{CRISIS_COMMUNICATIONS_LEAD_ROLE}} (internal, customer, regulator, board messaging).
- Regulator liaison and legal lead: {{REGULATOR_LIAISON_ROLE}} (notification clocks, privilege capture, regulator-facing record).
- Security incident commander (when the disruption is paired to an incident): {{SECURITY_INCIDENT_COMMANDER_ROLE}}.
- Vendor and third-party management lead: {{VENDOR_MANAGEMENT_LEAD_ROLE}} (supplier substitution, contractual recovery commitments).
- Finance and insurance lead: {{FINANCE_INSURANCE_LEAD_ROLE}} (claim notification, financial-readiness decisions).
Supporting roles (engaged as the scenario requires):
- Line-of-business process owners (per affected process, listed in the BIA workbook).
- HR and workforce-coordination lead (when alternate work arrangements activate).
- Facilities and physical-security lead (when a physical-site event activates).
- Customer-success and account leads (when customer notifications activate).
- Internal audit (engaged for evidence-preservation discipline).
Activation timeline (captured on the workspace activity log from the moment of declaration):
- Declaration timestamp, declarer identity, declaration reason.
- Standing-role acknowledgement timestamps.
- Workstream-lead acknowledgement timestamps.
- First decision captured at activation, named decider, dissent or alternative captured if any.
Stand-down criteria:
- All affected tier-zero and tier-one systems back at documented service levels for {{STAND_DOWN_OBSERVATION_WINDOW}}.
- After-action capture initiated and named after-action owner assigned.
- Stand-down decision captured by the declaration authority and logged with timestamp.
4. Continuity strategy and minimum acceptable service levels
The continuity side keeps the business operating while the recovery side restores systems. ISO 22301 Clause 8.3 expects the continuity strategy to name the workarounds, the alternate arrangements, the supplier substitutions, and the minimum acceptable service levels per affected process. This section is the artefact that lets line-of-business operations function during the disruption window.
Continuity strategy by tier:
Tier 0 continuity arrangements:
- Manual workaround: {{TIER_0_MANUAL_WORKAROUND_DESCRIPTION}}
- Alternate work location: {{TIER_0_ALTERNATE_LOCATION}}
- Communications channel during disruption (out-of-band): {{TIER_0_OUT_OF_BAND_CHANNEL}}
- Identity provider fallback (when the primary IdP is itself affected): {{TIER_0_IDP_FALLBACK}}
- Minimum acceptable customer-facing service level during disruption: {{TIER_0_MINIMUM_SERVICE_LEVEL}}
- Supplier substitution plan if a critical upstream vendor cannot meet its recovery window: {{TIER_0_SUPPLIER_SUBSTITUTION}}
Tier 1 continuity arrangements:
- Manual workaround: {{TIER_1_MANUAL_WORKAROUND_DESCRIPTION}}
- Alternate work location: {{TIER_1_ALTERNATE_LOCATION}}
- Out-of-band communications: {{TIER_1_OUT_OF_BAND_CHANNEL}}
- Minimum acceptable customer-facing service level during disruption: {{TIER_1_MINIMUM_SERVICE_LEVEL}}
Tier 2 and Tier 3 continuity arrangements:
- Documented at the per-process level in the BIA workbook with the line-of-business owner.
Continuity discipline (applies to all tiers):
- The continuity strategy assumes corporate email, primary chat, and the primary identity provider may themselves be affected; the out-of-band channel is independent of the production identity stack.
- The continuity strategy names the workforce that can operate the workaround and the capacity ceiling beyond which the workaround degrades.
- The continuity strategy is rehearsed alongside the recovery procedure at the exercise cadence in Section 8.
- The continuity workarounds carry the same data-protection and confidentiality commitments as the in-production process (the workaround does not become a control-relaxation vehicle).
Customer-facing service-level discipline:
- Customer-visible service-level commitments during disruption are documented per service in the customer agreement and the trust centre.
- Status-page updates and customer notifications during disruption follow Section 7 of this plan.
- The customer-success workstream owns the per-account contact during the disruption window.
Workforce coordination:
- HR-led workforce check-in within {{WORKFORCE_CHECK_IN_WINDOW}} of declaration when the disruption affects a physical site or remote-work capacity.
- Alternate-work-arrangement activation criteria for the affected workforce.
- Compensation and benefits continuity commitments during the disruption window.
5. Recovery strategy and architecture per tier
The recovery strategy is the technical answer to the BIA recovery objectives. Hot-standby, warm-standby, cold-standby, and backup-and-restore are the four canonical patterns; ISO/IEC 27031 Section 7 and NIST SP 800-34 Section 3.4 read this section directly. The plan must name the chosen strategy per tier, the architecture that supports it, the cost commitment, and the rehearsal cadence that proves the chosen strategy delivers against the documented objectives.
Recovery strategies in use (by tier):
Tier 0 recovery strategy:
- Pattern: {{TIER_0_RECOVERY_PATTERN_HOT_OR_WARM_OR_COLD_OR_BACKUP}}
- Architecture: {{TIER_0_RECOVERY_ARCHITECTURE_DESCRIPTION}}
- Cloud region or alternate site: {{TIER_0_ALTERNATE_REGION_OR_SITE}}
- Data replication design: {{TIER_0_DATA_REPLICATION_DESIGN}}
- Failover procedure reference: {{TIER_0_FAILOVER_RUNBOOK_REFERENCE}}
- Cost commitment: {{TIER_0_RECOVERY_COST_COMMITMENT}}
Tier 1 recovery strategy:
- Pattern: {{TIER_1_RECOVERY_PATTERN}}
- Architecture: {{TIER_1_RECOVERY_ARCHITECTURE_DESCRIPTION}}
- Cloud region or alternate site: {{TIER_1_ALTERNATE_REGION_OR_SITE}}
- Data replication design: {{TIER_1_DATA_REPLICATION_DESIGN}}
- Failover procedure reference: {{TIER_1_FAILOVER_RUNBOOK_REFERENCE}}
Tier 2 and Tier 3 recovery strategy:
- Pattern: typically backup-and-restore.
- Architecture: documented at the per-system level in the recovery runbook portfolio.
Recovery strategy patterns (the durable definitions the plan reads against):
- Hot-standby and active-active failover: two production-ready estates running in parallel with synchronous or near-synchronous data replication. Supports sub-hour RTO with near-zero RPO. Highest cost.
- Warm-standby: a non-production estate that holds the data replication and the application configuration but is not running production traffic. Supports an hours-range RTO with a sub-hour RPO.
- Cold-standby: an alternate site that holds the architecture but not the running configuration. Supports a days-range RTO with whatever the backup cadence supports.
- Backup-and-restore: no alternate site; recovery is rebuild-from-backup against a fresh estate. Supports days-or-weeks RTO with the backup-cadence RPO.
Architecture commitments:
- The recovery strategy is documented per system in an architecture record that names the upstream cloud, the identity provider, the data store, the network path, and the runtime platform.
- The recovery architecture is reviewed at each material change (cloud-region migration, identity-provider change, data-store change, runtime-platform upgrade).
- The recovery architecture review includes the security architecture review template so the recovery posture does not introduce uncatalogued attack surface.
Recovery objective validation:
- Every tier-zero and tier-one system carries a recovery objective validation record from the most recent exercise.
- The validation record names the observed RTO, the observed RPO, the gap against the documented objective, and the remediation plan if any.
- The validation record is read at every quarterly governance meeting and at every BIA refresh.
6. Backup, replication, immutability, and the 3-2-1-1-0 rule
A backup that ransomware encrypts at the moment it encrypts the production estate is not a backup. CISA Cybersecurity Performance Goals Goal 2.R names immutable backups as a load-bearing control. NIST SP 800-209 reads the same set of expectations on storage security. The plan must commit to an immutability layer that resists adversary-driven corruption alongside the cadence, retention, encryption, and integrity-verification rules.
Backup and replication commitments by tier:
Tier 0 backup and replication:
- Backup cadence: {{TIER_0_BACKUP_CADENCE}}
- Replication cadence: {{TIER_0_REPLICATION_CADENCE}}
- Retention horizon: {{TIER_0_RETENTION_HORIZON}}
- Storage tier: {{TIER_0_STORAGE_TIER}}
- Immutability layer: {{TIER_0_IMMUTABILITY_LAYER_WORM_OR_OBJECT_LOCK_OR_AIR_GAP}}
- Cross-account or cross-tenant isolation: {{TIER_0_CROSS_ACCOUNT_ISOLATION}}
- Encryption at rest and in transit: {{TIER_0_ENCRYPTION_COMMITMENT}}
Tier 1 backup and replication:
- Backup cadence: {{TIER_1_BACKUP_CADENCE}}
- Retention horizon: {{TIER_1_RETENTION_HORIZON}}
- Immutability layer: {{TIER_1_IMMUTABILITY_LAYER}}
- Cross-account isolation: {{TIER_1_CROSS_ACCOUNT_ISOLATION}}
- Encryption commitment: {{TIER_1_ENCRYPTION_COMMITMENT}}
Tier 2 and Tier 3 backup arrangements:
- Documented per system in the backup design record.
The 3-2-1-1-0 rule (applies to tier-zero and tier-one data):
- Three copies of data (one production, two recovery copies).
- Two different media types or storage tiers.
- One off-site or cross-region copy.
- One immutable or air-gapped copy resistant to adversary-driven corruption.
- Zero errors verified on the most recent integrity check and the most recent restore test.
Integrity-verification cadence:
- Tier-zero: monthly automated integrity check; quarterly full restore rehearsal on a representative workload with the result captured.
- Tier-one: quarterly automated integrity check; semi-annual restore rehearsal.
- Tier-two: semi-annual automated integrity check; annual restore rehearsal.
- Tier-three: annual integrity check and restore rehearsal.
Integrity-verification evidence:
- Restore rehearsal results are captured in the workspace record with the named operator, the timestamp, the system identifier, the observed RTO, and the observed RPO.
- Failed integrity checks open a remediation finding with a target date and a named owner.
- The integrity-verification record is read at every quarterly governance meeting.
Ransomware resilience overlay:
- Tier-zero backup posture is sealed against the production-account compromise path through cross-account isolation, immutability locks, and the separation of backup-administration credentials from production-administration credentials.
- The ransomware readiness programme reads this section directly; backup posture without rehearsed restore is the single largest failure mode the wider programme has to design against.
- The encryption-key management for backup integrity follows the cryptographic key management policy under documented rotation and custody rules.
7. Recovery procedures, restore order, and validation
Per-system recovery runbooks are the operational tools the recovery team uses under load. ISO/IEC 27031 Section 8 and NIST SP 800-34 Section 4.3 expect the documented procedure, the dependency-respecting restore order, and the validation checks. This section names the runbook portfolio, the restore-order discipline, and the validation evidence that proves restoration to documented service levels.
Recovery runbook portfolio:
- Each tier-zero and tier-one system carries a per-system recovery runbook covering activation criteria, pre-recovery checks, restore-from-backup or failover-to-alternate procedure, dependency-respecting sequencing, validation checks, communications updates, and stand-down criteria.
- Runbooks live in document management with version history, named operators, and an exercise-update record.
- Runbook updates trigger a notification to the standing-role workstream leads named in Section 3.
Restore order (dependency-respecting):
The recovery sequence reads against the dependency map; lower-level dependencies recover before higher-level dependencies.
1. Identity, authentication, and authorisation services (the primary identity provider, the secrets store, the certificate authority).
2. Network and connectivity services (transit, DNS, load balancers, ingress).
3. Data platform services (databases, object storage, message brokers, caches).
4. Platform and runtime services (compute, container orchestration, build pipelines).
5. Tier-zero customer-facing services in the documented order.
6. Tier-one customer-facing services in the documented order.
7. Tier-two and tier-three services in priority order against the BIA.
8. Internal corporate functions that support the line-of-business.
Validation checks after each recovery stage:
- Service-availability check: the system answers a synthetic check that reads representative production behaviour.
- Data-integrity check: a representative read against the restored data store matches the expected reference values.
- Authentication check: the identity flow operates end-to-end against the restored identity provider.
- Audit-log check: the system writes to the activity log against the restored audit pipeline.
- Recovery-objective verification: the observed RTO and RPO are captured and compared to the documented objectives.
Failure handling:
- A validation-check failure pauses the next recovery stage and escalates to the DR technical lead.
- The escalation reason, the named approver of the alternative action, and the timestamp are captured on the activation timeline.
- If the alternative requires a deviation from the documented procedure, the deviation is captured as a runbook update for the next revision.
Recovery completion criteria:
- All in-scope tier-zero and tier-one systems are validated to documented service levels.
- The validation evidence is captured in the workspace record.
- The stand-down criteria in Section 3 are met.
- The after-action capture in Section 8 is initiated.
8. Communication plan and stakeholder cadence
Communications fail at the same rate the technical track succeeds. ISO 22301 Clause 8.4.3 expects the communication plan to name the audiences, the channels, the release authority, and the cadence. The communications workstream runs independently of the technical track so it does not lag the recovery by hours during a public event.
Audiences and release authority:
Internal workforce (all hands):
- Channel: {{INTERNAL_CHANNEL_PRIMARY}} with out-of-band fallback {{INTERNAL_CHANNEL_FALLBACK}}.
- Release authority: {{INTERNAL_RELEASE_AUTHORITY_ROLE}}.
- Cadence: initial within {{INTERNAL_INITIAL_WINDOW}} of declaration, then every {{INTERNAL_UPDATE_CADENCE}} until stand-down.
Customers and account contacts:
- Channel: trust centre and status page, plus direct account-team outreach for tier-zero and tier-one customers.
- Release authority: {{CUSTOMER_RELEASE_AUTHORITY_ROLE}} with the legal authority co-signing for content that touches breach-notification scope.
- Cadence: initial status-page update within {{CUSTOMER_INITIAL_WINDOW}} of declaration when the disruption is customer-visible; account-team direct outreach for tier-zero and tier-one customers within {{CUSTOMER_DIRECT_OUTREACH_WINDOW}}.
Regulators and supervisory authorities:
- Channel: regulator-specific (the GDPR Article 33 notification interface, the NIS2 Article 23 notification interface, the DORA Article 19 reporting interface, the SEC Form 8-K Item 1.05 channel, the sector-specific channels).
- Release authority: {{REGULATOR_RELEASE_AUTHORITY_ROLE}} with the legal authority co-signing.
- Cadence: per the regulator clock that applies; the regulator-clock matrix is maintained in the breach notification and regulator readiness workflow.
Board, audit committee, and executive sponsors:
- Channel: direct executive briefing.
- Release authority: {{EXECUTIVE_RELEASE_AUTHORITY_ROLE}}.
- Cadence: initial executive briefing within {{EXECUTIVE_INITIAL_WINDOW}} of declaration when the disruption is escalated past containment; then every {{EXECUTIVE_UPDATE_CADENCE}} until stand-down; closing briefing on stand-down with the after-action.
Insurers and brokers:
- Channel: per the policy notification clause.
- Release authority: {{INSURANCE_RELEASE_AUTHORITY_ROLE}}.
- Cadence: notification within the policy-mandated window; periodic updates as the policy requires.
Suppliers and third-party vendors:
- Channel: vendor relationship contact per the procurement record.
- Release authority: {{VENDOR_RELEASE_AUTHORITY_ROLE}}.
- Cadence: when the disruption affects a shared service the vendor operates or when the vendor recovery commitment is read against the firm RTO.
Communication discipline:
- Every external statement is logged with the named release authority, the audience, the timestamp, the version, and the substantive content.
- The legal authority capture-at-creation discipline applies to communications that touch breach-notification scope.
- Customer notifications, regulator notifications, and board briefings are produced from the same workspace data so versions do not diverge between audiences.
- Templated initial and follow-up messages are pre-drafted per audience so the first communication does not depend on event-time drafting.
9. Vendor, supplier, and third-party dependency management
A plan that maps only the SaaS providers the firm pays misses the cloud regions, identity providers, and upstream data processors those SaaS providers depend on. NIS2 Article 21 supply-chain security and DORA Article 28 ICT third-party risk management both read the upstream side. This section names the dependency mapping, the contractual recovery commitments, the substitution plan, and the fourth-party visibility.
Dependency mapping:
- Tier-zero and tier-one systems carry a documented dependency map covering the cloud provider, the cloud region, the identity provider, the secrets store, the certificate authority, the data platform, the runtime platform, and the upstream SaaS providers each system reads against.
- The dependency map is read in the recovery runbook portfolio so the restore order in Section 7 reads against the actual dependency graph.
Vendor recovery commitments:
- For tier-zero and tier-one upstream vendors, the firm captures the contractual recovery commitment (RTO, RPO, recovery procedure, customer-side notification commitments) and reads it against the firm-side recovery objective per process.
- A vendor recovery commitment shorter than the firm RTO for the process the vendor supports is read as an acceptable upstream commitment; a vendor recovery commitment longer than the firm RTO is read as a substitution or compensation requirement.
Substitution plan:
- A documented substitution plan exists for every upstream tier-zero and tier-one vendor where the firm RTO is shorter than the vendor recovery commitment.
- The substitution plan names the substitute vendor or the in-house workaround, the activation procedure, the data-portability path, and the contractual standby arrangement (if any).
- The substitution plan is rehearsed at the same cadence as the per-tier recovery exercise.
Fourth-party visibility:
- For tier-zero upstream vendors, the firm captures and reviews the vendor disclosure of their own upstream cloud, identity provider, data processor, and resilience arrangement.
- Material changes to a tier-zero vendor fourth-party posture trigger a vendor risk reassessment and a BIA revisit if the change reaches the firm recovery objective.
Vendor exception register:
- An upstream vendor that cannot meet its contractual recovery commitment carries an exception with a remediation date, a compensating-control narrative, and a target replacement plan.
- The vendor exception register is reviewed at every quarterly BCDR governance meeting and reported to the executive sponsor.
Joint exercise:
- Tier-zero upstream vendors participate in the firm tabletop exercise at least once per year so the joint recovery procedure is rehearsed under representative conditions.
- The joint-exercise after-action is captured in the firm exercise record.
10. Exercise, test, rehearsal cadence, and after-action
Rehearsal cadence is the strongest single predictor of whether the plan works under load. ISO 22301 Clause 8.5 expects exercise and testing of the plan; NIST SP 800-34 Section 3.5 lists the five exercise types (plan review, walk-through, tabletop, simulation, parallel test, and full interruption test); CISA CPGs Goal 5.A reads the exercise programme directly. This section names the cadence, the exercise types, the observer rubric, and the after-action discipline.
Exercise types and the durable definitions:
- Plan review: the plan is read against the current estate. Lowest-cost rehearsal; surfaces drift first.
- Walk-through: the response team narrates the plan against a hypothetical scenario; surfaces role-clarity and decision-authority gaps.
- Tabletop: the executive team, legal, communications, insurance, and technical responders work a scenario with named decision points, observers, and a structured decision register; surfaces cross-function coordination gaps.
- Simulation: a partial enactment of the recovery procedure in a test environment; surfaces gaps in the technical procedure.
- Parallel test: the recovery procedure runs on a representative workload in parallel with production; production remains available. Proves the recovery objectives at controlled risk.
- Full interruption test: production is taken offline and recovered to completion. Highest residual risk; surfaces gaps no other exercise type detects.
Rehearsal cadence (the durable minimum):
- Annually: plan review against the current estate.
- Annually: walk-through with the standing roles.
- Annually: tier-zero tabletop with the executive team, legal, communications, and technical responders.
- Annually: tier-zero simulation against a representative workload.
- Annually: parallel test on a representative tier-zero workload.
- Annually or on regulator schedule: full interruption test where the regulatory posture requires it.
- Quarterly: tier-zero restore rehearsal (paired to the integrity-verification cadence in Section 6).
- Trigger-driven: out-of-cycle exercise after a material estate change, a material regulator change, a near-miss event, or a peer-industry incident with adjacent learning.
Scenario rotation:
- Maintain a portfolio of at least six scenario classes and rotate so the same scenario does not repeat within a two-year window: cloud-region outage, ransomware on tier-zero data, identity-provider outage, third-party SaaS outage, physical-site event, internal infrastructure misconfiguration cascading to production. Rotate to keep the response team from rehearsing a single muscle memory.
Observer rubric (six dimensions):
- Activation discipline: declaration timing, declarer identity, activation reason capture.
- Role mobilisation: standing roles acknowledged in time, workstream leads on the timeline.
- Decision discipline: decisions captured with named decider and timestamp; dissent or alternatives captured.
- Communication discipline: external statements logged with named release authority and version.
- Recovery discipline: validation checks captured, recovery objectives verified, deviations captured.
- Stand-down discipline: stand-down criteria met, after-action initiated, named after-action owner assigned.
After-action discipline (mandatory after every activation and every named exercise):
- Written after-action covers what was the scenario, what was rehearsed, what went well, what was missed, what changed since the previous exercise, what is the named-owner action list with target dates.
- After-action items track to closure as findings on the same workspace record as the wider security backlog so the closure rate is read against documented commitments.
- After-action is presented at the next quarterly BCDR governance meeting and the next board or audit-committee read.
Non-decision scribe:
- A named non-decision scribe captures the decision register during every tabletop, simulation, parallel test, and full interruption test so the decision discipline does not depend on the responders writing their own decisions in flight.
11. Plan maintenance, training, awareness, and material revision triggers
A plan that is revised only annually drifts from the actual estate. ISO 22301 Clause 9 expects performance evaluation; Clause 10 expects improvement; SOC 2 CC9.1 reads the maintenance cadence in the same shape. This section names the review cadence, the material revision triggers, the workforce training arrangement, and the awareness cadence.
Review cadence:
- Operational review: monthly. Surfaces in-flight runbook updates, exercise schedule, open after-action items, and any activation events in the period.
- Tactical review: quarterly BCDR governance meeting. Surfaces tier classification drift, BIA refresh items, vendor exception register, after-action closure progress, and the recovery-objective validation evidence.
- Strategic review: annual. Surfaces standards-version changes, regulator-scope changes, material estate changes, exercise programme rollup, residual risk position, and the executive plan attestation.
Material revision triggers:
- A standards version change (ISO 22301 revision, ISO/IEC 27031 revision, NIST SP 800-34 revision, sector regulator update).
- A material estate change (acquisition, divestiture, new product line, new sector regulator, new third-party SaaS commitment, identity-provider change, cloud-region migration).
- A material activation event with after-action items that require a plan section update.
- A material exercise finding that calls a plan section out of date.
- An audit finding that calls a plan section out of date.
Training and awareness:
- All workforce receives BCDR awareness training at hire and at the annual security awareness cycle covering activation criteria, the standing-role identification, and the workforce communication channel during disruption.
- Standing-role holders receive role-specific training within {{STANDING_ROLE_TRAINING_WINDOW}} of role assignment.
- Standing-role holders rehearse against the plan at the exercise cadence in Section 10.
- Line-of-business process owners receive BIA-refresh training in the year they own a BIA workbook update.
Onboarding integration:
- New-hire onboarding includes BCDR plan acknowledgement and the awareness module.
- Standing-role onboarding includes a one-to-one walk-through with the BCDR coordinator and the relevant predecessor.
Sunsetting:
- Retired plan versions are archived in document management with the disposition timestamp, the named approver, and the reason.
- Archived plans remain readable for the retention horizon documented in the audit-evidence retention policy.
12. Document control, version history, retention, and signed approval
Document control is the artefact-management layer that makes the plan auditable. Each revision has a version number, an effective date, a named approver, a difference summary, and a notification record so the audit can reconstruct the plan as it stood at any point in time.
Version history table (kept in this section across the plan lifetime):
- {{VERSION_1}} | {{V1_EFFECTIVE_DATE}} | {{V1_APPROVER}} | Initial publication.
- {{VERSION_2}} | {{V2_EFFECTIVE_DATE}} | {{V2_APPROVER}} | {{V2_CHANGE_SUMMARY}}
- {{VERSION_3}} | {{V3_EFFECTIVE_DATE}} | {{V3_APPROVER}} | {{V3_CHANGE_SUMMARY}}
Difference summary template (one entry per material revision):
- Sections changed
- Reason for the change (standards update, estate change, audit finding, exercise after-action, regulator scope change)
- Effective date of the new version
- Approver
- Stakeholder notification record (which acknowledgement renewals were collected)
Retention horizon:
- The retention horizon for the plan version, the BIA artefacts, the exercise after-actions, the activation timelines, the decision registers, and the recovery validation evidence follows the longer of the regulator-mandated horizon, the contractual horizon, and the firm audit-evidence retention policy.
- Plan version retention: minimum {{PLAN_VERSION_RETENTION_YEARS}} years from supersession.
- BIA artefact retention: minimum {{BIA_RETENTION_YEARS}} years from supersession.
- Exercise after-action retention: minimum {{EXERCISE_AFTER_ACTION_RETENTION_YEARS}} years from exercise date.
- Activation timeline and decision register retention: minimum {{ACTIVATION_TIMELINE_RETENTION_YEARS}} years from stand-down or per the sector retention floor, whichever is longer.
Disposal rule:
- At the end of the retention horizon, BCDR records are disposed of through the firm secure-deletion process under documented hold-and-disposition discipline.
- The disposition record is captured in document management with the deletion timestamp, the named approver, and the reason.
Related documents:
- Audit evidence retention policy
- Incident response plan
- Incident response runbook portfolio
- Incident response tabletop exercise programme
- Breach notification and regulator readiness workflow
- Ransomware readiness programme
- Cyber insurance readiness
- Vulnerability management policy
- Cryptographic key management policy
- Secrets management policy
- Data classification policy
- Vendor security risk assessment
Sign-off panel:
- Plan owner: {{PLAN_OWNER_SIGNATURE_BLOCK}}
- Disaster recovery technical lead: {{DR_TECHNICAL_LEAD_SIGNATURE_BLOCK}}
- Business continuity lead: {{BC_LEAD_SIGNATURE_BLOCK}}
- Executive sponsor: {{EXECUTIVE_SPONSOR_SIGNATURE_BLOCK}}
- Legal authority: {{LEGAL_AUTHORITY_SIGNATURE_BLOCK}}
Acknowledgement (recorded for stakeholder groups; renewed at material revision):
- Heads of line-of-business operations in scope: {{LINE_OF_BUSINESS_ACKNOWLEDGEMENTS}}
- Heads of engineering and platform: {{ENGINEERING_ACKNOWLEDGEMENTS}}
- Heads of customer-facing functions: {{CUSTOMER_FACING_ACKNOWLEDGEMENTS}}
- HR and workforce coordination: {{HR_ACKNOWLEDGEMENTS}}
- GRC and internal audit: {{GRC_ACKNOWLEDGEMENTS}}
- Insurance and finance: {{INSURANCE_ACKNOWLEDGEMENTS}}
Effective date once all approval signatures collected: {{EFFECTIVE_DATE_FINAL}}
Acknowledgement evidence:
- Signed acknowledgement records stored with the plan version.
- Acknowledgement renewal cadence: at every material revision plus annual training cycle.
- New stakeholder onboarding includes plan acknowledgement.
Six failure modes the plan has to design against
A BCDR plan fails the regulator read, the audit read, the insurer read, and the internal-operations read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the plan defensible.
Backup posture without rehearsed restore
The firm runs daily backups, holds them in object storage with retention locks, and reports a green backup status to the audit committee. The first time the restore procedure runs against a tier-zero workload, it is the event itself rather than a quarterly rehearsal. The observed restore time exceeds the documented RTO by a multiple, the application configuration does not survive the restore because the runbook was last updated against a prior schema, and the dependency on the secondary identity provider was never documented. The fix is the integrity-verification cadence in Section 6 and the parallel-test cadence in Section 10: rehearse the restore on a representative tier-zero workload at the quarterly cadence and capture the observed RTO and RPO against the documented objectives.
BIA based on guessed impact bands rather than business-owner validation
The plan tier definitions look professional but the financial impact bands per hour were drafted by the BCDR coordinator without sitting with the line-of-business owner. The recovery strategy in Section 5 is then over-engineered for processes the business could tolerate offline for a week and under-engineered for processes the business cannot tolerate offline for an hour. When the activation criteria in Section 3 fire on a tier-two outage that turns out to be a tier-zero outage in customer perception, the recovery investment is misaligned. The fix is the BIA validation discipline in Section 2: validate every tier classification with the named line-of-business owner and the executive sponsor, and validate every RTO against the recovery strategy so the plan does not promise objectives the architecture cannot deliver.
Plan as document the audit reads, not procedure the operators rehearse
The plan exists, the audit passes, the exercise is annual at most, and the response team has never run the procedure under representative conditions. When the activation criteria fire, the standing roles in Section 3 mobilise but spend the first hour re-reading the plan and re-discovering the dependency map. The recovery sequencing improvises against the runbook rather than executing against rehearsed muscle memory. The fix is the exercise cadence in Section 10: multiple cadences across plan review, walk-through, tabletop, simulation, parallel test, and full interruption test so the plan is procedure not literature.
Vendor dependency mapping that stops at the first tier
The firm maps the SaaS providers it pays directly but does not map the cloud regions, identity providers, certificate authorities, and upstream data processors those SaaS providers depend on. A regional cloud outage takes down a SaaS provider the firm does not even know was hosted there; the recovery commitment from the SaaS vendor reads against the SaaS-side RTO but not the underlying-cloud RTO; the substitution plan was never written because the dependency was invisible. The fix is the fourth-party visibility discipline in Section 9: capture the upstream cloud, identity provider, data processor, and resilience arrangement for tier-zero vendors, and read material changes against the firm recovery objective.
Continuity strategy that assumes corporate email and chat are available
The plan reads as if the workforce can coordinate through corporate email and the primary chat platform during the disruption. The disruption that takes down the primary identity provider also takes down the email and the chat. The workstream leads cannot reach each other through the documented channels and revert to personal channels with no audit trail. Customer notifications cannot leave the trust centre because the trust centre depends on the same identity provider. The fix is the out-of-band channel discipline in Section 4: the continuity strategy assumes the primary identity, email, and chat may themselves be affected and names the out-of-band channel that is independent of the production identity stack.
Plan revision triggered only by the annual review
The estate changes during the year through acquisitions, new product lines, new sector regulators, new third-party SaaS commitments, cloud-region migrations, and identity-provider changes. The plan is revised once a year. By the time the annual review surfaces the drift, the plan reads against an estate that no longer exists and the BIA workbook references systems that have been retired. When the activation criteria fire on the actual estate, the runbook portfolio is incomplete for the systems that are actually affected. The fix is the material revision trigger discipline in Section 11: every standards change, every material estate change, every material activation event, every material exercise finding, and every audit finding triggers a plan revision rather than waiting for the annual cycle.
Ten questions the quarterly governance review has to answer
Operational review keeps the runbooks and the exercise schedule current. Governance review answers whether the programme is delivering durable continuity and recovery capability or accumulating drift between the documented plan and the lived estate. Run these ten questions at every quarterly review and capture the answers in the governance record.
1.What is the BIA refresh status across in-scope business processes, how many processes were tier-reclassified in the period, and is the current tier classification validated with named line-of-business owners.
2.What is the observed RTO and RPO on the most recent restore rehearsal per tier-zero system, what is the gap against the documented objective, and what is the remediation plan if any.
3.How many exercise events ran in the period across plan review, walk-through, tabletop, simulation, parallel test, and full interruption test, what scenarios did they cover, and what after-action items remain open past their target dates.
4.How many activation events fired in the period, what was the longest activation duration, what was the median time from declaration to standing-role mobilisation, and what after-action items remain open.
5.What is the upstream vendor coverage rate for documented recovery commitments against tier-zero and tier-one dependencies, and how many vendor exceptions are currently open in the register.
6.How many fourth-party material changes were captured in the period, how many of them affected the firm recovery objective, and how many triggered a BIA revisit.
7.How many runbook updates were issued in the period, how many were triggered by exercise findings versus material estate changes, and what is the median age of the per-system runbooks.
8.What is the integrity-verification cadence performance against the documented schedule per tier, how many failed checks opened remediation findings, and what is the closure rate.
9.Did a standards version change (ISO 22301 revision, ISO/IEC 27031 revision, NIST SP 800-34 revision, sector regulator update) trigger a plan revision in the period.
10.What did the most recent annual board or audit-committee read of the BCDR programme summary surface, and what residual risk position was accepted by the executive sponsor.
How the plan pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs incident response, vulnerability management, audit evidence, and security testing on a workspace, the plan commitments become the byproduct of the work rather than a separate tracking project. SecPortal carries every signed plan version, every BIA artefact, every exercise after-action, every activation timeline, every decision register, and every recovery validation evidence record on one workspace so the audit committee read of continuity and recovery performance and the operational read are the same record.
The document management feature carries the plan versions, the BIA workbook, the per-system recovery runbooks, the vendor recovery commitments, the exercise after-actions, and the disposition record for retired plan versions. The activity log captures every plan publication, every activation event, every standing-role acknowledgement, every recovery decision, every external statement release, every stand-down decision, and every after-action commitment with the actor, the timestamp, and the workspace context, so an auditor or a regulator can reconstruct the event with a single CSV export. The findings management feature carries the recovery-anchored findings (vulnerabilities surfaced during a restore, dependency gaps surfaced during an exercise, runbook defects surfaced during a tabletop) with CVSS 3.1 scoring and the 300+ template library, so the exercise after-action items track to closure on the same record as the wider vulnerability programme. The engagement management feature scopes every activation event and every named exercise so the timeline, the decision register, the recovery validation evidence, and the after-action are one record.
The compliance tracking feature carries the framework crosswalk so the ISO 22301, ISO/IEC 27031, NIST SP 800-34, SOC 2, PCI DSS, HIPAA, NIS2, and DORA audit-read is a query against the live record rather than a reconstruction. The team management RBAC carries the standing roles in Section 3 (BCDR coordinator, DR technical lead, BC lead, crisis communications lead, regulator liaison, security incident commander, vendor management lead, finance and insurance lead) so a regulator question or a workstream issue reaches a named person on the workspace rather than an inbox. The multi-factor authentication control gates the access to the plan record and the activation workspace.
The AI report generation workflow drafts the leadership briefing, the board update, the insurer disclosure pack, and the regulator notification text from the same engagement data so the executive review and the audit read are the same record. The notifications and alerts feature routes standing-role acknowledgement and workstream-lead engagement during activation. The continuous monitoring schedules the periodic external, authenticated, and code scans that read against the recovery posture so the recovery-anchored vulnerabilities surface on the same backlog as the wider security record. The encrypted credential storage carries the AES-256-GCM-encrypted scanning credentials so the authenticated scans that validate restored systems do not require ad-hoc credential staging.
The platform does not execute the failover, drive the backup replication, operate the regulator notification on the firm behalf, or replace the dedicated BCDR-management systems and the infrastructure-as-code recovery automation the engineering function operates. The responders run the response, the recovery engineers run the recovery, the plan codifies the rules, and SecPortal carries the durable workspace record the response runs against and the audit reads after.