Business Continuity Management (BCM)

Business Continuity Management (BCM) — What is BCM?

TL;DR — Is BCM the same as BCP?

Business Continuity Management (BCM) is the management system an organisation uses to keep operating through disruption: business impact analysis, risk assessment, choice of strategy, plans, testing, audit and improvement, run as a cycle rather than as a project. The distinction that causes most confusion is that BCM is the process, a Business Continuity Plan (BCP) is one of the documents it produces, and a Disaster Recovery Plan (DRP) is the IT-focused subset of that plan. The international standard describing the whole system is ISO 22301:2019, and it is the reference auditors work from. For a deeper operational walkthrough see the full BCM guide and the article on the business continuity plan (BCP).

BCM vs BCP vs DRP vs IRP — comparison table

The four terms are often used interchangeably, even though they describe different levels of abstraction. The table below clarifies how they relate:

Property	BCM	BCP	DRP	IRP
Definition	Management process for operational continuity (the BCMS)	Continuity plan for a specific business process	IT environment recovery plan after a disaster	Plan for responding to a security incident
Scope	Whole organization, all critical processes	A single business process or unit	Specific IT systems, data centers, applications	A single incident (cyberattack, breach, malware)
Time horizon	Continuous (PDCA)	Activated during a disruption, runs until recovery	Activated during an IT disaster, runs until recovery	Activated from detection to incident closure
Ownership	Business Continuity Manager, executive sponsor	Business process owner	CIO / IT Operations	CISO / SOC, Incident Response team
ISO standard	ISO 22301:2019 (BCMS), ISO 22313 (guidance)	ISO 22301 (contains BCP requirements)	ISO 27031 (ICT readiness), NIST SP 800-34	ISO 27035, NIST SP 800-61
Deliverable format	Policy + management system + BCMS documentation	Operational document + runbook + contact list	Technical documentation + scripts + runbooks	SOC playbooks + SOAR procedures + IR runbooks
Update cadence	Annual internal audit and management review, plus after major changes	After process changes, at minimum annually plus after each test	After IT architecture changes, at minimum annually	After every incident (lessons learned)
Typical team	Executives, BCM Office, risk, compliance, IT	Process owner + operational team	IT Operations, infrastructure, network, database	SOC, CSIRT, IR team, legal, PR

In practice: BCM contains BCP, and BCP contains DRP. The Incident Response Plan (IRP) runs in parallel and is triggered by cybersecurity incidents — during a serious incident (for example, ransomware paralyzing systems) the IRP usually escalates alongside the BCP and DRP, as described in incident response.

Definition of Business Continuity Management

Business Continuity Management (BCM) is the continuous, systematic management process by which an organization identifies potential threats to its operations and the impact of those threats on business functions, and then builds the capability (plans, procedures, technology, resources) to preserve operational continuity or rapidly resume operations after an incident. ISO 22301:2019 defines the Business Continuity Management System (BCMS) as the part of the overall management system that establishes, implements, maintains, and improves business continuity.

In practice, BCM answers three core questions:

1. Which business processes are critical — what truly cannot stop, and what can survive a few days of disruption?
2. How much loss is acceptable — in time (RTO), in data loss (RPO), in money, in reputation, in regulatory exposure?
3. Which capabilities must we maintain — alternate locations, backup suppliers, replicated systems, manual procedures, communication plans?

BCM is not a one-off project. It is a management system, similar to ISMS (ISO 27001) or QMS (ISO 9001), running a PDCA (Plan-Do-Check-Act) cycle with regular internal and external audit.

Core components of a BCM framework

A mature BCM framework typically contains eight key components, which generally map directly to the structure of ISO 22301:

