DORA's Hidden Pillar: Why Business Continuity (Art. 11-12) Is the Foundation
The Foundation Nobody Talks About
DORA discourse concentrates on its more novel provisions: the CTPP oversight regime, TLPT requirements, the Register of Information, information sharing arrangements. These are genuine innovations that distinguish DORA from its regulatory predecessors. But they are innovations built on a foundation, and that foundation is Articles 11 and 12 — the regulation's business continuity and backup requirements.
Art. 11 establishes the requirement for ICT business continuity policies and plans. Art. 12 establishes the requirement for backup policies and recovery methods. Together, they define the institution's fundamental capability to continue operating when things go wrong — and everything else DORA requires is predicated on this capability existing.
The ECB's 2024 stress test of the European banking sector's operational resilience made this point empirically: recovery capabilities were flagged as the single largest gap across the tested institutions. Banks could articulate their risk frameworks, identify their critical functions, and document their testing programmes. But when the stress test scenario required them to demonstrate actual recovery — within their stated RTO targets, using their documented procedures, with their declared backup systems — the results were sobering.
The Iberian blackout in 2025 provided real-world confirmation. When the electrical grid across Spain and Portugal failed, financial services recovery timelines ranged from 3 hours to 24 hours depending on the institution and the service. The institutions that recovered in 3 hours had tested their business continuity plans against exactly this scenario. The institutions that took 24 hours had plans that existed on paper but had not been validated against a grid-level failure.
Article 11: ICT Business Continuity Policy
Art. 11 requires financial entities to establish a "comprehensive ICT business continuity policy" that addresses at least:
Critical Function Identification
Art. 11(1) requires identification of "all ICT supported business functions, roles and responsibilities, the ICT assets and ICT services that support them, including their interdependencies." This is not a technology inventory — it is a mapping of business functions to their ICT dependencies, with the interdependencies between those dependencies explicitly documented.
The interdependency mapping is where most institutions fall short. An institution may know that its payment processing system depends on a specific database. But does it know that the database depends on a specific DNS configuration, which depends on a specific network route, which transits a specific telecommunications provider's infrastructure? The Iberian blackout demonstrated that failure at the infrastructure layer cascades through every layer above it.
Response and Recovery Plans
Art. 11(3) requires "ICT response and recovery plans" that specify:
- Conditions for activation
- Procedures to be followed
- Recovery priorities (which functions are restored first)
- Recovery time objectives
- Communication protocols (internal and external)
| BCP component | DORA requirement (Art. 11) | Common gap |
|---|---|---|
| Activation triggers | Defined conditions for plan activation | Ambiguous triggers that delay activation by hours |
| Recovery sequencing | Prioritized recovery order for critical functions | All functions treated as equal priority |
| RTO/RPO targets | Defined per critical function | Targets set without validation; aspirational rather than achievable |
| Communication plan | Internal escalation + external notification | Ad hoc communication; no pre-defined templates or channels |
| Resource requirements | People, systems, facilities needed for recovery | Assumption that resources are available during a crisis |
| Dependencies | Explicit documentation of recovery dependencies | Recovery plan assumes dependencies are available |
Testing Requirements
Art. 11(6) mandates that ICT business continuity plans shall be "tested at least yearly and after substantive changes to the ICT systems." The testing must validate that the plans achieve their stated objectives — not merely that the documentation exists.
The "substantive changes" trigger is critical. Cloud migration, core banking upgrades, network architecture changes, and new third-party service integrations all constitute substantive changes that should trigger BCP retesting. An institution that migrated its payment processing to a new cloud provider six months ago but has not retested its BCP for payment processing has a compliance gap under Art. 11(6).
Article 12: Backup Policies and Recovery Methods
Art. 12 is more operationally specific than Art. 11, addressing the technical capabilities that make recovery possible:
Backup Scope and Frequency
Art. 12(1) requires that backup policies specify "the scope of the data that is subject to backup and the minimum frequency of the backup, based on the criticality of information." This requires a criticality-based backup strategy:
| Data criticality | Backup frequency (minimum) | Retention period | Recovery testing |
|---|---|---|---|
| Critical (e.g., transaction data, customer balances) | Real-time or near-real-time replication | Per regulatory retention + org policy | Quarterly |
| High (e.g., configuration data, audit logs) | Daily | Per retention policy | Semi-annual |
| Medium (e.g., reporting data, analytics) | Weekly | Per retention policy | Annual |
| Low (e.g., development data, temporary files) | Monthly or as-needed | Limited | As-needed |
Recovery Method Validation
Art. 12(2) requires that "the restoration of backup data using a separate ICT processing environment" is tested. This provision specifically requires that recovery is validated in an environment separate from the production system — because a backup that can only be restored on the production system that is currently unavailable is not a useful backup.
The separate environment requirement has significant infrastructure implications. Institutions must maintain or have access to a recovery environment that is sufficiently independent from their production infrastructure that it remains available during the failure scenarios they are recovering from. For cloud-hosted services, this may mean a recovery environment on a different cloud provider or in an on-premises data center.
Segregation of Backup Systems
Art. 12(3) requires "adequate separation between the ICT production environment and the backup environment" to prevent a single event from compromising both. This provision was prescient: ransomware attacks that target both production systems and their backups simultaneously are an established attack pattern. An institution whose backups reside on the same network segment, the same storage platform, or the same cloud account as its production systems may find both compromised in a single incident.
The Maturity Model: Where Your Institution Stands
Business continuity maturity can be assessed across five capability dimensions, from reactive (Level 1) to optimized (Level 5):
| Capability dimension | Level 1: Reactive | Level 3: Defined | Level 5: Optimized |
|---|---|---|---|
| Planning | Ad hoc response, no documented plans | Formal BCPs for critical functions | Dynamic plans updated in real-time based on changes |
| Testing | No testing or untested plans | Annual testing per Art. 11(6) | Continuous testing with chaos engineering |
| Backup | Basic backups, untested restoration | Criticality-based backup with tested recovery | Immutable backups, automated failover, sub-minute RPO |
| Dependencies | Unknown interdependencies | Documented primary dependencies | Full dependency graph with automated impact analysis |
| Integration | BCP isolated from operations | BCP integrated with incident management | BCP integrated with risk management, testing, and audit |
Most European financial institutions, based on the ECB stress test findings, operate between Level 2 and Level 3 — they have formal plans but testing is insufficient, backup recovery is not regularly validated, and dependency mapping is incomplete. DORA's Art. 11-12 requirements align with Level 3-4 capabilities.
The Iberian Blackout Lessons
The Iberian blackout — a cascading electrical grid failure across Spain and Portugal — provided the most significant real-world test of financial sector business continuity in recent European history. The lessons are directly applicable to DORA Art. 11-12 compliance:
Lesson 1: Infrastructure dependencies are invisible until they fail. Financial institutions with robust ICT business continuity plans discovered that those plans assumed continuous electrical power supply. When the power failed, backup generators activated — but generator fuel reserves, cooling system dependencies, and telecommunications infrastructure that relied on the same electrical grid all became failure points that the BCPs had not addressed.
Lesson 2: Recovery time varies enormously across services. Within the same institution, some services recovered within 3 hours while others took 24 hours. The difference was not random — it correlated with the maturity of business continuity planning for each specific service. Services with tested recovery procedures, validated backup systems, and documented dependencies recovered faster.
Lesson 3: Communication is as critical as recovery. Institutions that communicated proactively with customers — via SMS, app notifications, and social media — maintained trust even while services were degraded. Those that went silent faced customer backlash that amplified the operational impact.
Lesson 4: Testing against realistic scenarios matters. Institutions that had tested business continuity against infrastructure-level failure scenarios (not just application-level failures) performed materially better. A BCP that has only been tested against "database failure" or "application crash" is not prepared for "everything that depends on electrical power stops simultaneously."
Building a DORA-Compliant BCP Programme
Step 1: Map Critical Functions to ICT Dependencies
Start with Art. 3(22) critical functions and map each to its complete ICT dependency chain. Include: applications, databases, network components, cloud services, third-party integrations, infrastructure dependencies (power, cooling, telecommunications), and human dependencies (key personnel, specialist skills).
Step 2: Set Validated RTO/RPO Targets
RTO and RPO targets must be achievable, not aspirational. If your BIA sets a 4-hour RTO for payment processing, you must demonstrate through testing that payment processing can be restored within 4 hours. The ECB stress test found that many institutions set ambitious RTO targets without validating them — and discovered during the stress test that actual recovery times significantly exceeded their targets.
Step 3: Design Backup Architecture for Resilience
Apply Art. 12's requirements: criticality-based backup frequency, separate recovery environment, segregation from production, and tested restoration procedures. For cloud-hosted services, consider cross-provider backup to address the scenario where the primary cloud provider is unavailable.
Step 4: Test Against Realistic Scenarios
Art. 11(6) requires at least annual testing. Go beyond the minimum:
- Tabletop exercises: Walk through the BCP with key stakeholders, identifying assumptions and gaps
- Functional testing: Validate that backup restoration works in the separate recovery environment
- Full-scale simulation: Simulate a major disruption scenario (cloud provider outage, ransomware attack, infrastructure failure) and measure actual recovery times against RTO targets
- Chaos engineering: Deliberately introduce failures into the production environment (in controlled conditions) to test automated recovery mechanisms
Step 5: Integrate with the ICT Risk Framework
Art. 11 does not exist in isolation. Business continuity testing results should feed into the ICT risk management framework (Art. 6), inform the testing programme (Art. 24-25), and produce evidence for the audit trail (Art. 17). A BCP programme that operates independently of the broader DORA framework misses the integration that makes both more effective.
The Hidden Pillar Is the Real Pillar
DORA's testing requirements matter because they validate that resilience is real. Its third-party risk management requirements matter because they address the concentration risks that individual institutions cannot manage alone. Its incident management requirements matter because they ensure that disruptions are detected, classified, and reported.
But all of these capabilities are predicated on a more fundamental question: when something goes wrong, can the institution continue to operate? Art. 11-12 answer that question. They are not the most innovative provisions in DORA. They are not the most discussed. But they are the provisions that determine whether everything else works when it is needed most.
This analysis reflects DORA Regulation (EU) 2022/2554 Articles 11-12, ECB operational resilience stress test findings (2024), and lessons from the Iberian blackout (2025).