BCPMP cheat sheet

Program scope defines which products, services, sites, and legal entities fall inside the BCMS; anything outside scope must be documented as an explicit exclusion with rationale.

The four phases of the BCM lifecycle are plan (establish the program), do (implement and operate), check (test and review), and act (maintain and improve); each phase produces auditable evidence.

A program charter assigns authority to the BC manager, names an executive sponsor, and defines decision rights for plan activation and resource spending.

Steering committee membership should include operations, IT, facilities, HR, legal, finance, communications, and supply chain; single-function ownership is a common failure mode.

The BIA and risk assessment are the only defensible basis for strategy selection; budgets justified by BIA-derived RTOs and financial impact survive executive review better than generic uptime targets.

Program maturity can be scored on a five-level scale (ad hoc, developing, defined, managed, optimized) across policy, BIA, strategies, plans, exercises, and maintenance.

Policy statements must state the program's objectives, mandatory requirements, scope, and the accountability of all staff, and must be reviewed at least annually or after major change.

Budgeting for continuity should separate recurring costs (staff, tools, maintenance) from one-time costs (alternate site build, plan development, initial exercises).

Regulatory and contractual drivers (sector regulators, customer SLAs, audit obligations) should be inventoried at initiation because they set minimum acceptable RTO and testing frequency.

Risk = likelihood × impact; a common five-by-five matrix yields scores from 1 to 25, with thresholds (for example 12 or higher) triggering treatment or escalation.

Risk treatment options are avoid, reduce, transfer (insurance, contracts), and accept; residual risk after treatment must be documented and formally accepted by a risk owner.

The BIA collects three time-based values per activity: RTO (maximum tolerable downtime), RPO (tolerable data loss), and MTD/MTPD (point at which harm becomes unacceptable).

MTD is always greater than or equal to RTO, and RTO must be less than or equal to MTD; a plan whose recovery exceeds MTD is non-compliant by definition.

Impact categories typically assessed over time horizons (1 hour, 4 hours, 1 day, 1 week, 1 month) are financial, regulatory/legal, operational, reputational, safety, and contractual.

Dependency mapping flows upward from critical activities to the applications, data, people, facilities, utilities, and third parties they rely on; the shortest dependency chain sets the true recovery constraint.

Recovery priority is assigned by combining impact at the RTO horizon with dependencies; activities with the earliest RTO and highest impact rank highest regardless of organizational seniority.

BIA data should be gathered by structured interviews or questionnaires, validated by the activity owner, and reconciled against the risk register so that single points of failure are visible.

Maximum tolerable data loss (RPO) drives backup and replication design; a 15-minute RPO cannot be met by nightly tape backup.

Strategy options, in ascending cost, are do nothing/accept, manual workaround, reciprocal agreement, cold site, warm site, hot site, and fully redundant active-active; each must be justified against the BIA-derived RTO.

Recovery time achievable at a site equals activation time plus data restoration time plus application start-up time; a strategy that ignores any one of these three will miss its RTO.

Alternate site distance must exceed the credible impact radius of the most likely disaster (flood plain, wildfire zone, regional grid outage, hurricane track).

Data replication choices: synchronous replication gives near-zero RPO but requires low latency and doubles write cost; asynchronous replication tolerates distance at the cost of some data loss.

Work-from-home as a strategy requires verified per-role suitability, bandwidth, endpoint security, and a tested ability to handle the peak concurrent remote load.

Manual workarounds are valid strategies for short RTOs only if the required forms, authority limits, and trained staff are pre-positioned and exercised.

Single points of failure to eliminate or mitigate include one power feed, one telecom carrier, one DNS provider, one identity provider, one key person, and one supplier.

Strategy selection should record residual risk, cost, dependencies, and the owner's sign-off, because auditors ask why a cheaper or more expensive option was rejected.

Third-party recovery capacity (shared hot sites, cloud regions) must be contractually reserved with defined activation times; unreserved capacity is not a strategy.

The incident management team operates under a recognized structure (for example an incident command system) with defined roles: incident commander, operations, planning, logistics, finance/administration, and liaison.

Life safety takes precedence over asset protection and business recovery; evacuation, shelter-in-place, and accounting for personnel are always the first objectives.

Crisis communication follows a single-voice rule: one designated spokesperson, pre-approved holding statements, and a defined cadence (for example updates every 60 minutes) until resolution.

Notification cascades must be tested for both speed and completeness; a common target is reaching all critical staff within 30 minutes via at least two independent channels.

Emergency response plan elements include hazard identification, evacuation routes and assembly points, shelter-in-place triggers, medical response, and interaction with public responders.

Activation criteria and escalation triggers should be objective (for example a facility unavailable for more than two hours, or any fatality) to avoid delayed or inconsistent declarations.

Crisis teams need a designated alternate for every role and a remote or alternate meeting capability in case the primary command location is inaccessible.

