DORA Business Continuity and Disaster Recovery: Articles 11–12 Roadmap for 2026

Last reviewed: 27 April 2026

What DORA requires for BCDR in 2026 (short answer)

The EU Digital Operational Resilience Act (Regulation (EU) 2022/2554, known as DORA) has applied since 17 January 2025. The deadline question is closed. For business continuity and disaster recovery (BCDR), three things now have to hold up under supervisory review and partner-bank scrutiny:

A documented ICT business continuity policy with response and recovery procedures (Article 11), tested under severe-but-plausible scenarios.
Backup policies, restoration and recovery procedures and methods that are tested and segregated, supported by redundant ICT capacities and a sufficiently geographically distant secondary site for non-microenterprises (Article 12).
Tested resilience capability: digital operational resilience testing under Article 25, plus threat-led penetration testing (TLPT) at least every three years for financial entities identified by the competent authorities under Article 26 — not for every entity that thinks of itself as "critical".

In 2026 the work is no longer about reaching a date. Supervisors and partner banks now ask for operating evidence: tested restoration logs, version-controlled BCP with management-body sign-off, after-action reports, third-party register entries, and incident-reporting timeline records.

DORA BCDR requirements at a glance

DORA requirement	What it means for BCDR	Evidence / artifact to maintain
Article 11 — ICT business continuity policy	Documented policy, integrated with overall business continuity, covering critical or important functions	Approved BCP, version history, management-body sign-off
Article 11 — Response and recovery procedures	Containment, escalation, crisis communication, restoration playbooks	Playbooks, RACI matrix, communication templates, after-action reports
Article 11 — Testing of plans	Plans tested at least yearly and after any material change	Test plan, scenario library, gap-tracking register
Article 6(6) — Periodic audit of the ICT risk management framework (BCDR included)	At least once a year for non-microenterprises, by independent auditors with sufficient knowledge	Internal audit report covering ICT BCP scope; remediation evidence
Article 12 — Backup policies and procedures	Scope, frequency, retention, logical and physical segregation	Backup policy, retention schedule, segregation and integrity evidence
Article 12 — Restoration and recovery procedures and methods	Tested restoration meeting RTO and RPO; integrity verification	Restoration test reports, RTO/RPO measurements, witness logs
Article 12 — Redundant ICT capacities and secondary site (non-microenterprises)	Sufficiently geographically distant secondary processing site for critical or important functions	Architecture diagram, failover test results, site-distance documentation
Article 25 — Testing of digital operational resilience	Annual programme of vulnerability assessments, scenario-based testing, performance testing, end-to-end testing	Test programme document, results register, remediation tracker
Article 26 — Threat-led penetration testing	TLPT at least every three years for entities identified by competent authorities	TLPT scope statement, red-team report, remediation plan
Articles 17–19 — Incident management, classification and reporting	Major ICT-related incidents follow the Joint Technical Standards on major incident reporting	Initial notification within 4 h of classification (≤24 h from detection); intermediate within 72 h; final within 1 month

DORA's five pillars and where BCDR sits

DORA establishes a unified EU framework for digital operational resilience across the financial sector and brings critical ICT third-party providers into supervisory scope through the Lead Overseer regime. It is structured around five pillars:

ICT risk management — the framework that owns BCDR objectives.
ICT-related incident management, classification and reporting — the trigger for BCDR activation.
Digital operational resilience testing — proves BCDR capability under stress.
Management of ICT third-party risk — extends BCDR coverage to outsourced services.
Information sharing — voluntary intelligence sharing on cyber threats.

BCDR sits at the intersection of pillars 1 and 3 and depends on pillars 2 and 4 to be effective in practice.

What DORA Article 11 requires (Response and recovery)

Article 11 — Response and recovery — requires financial entities to put in place an ICT business continuity policy as an integral part of their overall operational business continuity policy. The policy and supporting plans must:

Cover continuity of all critical or important functions (DORA's defined term — replacing earlier wording such as "essential functions" in some pre-DORA frameworks).
Set out procedures to contain damage, escalate, manage crises, communicate with stakeholders, and restore ICT systems and operations.
Be tested at least once a year, after any material change to ICT systems supporting critical or important functions, and following significant ICT-related incidents.
Drive lessons-learned cycles that feed back into the ICT risk management framework under Article 5 and Article 6.

Implementation focus in 2026: most financial entities have a BCP. What supervisors check now is whether the policy has actually been operated and tested — version-controlled, with management-body sign-off, and evidenced through after-action reports tied to specific test runs and real incidents.

What DORA Article 12 requires (Backup, restoration and recovery)

Article 12 — Backup policies and procedures, restoration and recovery procedures and methods — requires financial entities to put in place:

A backup policy specifying the scope of data subject to backup, the minimum frequency, and retention, taking into account the criticality of the information and the confidentiality of the data.
Restoration and recovery procedures and methods, including periodic testing of those procedures.
Where applicable, redundant ICT capacities with appropriate resources, capabilities and functions to ensure business needs are met.
A secondary processing site sufficiently geographically distant from the primary site to bear a similar risk profile, with the resources, capabilities, functions and staffing arrangements to ensure continuation of business.

The supervisory question in 2026 is no longer "do you have backups?" — it is "show us the last successful restoration test, the RTO measured, who witnessed it, and what was changed afterwards."

Integrating BCDR with the ICT risk management framework

DORA Article 5 puts management-body accountability at the centre of operational resilience. Effective BCDR therefore has to be:

Owned by the management body, with explicit responsibilities and reporting lines.
Embedded in the ICT risk management framework under Article 6, supported by the EBA RTS on the ICT risk management framework.
Mapped to critical or important functions and the underlying ICT assets, applications and third-party dependencies.
Anchored in defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) that are realistic, tested, and demonstrably met under severe-but-plausible scenarios.

