BCB-PMD cheat sheet

BCMS lifecycle per ISO 22301: Plan-Do-Check-Act, with four mandatory elements: management commitment, BC policy, BC objectives, and documented BCMS scope.

Program scope statement must name included organizational units, products/services, locations, and exclusions with justification; scope drives all downstream BIA and risk work.

BC policy is approved by top management, communicated internally, and reviewed at planned intervals; it authorizes the BC program and defines roles and responsibilities.

RACI model assigns accountability for BC: top management owns the BCMS, the BC coordinator manages the program, business unit owners own plans, and all staff own response actions.

BCM program maturity is commonly staged: project initiation, BIA and risk assessment, strategy selection, plan development, exercising, and continuous improvement.

Three program drivers: regulatory/compliance obligation, contractual/customer requirement, and business self-interest (revenue, reputation, legal liability).

BCM program budget covers personnel, tools (BIA/planning software, alerting), alternate site contracts, exercising costs, and training.

Program documentation hierarchy: BC policy, BCMS scope and objectives, BIA and risk results, BC strategies, plans, exercise reports, and audit records.

Integration rule: BC must align with ERM, IT disaster recovery, supply chain risk, and crisis communications; standalone BC programs fail audit and real-event tests.

BIA output: for each activity, identify criticality, dependencies, RTO, RPO, MTD/MAO, and financial/operational/regulatory impact over time.

RTO = maximum tolerable time to restore a process; RPO = maximum tolerable data loss measured in time; MTD = time beyond which impact is unacceptable; MAO = MTD minus time to detect and respond.

Risk score = likelihood × impact (or consequence × probability); heat maps rank risks into tiers that determine treatment priority.

Impact categories in BIA: financial, operational, legal/regulatory, reputational, safety, and contractual; each is rated over time horizons (hours, days, weeks).

Criticality tiers commonly: critical (RTO < 4 hours), high (4–24 hours), medium (24–72 hours), low (>72 hours); tiering drives recovery strategy.

Risk treatment options: mitigate, transfer (insurance/contract), avoid, accept; residual risk must be documented and approved by the risk owner.

BIA data sources: interviews with process owners, workflow documentation, financial records, dependency mapping, and historical incident data.

Dependency mapping captures internal (people, systems, facilities) and external (suppliers, utilities, telecom) inputs; single points of failure are flagged for strategy.

Risk assessment must be repeated at planned intervals and after significant change (merger, new system, site move, supplier change).

Strategy selection compares recovery options by RTO/RPO fit, cost, risk, and feasibility; the chosen strategy must meet the BIA-derived RTO and RPO.

Recovery tiers for facilities: hot site (ready, near-zero RTO), warm site (partially equipped, hours to days), cold site (shell, days to weeks), and reciprocal/mobile/workspace recovery.

Data recovery strategies: backups (frequency defines RPO), replication (synchronous = near-zero RPO, asynchronous = minutes of data loss), and continuous data protection.

Workforce strategies: cross-training, succession planning, remote work capability, alternate shift patterns, and mutual aid agreements.

Supplier strategies: dual sourcing, buffer stock, contractual BC clauses, supplier BIA, and geographic diversification of critical vendors.

Strategy cost is justified by the cost of downtime; if recovery cost exceeds the loss from downtime, the strategy is over-engineered.

Solution design must address people, process, technology, facilities, data, and suppliers together; a gap in any one component invalidates the strategy.

Interdependencies constrain strategy: a system recovery that depends on a network or identity service must recover those dependencies first (recovery sequencing).

Plan structure: purpose and scope, roles and responsibilities, activation criteria, notification procedures, response actions, recovery procedures, and appendices (contact lists, resource inventories).

Plans must be written for the audience: action-oriented, task-based, with named roles rather than named individuals where possible.

Contact lists require multiple channels, out-of-band verification, and scheduled review; stale contacts are the most common plan failure.

Activation criteria are pre-defined thresholds (e.g., site unavailable > 2 hours, system outage exceeding RTO) that trigger plan invocation without debate.

Plans must document manual workarounds for critical processes when systems are unavailable, including paper forms and alternate approvals.

Version control: each plan carries a version number, owner, approval date, and distribution list; superseded copies are withdrawn.

Recovery procedures should be sequenced and time-stamped so teams know the order of restoration and dependencies.

Plan documentation must include crisis communications templates, regulatory notification requirements, and escalation paths to executive management.

Crisis management team (CMT) roles: crisis leader, operations, communications, legal, HR, IT, and liaison to emergency services; each has a named alternate.

Emergency response priorities in order: life safety, incident stabilization, property protection, then business recovery.

Crisis communications: single spokesperson, pre-approved holding statements, stakeholder-specific channels, and a defined cadence for updates.

Incident command structure (e.g., ICS) separates command, operations, planning, logistics, and finance/administration for scalable response.

Notification systems: mass notification, call trees, and alerting tools must be tested; escalation timing is defined in the plan.

Crisis decision log records time-stamped decisions, rationale, and approvals for post-incident review and legal defensibility.

Regulatory and contractual notifications (data breach, safety incident, service-level breach) have legal deadlines that must be pre-identified.

Demobilization and recovery-to-normal transition criteria are documented so the CMT knows when to stand down.

Exercise types in increasing complexity: plan review/walkthrough, tabletop, functional drill, full-scale simulation, and live failover test.

Exercise program should follow a multi-year cycle that covers all critical plans and strategies at least annually, with high-risk plans more often.

Every exercise requires objectives, scope, scenario, participants, evaluation criteria, and a written after-action report with corrective actions.

Corrective actions are tracked to closure with owners and due dates; open actions are reported to management.

Maintenance triggers: scheduled review (at least annually), organizational change, new system or supplier, audit finding, and post-incident lessons.

Testing alternate sites and recovery technology validates that documented RTO/RPO can actually be achieved.

Exercise metrics: objectives met, issues found, time to activate, time to recover, and percentage of corrective actions closed.

Lessons learned must feed back into BIA, risk assessment, strategy, and plan updates - closing the PDCA loop.

KPIs measure program health: plan coverage %, exercise completion %, corrective action closure rate, training completion %, and BIA currency.

Metrics must be SMART - specific, measurable, achievable, relevant, time-bound - and tied to BC objectives.

Internal audit and management review are required BCMS elements; review inputs include audit results, exercise outcomes, and risk changes.

Nonconformities and corrective actions follow a documented process: identify, contain, root-cause, correct, verify effectiveness.

Maturity models (e.g., capability maturity levels 1–5) benchmark the program from ad hoc to optimized.

Trend analysis of incidents and exercises identifies systemic weaknesses for strategic investment.

Management review outputs include decisions on resources, scope changes, and improvement priorities.

Benchmarking against standards (ISO 22301, NFPA 1600) and peer organizations guides improvement targets.

Professional codes require competence, integrity, confidentiality, objectivity, and avoidance of conflicts of interest.

Governance structures: board or executive oversight committee, BC program owner, and internal audit independence from program management.

Documentation and records must be retained per legal/regulatory schedules and protected for confidentiality and availability.

Ethical duties include accurate reporting of program status, transparent disclosure of residual risk, and protection of stakeholder safety.

Third-party and supplier governance: due diligence, contractual BC requirements, right-to-audit clauses, and periodic assurance.

Regulatory landscape includes industry rules (financial, healthcare, utilities) and privacy laws that impose notification and continuity obligations.

Professional development: certifications (CBCP, MBCI), continuing education, and participation in professional associations maintain competence.

Whistleblowing and escalation channels must exist for reporting unsafe or noncompliant BC practices without retaliation.