Business Continuity Planning: A Comprehensive Guide
Comprehensive guide to business continuity planning for EU organisations. Covers BCP fundamentals, DORA Article 11 business continuity requirements, NIS2 Article 21(2)(c) crisis management obligations, business impact analysis, recovery strategies, and testing and exercising methodologies.
- 1
DORA Article 11 imposes the most detailed BCP requirements in EU law, including mandatory annual testing, segregated backup infrastructure (Article 12(2)), and ICT-specific response and recovery plans.
- 2
NIS2 Article 21(2)(c) requires business continuity and crisis management measures proportionate to the entity's risk exposure, with integration into the Member State and EU-level crisis coordination structures.
- 3
Business impact analysis is the non-negotiable foundation of credible BCP — without it, recovery priorities are based on assumptions rather than validated business requirements.
- 4
Testing spans a spectrum from tabletop walkthroughs (quarterly) through functional tests (semi-annually) to full-scale simulations (annually) — all three levels are necessary for validated capability.
- 5
BCP maintenance must be triggered by organisational changes, test results, and incidents — not just an annual review cycle — to prevent plans from diverging from operational reality.
1. Business Continuity Planning Fundamentals
Business continuity planning (BCP) is the process of creating systems of prevention and recovery to deal with potential threats to an organisation's ability to continue operating. In the cybersecurity context, BCP addresses a specific question: when — not if — a significant disruption occurs, how does the organisation maintain or rapidly restore its critical business functions? The shift from 'if' to 'when' reflects a maturity in thinking that EU regulators have formalised into law: both DORA and NIS2 assume that disruptions will occur and mandate preparedness rather than relying solely on prevention.
BCP encompasses several related but distinct disciplines. Business impact analysis (BIA) identifies critical business functions and the resources they depend on. Recovery strategy development defines how those functions will be maintained or restored during a disruption. Business continuity plan creation documents the specific actions, roles, and procedures for executing the recovery strategies. Crisis management addresses the decision-making, communication, and coordination structures activated during a major incident. And testing and exercising validates that plans work in practice, not just on paper. Each discipline builds on the preceding one — a recovery strategy without a BIA is based on assumptions rather than analysis, and a plan without testing is untested theory.
For EU organisations in 2026, BCP is not a voluntary best practice — it is a regulatory obligation with specific requirements and enforcement consequences. The days when business continuity was an afterthought managed by a part-time coordinator are over. Modern EU regulations treat business continuity as a core governance responsibility, subject to management body oversight, supervisory examination, and penalty exposure for deficiencies.
The scope of BCP has also expanded beyond traditional IT disaster recovery. While IT system restoration remains a critical component, EU regulations require business continuity planning that addresses operational processes, human resources, supply chain dependencies, communication with stakeholders, and coordination with sector-specific response mechanisms. A BCP that only covers IT restoration — without addressing how the business operates while IT systems are being restored — is incomplete by regulatory standards.
2. DORA Business Continuity Requirements (Article 11)
DORA Article 11 establishes the most detailed business continuity requirements in EU financial services regulation. It requires financial entities to establish a comprehensive ICT business continuity policy and associated ICT business continuity plans, ICT response and recovery plans, and arrangements for backup, restoration, and recovery. These are not suggestions — they are mandatory elements of the ICT risk management framework that supervisory authorities will examine.
The ICT business continuity policy must, under Article 11(1), be based on the entity's BIA and must aim to ensure the continuity of the entity's critical or important functions. This policy must address the arrangements for managing and resolving ICT-related incidents, the backup and restoration measures, the switchover and failover mechanisms, and the testing requirements. Critically, Article 11(3) requires financial entities to estimate the potential impact of severe business disruptions — not just routine incidents — using scenarios that include cyber-attacks, ICT failures, and natural disasters.
The ICT response and recovery plans are distinct from general business continuity plans and must focus specifically on ICT-related incidents. Article 11(4) requires these plans to be activated based on the entity's ICT incident classification, to include containment measures to limit the impact of ICT-related incidents, to define recovery procedures and timelines, and to include communication plans for internal and external stakeholders (including clients, counterparts, and supervisory authorities). The plans must also address the coordination between ICT response teams and the broader crisis management structures of the entity.
DORA Article 12 imposes specific requirements for backup policies and restoration procedures. Financial entities must maintain backup policies that specify the scope, frequency, and retention of backups; backup procedures that are regularly tested to ensure the integrity and completeness of backed-up data; and restoration and recovery methods that ensure recovery within defined time objectives. Article 12(2) is particularly important: when restoring backup data using own systems, financial entities must use ICT systems that are physically and logically segregated from the source system. This requirement directly addresses the ransomware scenario where attackers encrypt both production systems and accessible backups.
The Regulatory Technical Standards on ICT risk management, developed by the European Supervisory Authorities, add further granularity to these requirements. They specify the scenarios that must be considered in BCPs, the minimum testing frequency and methodology, the documentation standards, and the reporting obligations to supervisory authorities. Ensure your BCP programme tracks the final RTS text, not just the DORA Level 1 regulation.
DORA Article 12(2) requires backup systems to be physically and logically segregated from production systems. Air-gapped or immutable backup solutions are the most straightforward way to meet this requirement. If your backup infrastructure shares network segments, authentication systems, or management interfaces with production, it does not satisfy the segregation requirement.
3. NIS2 Crisis Management Requirements
NIS2 Article 21(2)(c) lists business continuity, such as backup management and disaster recovery, and crisis management as one of the ten mandatory measure categories for essential and important entities. While less prescriptive than DORA Article 11, NIS2's requirements apply to a broader range of organisations across all eleven Annex I sectors and seven Annex II sectors, making its business continuity obligations the most widely applicable in EU law.
NIS2's crisis management requirements operate at two levels: the entity level and the Member State/EU level. At the entity level, organisations must have business continuity and crisis management capabilities that enable them to maintain operations during and recover from significant cyber incidents. The Article 21(2)(c) measures must be proportionate to the organisation's size, risk exposure, and societal impact — a hospital's business continuity requirements are legitimately more demanding than those of a waste management company, even though both fall under NIS2.
At the Member State and EU level, NIS2 establishes crisis management structures that organisations must be prepared to engage with. Article 9 requires each Member State to adopt a national cybersecurity strategy that includes policies on crisis management. Article 15 establishes the EU Cyber Crisis Liaison Organisation Network (EU-CyCLONe) for coordinated management of large-scale cybersecurity incidents. Article 23 requires entities to submit early warning notifications within 24 hours and incident notifications within 72 hours to their national CSIRT or competent authority. Your business continuity plans must account for these notification obligations and build them into your incident response timelines.
The interaction between NIS2 business continuity requirements and incident reporting obligations deserves particular attention. When a significant incident triggers your BCP, your crisis management team is simultaneously managing the operational response (restoring services), the communication response (notifying customers, partners, and media), and the regulatory response (NIS2 notifications within 24/72 hours, potential GDPR breach notification within 72 hours under Article 33, and DORA incident classification reporting for financial entities). Your BCP must integrate these parallel workstreams rather than treating them as separate processes — the operational team cannot monopolise all senior resources while the regulatory team scrambles to meet notification deadlines with incomplete information.
Member State transposition of NIS2 may impose additional business continuity requirements beyond the Directive's minimum. Germany's NIS2UmsuCG, for example, introduces sector-specific continuity requirements for critical infrastructure operators. Review your national transposition law to identify any obligations beyond the baseline NIS2 text and ensure your BCP addresses them.
4. Business Impact Analysis
The business impact analysis is the foundation of any credible BCP. Without a BIA, your continuity plans are based on assumptions about which functions are critical, how quickly they must be restored, and what resources they depend on. A BIA converts these assumptions into documented, management-validated facts.
A BIA follows a structured process. First, identify all business functions — not just IT systems, but the end-to-end business processes that the organisation performs. For a financial entity, this includes transaction processing, customer onboarding, regulatory reporting, treasury operations, risk management, and customer service. For a healthcare provider, it includes patient care, pharmaceutical management, laboratory services, appointment scheduling, and billing. Map each function to the organisational unit responsible, the IT systems that support it, the personnel required, the third-party dependencies, and the physical locations involved.
Second, assess the impact of disruption for each function across multiple time horizons. The impact of losing a function for one hour is different from losing it for one day, which is different from losing it for one week. Assess impact at each time horizon across relevant dimensions: financial impact (lost revenue, penalties, remediation costs), operational impact (downstream process disruption, backlog accumulation), regulatory impact (missed reporting deadlines, supervisory concern), reputational impact (customer trust, market perception), and — for DORA-obligated entities — systemic impact (effects on clients, counterparts, and the financial system).
Third, determine the recovery time objective (RTO) and recovery point objective (RPO) for each function. The RTO is the maximum acceptable time before a function must be restored. The RPO is the maximum acceptable data loss measured in time — an RPO of four hours means you can tolerate losing up to four hours of data. These objectives must be validated by business stakeholders (not set by IT alone) and must be achievable with the recovery strategies you have in place. An RTO of two hours for a critical trading system is meaningless if your backup restoration process takes twelve hours.
Finally, identify dependencies and single points of failure. Many business functions share underlying IT infrastructure, third-party services, or key personnel. A BIA that evaluates functions in isolation will miss these shared dependencies — and the cascade failures they enable. If three critical functions all depend on the same database cluster, that cluster's recovery must be prioritised above all three functions' RTOs. If a single vendor provides a service that underpins multiple business processes, that vendor relationship is a concentration risk that your BCP must address. Map these dependencies explicitly and use them to prioritise your recovery sequence.
Conduct BIA interviews with business function owners, not just IT managers. IT can tell you which systems support a function; only the business can tell you the actual impact of losing that function for different durations. The difference between IT's assumption and the business's reality often reveals critical misalignments in recovery priorities.
5. Recovery Strategies and Architecture
Recovery strategies define how critical business functions will be maintained or restored during a disruption. The choice of strategy for each function is driven by its RTO and RPO (from the BIA), the cost of implementation, and the organisation's risk appetite. There is no one-size-fits-all approach — different functions warrant different recovery strategies based on their criticality and the cost-benefit calculus of protection.
Hot standby (active-active) involves running parallel environments that can assume the full workload with zero or near-zero interruption. This strategy delivers the lowest RTO (typically seconds to minutes) and RPO (typically zero data loss through synchronous replication) but is the most expensive, as it requires duplicating the entire infrastructure and maintaining both environments at production readiness. Hot standby is appropriate for the most critical functions — real-time transaction processing, patient monitoring systems, or operational technology controlling physical infrastructure — where any downtime has immediate safety, financial, or systemic consequences.
Warm standby involves maintaining a secondary environment that is partially configured and can be brought to full operation within hours. The RTO is typically 2-8 hours, with RPO depending on the replication frequency (asynchronous replication at hourly intervals produces an RPO of approximately one hour). Warm standby is the most common strategy for important-but-not-critical functions and provides a reasonable balance between cost and recovery speed. For DORA-obligated entities, warm standby for critical or important functions is typically the minimum acceptable strategy.
Cold standby involves maintaining infrastructure capacity (hardware, cloud reservations, licenses) that must be fully configured and loaded with data from backups before becoming operational. RTOs range from days to weeks, and RPO depends on backup frequency. Cold standby is appropriate for non-critical functions where extended disruption is tolerable. However, under NIS2 and DORA, any function classified as critical or important should have a recovery strategy more capable than cold standby — regulators will question whether a multi-day recovery timeline constitutes adequate business continuity for essential services.
Beyond IT recovery, your strategy must address operational continuity: how do personnel perform their functions if primary work locations are unavailable (remote work capability, alternative site arrangements), how do manual workarounds substitute for automated processes during IT restoration, how are customers and partners informed and serviced during the disruption, and how are regulatory obligations (reporting, notification, ongoing supervision) maintained. A BCP that restores IT systems but does not address the human, process, and communication dimensions of continuity is incomplete.
6. Testing and Exercising
An untested BCP is a hypothesis, not a plan. Testing and exercising are the mechanisms that convert documented plans into validated capabilities. EU regulations recognise this explicitly: DORA Article 11(6) requires financial entities to test their ICT business continuity plans and ICT response and recovery plans at least annually, and after substantive changes to ICT systems. NIS2 Article 21(2)(c), through its requirement for crisis management measures, implies testing as an inherent component of crisis preparedness. ISO 27001 Annex A 5.30 requires ICT readiness for business continuity to be planned, implemented, maintained, and tested.
Testing exists on a spectrum of complexity and realism. At the simplest level, desktop walkthroughs involve gathering the crisis management team around a table, presenting a scenario, and walking through the plan step by step. Walkthroughs are low-cost, low-risk, and effective at identifying obvious gaps in plans — missing contact information, unclear escalation paths, undefined decision authorities, or assumptions about resource availability that do not hold. Every organisation should conduct tabletop exercises at least quarterly, focusing on different scenarios each time.
Functional tests validate that specific technical capabilities work as documented. Can you restore a database from backup within the documented RTO? Does the failover mechanism to the secondary data centre actually transfer traffic without data loss? Do notification systems reach all required stakeholders within the required timelines? Functional tests are more resource-intensive than walkthroughs but provide empirical evidence of capability rather than theoretical confidence. Conduct functional tests of critical recovery components at least semi-annually.
Full-scale simulation exercises replicate a disruption scenario as realistically as possible, activating the complete crisis management structure, executing recovery procedures, and measuring actual recovery times against documented objectives. These exercises are expensive and disruptive — they may require scheduled downtime for production systems — but they are the only way to validate end-to-end recovery capability under realistic conditions. DORA Article 11(6) envisions this level of testing for critical or important functions. Conduct full-scale exercises at least annually, and ensure they include scenarios that test not just IT recovery but crisis communication, regulatory notification, customer management, and coordination with third-party providers.
Document every test: the scenario, the participants, the timeline of actions taken, the results (including what worked, what failed, and what was slower than expected), and the improvement actions identified. This documentation serves multiple purposes: it provides evidence for regulatory examination, it creates a historical record for measuring improvement over time, and it feeds directly into plan maintenance — every test should result in at least some plan updates. Track the closure of improvement actions from tests with the same rigour you apply to audit findings.
DORA Article 26 requires significant financial entities to conduct threat-led penetration testing (TLPT) at least every three years. While TLPT is distinct from BCP testing, the scenarios and findings should feed into your business continuity planning — if TLPT reveals that an attacker could compromise a critical system faster than your detection and response time, your BCP assumptions need updating.
7. Plan Maintenance and Governance
BCP maintenance is the discipline that separates resilient organisations from those that discover their plans are outdated during an actual crisis. Plans degrade naturally as the organisation changes — new systems are deployed, existing systems are decommissioned, personnel rotate, vendor relationships change, and office locations are opened or closed. Without deliberate maintenance, the BCP diverges from reality until it becomes fiction.
Establish a maintenance cadence that balances currency with effort. At a minimum: review and update plans after every test or exercise (incorporating lessons learned and correcting inaccuracies discovered during testing), after every significant change to the IT environment (new system deployments, cloud migrations, vendor changes), after every organisational change (restructuring, office moves, key personnel departures), and on a fixed annual cycle (even if no specific triggers have occurred). For DORA-obligated entities, Article 11(6) mandates annual testing and implicit annual plan review — build your maintenance cycle around this regulatory cadence.
Governance structures ensure that BCP is not a one-person effort that collapses when that person leaves the organisation. Establish clear ownership: a senior executive sponsor (typically the COO or CRO) who is accountable for business continuity at the board level, a BCP programme manager who coordinates the planning, testing, and maintenance activities, and function-level BCP owners who maintain the plans for their specific business areas. This distributed ownership model ensures that plans are maintained by the people who understand the functions they protect, while the programme manager ensures consistency, completeness, and adherence to standards.
Integrate BCP governance into your broader risk governance structure. Business continuity status should be a standing item in risk committee meetings. BCP test results should feed into the risk register — if a test reveals that a recovery time exceeds the documented RTO, that is a risk event that should be captured and treated. Board reporting should include BCP readiness status alongside other risk metrics. And supervisory examination preparation should treat BCP documentation as a high-priority item — regulators under both NIS2 and DORA will examine business continuity capabilities, and the quality of your documentation directly affects their assessment.
Finally, learn from real incidents — both your own and others'. Every actual disruption, whether it triggered full BCP activation or was resolved before that threshold, contains lessons about the accuracy of your plans, the effectiveness of your recovery capabilities, and the resilience of your people and processes under pressure. Conduct a structured post-incident review after every significant disruption, compare actual outcomes against plan assumptions, and update the BCP based on what you learn. Equally, monitor significant disruptions at other organisations in your sector — if a peer suffers a major outage due to a scenario your BCP does not cover, that is a signal to evaluate your own preparedness for that scenario.
What is the difference between BCP and disaster recovery (DR)?
Disaster recovery is a subset of business continuity planning focused specifically on restoring IT systems and data after a disruption. BCP is broader: it addresses the continuity of business functions — including people, processes, communication, and facilities — not just IT systems. A DR plan might successfully restore your database within four hours, but if your BCP does not address how customer-facing staff operate during those four hours, the business impact is not mitigated. Under DORA, both dimensions are mandatory: Article 11 covers ICT business continuity (DR), while Article 11(3) requires consideration of severe business disruptions more broadly.
How do DORA and NIS2 BCP requirements differ?
DORA (Article 11-13) is highly prescriptive: it mandates specific plan components (ICT continuity policy, response plans, recovery plans, backup policies), testing requirements (annual minimum, with specific scenarios), and backup segregation (Article 12(2)). NIS2 (Article 21(2)(c)) takes a principles-based approach: organisations must implement business continuity and crisis management measures that are appropriate and proportionate, but the specific implementation is left to the entity. For organisations subject to both, implement DORA's detailed requirements and verify that your implementation also satisfies NIS2 — DORA compliance will generally exceed NIS2 BCP requirements.
How should we handle BCP for cloud-hosted critical functions?
Cloud hosting shifts some recovery responsibilities to the cloud provider but does not eliminate the organisation's BCP obligations. Your BCP must address: the provider's availability commitments (SLA terms and historical performance), your recovery options if the provider suffers an outage (multi-region deployment, multi-cloud strategy, or offline capability), data backup and restoration independent of the provider (DORA Article 12 requirements apply to cloud-hosted data), and exit strategy provisions (DORA Article 28 requires contractual exit provisions for critical ICT services). Test cloud-specific scenarios — do not assume that 99.99% SLA uptime eliminates the need for business continuity planning.
What scenarios should our BCP testing cover?
At minimum: ransomware attack on production systems (the most likely high-impact scenario for most EU organisations), loss of a critical third-party ICT service provider, failure of the primary data centre or cloud region, extended loss of key personnel (pandemic scenario), simultaneous cyber incident and regulatory examination, and insider threat resulting in data destruction. DORA's RTS on ICT risk management specifies additional scenario requirements for financial entities. Rotate scenarios across test cycles so that each major scenario is tested at least every two years, and include at least one scenario that was not pre-planned — testing the team's ability to respond to an unfamiliar situation is as valuable as validating documented plans.
How do we set appropriate RTOs and RPOs?
RTOs and RPOs must be driven by business impact, not IT capability. Start with the BIA: for each critical function, determine the maximum tolerable downtime (MTO) — the point at which the disruption becomes existential for the function. The RTO must be shorter than the MTO to provide a safety margin. RPO depends on the data sensitivity and the cost of recreating lost data — a trading system may need near-zero RPO while a reporting system may tolerate 24 hours of data loss. Validate that your recovery infrastructure can actually deliver the stated RTOs and RPOs through testing. An RTO that your infrastructure cannot achieve is not an objective — it is an aspiration that creates false assurance.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.