DORA compliance: a practical guide

In a July 2025 survey, 96% of EMEA financial services organisations said they needed to improve their resilience to meet DORA requirements ^[1]. The regulation has been enforceable since January 2025, so any shortfall is now a live compliance risk that the next audit or attack will expose. 

This DORA compliance guide covers what DORA requires, who it applies to, the costs of non-compliance, and the weak link in the compliance chain that most organisations underestimate: recoverability, the ability to restore data after an attack. 

Key takeaways

• DORA is EU Regulation 2022/2554. It applies to more than 22,000 financial entities and their ICT providers since 17 January 2025. 

• DORA compliance means acting on five requirements: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. 

• Penalties are set by individual EU Member States. Ceilings reach up to €20 million or a fixed share of turnover, on top of public censure and management bans. 

• Article 12 is the backup-specific article. It requires tested, segregated, tamper-protected recovery systems. 

What is DORA compliance?

DORA stands for the Digital Operational Resilience Act. It is a regulation introduced by the European Union to strengthen the digital resilience of financial entities. 

It came into effect on 17 January 2025 and ensures that banks, insurance companies, investment firms, and other financial entities can withstand, respond to, and recover from ICT (Information and Communication Technology) disruptions, such as cyberattacks or system failures ^[2]. 

DORA compliance means meeting the obligations set out in the regulation, officially known as Regulation (EU) 2022/2554. 

The reason it exists is straightforward. Financial firms have become increasingly reliant on digital systems to deliver services, manage operations, and process transactions. That growing dependence has created new operational and cybersecurity risks. Ransomware attacks on the financial sector have surged, and a serious failure at one firm can now spread to others and threaten the stability of the whole market. 

DORA treats an ICT failure as a risk to financial stability, much like regulators have traditionally viewed risks such as capital shortages. This makes building real cyber resilience a regulatory duty, not a best practice. 

Who must comply with DORA?

DORA applies to more than 22,000 financial entities across the EU, as well as the third-party ICT providers that serve them ^[3]. 

The regulation names 20 different types of financial entities ^[2], which fall into five broad groups: 

• Banking and payments: credit institutions, payment institutions, electronic money institutions, and account information service providers. 

• Capital markets: trading venues, investment firms, trade repositories, central counterparties (CCPs), and central securities depositories. 

• Asset management: alternative investment fund managers and UCITS management companies. 

• Insurance and pensions: insurance intermediaries, insurance and reinsurance undertakings, and institutions for occupational retirement provision. 

• Other regulated entities: credit rating agencies, securitisation repositories, benchmark administrators, crypto-asset service providers, crowdfunding service providers, and data reporting service providers. 

DORA also extends to the technology vendors behind these firms. Any third-party ICT provider that serves an in-scope financial entity is subject to the regulation, including providers based outside the EU.  

This means, for example, that a cloud platform, managed service provider, or software vendor cannot avoid DORA simply because its headquarters are elsewhere. 

The five DORA compliance requirements 

Knowing how to comply with DORA comes down to five requirements: risk management, incident reporting, resilience testing, third-party oversight, and information sharing. 

Falling short on any one of them leaves an organisation non-compliant. 

1. ICT risk management 

This is the foundation. Financial entities need a documented ICT risk management framework that covers the full lifecycle of risk: identification, protection, detection, response, and recovery. Ownership has to sit at senior management level, with the management body accountable for approving and overseeing it. 

The framework also has to set a clear risk tolerance, meaning the maximum disruption a critical function can absorb before harm becomes unacceptable. These DORA cybersecurity requirements make risk management a board-level responsibility. 

2. ICT incident reporting 

When a major incident hits, regulators want to know quickly. DORA requires organisations to implement a severity classification system and a reporting workflow that escalates a significant incident to the competent authority without undue delay. 

In practice, that means three steps: an initial alert within 24 hours of classifying the incident, a status update within 72 hours, and a final root-cause report about a month after the incident is resolved ^[5]. The aim is a clear, consistent account of what happened and why. 

3. Digital operational resilience testing 

