If you work in financial services and your organization operates in the EU, you have almost certainly heard of the Digital Operational Resilience Act (DORA) by now. DORA is Regulation (EU) 2022/2554, published on December 27, 2022, and it became fully applicable on January 17, 2025. The regulation covers how financial entities must manage Information and Communication Technology (ICT) risk across five pillars: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing.
One pillar that catches organizations off guard is backup policy. Article 12 of DORA lays out specific, enforceable requirements for how you document, activate, test, and recover data. This is not a soft guideline you can interpret creatively. Regulators expect written evidence, tested procedures, and segregated systems. I am going to break down exactly what Article 12 requires, why each requirement exists, and what a genuinely solid backup program looks like in practice.
Why Backup Policy Gets Its Own Article in DORA
Most regulations fold backup into broader IT security guidance. DORA does not. Article 12 exists as a standalone provision because EU lawmakers recognized a clear pattern: financial institutions were allocating capital to cover potential losses from ICT failures rather than actually building the technical capability to prevent and recover from them. That approach does not work when a cyberattack or system failure disrupts cross-border financial services. The downstream effects can destabilize entire markets.
DORA also recognizes that backup failure is frequently the reason a minor incident becomes a catastrophic one. When a backup is untested, corrupted, or stored on the same system it is meant to protect, it offers no real protection. Article 12 closes that gap by making your backup architecture a matter of regulatory record, not just internal IT policy.
Who DORA’s Backup Requirements Apply To
DORA applies to a wide set of financial entities operating in the EU, including banks, investment firms, insurance companies, payment institutions, crypto-asset service providers, and data reporting service providers. The regulation also applies to ICT third-party service providers that support critical functions for these entities.
There is one meaningful carve-out: microenterprises, defined as entities with fewer than 10 employees and an annual turnover or balance sheet total that does not exceed EUR 2 million. Microenterprises must still assess whether they need redundant ICT capacity, but they are not automatically required to maintain it. For every other entity, the full requirements of Article 12 apply.
The Six Core Requirements of Article 12
1. You Must Document a Formal Backup Policy
Article 12(1)(a) of Regulation (EU) 2022/2554 requires financial entities to develop and document backup policies and procedures that specify the scope of data subject to backup and the minimum frequency of backup, based on the criticality of information or the confidentiality level of the data. Frequency is not left to your discretion. It must be tied to a documented assessment of how critical or sensitive each data category is. Critical transactional data may require near-continuous backup. Administrative records may justify a longer interval. The key is that the rationale is written down and auditable.
Your policy must also define restoration and recovery procedures as a companion document. Backup and recovery are treated as a pair under DORA because a backup that cannot be reliably restored is operationally worthless.
2. Your Backup Systems Must Actually Be Activatable
Article 12(2) requires that you set up backup systems that can be activated in accordance with your documented policies. This sounds obvious, but it rules out a common failure mode: having a backup policy that describes procedures your actual infrastructure cannot execute. If your policy says you can restore within four hours but your systems have never been tested and nobody knows the recovery steps, you are out of compliance regardless of how well-written the document is.
Critically, the activation of backup systems must not compromise the security, availability, authenticity, integrity, or confidentiality of data. Spinning up a backup must not open new attack surfaces or expose unencrypted data.
3. Backups Must Be Physically and Logically Segregated
Article 12(3) requires that when restoring backup data using your own systems, you use ICT systems that are physically and logically segregated from the source ICT system. Physical segregation means the backup is not on the same hardware or in the same data center as the primary system. Logical segregation means it is on a separate network segment, access-controlled independently, and not reachable by the same credentials or pathways that could compromise the primary system.
This requirement is the regulatory response to a now-common ransomware attack pattern: attackers who compromise a network will often encrypt or destroy backup data before triggering the main attack. If your backup lives in the same logical environment as your production data, it will be taken out in the same strike. Immutable storage, air-gapped copies, and third-party backup platforms address this requirement in practice.
4. You Must Test Backup and Recovery Procedures Periodically
The testing requirement in Article 12(2) is non-negotiable. Backup tests must happen regularly, and for larger entities Article 11 of DORA extends this obligation by requiring that testing plans include scenarios of cyber attacks and switchovers between primary infrastructure and redundant backups. Threat-led penetration testing (TLPT) is required for significant entities under Article 26.
What does good testing look like? A genuine restoration test, not just a connectivity check. You should be confirming that data can be recovered to a working state within your defined Recovery Time Objective (RTO) and that data loss does not exceed your Recovery Point Objective (RPO). Both objectives must be documented, and they must account for whether each function is critical or important and the potential overall impact on market efficiency, as stated in Article 12(6).
5. Non-Microenterprises Must Maintain Redundant ICT Capacity
Article 12(4) requires that all financial entities except microenterprises maintain redundant ICT capacity equipped with resources, capabilities, and functions adequate to ensure business needs. Redundancy is not optional and it is not just about storage. It covers compute, networking, and staffing. If your primary environment goes down, your redundant environment needs to be capable of running your critical operations, not just storing data.
Central securities depositories face an additional requirement under Article 12(5): at least one secondary processing site at a geographic distance from the primary site, capable of maintaining critical functions and immediately accessible to staff.
6. Data Integrity Must Be Verified After Recovery
Article 12(7) requires that when recovering from an ICT-related incident, financial entities perform necessary checks, including multiple reconciliations, to ensure the highest level of data integrity is maintained. This applies both to internally restored data and to data reconstructed from external stakeholders. Every restored system must be verified for consistency before it is returned to production use.
This requirement matters because recovery is when errors are most likely to compound. Incomplete transaction records, mismatched timestamps, or corrupted reference data can create downstream financial reporting failures that are sometimes harder to unwind than the original incident.
A Practical Backup Compliance Checklist
Here is how I would translate the Article 12 requirements into operational steps:
| Requirement | Practical Action |
|---|---|
| Documented backup policy | Classify data by criticality; assign backup frequency per tier |
| Activatable backup systems | Run quarterly activation drills; verify RTO and RPO |
| Physical and logical segregation | Use immutable off-site or cloud storage; separate access controls |
| Periodic testing | Schedule restoration tests; document results; update plans |
| Redundant ICT capacity | Provision a secondary environment capable of running critical functions |
| Data integrity post-recovery | Build reconciliation checks into every recovery runbook |
DORA Backup Policy and Related Standards
DORA does not exist in isolation. Two international standards sit naturally alongside it: ISO 22301, which covers business continuity management, and ISO 27031, which covers ICT readiness for business continuity. If your organization already maintains certification under either of those standards, you have a head start on DORA’s backup requirements. The concepts of RTO, RPO, and recovery procedure documentation overlap significantly.
The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, also intersects with backup policy. Personal data stored in backups remains subject to GDPR obligations, including data subject rights and retention limits. A DORA-compliant backup that retains personal data indefinitely may still create a GDPR violation. These two frameworks need to be managed in coordination.
The Governance Angle Most Organizations Miss
Here is the part that surprises most compliance teams: DORA treats backup as a governance issue, not just an IT issue. Article 5 makes the management body of a financial entity directly responsible for ICT risk management. That means your board or executive leadership is accountable for approving the ICT risk framework that includes the backup policy. If your backup program sits entirely within IT and has never been reviewed by senior leadership, that is a structural gap.
Practically, this means your backup policy documentation needs to show a clear chain of approval at the governance level. It also means that when supervisory authorities ask for evidence of compliance, they will look for board-level awareness and sign-off, not just technical configuration records.
Non-Compliance Is Expensive
The European Supervisory Authorities (EBA, ESMA, and EIOPA) have oversight powers under DORA. Financial entities that violate the regulation’s requirements can face fines of up to 2% of total annual worldwide turnover. For individuals, penalties can reach EUR 1 million. Beyond direct fines, non-compliance exposes entities to supervisory scrutiny, reputational risk, and potential restrictions on operations.
The enforcement environment is active. Supervisory authorities have the power to request copies of backup testing results and recovery documentation, conduct on-site inspections, and issue binding recommendations. A paper policy that has never been tested is not a defense.
Where to Start If You Are Not Yet Fully Compliant
If you are reading this and realizing your backup program needs work, the honest starting point is a gap analysis. Measure your current backup scope, frequency, and testing cadence against the requirements of Article 12. Document what you have, identify where the gaps are, and build a remediation plan with timelines that can be shown to regulators.
The most common gaps I see are: backup systems that have never been tested with a live restoration, backup copies that are not segregated from the primary environment, and no documented RPO or RTO for critical functions. Each of those is fixable, and fixing them makes your operations genuinely more resilient, not just more compliant.
DORA’s backup requirements are not designed to generate paperwork. They reflect what good operational discipline looks like for a financial entity that cannot afford prolonged downtime or data loss. Getting compliant and getting resilient are the same work.