1. Policy & Governance — a BCM policy approved by executive leadership, definition of BCMS scope, roles, and responsibilities (Business Continuity Manager, executive sponsor, process owners, crisis management team).
2. Business Impact Analysis (BIA) — identification of business processes, their criticality, dependencies (people, suppliers, IT, locations), and quantification of financial and reputational loss as a function of downtime. ISO 22317 is the standard dedicated specifically to BIA.
3. Risk Assessment — analysis of threat scenarios: cyberattack, data center outage, fire, supplier failure, pandemic, terrorism, natural disaster, telecom failure.
4. Strategy Selection — choice of a continuity strategy for each critical process: hot/warm/cold site, synchronous replication, remote work, alternate supplier, manual fallback procedures, network redundancy.
5. Implementation — production of operational documentation: BCP per process, DRP per IT system, crisis management plan, crisis communication plan, runbooks.
6. Awareness & Training — team training, emergency contacts, decision maps, crisis-team leader training, employee awareness of evacuation and notification procedures.
7. Testing & Exercising — from table-top exercises (workshops walking through a scenario) through walk-throughs (live simulation involving operational teams) to a full failover to the alternate site. Typically at least once a year, and more often for NIS2/DORA-regulated entities.
8. Review & Improvement — internal audit, management review, lessons learned from tests and real incidents, BIA refresh after organizational changes (mergers, new systems, new locations).

These components are not optional — ISO 22301 requires their presence as a condition of BCMS certification.

BCM lifecycle aligned with ISO 22301

ISO 22301:2019 organizes its requirements into the classic PDCA (Plan-Do-Check-Act) cycle that is familiar from other ISO management system standards. The mapping is:

• Plan (clauses 4-6): Context of the organization, leadership, planning. Defining BCMS scope, BCM policy, continuity objectives, roles, and responsibilities.
• Do (clauses 7-8): Support and operations. This is the heart of the system — BIA, risk assessment, continuity strategies, plan development (BCP, DRP, crisis plans), training, awareness, communication.
• Check (clause 9): Performance evaluation. Monitoring, measurement, internal audit, management review, testing, and exercising continuity plans.
• Act (clause 10): Improvement. Corrective actions following nonconformities, lessons learned, continual improvement of the BCMS.

Clauses 1-3 of ISO 22301 are introductory — scope, terms, and normative references — and contain no auditable requirements.

ISO 22301 is often implemented alongside ISO 27001 (information security management system) — both standards share the ISO High Level Structure (HLS) and are naturally complementary. An organization that already runs an ISMS usually has much of the organizational infrastructure required for a BCMS. For entities subject to NIS2 and DORA, a combined ISO 27001 + ISO 22301 implementation is often the most efficient approach.

BIA (Business Impact Analysis) step by step

Business Impact Analysis is the foundation of BCM — without a properly executed BIA the rest of the system rests on assumptions. A typical BIA covers seven steps:

1. Identify business processes — all the organization’s key processes (sales, customer service, production, logistics, billing, HR, IT operations). A mid-size organization usually has 30 to 80 processes to catalog.
2. Measure the criticality of each process — a typical four-level scale: critical (a stop of less than 4h is catastrophic), highly important (4-24h), important (1-3 days), low priority (more than 3 days). Measured along financial, regulatory, reputational, operational, and life-safety dimensions.
3. Determine RTO and RPO per process — the Recovery Time Objective (how quickly the process must be back) and the Recovery Point Objective (how much data can be lost). These two parameters drive the entire DR architecture design and its cost.
4. Identify supporting resources — for each critical process, list the resources required to perform it: people (skills), IT applications, databases, network infrastructure, third-party suppliers, physical locations, documentation.
5. Map dependencies — relationships between processes (process A needs the output of process B), single-supplier dependencies (single points of failure), shared infrastructure. This is often the hardest part of the BIA and where hidden risks tend to surface.
6. Estimate loss as a function of time — how much the organization loses financially per hour / day / week of process downtime, what the reputational and regulatory consequences are, and what the impact on customers is.
7. Validate results with executives and process owners — a BIA is not an IT document, it is a business document. It needs formal validation and sign-off from process owners and the executive team.

