DORA Article 11: Business Continuity and Disaster Recovery

DORA Article 11 requires every in-scope financial entity to maintain a documented ICT business continuity policy, backed by response and recovery plans with set recovery time and recovery point objectives, tested at least once a year. Article 12 adds the backup layer underneath it: documented backup frequency, segregated restoration systems, and periodic restoration testing. Neither article is new in 2026, but gaps in both remain among the most common findings auditors raise.

What Article 11 actually requires

Article 11 sits inside DORA's ICT risk-management chapter and can be a standalone document or part of a broader corporate business continuity policy, as long as it is clearly identifiable as the ICT-specific piece. It has to be built on the asset inventory and criticality mapping that Article 8 already requires, because a continuity plan that does not know which systems support which critical or important function cannot sequence a recovery correctly.

The policy is put into practice through documented arrangements, plans, procedures, and mechanisms with two linked goals: keep critical or important functions running through a disruption where possible, and restore them fast enough, where that is not possible, to limit damage to the entity, its clients, and the wider financial system. That second goal is why Article 11 reads differently from a generic corporate continuity plan. It is written around the specific DORA concept of a critical or important function, not around the business as a whole.

The business impact analysis behind the plan

Before an entity can write a credible continuity plan, Article 11 requires a business impact analysis (BIA) of its exposure to severe business disruptions. The BIA has to assess the criticality of mapped business functions, supporting processes, third-party dependencies, and information assets, along with the interdependencies between them. In practice this means the continuity plan cannot be drafted in isolation from the third-party risk register: a critical function that depends on an ICT third-party provider needs that dependency reflected in the BIA, not treated as someone else's problem to plan for.

The BIA result also drives proportionality. An entity does not have to build the same depth of continuity planning for every system it runs, only for those the BIA identifies as supporting a critical or important function, or whose failure would otherwise create unacceptable impact.

Recovery time and recovery point objectives

For each critical or important function, Article 11 requires defined recovery time objectives (RTO) and recovery point objectives (RPO). The RTO sets the maximum tolerable downtime before impact becomes unacceptable; the RPO sets the maximum tolerable data loss, measured as a point in time to which systems and data must be restorable. DORA does not prescribe fixed figures for either: they have to be set by the entity, proportionate to its own risk profile, and then validated against what its ICT environment can actually deliver.

This is where plans most often fail in practice. An RTO written on paper without a tested recovery path behind it is not a control; it is an assumption. Article 11's testing duty, covered below, exists precisely to close that gap.

Backup policies and restoration under Article 12

Article 12 is the companion provision that makes recovery objectives achievable. It requires a documented backup policy setting the scope of data to be backed up and the minimum backup frequency, calibrated to how critical or confidential that data is, together with restoration and recovery procedures and methods. A backup schedule that is the same for every system regardless of criticality does not meet this standard.

Where an entity restores data using its own systems, Article 12 requires those restoration systems to be physically and logically segregated from the source environment, so a single event, a ransomware attack that spreads laterally, for instance, cannot take out the backup along with the original. Restoration procedures have to be tested periodically, and DORA's working assumption is that an untested backup is functionally equivalent to no backup: the control being assessed is the ability to restore, not the existence of a backup file.

Testing cadence: what "at least yearly" covers

Article 11(6) sets the testing floor: ICT business continuity plans and ICT response and recovery plans must be tested at least once a year for systems supporting all functions, and again after any substantive change to the ICT systems supporting a critical or important function. For entities other than microenterprises, those tests have to include scenarios of cyberattacks and switchovers between primary ICT infrastructure and the redundant capacity, backups, and facilities required under Article 12. Article 11(6) separately requires testing the crisis communication plans that Article 14 covers, so a continuity test that only exercises technical failover without checking whether the right people are notified on time has not covered the whole requirement.

This annual cadence is distinct from the threat-led penetration testing that Articles 26-27 require for a smaller set of significant entities. TLPT tests whether defences hold up under a live, intelligence-led attack; Article 11 testing checks whether the entity can actually recover once something has already gone wrong. A programme that only runs one of the two has a visible gap a supervisor will ask about.

Crisis communication and recordkeeping

Article 11 also requires crisis communication plans that keep staff, clients, counterparties, and competent authorities informed during a disruption, with disclosure procedures agreed in advance rather than improvised mid-incident. Alongside that, entities have to keep readily accessible records of activities before and during disruptions, both to support the entity's own post-incident review and to satisfy a supervisor's request for evidence that the plan was actually followed, not just filed.

Review triggers beyond the calendar

Article 11 requires the continuity policy and the response and recovery plans to be reviewed regularly, and specifically after test results, an ICT-related incident, or an audit or supervisory recommendation. An entity that treats the annual test as the only occasion to revisit its plans is missing the other triggers DORA expects it to act on.

Where this fits across the other pillars

Article 11 does not operate in isolation. The recovery objectives it sets are the same ones resilience testing checks against, the dependencies it maps feed directly into third-party risk assessments and exit planning, and a failed recovery during a live incident is exactly what major-incident reporting thresholds are built to catch. Our broader explainer on the eight-part ICT risk management framework covers how Articles 8 through 15 connect as a set; this piece goes deeper on the recovery and backup pieces specifically.

Common gaps we see

• RTOs and RPOs set once, never validated. Objectives exist on paper but have not been tested against a realistic failover.
• Backup frequency that ignores criticality. The same nightly schedule applied to a critical payments system and a low-impact internal tool.
• Restoration systems sharing infrastructure with the source. Backups sit on the same network segment or credentials as the primary system, defeating the segregation Article 12 requires.
• Crisis communication left out of the annual test. Technical failover gets exercised; notifying clients and regulators on time does not.
• Reviews triggered only by the calendar, not by an incident, a test finding, or a supervisory recommendation.

A practical checklist

• Confirm the BIA maps each critical or important function to its supporting systems, processes, and third-party dependencies.
• Check that RTOs and RPOs are documented per critical function and validated by a test in the last 12 months, not a tabletop walkthrough alone.
• Verify backup frequency is tied to a documented criticality assessment, not a blanket schedule.
• Confirm restoration systems are segregated from the source environment, and that a restoration test, not just a backup-completion check, has run in the last year.
• Check that the most recent annual test included a cyberattack scenario, a switchover exercise, and a crisis-communication test.

Entities working through a full DORA checklist or scoping a DORA gap assessment can use the DORA Readiness Score to see how resilience and recovery planning scores against the other DORA pillars before committing budget to a full review.

Sources

• Regulation (EU) 2022/2554 (DORA), Articles 8, 11, 12, and 14, EUR-Lex.
• Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, RTS on ICT risk management tools, methods, processes and policies, EUR-Lex.
• EBA, Digital operational resilience Regulation (DORA).
• ESMA, Digital Operational Resilience Act (DORA).

Last updated: 12 October 2026.