A BCM program solution should do more than store continuity documents. A useful solution connects the operating model: organization structure, critical services, business impact analysis, recovery objectives, dependencies, strategies, plans, exercises, incidents, actions and reporting. The value is the relationship between those records. When one dependency changes, owners should be able to see which BIAs, plans and recovery assumptions are affected.
A complete BCM program solution usually needs governance, BIA, dependency mapping, continuity strategy, BCP/DR plans, exercises, corrective actions, incident activation, dashboards, permissions, integrations and a reliable audit trail. The software should support the BCM method; it should not become the method.
BCM program solution module map
| Module | What it should manage | Useful output |
|---|---|---|
| Governance | Scope, policy, committees, roles, review calendar and exceptions | Ownership and overdue decisions |
| Organization & services | Business units, locations, products, services, processes and owners | Common BCM data model |
| BIA | Impacts over time, MAO/MTPD, RTO, RPO, MBCO, resources and dependencies | Approved recovery requirements |
| Strategy | People, workplace, technology, data, supplier and process recovery options | Selected recovery capability |
| Plans | Activation, contacts, response, workarounds, recovery steps and return to normal | Usable BCP/DR runbooks |
| Exercises | Scenarios, objectives, injects, participants, observations and evidence | Validated capability and findings |
| Actions | Gaps, owners, due dates, evidence and verification | Improvement backlog |
| Incident mode | Activation, impacted services, situation log, tasks and status | Operational continuity view |
| Reporting | Coverage, readiness, risk, exercise status, actions and trends | Executive and operational dashboards |
The end-to-end workflow matters more than the menu
Consider a payment service with an eight-hour maximum acceptable outage, a two-hour RTO and an RPO of 15 minutes. Its BIA depends on identity services, a database, two suppliers and a small specialist team. A good BCM system lets those dependencies be reused rather than typed into separate documents. If the database recovery test shows four hours instead of two, the platform should expose a recovery gap against the approved RTO and send it into an action workflow. The plan and dashboard should then reflect the same truth.
Data model: the foundation people often underestimate
Before implementation, decide what the organization is actually managing. Some companies plan by process, others by critical service, product, legal entity, site or a combination. Define unique identifiers, ownership, hierarchy and many-to-many relationships. A service can depend on several processes; a process can support several services; one application or supplier can support hundreds of processes. If the data model cannot represent that reality, reporting will become spreadsheet reconciliation.
Requirements checklist for a BCM solution
- Configurable BIA impact categories, timeframes and approval workflow.
- RTO, RPO, MAO/MTPD and MBCO with validation rules rather than free-text only.
- Dependency records for people, applications, data, sites, equipment, suppliers and upstream/downstream processes.
- Recovery strategy decisions linked back to approved BIA requirements.
- Plan generation or structured authoring without duplicating master data.
- Exercise scheduling, scenario/inject capture, evidence and after-action tracking.
- Corrective actions with accountable owner, due date, escalation and verification.
- Role-based access down to organization or record scope, plus SSO/MFA where required.
- Audit history showing who changed important recovery assumptions and when.
- APIs/imports for HR, CMDB, supplier, incident, notification and reporting data.
- Dashboards that show capability gaps, not only completion percentages.
- Export and exit capability so BCM data is not trapped in a proprietary format.
What should a BCM dashboard show?
Separate coverage from capability. Ninety-eight percent of plans being approved does not prove the organization can recover. A stronger dashboard combines BIA freshness, plans due for review, untested critical services, RTO versus demonstrated recovery time, supplier evidence, overdue high-severity actions, exercise findings and changes affecting critical dependencies. Leadership needs the exceptions and trend; BCM teams need the underlying records.
Implementation phases
- Method first: agree scope, terminology, approval stages, impact scales and recovery fields.
- Data model: load organization, critical services, systems, suppliers, sites and owners.
- Configure one thin slice: complete one service from BIA through plan, exercise and dashboard.
- Integrate authoritative data: HR/identity, CMDB, supplier or asset sources where justified.
- Migrate selectively: move current, owned records rather than every historical spreadsheet.
- Roll out by criticality: prioritize the services where recovery decisions matter most.
- Measure adoption and quality: ownership, stale data, recovery gaps and actions are better indicators than login counts.
Open the BCM System Playground to create a demo process, run a BIA, choose a recovery strategy, build a plan, simulate an incident and see the dashboard update in your browser.
BCM software, BCMS and BCM program solution: what is the difference?
BCMS is the management system used to establish, operate, monitor, review and improve business continuity. BCM software is technology that can support parts of that management system. BCM program solution is often used commercially to describe an end-to-end platform or operating approach. ISO 22301 defines requirements for the organization’s BCMS; it does not prescribe a particular software product.
References and further reading
For the management-system foundation, see ISO 22301:2019 and its 2024 climate-action amendment. ISO has also begun development of Edition 3, which is not yet the published replacement. BCM.Center summarizes requirements without reproducing the copyrighted standard text.
Frequently asked questions
What are the core modules of BCM software?
Most mature programs need organization/services, BIA, dependencies, strategies, continuity plans, exercises, actions, reporting and administration. Incident or crisis features can be integrated when the operating model requires them.
Should a BCM solution calculate RTO automatically?
Software can propose or validate values, but RTO is a business recovery requirement that should be justified by impact and approved by accountable owners.
Can BCM software replace ISO 22301 implementation?
No. Technology can support evidence and workflow, but leadership, scope, competence, analysis, strategy, validation, audit and continual improvement remain organizational responsibilities.
Reference data model: the records a connected BCM solution needs
| Entity | Key fields | Relationships |
|---|---|---|
| Organisation unit | Code, owner, hierarchy, location, legal entity | Services, people, plans, approvals |
| Business service / product | Owner, customers, criticality, operating window | Processes, BIAs, dependencies, incidents |
| Process / activity | Owner, volumes, peak periods, workarounds | Service, BIA, resources |
| BIA | Impact by time, MTPD/MAO, RTO, RPO, MBCO, approvals | Service/process + dependencies + strategy |
| Dependency | Type, provider, location, criticality, fallback, recovery commitment | Services, processes, suppliers, applications |
| Recovery strategy | Scenario, option, capacity, cost, owner, evidence | BIA requirement, plan, capability gap |
| Plan / runbook | Activation, roles, procedures, communications, version | Service, dependencies, exercise, incident |
| Exercise | Scenario, objectives, participants, evidence, results | Plans, services, findings |
| Finding / action | Risk, priority, owner, due date, retest | Exercise, audit, incident, strategy |
| Incident activation | Affected services, decisions, tasks, SITREPs, timeline | Plans, dependencies, owners |
| Metric | Formula, source, threshold, trend, owner | Program, service, action |
Workflow states that prevent “everything is approved”
| Record | Example workflow |
|---|---|
| BIA | Draft → owner review → BCM challenge → approved → change-triggered review |
| Strategy | Proposed → feasibility review → funded/accepted → implemented → validated |
| BCP | Draft → dependency review → approved → exercised → current / review due |
| Exercise | Planned → approved → running → evaluated → actions open → closed/retested |
| Capability gap | Detected → risk assessed → remediation/acceptance → evidence → retest → closed |
40 practical requirements for a BCM program platform
- Configurable organisation hierarchy and legal-entity boundaries.
- Business-service model that can span multiple departments.
- Role-based ownership and delegated approvers.
- Configurable impact categories and time bands.
- MTPD/MAO, RTO, RPO and MBCO validation rules.
- Peak-period / seasonal criticality.
- People, site, application, data, supplier and utility dependencies.
- Upstream/downstream service mapping.
- Dependency concentration view.
- Recovery strategy option appraisal.
- Capability-vs-requirement gap register.
- BCP templates with controlled versions and approvals.
- Technology DR/runbook references without duplicating operational documentation.
- Offline/emergency access design.
- Call tree / contact test evidence.
- Exercise scheduling and scenario library.
- Injects, evaluator notes and evidence capture.
- After-action findings and corrective actions.
- Retest and closure evidence.
- Supplier continuity assessments and expiry review.
- Incident activation from approved plans.
- Task/action assignment with due/overdue visibility.
- Decision and event timeline.
- SITREP generation from structured facts.
- Internal/external communication approvals.
- Executive dashboard for material gaps.
- Service-owner dashboard for upcoming reviews/actions.
- RTO vs demonstrated recovery metric.
- MBCO/capacity validation metric.
- Audit log for content and approvals.
- SSO/MFA integration.
- Fine-grained organisational access control.
- HR integration with joiner/mover/leaver handling.
- CMDB/application inventory integration.
- Supplier master integration where justified.
- API/export capability and data ownership.
- Retention and privacy controls.
- Backup/DR for the BCM platform itself.
- AI grounding with permission-aware source retrieval and human approval.
- Exit capability: documented export so continuity data is not trapped in the tool.
Proof-of-concept scenarios that reveal weak products
- Create one service that spans two departments and three locations.
- Run a BIA with different impacts over 4h/12h/24h/3d and approve an 8h RTO.
- Map one application to five services and show concentration risk.
- Create a supplier used by multiple services and expire its resilience evidence.
- Record a DR test that misses RTO and prove the gap automatically appears on dashboards.
- Activate a service plan into incident mode and show only authorized data.
- Change an HR owner and demonstrate controlled ownership update without losing history.
- Export the complete service/BIA/plan/exercise/action history in a documented format.