The integration check that supervisors and external auditors now run: for any critical or important function, can you trace the chain — business impact analysis → ICT asset inventory → continuity arrangement → restoration test result → board reporting?

Eight steps to a defensible DORA BCDR posture in 2026

Step 1: Gap analysis against operating evidence, not policy text

Don't audit your policies — audit your operations. Compare actual procedures, evidence and test results against DORA Articles 11, 12, 25 and 26, plus the EBA Regulatory Technical Standards on the ICT risk management framework. The frequent surprise: the policy is fine, the evidence is not.

Step 2: Strengthen the ICT risk management framework

Confirm board-level ownership, current ICT-asset inventory, and continuous control monitoring. The EBA guidelines on ICT and security risk management remain a useful baseline that DORA builds on.

Step 3: Refresh the BIA and map critical or important functions

Re-run the Business Impact Analysis using DORA's defined term critical or important functions. Map each one to ICT assets, applications and third-party dependencies. Set RTOs and RPOs that you can actually meet — and prove with test data.

Step 4: Operate response and recovery plans

Develop or refine ICT response and recovery plans covering incident resolution, containment, damage limitation, crisis management, stakeholder communication, and step-by-step restoration of services and operations. Align with the DORA-compliant ICT risk register.

Step 5: Run the resilience testing programme

Annual testing of BCP and ICT response and recovery plans using severe-but-plausible scenarios (Article 25).
TLPT at least every three years for financial entities identified by the competent authorities under Article 26 — TLPT is not a universal obligation.
Capture scope, methodology, findings, lessons learned, witness logs and remediation in a structured test register.

Step 6: ICT third-party risk management

Validate provider resilience capabilities, embed Article 30 contractual provisions, and assess concentration risk. Maintain a complete DORA Register of Information per the implementing technical standard.

Step 7: Standardise incident management and reporting

Classification follows the Joint Committee Regulatory Technical Standards on classification and reporting. For major ICT-related incidents, the reporting cadence is:

Initial notification — within 4 hours after the incident is classified as major, and no later than 24 hours from when the entity becomes aware of or detects the incident.
Intermediate report — within 72 hours of the initial notification, with status updates as conditions change.
Final report — within one month of the initial notification, including root cause and remediation.

Significant cyber threats can be reported on a voluntary basis. There is no mandatory cyber-threat notification regime under DORA.

Step 8: Document and continuously review

Maintain a complete evidence pack: BCP versions, BIA outputs, restoration test reports, TLPT remediation records, incident register, third-party register, audit findings. Review at least annually and after every material change or incident. See common DORA compliance mistakes to avoid in evidence cleanup.

Common pitfalls in 2026

Policy without operations. Approved BCP, no recent test evidence, no after-action reports.
BIA detached from architecture. Critical or important functions listed but not mapped to ICT assets and third parties.
TLPT misapplication. Treating TLPT as universal — it isn't. TLPT applies to financial entities identified by the competent authorities under Article 26 at least every three years.
Wrong incident terminology. Confusing "essential functions" with critical or important functions, or treating significant cyber threats as mandatory notifications.
Incident-reporting timeline confusion. Mixing 4 h, 24 h, 72 h and 1-month thresholds; missing the "after classification as major" qualifier on the 4 h trigger.
Backups untested. Backup policy exists; the last documented restoration test is older than 12 months.
Third-party gaps. Critical-or-important-function dependency on a provider whose resilience evidence is opaque or unverified.

FAQ

How does DORA BCDR differ from traditional BCDR?

DORA mandates that BCDR is integrated with the ICT risk management framework, evidenced through testing under severe-but-plausible scenarios, and extended to ICT third-party providers via Article 30 contractual provisions. The bar in 2026 is operating evidence, not policy text alone.

What are the obligations for microenterprises?

Microenterprises operate a proportionate regime. They are exempt from some specific requirements, including certain redundant-capacity requirements under Article 12 and parts of the Article 6 audit obligation. They must still implement BCDR proportionate to their size, nature, scale and complexity.

What is the frequency and type of testing required?

Article 25 requires a comprehensive testing programme covering vulnerability assessments, scenario-based testing, performance testing and end-to-end testing of ICT systems supporting critical or important functions. BCP and ICT response and recovery plans must be tested at least once a year and after any material change.

What are the requirements for TLPT under Article 26?

Threat-led penetration testing applies at least every three years to financial entities identified by the competent authorities based on criteria set out in the related Joint RTS. It is not a universal requirement. The exercise uses a threat-led methodology with red-team testing on production systems supporting critical or important functions, conducted by qualified testers.

How should cloud and other ICT third-party contracts be handled under DORA?

Article 30 sets out mandatory contractual provisions for arrangements with ICT third-party service providers, with stricter requirements where the function is critical or important: service-level descriptions, data processing locations, access and audit rights, security requirements, exit strategies, and assistance during ICT-related incidents.

Can existing ISO 27001 certifications help with DORA compliance?

ISO 27001 provides a solid foundation for the ICT risk management framework, but does not equate to DORA compliance. DORA-specific elements — incident classification and reporting under the Joint RTS, TLPT where applicable, the ICT third-party register, Article 30 contractual provisions — must be mapped on top.

Related reading