DORA ICT Business Continuity and Disaster Recovery: Operationalising Articles 11 and 12 | FortisEU

Most financial entities have a disaster recovery plan. It exists in a document management system, it was approved by senior management, and it references recovery time objectives that someone defined during a workshop. The question DORA asks is not whether the plan exists. The question is whether it works — whether the entity can actually recover its critical ICT services within the timeframes it committed to, under conditions that include simultaneous failure of primary and backup systems, unavailability of key personnel, and loss of the ICT environment that supports the recovery process itself.

Articles 11 and 12 of Regulation 2022/2554 establish the ICT business continuity and disaster recovery requirements for financial entities. These articles sit within the broader ICT risk management framework under Articles 5-16, and they are among the most operationally testable requirements in the regulation. A supervisor can assess your risk management framework by reviewing documentation and governance records. Business continuity and disaster recovery are assessed by examining test results — measured recovery times, scenario coverage, and evidence that tests have exposed weaknesses that were subsequently addressed.

This guide covers what Articles 11-12 require at an operational level, how the ESA Regulatory Technical Standards elaborate these requirements, and how to build a testing programme that satisfies supervisory expectations.

Article 11: ICT Business Continuity Policy and Plans

Article 11 requires financial entities to put in place a comprehensive ICT business continuity policy as an integral part of their operational business continuity policy. The ICT business continuity policy must be implemented through dedicated, appropriate, and documented arrangements, plans, procedures, and mechanisms.

The distinction between an ICT business continuity policy and a general business continuity policy is deliberate. DORA recognises that ICT disruption is a specific and increasingly dominant category of business disruption for financial entities. The ICT-specific policy must address the characteristics of ICT failures — which are often fast-moving, technically complex, and capable of cascading across interconnected systems in ways that physical disruptions typically do not.

Business Impact Analysis

The foundation of Art. 11 compliance is the business impact analysis (BIA). The BIA must identify and assess the potential impact of severe business disruptions on the entity's critical or important functions — as defined under Art. 3(22) of DORA. The analysis must consider:

Service dependencies. Which ICT services support which business functions? The mapping must be granular enough to identify single points of failure — an ICT service that, if disrupted, would simultaneously affect multiple critical functions. This dependency mapping should draw from the identification work required under Article 8 of the ICT risk management framework.

Maximum tolerable downtime. For each critical or important function, the entity must determine the maximum period of disruption it can tolerate before the impact becomes unacceptable. "Unacceptable" is defined in terms of financial impact, regulatory breach, client harm, and reputational damage. This determination drives the recovery time objective (RTO) — the target time within which the function must be restored.

Data loss tolerance. For each critical function, the entity must determine the maximum acceptable data loss in the event of disruption. This drives the recovery point objective (RPO) — the maximum age of data that must be recoverable from backups or replicated systems.

Cascading impact. The BIA must consider how disruption of one function affects others. Financial services are highly interconnected — a payment processing disruption may cascade into settlement failures, which cascade into liquidity impacts, which cascade into regulatory reporting failures. The BIA must map these cascading dependencies to ensure that recovery sequencing addresses the most impactful cascades first.

The RTS specifies that the BIA must be reviewed at least annually and updated whenever significant changes occur to the entity's ICT systems, business processes, or organisational structure. A BIA conducted during initial DORA compliance that has not been updated since is already non-compliant if the entity has undergone material changes.

ICT Response and Recovery Plans

Based on the BIA, Article 11 requires entities to establish ICT response and recovery plans. The RTS details the minimum content and operational requirements for these plans.

ICT response plans must include:

Conditions for activation — the criteria that trigger the transition from normal incident response to business continuity response
Roles and responsibilities — who activates the plan, who leads the recovery effort, who communicates with stakeholders, and who has decision-making authority when normal management structures are disrupted
Immediate actions to contain the disruption and prevent further degradation
Communication procedures — both internal (to staff and management) and external (to clients, counterparts, regulators, and the public)
Escalation procedures for scenarios that exceed the initial response capability

ICT recovery plans must include:

Recovery procedures for each critical or important function, in priority order based on the BIA
RTOs and RPOs for each critical function, approved by the management body
Recovery scenarios covering the plausible disruption types identified in the entity's risk assessment — ranging from localised system failure to complete data centre loss
Resource requirements — the personnel, infrastructure, and third-party support needed for each recovery scenario
Alternative processing arrangements — how critical functions will be maintained during the recovery period if the primary system cannot be restored immediately
Procedures for validating recovered systems — confirming data integrity, functional correctness, and security posture before returning recovered systems to production

The plans must address a specific DORA requirement that distinguishes these from traditional DR plans: the plans must consider scenarios where ICT third-party service providers fail to deliver their services. Given the concentration of critical ICT services among a small number of providers, the scenario where a critical third-party provider experiences an outage is not hypothetical — it is a recurrent reality. The recovery plan must address how the entity maintains critical functions when the third-party provider is unavailable, including the possibility that the unavailability persists beyond the provider's own recovery commitments.

Article 12: Backup Policies and Recovery Methods

Article 12 establishes specific requirements for backup policies and procedures, data restoration, and recovery methods.