In practice, BIAs are run on a cycle (usually annually and after major organizational changes — mergers, new business lines, migrations of critical systems). ISO 22317 provides detailed methodological guidance for BIA.

RTO, RPO, MTPD, MAO — key BCM metrics

Four metrics dominate BCM decisions. All of them are expressed in units of time and are direct inputs to DR architecture design and cost.

Metric	Definition	Example values
RTO (Recovery Time Objective)	Maximum acceptable time from disruption to process restoration	Online bank: 4h. Critical hospital systems: 30 min. E-commerce during peak season: 1h. Internal BI: 3 days.
RPO (Recovery Point Objective)	Maximum acceptable data loss measured in time (how much work in minutes/hours can be lost)	Bank: under 5 min (synchronous replication). E-commerce: 15 min. Payroll: 24h. Internal CRM: 4h.
MTPD (Maximum Tolerable Period of Disruption)	Maximum period after which the absence of a process threatens the organization’s survival	Factory production line: 7 days. Online banking: 24h. Billing system: 14 days.
MAO (Maximum Acceptable Outage)	Synonym of MTPD used in some frameworks (BCI Good Practice Guidelines, DRII)	Often treated interchangeably with MTPD in practice

In practice, RTO must be shorter than MTPD with a safety margin. If MTPD is 7 days, RTO is typically set at 2-4 days, giving the organization a buffer for unforeseen complications. RPO in turn drives the cost of the backup solution — the lower the RPO, the more expensive the solution (synchronous replication versus daily tape backup is an order-of-magnitude cost difference).

Common regulatory frameworks requiring BCM in 2026

In 2026, BCM is required directly or indirectly by numerous regulatory frameworks across the EU, US, UK, and APAC. The list keeps growing:

• NIS2 Directive (EU, transposition into national law completed across most member states 2024-2025) — Article 21 requires essential and important entities to implement measures including business continuity, backup management, disaster recovery, and crisis management. Fines up to EUR 10M or 2% of global turnover.
• DORA (Digital Operational Resilience Act) — in force since January 2025. Imposes detailed ICT operational resilience requirements on the EU financial sector (banks, insurers, investment firms, fintechs, ICT third-party providers), including TLPT (Threat-Led Penetration Testing), ICT incident reporting, and third-party risk management.
• GDPR Article 32 — the data controller must ensure “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”. In practice, a BCP/DRP requirement for systems processing personal data.
• HIPAA Security Rule (US) — covered entities must implement a contingency plan with a data backup plan, disaster recovery plan, emergency mode operation plan, testing procedures, and applications/data criticality analysis.
• SOX Section 404 (US) — internal controls over financial reporting require the continuity of financial systems and processes.
• SOC 2 — Common Criteria 9.1 (CC9.1) — the entity must identify, select, and develop risk mitigation activities for disruptions to business operations. BCP and DR controls are routinely tested by auditors.
• PCI DSS 12.10 — requires the entity to implement an incident response plan that includes business continuity procedures.
• MAS TRM (Monetary Authority of Singapore Technology Risk Management) and MAS Cyber Hygiene — sectoral resilience requirements for the Singapore financial sector.
• APRA CPS 230 (Australia, in force since July 2025) — operational risk management standard requiring a BCP, BIA, tolerance levels, and third-party service provider management for regulated financial entities.
• UK Operational Resilience (PRA / FCA / Bank of England) — UK financial regulators require firms to identify important business services and set impact tolerances.
• Critical Entities Resilience Directive (CER) — operators of critical infrastructure (energy, transport, water, health, finance, digital infrastructure) must maintain resilience plans.
• ISO 22301 — not legally mandatory by itself, but widely used as evidence of conformance in NIS2, DORA, customer due diligence, and tender processes.

In practice, many organizations decide on a combined ISO 27001 + ISO 22301 implementation, because both standards share the ISO HLS structure and most of the system documentation.

