What DORA requires of backups
DORA requires most EU financial entities to document backup policies (scope and frequency set by data criticality or confidentiality) and restoration methods, test them periodically, use ICT systems segregated from the source when restoring with their own systems, and set RTO and RPO per function. It sets no general numeric RTO and never says immutable, air gap or ransomware.
Note: This is an engineering reading of the Regulation, not legal advice. Whether an entity is compliant is for the entity, its counsel and its competent authority to decide.
Scope
DORA is Regulation (EU) 2022/2554, and it "shall apply from 17 January 2025" (Article 64). Article 2(1) covers credit institutions, payment and e-money institutions, investment firms, insurers, trading venues, central securities depositories (CSDs), central counterparties (CCPs) and other financial entities.
The backup duties sit in Article 12 and in Delegated Regulation (EU) 2024/1774, the regulatory technical standards (RTS) on ICT risk management. Microenterprises (Article 3(60)) are spared several duties. Entities on the simplified framework of Article 16, such as small and non-interconnected investment firms, fall outside Article 12. They still need "back-up and restoration measures" for the continuity of critical or important functions, tested "on a regular basis".
Article 12 mapped to Veeam controls
Only the first column quotes the DORA texts. The control and evidence columns are our interpretation for Veeam Backup & Replication 13. Completing every row does not make an entity compliant.
| Requirement | Reference | Veeam control | Evidence |
|---|---|---|---|
| Scope and minimum frequency "based on the criticality of information or the confidentiality level of the data" | 12(1)(a) | Schedules and retention differ by data class; every in-scope workload sits in a job | Written policy; asset register reconciled against the job inventory |
| "restoration and recovery procedures and methods" | 12(1)(b) | A runbook per workload type: full VM, Instant Recovery, application item, database | Versioned runbooks with named owners |
| Activation "shall not jeopardise the security of the network and information systems" | 12(2) | Restored systems verified or scanned before reconnection, for example with Secure Restore | Scan or verification result per recovery |
| Testing "undertaken periodically" | 12(2) | Scheduled SureBackup verification plus real restores of critical systems | Dated reports: restore point, duration, result |
| Restore on systems "physically and logically segregated from the source ICT system" | 12(3) (our reading) | An isolated recovery environment with its own credentials | Network diagrams; firewall rules; credential inventory |
| Restore systems "securely protected from any unauthorised access or ICT corruption" | 12(3) (our reading) | MFA and four-eyes authorization on the backup server; repositories outside the production domain | Role assignments; access reviews |
| "redundant ICT capacities" (not microenterprises) | 12(4) | Backup copy to a second site or provider, with compute to run what is restored | Capacity plan; copy job history |
| RTO and RPO "for each function" | 12(6); RTS 4(2)(b)(vi) | Job frequency derived from RPO; restore throughput measured against RTO; both recorded per asset | Business impact analysis; restore-point age report; a full restore at production scale (SureBackup shows boot and application checks, not RTO) |
| "necessary checks, including any multiple checks and reconciliations" | 12(7) | Application-level reconciliation beyond "the VM booted" | Reconciliation records |
| Keys replaceable "in the case of loss" | RTS 7 | Backup encryption passwords stored and recoverable outside the backup server | Key inventory; a restore test that used the recovered key |
| Logs protected "against tampering, deletion, and unauthorised access" | RTS 12(2)(d) | Backup logs kept where the backup administrator cannot alter them | Log store access list |
Note: Article 12(3) is worded around the systems used to restore, not where copies are stored. EIOPA's non-binding answer to Q&A DORA038 is consistent with that reading but does not settle it. That reading has two practical consequences: restoring on a provider's systems (DRaaS) is not "own systems" and falls under the third-party rules of Articles 28 to 30, and separated backup copies are better justified by Article 9(3)(b), Article 12(4) and RTS Article 26(2). The paragraph's second sentence can reasonably be read to cover the backup server and repositories used to restore, which is why the table applies it to them.
Testing
- Yearly plan tests. Article 12(2) only says "periodically". Article 11(6) requires plan tests "at least yearly", and entities other than microenterprises include switchovers to "backups and redundant facilities". RTS Article 25(2) adds failback: the tests verify "whether the normal functioning may be restored".
- Independent tests. Article 24(6) requires entities other than microenterprises to test all ICT systems and applications supporting critical or important functions "at least yearly". Article 24(4) requires tests by "independent parties, whether internal or external". We read that to include the backup server that protects a critical function.
- TLPT. Threat-led penetration testing (Article 26) applies only to entities their competent authority identifies.
Incident reporting
A ransomware attack on backups falls under DORA's incident rules (Articles 17 to 23). Under Delegated Regulation 2024/1772, "service downtime is longer than 2 hours for ICT services that support critical or important functions" is one materiality threshold. A major incident starts the clock of Delegated Regulation 2025/301: initial notification within 4 hours of classification and no later than 24 hours from awareness, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report. Set RTOs with that clock in mind.
Backup and storage providers
A backup SaaS, an S3-compatible storage service or an MSP running Veeam is an "ICT third-party service provider" (Article 3(19)), and the entity "shall, at all times, remain fully responsible" (Article 28(1)(a)). Record the contract in the register of information (Article 28(3), templates in Implementing Regulation 2024/2956). Make sure it states "the storage location" and provides for "access, recovery and return in an easily accessible format" on insolvency, resolution, discontinuation or termination (Article 30(2)). Weigh concentration (Article 29(1)): backups on the same provider as production weaken the 12(4) redundancy they are meant to supply.
Note: In S3 compliance mode a locked version's "retention period can't be shortened". Leaving a provider means copying data out while the locked originals stay until retention expires.
What DORA does not say
We searched the English Official Journal texts of DORA and of Delegated Regulation 2024/1774: neither contains "immutable", "air gap", "offline", "WORM", "3-2-1" or "ransomware".
- No 2-hour RTO for most entities. Only CCPs, CSDs and trading venues get numeric targets (RTS Article 24). The other 2-hour figure is the reporting threshold above.
- No air-gap rule. See the note under the table.
- No compliance through a storage feature. Immutability (hardened repository or Object Lock through Veeam) serves Article 9(3)(b), to "minimise the risk of corruption or loss of data". It is evidence for part of one paragraph. The policy, the tests, the segregation and the contracts are the rest. Whether a lock actually holds is a separate question, covered in how to prove immutable backups are immutable. Monitoring serves Article 10. The 3-2-1-1-0 rule organises these controls, although DORA does not mention it.
Key words such as "periodically", "adequate" and "timely" are undefined, and Article 4 makes the rules proportionate, so a small insurer and a systemic bank can read one sentence differently and both be right. ESA answers in the Single Rulebook Q&A are not binding, and we have not surveyed national competent authorities' own expectations. The Digital Omnibus proposal of 19 November 2025 would change the incident reporting channel. As far as we could verify, it is still pending.
How BackupSec approaches this
We do not make anyone DORA compliant. We can produce evidence for the engineering parts of Article 12. ZeroPEN runs a controlled ransomware kill-chain against a Veeam estate and delivers a regulatory mapping matrix and a retest for critical findings. It can be one of the tests in an Article 24 and 25 programme. It is not a TLPT under Article 26. ZeroTAM reviews architecture, hardening and recovery strategy (RTO and RPO). ZeroMON watches Veeam on-premises through a read-only account and alerts when jobs fail or immutability is switched off on a repository.