Backup Requirements

The backup policy must ensure that backup and restoration procedures:

Specify the scope of data subject to backup and the minimum frequency of backup. The scope must cover all data necessary to restore the critical or important functions identified in the BIA. The frequency must be aligned with the RPOs established for each function — if a function's RPO is four hours, the backup frequency must ensure that no more than four hours of data can be lost.

Consider the confidentiality and integrity of data. Backup data must be protected to the same standard as production data. Encryption of backups, secure storage, and access controls are baseline requirements. If production data is subject to specific confidentiality requirements — contractual, regulatory, or classification-based — those requirements apply equally to backup copies.

Include offline or remote backup capabilities. The RTS requires entities to maintain at least one backup site that is physically and logically separated from the primary site. This backup site must have a security profile that is at least equivalent to the primary site. The separation requirement is specifically designed to protect against scenarios where the primary site and its directly connected backup systems are simultaneously compromised — ransomware that encrypts both production and network-attached backup storage is the canonical example.

Enable timely restoration. The ability to restore data is not the same as the ability to recover a functioning service. The backup policy must address not just data restoration but the restoration of the complete environment needed to deliver the critical function — operating systems, applications, configurations, network connectivity, and security controls. A backup that restores data but not the application that processes it has limited value under time pressure.

Restoration Testing

Article 12 requires entities to periodically test backup and restoration procedures. The RTS specifies that this testing must verify:

The integrity of backup data — can it be read and restored without corruption?
The completeness of backup scope — does the backup contain all data needed to restore the function?
The ability to restore within the defined RTO — not the data restoration time, but the time to recover a functioning service capable of supporting the critical function
The usability of restored systems — are they functionally correct and ready for production use?

Restoration testing that verifies backup integrity (the file restored successfully) but does not verify service recovery (the function is operational) does not satisfy the DORA requirement. The test must demonstrate end-to-end recovery — from bare infrastructure to a functioning service delivering the critical business function.

The Testing Obligation

Testing is where DORA's business continuity requirements have the most operational impact and where the gap between documentation and capability becomes measurable.

What Must Be Tested

Article 11(6) requires entities to test their ICT business continuity plans at least annually. The RTS elaborates the testing requirements:

Scenario coverage. Tests must cover a range of scenarios that are plausible based on the entity's risk assessment. These include: localised system failure, data centre loss, third-party provider outage, cyber attack (including ransomware), data corruption, and simultaneous failure of primary and secondary systems. Testing the same benign scenario each year does not satisfy the requirement.

Functional coverage. All critical or important functions must be included in the testing programme over a reasonable cycle. Testing a single function each year while leaving others untested for multiple years is not adequate.

End-to-end recovery. Tests must demonstrate the ability to recover from the point of disruption to the resumption of the critical function at a level that satisfies the entity's continuity requirements. Partial tests — restoring a database but not validating that the application functions correctly, or recovering a system but not testing client connectivity — are insufficient.

Communication testing. The crisis communication procedures must be tested alongside the technical recovery procedures. This includes internal escalation, management body notification, client communication, and regulatory notification. If the incident reporting pipeline depends on systems that are themselves affected by the disruption scenario, the communication test must address that dependency.

Types of Tests

The testing programme should employ a range of test methods, escalating in complexity and realism:

Tabletop exercises. Walk-through scenarios that test decision-making, coordination, and communication without actually disrupting systems. Tabletop exercises are valuable for testing governance processes, escalation paths, and crisis communication, but they do not prove technical recovery capability.

Component recovery tests. Restore individual systems or services from backup to verify technical recovery procedures. These tests validate that the backup is restorable and the recovery documentation is accurate, but they do not test the interaction between recovered components.

Integrated recovery tests. Recover multiple interconnected systems simultaneously and verify that the integrated service functions correctly. These tests expose dependency issues — a system that recovers successfully in isolation but fails when its dependent services are also recovering.

Full-scale simulation. Simulate a complete disruption scenario and execute the full business continuity response — activation, communication, recovery, validation, and return to normal operations. These tests are the most operationally demanding but provide the highest-confidence evidence of recovery capability.

The RTS requires entities to use the results of testing to improve their plans, procedures, and capabilities. A test that identifies weaknesses but does not lead to remediation provides no value — and provides evidence to supervisors that the entity identifies problems without resolving them.

Testing Documentation

Every test must be documented with:

The scenario tested and the rationale for selecting it
The scope of functions and systems included
The participants and their roles
The timeline of actions taken, with timestamps
The outcome — including measured recovery times compared against RTOs
Deviations from the plan and how they were handled
Findings — weaknesses, bottlenecks, or failures identified
Remediation plan — what will be changed, by whom, and by when

This documentation is your primary evidence of Art. 11-12 compliance in supervisory interactions. Supervisors will review test records not just for pass/fail results but for evidence of realistic scenarios, adequate scope, honest identification of weaknesses, and demonstrable follow-through on remediation.

Crisis Communication Under DORA

Articles 11 and 14 together require entities to have crisis communication procedures that function under disruption conditions. This includes:

