DORA backup requirements and resilience testing: what Article 12(3) and the RTS ask of IT

DORA backup requirements: what the regulation and its RTS ask of IT

DORA, Regulation (EU) 2022/2554, places backup and recovery in Chapter II, “ICT risk management”, in Article 11, “Response and recovery”, and Article 12, “Backup policies and procedures, restoration and recovery procedures and methods” (titles as in the EBA’s Interactive Single Rulebook). Article 12(1) requires documented “backup policies and procedures specifying the scope of the data that is subject to the backup and the minimum frequency of the backup, based on the criticality of information or the confidentiality level of the data”, and restoration and recovery procedures. Article 12(2) adds: “Testing of the backup procedures and restoration and recovery procedures and methods shall be undertaken periodically.” Under Article 12(3), restores onto the entity’s own systems use systems segregated from the source.

For the plans, Article 11(6)(a) requires financial entities to “test the ICT business continuity plans and the ICT response and recovery plans in relation to ICT systems supporting all functions at least yearly, as well as in the event of any substantive changes to ICT systems supporting critical or important functions”. Article 64 sets the date: “It shall apply from 17 January 2025.”

The technical detail is in Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, the regulatory technical standards (RTS) on the ICT risk management framework, in Articles 24 to 26 and, for the simplified framework, Articles 39 and 40. Encryption, logging, segmentation and access control under the same RTS are in our article on GPU servers for banks and insurers.

Which text applies: full framework, simplified framework and NIS2

The RTS has two regimes. Title II sets the full framework, and Title III the simplified ICT risk management framework for the financial entities referred to in Article 16(1) of DORA.

For entities that DORA covers, recital 28 of the NIS2 Directive says the DORA provisions on ICT risk management, incident reporting, resilience testing, information sharing and third-party risk “should apply instead of those provided for in this Directive”. Our guide to NIS2 backup and business continuity requirements covers companies outside financial services. Whether a company falls under DORA, which regime applies and which functions are critical or important is a legal assessment for its legal and compliance function.

Article 12(3): segregated restore systems and backup scope

Article 12(3) of DORA states: “When restoring backup data using own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system.” In Q&A DORA038, submitted on 14 February 2024 and marked final, EIOPA notes that DORA does not define “own systems” and reads the provision as restoring “by using ICT systems for which the financial entity has full control and responsibility”, systems “that are not directly connected with the main one”.

For a virtualised estate, one technical design in line with that reading has its own hosts or cluster, a network segment with no direct route to production, and administrator accounts outside the production directory. Sized for the systems behind critical or important functions, with the rest restored in waves, it needs a fraction of the production hosts. The design choices are in our guide to the isolated recovery environment.

For the simplified framework, RTS Article 39(2)(g) asks the plan for the backup scope and a minimum backup frequency based on the criticality of the function. Under Title II, Article 4 of the RTS, on the ICT asset management policy, requires records of “the ICT business continuity requirements, including recovery time objectives and recovery point objectives”, so the inventory and the backup jobs can be checked against the same objectives.

Recovery objectives and the ICT response and recovery plan

Under Article 24(1) of the RTS, the continuity policy sets recovery objectives, specifying that the entity “shall be able to recover the operations of its critical or important functions after disruptions within a recovery time objective and a recovery point objective”. RTS Article 24 sets figures only for central counterparties, central securities depositories and trading venues, all around a 2-hour recovery time. Other entities set their own from the business impact analysis; our guide to the business impact analysis for IT shows how to get to an RTO and RPO per system.

Under RTS Article 26(1), the ICT response and recovery plans specify the conditions for activation and deactivation and describe the actions that ensure “the availability, integrity, continuity, and recovery” of at least the systems supporting critical or important functions. They are documented and “readily accessible in case of emergency”, provide short-term and long-term options “including partial systems recovery”, and lay down the conditions to declare a successful execution. That last item gives every recovery test its pass criterion in advance: a named service working within its RTO, from a restore point within its RPO, confirmed by its owner.

RTS Article 26(2) lists the scenarios the plans consider, among them “cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups, and redundant facilities”, the failure of data centres and widespread power outages. A cyber-attack scenario needs its own runbook, because replicas updated every few minutes may already hold encrypted data, and that recovery starts from an older, clean restore point in segregated systems.

Testing business continuity plans: scenarios, switchover and failback