Post-incident review within a defined window (for example 10 business days) captures timeline, decisions, root cause, and corrective actions with owners and due dates.

Joint training with fire, police, public health, and utility providers improves response; external responders should know site layouts, shut-offs, and hazardous materials locations.

Plan hierarchy: policy, business continuity plan, business unit/functional plans, IT disaster recovery plan, crisis communication plan, emergency response plan, and supplier contingency plans, each cross-referenced.

Every plan must contain purpose, scope, assumptions, roles and responsibilities, activation authority, procedures, dependencies, contact lists, and a version control block.

Plans are written for use under stress: short action-oriented steps, checklists, decision trees, and clearly marked decision points outperform narrative prose.

Contact and call-tree data must include alternates, be stored offline and off-site, and be refreshed on a fixed cycle (for example quarterly) because stale contacts are the most common plan failure.

Recovery procedures should state prerequisites, sequence, expected duration, verification steps, and the point at which normal operations resume.

Assumptions must be explicit and testable (for example 'the primary data center is destroyed but the network core survives'), because untested assumptions are the largest hidden risk.

Document control requires unique document IDs, version numbers, approval signatures, distribution lists, and a defined review frequency, typically annual or upon significant change.

Plans should be available in a format accessible without the corporate network, such as printed copies or an offline repository, since the intranet may be the outage.

Recovery runbooks for technology must map each application to its servers, data stores, dependencies, backup location, and restoration order.

Exercise types in ascending complexity: plan walkthrough (tabletop), component test, functional exercise, full-scale simulation; each validates different objectives and should be scheduled in a progression.

Every exercise needs documented objectives, scope, scenario, participants, a safety plan, and a no-fault ground rule so that findings are reported honestly.

After-action reports should be produced within a defined window (for example 30 days) and must include observations, root causes, corrective actions, owners, and due dates.

Exercise frequency is commonly annual for full-scale and semi-annual for tabletop, but contractual or regulatory requirements may set a higher bar.

Awareness training targets all staff and covers what to do in the first minutes, evacuation, reporting, and where plans live; it is distinct from role-based training for recovery teams.

Role-based training for the crisis team, recovery teams, and call-tree coordinators should be competency-checked, not merely attendance-tracked.

Exercise scenarios should be rotated across hazards (cyber, facility loss, supplier failure, pandemic, utility outage) so that plans are not validated against only one threat.

Metrics that evidence program health include percentage of staff trained, exercise completion rate, corrective actions closed on time, and mean time to activate.

Corrective actions must be tracked to closure in a register; an exercise whose findings are never remediated provides false assurance.

Plans should be reviewed at least annually and after any of: a real incident, an exercise, a major organizational change, a new critical supplier, or a significant technology change.

A maintenance calendar should schedule BIA refresh, risk assessment refresh, plan updates, training, exercises, supplier reviews, and management review so that none is skipped.

Change management integration is essential: projects that alter critical applications, sites, or suppliers must trigger a continuity impact check before go-live.

Management review should examine metrics, audit findings, exercise results, residual risk, and resource adequacy, and should record decisions and approvals.

Program audits, whether internal or third-party, should test evidence rather than intent: call-tree logs, exercise reports, training records, and plan version history.

Key risk indicators and maturity scores tracked over time demonstrate improvement; a flat trend across cycles signals a maintenance failure, not stability.

Corrective and preventive action registers need owner, due date, status, and verification of effectiveness, not just closure by assertion.

Version control discipline prevents responders from using superseded plans; superseded copies must be recalled and archived with a clear reason for the change.

Lessons learned from actual disruptions should be fed back into the BIA and risk assessment, since real events reveal dependencies that workshops miss.

External stakeholders to map include public emergency services, regulators, utilities, telecoms, key customers, critical suppliers, and industry information-sharing bodies.

Supplier criticality is tiered by the impact of failure on the organization's RTO-critical activities, not by spend; a low-cost sole-source component can be tier one.

Supplier due diligence should verify the supplier's own continuity plan, its RTO and RPO commitments, its dependency on the same hazard as the buyer, and its insurance.

Contracts should contain continuity obligations: notification timelines, recovery commitments, audit or attestation rights, subcontractor disclosure, and exit or transition assistance.

Concentration risk arises when multiple suppliers share a geography, a data center, a cloud region, or an upstream provider; map fourth parties to expose hidden common-mode failure.

Mutual aid and reciprocal agreements must be documented, tested, and reviewed because informal understandings fail under simultaneous regional demand.

Regulatory notification duties (for example breach or outage reporting to a sector regulator) have fixed deadlines and should be written into the crisis communication plan.

Information sharing with government and industry bodies should be governed by a defined protocol covering what is shared, with whom, and under what legal constraints.

Supplier resilience should be re-verified on a schedule and after supplier ownership or geographic changes, and results recorded in the risk register.