BUSINESS CONTINUITY AND DISASTER RECOVERY PLAN

Business Impact Analysis · Recovery Sequencing · Crisis Roles · DR Exercises · Cyber Recovery Interface

Table of Contents

1. Purpose and Scope
2. BCP and Cyber Recovery Boundary
3. Business Impact Analysis
4. Recovery Tier Model
5. Recovery Sequencing
6. Crisis Roles and Governance
7. Plan Activation and Communications
8. Disaster Recovery Exercise Program
9. Evidence and Records
10. Metrics
11. Roles and Responsibilities
12. Regulatory and Framework Alignment Summary
13. Document Control

1. Purpose and Scope

CERG-STD-RES-001 defines the technical recovery bar: backup protection, immutable copies, restoration testing, and cyber recovery tiers. This plan defines the operational wrapper around that bar: business impact analysis, recovery sequencing, crisis roles, recovery decisioning, exercise cadence, and evidence.

This plan applies to business processes and systems whose interruption could cause material operational, regulatory, customer, safety, financial, or reputational impact. It is written as a CERG-operable plan, not a full enterprise business-continuity program charter. It gives the program-in-a-box enough structure to survive an outage and to prove the recovery discipline existed before the outage.

A Backup Is Not a Continuity Plan

A clean restore is necessary, but it is not sufficient. The business still has to know which process comes back first, which degraded process is acceptable, who declares the crisis, who talks to customers, who approves operating below normal control posture, and what evidence proves the recovery was controlled. Disaster recovery restores technology. Business continuity restores the business.

2. BCP and Cyber Recovery Boundary

CERG does not replace Enterprise BCP. CERG supplies the cyber, risk, evidence, and control integrity layer that BCP needs.

3. Business Impact Analysis

The Business Impact Analysis (BIA) is the source record for recovery priority. Each in-scope business process has a BIA record with the fields below.

BIA records are reviewed at least annually and whenever a critical process, system dependency, regulated scope, or business owner changes.

4. Recovery Tier Model

The plan uses the recovery tiers defined in CERG-STD-RES-001. The BIA may assign a stricter business requirement than the technical recovery tier, but it may not silently assign a weaker one for a regulated or mission-critical process.

RTO and RPO Are Claims Until Tested

A stated RTO or RPO does not become a planning fact until it has been demonstrated. Until then, the recovery tier is aspirational and the gap is tracked as a resilience risk. The plan may still operate, but leadership must know which recovery promises are proven and which are hoped for.

5. Recovery Sequencing

Recovery sequencing is decided before an outage, not during the worst hour of one. Each T1 and T2 process has a sequencing record:

1. Confirm safety, legal, and regulatory constraints.
2. Confirm identity, network, logging, and backup platform availability.
3. Restore or fail over platform dependencies.
4. Restore core data stores and integrity checks.
5. Restore application or operational service.
6. Validate security controls: access, logging, encryption, endpoint posture, segmentation, backup protection.
7. Validate business function with the business owner.
8. Approve return to production or degraded operation.
9. Record residual risk and exceptions.
10. Preserve recovery evidence.

A process may resume in degraded mode only when the business owner, Engineering Pillar Leader, Risk Pillar Leader, and CISO or delegate understand the missing controls and approve the risk path.

6. Crisis Roles and Governance

Where an enterprise BCP or crisis-management program names additional roles, those roles remain outside CERG. CERG coordinates through its canonical roles.

7. Plan Activation and Communications

This plan is activated when an outage, incident, disaster, supplier failure, cyber event, facility issue, or platform failure threatens a T1 or T2 process, or when the CISO, Governance Pillar Leader, Engineering Pillar Leader, or enterprise crisis process requests activation.

Activation record:

• date and time activated;
• activating role and reason;
• affected business process and systems;
• current impact and expected trajectory;
• recovery tier and sequencing priority;
• cyber control state;
• communication cadence;
• recovery decision log;
• risk acceptances or exceptions;
• closure criteria.

Communications use the enterprise crisis communications process where one exists. CERG supplies technical facts, control posture, data classification, regulated-scope facts, recovery evidence, and residual-risk statements.

8. Disaster Recovery Exercise Program

Exercise findings become risk-register entries or tracked remediation actions. A passed exercise with missing evidence is not a passed exercise for audit purposes.

9. Evidence and Records

Continuity records are retained under CERG-PRC-AUD-001.

10. Metrics

11. Roles and Responsibilities

Roles below are canonical role names from CERG-GOV-OM-001 §6.1.

12. Regulatory and Framework Alignment Summary

13. Document Control

Revision History

Review Triggers

• Major outage or disaster-recovery event
• Material change to business-process criticality
• Material change to recovery tiering or backup architecture
• Failed DR exercise or missed RTO/RPO target
• New regulated-scope recovery requirement
• Direction from the CISO

Cyber Governance owns this plan. The Governance Pillar Leader is responsible for initiating reviews, managing the revision cycle, and obtaining CISO approval and Enterprise BCP owner concurrence where applicable.

Related Documents

Source: plans/CERG-PLN-BC-001_Business_Continuity_and_Disaster_Recovery_Plan.md · Download .md · View on GitHub