RTS Article 25 applies when financial entities test their ICT business continuity plans “in accordance with Article 11(6)” of DORA. Under Article 25(2) the tests run scenarios that simulate potential disruptions, “including an adequate set of severe but plausible scenarios”, and always the scenarios used to develop the plans. They test third-party ICT services where applicable, with scenarios of a provider’s insolvency or failure, and challenge the plans’ assumptions, “including governance arrangements and crisis communication plans”. For entities other than microenterprises, the second subparagraph of DORA Article 11(6) requires testing plans to include “scenarios of cyber-attacks and switchovers between the primary ICT infrastructure and the redundant capacity”, backups and redundant facilities, and RTS Article 25(2)(c) repeats the switchover scenarios.

For those switchovers, the testing “shall verify whether at least critical or important functions can be operated appropriately for a sufficient period of time, and whether the normal functioning may be restored”. Operation over a business period and failback therefore belong in the scope, beside the boot check at the secondary site. RTS Article 25(5) requires documented results, and “Any identified deficiencies resulting from that testing shall be analysed, addressed, and reported to the management body.” The test types are covered in our guide to disaster recovery testing.

Our disaster recovery service runs scheduled failover tests in an isolated environment, with a report after each one on what came up, how fast and what to fix. Tell us which functions you would switch over first and how you test them today.

How often DORA tests are due under the regulation and the RTS

Article 11(6)(a), quoted above, requires the continuity and recovery plan tests at least yearly. For backups, Article 12(2) asks for periodic tests without a fixed interval. In Chapter IV of DORA, Article 24(6) states: “Financial entities, other than microenterprises, shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.” Entities required to perform TLPT “shall carry out at least every 3 years advanced testing by means of TLPT” under DORA Article 26(1), and the competent authority may request a shorter or longer interval. Under the simplified framework, RTS Article 40(1) sets tests “at least once every year for the back-up and restore procedures, or upon every major change of the business continuity plan”.

Regulation (EU) 2022/2554 (DORA), official text at https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554, and Commission Delegated Regulation (EU) 2024/1774 in the Official Journal text, both read on 10 October 2026.

The tests of DORA Chapter IV, “Digital operational resilience testing”, come in addition to the continuity tests. We suggest including backup servers, repositories and their administrator accounts in them as systems of their own, since attackers go after them, as our article on why backup is not disaster recovery describes.

Evidence the IT team should be able to show

The table maps each requirement to records the IT team can produce; whether the entity meets the text is for its own assessment.

Regulation (EU) 2022/2554, Articles 12(1) and 12(3), on eur-lex.europa.eu; Delegated Regulation (EU) 2024/1774 read in the Official Journal text on 10 October 2026. The evidence column is our reading, not a statement of compliance.

Where a provider runs the off-site copy or the recovery site, RTS Article 25(2)(b) brings its services into the continuity tests where applicable, and RTS Article 26(4) asks entities to “consider and implement continuity measures to mitigate failures of ICT third-party service providers”. The contract should cover the provider’s part in your tests and its test reports.

Our cyber resilience assessment reviews infrastructure, access and backups, and for financial entities we include DORA requirements in the assessment and the work plan. Send us your continuity policy and your last test report through the form below.

A worked example: one test year for a bank with 900 VMs

As an example, take a bank with 1,400 staff running 900 VMs on 40 hosts in two data centres. Its business impact analysis maps the critical or important functions, such as payments, core banking and customer channels, to 140 VMs in tier 1, including the directory service, DNS and the database clusters; tiers 2 and 3 hold the other 760. At the estate’s average of about 22 VMs per host, a segregated restore cluster for tier 1 needs about seven hosts plus storage, and more if the tier 1 database servers are larger than the average VM. The calendar below covers each element of RTS Article 25(2) once in the year.

1. In the first quarter, run a tabletop exercise of the recovery plan and the crisis communication plan, led by someone outside IT, to challenge its assumptions.
2. In the second quarter, restore all 140 tier 1 VMs from backup onto the segregated cluster, timed against each RTO and checked by the system owners against the plan’s success conditions.
3. In the third quarter, switch tier 1 over to the second data centre in a maintenance window with a rollback plan, run it there for a business day, then fail back.
4. In the fourth quarter, test a cyber-attack scenario that starts from the newest clean restore point, and the failure of the off-site copy provider, with the provider where the contract allows.
5. After each test, document the results, give every deficiency an owner and a date, and report to the management body.

The quarters are our suggestion, not an interval set by DORA or the RTS; the bank’s own policy sets its cycle.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our cyber resilience service, our engineering partner Vixen.UNO reviews security and backup; for financial entities we include DORA requirements in the assessment and the work plan, and the legal opinion on compliance is prepared by your legal department. Under our disaster recovery service, we define the critical systems, the target RPO and RTO per tier and the disaster scenarios with you, and run scheduled failover tests in an isolated environment with a report after each test. The recovery site runs in Baltneta’s Tier-3 data centres in Lithuania, with your targets per tier fixed in the SLA. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