Internal communication. Staff must know what is happening, what their role is, and what they should do. During a major ICT disruption, the absence of clear internal communication creates confusion, duplicated effort, and inconsistent external messaging.

Client communication. Clients and financial counterparts affected by the disruption must be informed. The communication must be timely, factual, and actionable — telling clients what services are affected, what the expected resolution timeline is, and what alternative arrangements are available.

Regulatory communication. DORA incident reporting obligations under Art. 19 run in parallel with business continuity response. The entity must be able to file regulatory reports while simultaneously managing recovery. This means the reporting function and the recovery function must be staffed and coordinated independently — pulling the incident reporting lead into the technical recovery effort is a common failure mode.

Media and public communication. For incidents with public visibility, coordinated media communication prevents speculation from filling the information vacuum. Pre-approved holding statements for the most probable disruption scenarios reduce the time from incident to first public communication.

The crisis communication capability must be tested alongside technical recovery. If the communication plan assumes access to email systems that are themselves disrupted, or if the escalation chain depends on a contact list stored on a system that is unavailable, the plan has an untested dependency that will fail when it matters.

Third-Party Dependencies in Business Continuity

DORA's business continuity requirements explicitly address the scenario where ICT third-party service providers are the source of or contributors to the disruption. Article 11(3) requires entities to consider the impact of ICT third-party provider failures on their continuity plans.

This requirement connects directly to the TPRM and register of information obligations. For each critical or important ICT third-party relationship, the entity must:

Understand the provider's own business continuity and disaster recovery commitments (RTOs, RPOs, test frequency, geographic redundancy)
Assess whether the provider's commitments are sufficient to support the entity's own continuity requirements
Define what the entity will do if the provider fails to meet its commitments — alternative providers, manual workarounds, or degraded but functional service delivery
Include provider failure scenarios in the entity's own testing programme

The contractual arrangements under Art. 30 must address these continuity requirements — including provisions for exit strategies that maintain service continuity during transition from one provider to another.

The Maturity Gap: Where Entities Struggle

Based on the structure of DORA's requirements and the common patterns in implementation, the most consequential gaps in business continuity compliance cluster in predictable areas:

BIA currency. The BIA was conducted during initial compliance and has not been updated. The entity's ICT landscape has changed — new systems, new providers, new dependencies — but the BIA still reflects the original assessment.

RTO realism. Recovery time objectives were defined without empirical testing. The management body approved a 4-hour RTO for the payment processing function, but no test has ever achieved recovery in less than 12 hours. The RTO exists as an aspiration, not a validated capability.

Backup scope gaps. Data is backed up, but configuration, application state, and environmental dependencies are not. The entity can restore the database but cannot rebuild the application environment that makes the data usable.

Third-party blind spots. The entity's continuity plan assumes third-party services are available. When the provider experiences its own disruption, the entity has no alternative arrangement and no tested workaround.

Test realism. Annual tests use benign scenarios with advance notice, full staffing, and no time pressure. The test consistently "passes" because it does not approximate the conditions under which recovery will actually be required. A real disruption arrives without notice, during off-hours, affecting multiple systems simultaneously, with key personnel unavailable.

Communication dependency. The crisis communication plan depends on systems affected by the disruption. The escalation chain assumes access to corporate email, the internal messaging platform, or a contact database — all of which may be unavailable in the disruption scenario.

Addressing these gaps requires honest assessment. The purpose of business continuity testing under DORA is not to produce passing results. It is to identify weaknesses, prove capabilities, and demonstrate continuous improvement. A test that identifies a failure and leads to a documented remediation is more valuable — to the entity and to supervisors — than a test that passes because the scenario was not challenging enough to expose real weaknesses.

FortisEU's risk management and compliance automation platform supports the structured tracking of business continuity obligations, from BIA through recovery plan documentation, test scheduling, results capture, and remediation tracking — generating the audit trail that supervisory assessments demand.

Key Takeaways

Business continuity under DORA is a testable capability, not a document. Supervisors assess Articles 11-12 compliance by examining test results — measured recovery times, scenario realism, and evidence that findings drive improvements. Documentation without testing evidence is insufficient.
The BIA must be current, granular, and connected to the ICT risk framework. It must map critical functions to ICT dependencies, define RTOs and RPOs based on impact analysis, and be updated whenever the entity's ICT landscape changes materially.
Recovery testing must be end-to-end — from disruption to functioning service. Restoring backup data is not the same as recovering a functioning service. Tests must demonstrate that the critical function is operational, not just that files were restored.
Third-party provider failures must be included in testing scenarios. If your continuity plan assumes third-party services are available, it has an untested dependency. Include provider outage scenarios and test alternative arrangements.
Annual testing must use realistic and varied scenarios. Testing the same benign scenario with advance notice and full staffing each year does not demonstrate resilience. Scenarios must escalate in complexity and realism over time, covering data centre loss, cyber attack, simultaneous multi-system failure, and key personnel unavailability.
Crisis communication must be tested alongside technical recovery. If communication channels depend on systems affected by the disruption, the communication plan has a dependency that will fail under real conditions. Test communication independently and identify alternative channels.