Every in-scope entity must regularly test its resilience. The largest and most critical entities must go further and run Threat-Led Penetration Testing (TLPT), which consists of live, simulated attacks conducted by independent, certified testers on a three-year cycle. 

A business continuity plan can read well and still fall apart the first time it is used. Testing is the only way to know whether it will actually hold, before attackers force the answer. 

4. Third-party ICT risk management 

A financial entity is only as resilient as the vendors on which it depends. DORA requires firms to vet, monitor, and keep contractual leverage over every ICT provider, and to maintain a live Register of Information covering all of them. 

ICT providers whose services are widely used across the financial sector, and would be difficult to substitute, can be designated as critical. Those providers answer directly to EU regulators, under a dedicated Oversight Framework with penalties of its own. 

5. Information sharing 

This is the one voluntary requirement. DORA encourages financial entities to exchange cyber threat intelligence within trusted communities, so the sector can learn from each attack collectively rather than one victim at a time. 

DORA penalties for non-compliance 

DORA does not set a single fine for the entire EU. Each Member State establishes its own maximum penalties under Article 50, meaning the potential fine depends on where an entity operates ^[4]. 

The penalties target two groups: financial entities and their most critical ICT providers. In both cases, the consequences extend beyond fines and can include significant regulatory and reputational penalties. 

• Financial entities: National regulators set ceilings that vary widely. Absolute caps reach up to €20 million in Italy, while turnover-based caps range from 5% in Spain to 10% in Sweden ^[4].  

• Critical third-party ICT providers: The EU Lead Overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover, for each day of non-compliance, for up to six months ^[5]. 

• Beyond fines: Regulators can issue public notices naming the responsible party, order a firm to stop specific conduct, ban individuals from management roles, or suspend a license. 

Enforcement runs on two levels. National competent authorities, such as BaFin in Germany or the Central Bank of Ireland, supervise financial entities.  

One of the three European Supervisory Authorities (EBA, ESMA, or EIOPA) acts as Lead Overseer for each critical ICT provider. 

Proving resilience through backup and recovery

Passing an audit on paper is not the same as demonstrably being able to recover data after an attack.  

Cyber criminals usually target backup systems first, specifically because they know organisations depend on them for recovery. Corrupting or deleting backups therefore provides attackers with more leverage during extortion attempts. Unsurprisingly, among ransomware-hit organisations, 94% reported attempts to compromise their backup data, and 57% said those attempts succeeded ^[6].  

Deployment of verifiably immutable backup storage and fast recovery ensure an organisation can demonstrate resilience to regulators, not just show a policy document. 

 This approach to protecting backup data is fully aligned with DORA’s intent, and its concrete requirements: tested restores that meet Recovery Time and Recovery Point Objectives (RTO and RPO) under real conditions, and an evidence trail an auditor can follow. 

That proof maps onto two of the five main requirements of DORA: ICT risk management, which demands planned recovery capability, and resilience testing, which demands you show it works.  

An immutable backup storage solution with rapid recovery should be the backbone of an organisation’s recovery plan. This is data resilience in practice.

What does DORA Article 12 require for backups?

Article 12 translates DORA’s resilience principles into specific backup and recovery requirements. 

It sets four concrete obligations: 

• A documented backup policy stating what data gets backed up and how often, based on how critical or confidential that data is. 

• Documented restoration and recovery procedures. 

• Periodic testing of those backup and recovery procedures. Activating a backup must never compromise the security, availability, authenticity, integrity, or confidentiality of data. 

• When restoring, the systems used must be physically and logically segregated from the source system and protected from unauthorised access or corruption. 

The regulation's own words are worth reading: 

"Financial entities shall set up backup systems that can be activated in accordance with the backup policies and procedures ... Testing of the backup procedures and restoration and recovery procedures and methods shall be undertaken periodically ... When restoring backup data using own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system." ^[5] 

Compliance can be achieved by maintaining immutable backups, meaning that during a pre-defined time window, a backup cannot be altered or deleted. Care is needed here, though, because many systems that claim to offer immutable backups have hidden exceptions and loopholes. 