Most common BCM implementation mistakes

Several typical pitfalls repeatedly degrade BCM effectiveness in practice:

1. Treating BCM as a one-off project instead of a continuous process. Once the implementation closes, the documents end up on a shelf and no one updates them. After 18-24 months the BCM is a fiction — RTO/RPO values are outdated, contacts have changed, and systems have been migrated.
2. BCP without testing — a plan on paper that has never been exercised. In a real situation it turns out the API keys have expired, the alternate site has no internet, the backup data is incomplete, and a key person left the company a year ago.
3. Missing dependency mapping — the BCP focuses on a single process and ignores its dependencies. A customer service plan assumes a working CRM, but the CRM depends on a database whose DRP allows for a 24h RTO. The real customer service RTO is therefore 24h, not 4h.
4. RTO/RPO set without BIA — IT picks RTO/RPO based on “best practices” or its own comfort zone, not on real business criticality. The result is either over-engineered (RTO too aggressive) or insufficient (RTO too relaxed).
5. No executive ownership on the business side — BCM is delegated entirely to IT, while the assets that need protection are business processes. Without business-side process owners, BCM has no traction.
6. Paper-only plans, not digitally accessible — BCP stored as PDF on a corporate SharePoint that is unreachable when corporate AD is down. During a real outage the crisis team cannot access its own plan.
7. No crisis communication plan — the organization knows how to technically restore systems but has no idea who communicates with customers, media, regulators, and employees. During a ransomware incident it is often this communication void that generates more reputational damage than the attack itself.

In practice, BCM maturity is measured not by the existence of documents but by the number of scenarios that have actually been exercised and by the time between an organizational change and the corresponding BCP update.

Required documentation per ISO 22301

ISO 22301:2019 requires the organization to maintain a set of auditable documentation. The minimum BCMS document set includes:

• BCM policy approved by executive leadership, with a commitment statement and the BCMS scope.
• BCMS scope — description of which organizational units, locations, and processes are covered.
• Business continuity objectives — measurable objectives consistent with the policy and reviewed annually.
• Business Impact Analysis report — documented processes, their criticality, RTO/RPO, MTPD, dependencies, and losses.
• Risk assessment report — identified threat scenarios, likelihood and impact analysis, treatment plan.
• Continuity strategies — documented and justified strategy selection per critical process.
• Business Continuity Plans (BCP) — operational plans per critical process, with runbooks, contacts, and decision maps.
• Crisis response procedures — describing crisis team activation, escalation, and communication.
• Training and awareness program — documented training, participant lists, materials.
• Test and exercise plan and reports from completed tests with lessons learned.
• Internal BCMS audit report (at minimum annually).
• BCMS management review report (at minimum annually, by executive leadership).
• Register of nonconformities and corrective actions.

In most implementations the BCMS documentation is integrated with the existing ISMS documentation (ISO 27001), which reduces duplication and administrative overhead.

Related terms

• ISO 22301 — international standard for business continuity management systems
• Disaster Recovery — technical subset of BCM focused on IT restoration
• NIS2 — EU directive requiring business continuity and crisis management
• DORA — EU regulation on operational resilience for the financial sector
• Incident Response — response to an incident, running in parallel with BCP during a cyberattack
• Cyber Resilience Services — broader operational resilience capabilities encompassing BCM
• Backup — technical foundation of every DR and BCM strategy
• Risk Management — discipline feeding the BCM risk assessment phase

Explore our services

• SOC 24/7 — detection and blocking of threats, foundation of incident response
• Incident Response — coordination during a crisis
• IT security audit — assessment of organizational readiness in BCM and DR

Business Continuity Management is not a project with a delivery date — it is a management system that matures with the organization. In practice, a well-designed BCM pays for itself at the first serious incident, and in the realities of 2026 (NIS2, DORA, ransomware escalation) the question is generally not whether such an incident will occur, but when.