A solution to this is Absolute Immutability, which means that even the most privileged admin, or an attacker with access to backup storage, cannot modify or delete data. This level of protection can only be achieved with a backup storage system that is Secure-by-Design, with Zero Access to perform destructive actions, and that Zero Access must be verifiable through third-party testing. 

The Zero Access model is complemented by the 3-2-1-1-0 backup rule: at least three copies of data on two different media types, with one copy stored offsite and at least one kept offline or immutable to prevent tampering. The final zero stands for zero restoration errors, verified through the regular testing DORA requires to ensure RTO and RPO targets hold, even in extreme scenarios. 

DORA compliant backup storage: how Object First helps 

To fully align with the requirements under Article 12 of DORA, backup storage must be tamper-proof, tested, and quickly recoverable. This is where Object First comes in. 

Object First delivers secure, simple, and powerful backup storage that's purpose-built for Veeam. It features Absolute Immutability, enforced through Zero Access to destructive actions: this means that even the most privileged admin or attacker with access to backup storage cannot modify or delete data. This has been verified by independent third-party testing. 

The result is a tested, tamper-proof recovery copy that a financial entity can quickly restore from - and proof of resilience that can be presented to regulators. 

Download our guide to the Digital Operational Resilience Act (DORA) and learn how absolutely immutable backups can ensure operational resilience and, by extension, regulatory compliance.

FAQ 

DORA vs NIS2: what's the difference? 

NIS2 sets broad cybersecurity rules across many sectors. DORA is specific to the financial sector and takes precedence for financial entities wherever the two overlap, a legal principle known as lex specialis. 

An organisation that falls under DORA does not have to comply with NIS2 for the same cybersecurity and incident-reporting obligations. For the broader directive, use our NIS2 compliance checklist. 

What are the cybersecurity requirements for DORA compliance?

DORA's cybersecurity requirements sit inside its ICT risk management framework. Three articles carry most of the technical weight: 

• Article 9 (protection and prevention): this covers network security, encryption, access management, and patching. 

• Article 10 (detection): requires continuous monitoring to catch anomalous activity and potential incidents quickly. 

• Article 12 (backup, restoration, and recovery): establishes DORA's most detailed requirements for backup resilience, including recovery testing, segregation of recovery environments, and protection against tampering.. 

Together, they define what DORA compliance in cybersecurity looks like in practice. 

What is the DORA compliance deadline?

DORA has been in force since 17 January 2025, so the deadline has already passed. The focus in 2025 was largely on implementation. In 2026, regulators are increasingly testing whether firms can demonstrate the resilience capabilities that DORA requires.  

Which institutions oversee DORA?

National Competent Authorities (NCAs) in each member state supervise individual financial entities on a day-to-day basis. 

Above them, the three European Supervisory Authorities (EBA, ESMA, and EIOPA) developed DORA's technical standards and directly oversee critical ICT third-party providers through the Oversight Framework, with one authority serving as the Lead Overseer for each provider.

References

[1] Veeam Software / Censuswide. "96% of EMEA Financial Services Organizations Believe They Need to Improve Their Resilience to Meet DORA Requirements." 2025. https://www.veeam.com/company/press-release/96-percent-of-emea-financial-services-organizations-believe-they-need-to-improve-their-resilience-to-meet-dora-requirements.html 

[2] EIOPA. "Digital Operational Resilience Act (DORA)." https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en 

[3] LRQA. "DORA Compliance." https://www.lrqa.com/en-gb/dora-compliance/ 

[4] DLA Piper. "Divergence in administrative penalties under DORA." 2025. https://www.dlapiper.com/en-us/insights/publications/2025/10/divergence-in-administrative-penalties-under-dora 

[5] Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554 

[6] Sophos. "The State of Ransomware 2025." 2025. https://www.sophos.com/en-us/blog/the-state-of-ransomware-2025 

[7] Veeam. "2025 Ransomware Trends Report." 2025. https://www.veeam.com/blog/ransomware-trends.html