DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), is the European Union law that requires financial entities to withstand, respond to and recover from ICT-related disruptions and threats. It has applied since 17 January 2025 and sets one harmonized framework for ICT risk management, incident reporting, resilience testing and the oversight of technology suppliers in the financial sector.
In cybersecurity law, DORA is a sector-specific regulation that takes precedence over the general NIS2 rules for financial entities. Its distinctive feature is that it reaches beyond banks and insurers to their critical ICT third-party providers, such as major cloud platforms, which come under direct EU oversight.
Who DORA applies to
DORA covers about twenty types of financial entities, from large banks to small payment firms. The obligations are proportionate: they scale with an entity’s size, risk profile and the nature of its services, and microenterprises and certain small entities may follow a simplified ICT risk management framework.
| Group | Examples | Proportionality note |
|---|---|---|
| Banking and payments | Credit institutions, payment and e-money institutions | Largest entities face advanced testing |
| Investment and markets | Investment firms, trading venues, central counterparties | Market infrastructure held to high standards |
| Insurance and pensions | Insurers, reinsurers, occupational pension funds | Smaller intermediaries partly exempt |
| Crypto and new finance | Crypto-asset service providers, crowdfunding platforms | Licensed firms under sector law |
| ICT third-party providers | Cloud, data and software suppliers | Critical ones under EU oversight |
The five pillars of DORA
DORA is organized around five pillars that together form a complete resilience program. Each pillar has detailed technical standards adopted by the European supervisory authorities.
| Pillar | Core requirement | Key output |
|---|---|---|
| ICT risk management | Governance, identification, protection, detection, response and recovery | Documented ICT risk management framework |
| Incident management and reporting | Classify incidents and report major ones | Incident register and regulatory reports |
| Resilience testing | Regular testing of ICT systems and tools | Test program and remediation |
| ICT third-party risk | Manage risk from technology suppliers | Register of information and contracts |
| Information sharing | Voluntary exchange of threat intelligence | Sharing arrangements with peers |
The management body carries ultimate responsibility for ICT risk. Board members must approve the framework, allocate budget and keep their own ICT risk knowledge up to date, which makes resilience a governance duty, not only an IT task.
Incident classification and reporting deadlines
Financial entities must classify ICT-related incidents using criteria such as clients affected, duration, geographic spread, data losses, criticality of services and economic impact. Incidents that meet the thresholds for a major ICT-related incident must be reported to the competent authority in three stages.
| Report | Deadline | Content |
|---|---|---|
| Initial notification | Within 4 hours of classification, at most 24 hours after detection | Basic facts and first impact |
| Intermediate report | Within 72 hours of the initial notification | Updated details, root cause if known |
| Final report | Within one month of the intermediate report | Root cause, measures, lessons learned |
Entities may also notify significant cyber threats voluntarily, and they must inform affected clients without undue delay when an incident affects their financial interests. Because one event may also require notification under data protection law, coordinated incident playbooks are essential.
Resilience testing and threat-led penetration testing
All in-scope entities need a risk-based testing program that includes vulnerability assessments, network security reviews, scenario tests and source code reviews where relevant. Critical systems must be tested at least yearly.
Entities identified as significant must also carry out threat-led penetration testing (TLPT) at least every three years. TLPT simulates the tactics of real attackers against live production systems, follows a methodology aligned with the TIBER-EU framework, and normally uses external testers. The results are attested by the authority, and the attestation can be recognized across member states.
Managing ICT third-party risk
DORA treats outsourcing to technology providers as a core resilience risk. Every financial entity must keep a register of information listing all contractual arrangements with ICT providers, and contracts supporting critical or important functions must contain mandatory clauses.
- Service levels and locations for data processing and storage.
- Audit and access rights for the entity and its supervisor.
- Incident assistance and cooperation obligations.
- Termination rights and exit strategies tested for feasibility.
- Subcontracting conditions for critical functions.
Providers designated as critical ICT third-party providers come under an oversight framework led by one of the European supervisory authorities, the EBA, EIOPA or ESMA. The lead overseer can inspect, request information and issue recommendations, and it can impose periodic penalty payments on a provider that does not cooperate.
DORA compared with NIS2 and common pitfalls
Both DORA and NIS2 impose cybersecurity duties, but DORA is the lex specialis for the financial sector: where it applies, its rules replace the corresponding NIS2 obligations.
| Aspect | DORA | NIS2 |
|---|---|---|
| Legal form | Directly applicable regulation | Directive transposed nationally |
| Sector | Financial entities and ICT suppliers | Many essential and important sectors |
| Supplier oversight | Direct EU oversight of critical providers | Supply chain duties on entities |
| Testing | Mandatory program and TLPT | Risk measures without TLPT mandate |
Typical pitfalls include an incomplete register of information, exit plans that exist on paper but were never tested, and incident thresholds applied inconsistently across business lines. Concentration on a single cloud provider is a further risk that DORA expects entities to assess and justify.
In plain words
DORA is a European law that makes banks, insurers, payment firms and other financial companies ready for computer problems and cyberattacks. They must plan for disruptions, test their defenses and report serious incidents quickly.
It also looks at the technology suppliers these companies rely on, such as cloud services. The weakest supplier can stop a whole bank, so the law makes financial firms check their suppliers closely and lets regulators supervise the most important ones directly.
A real-world example
A mid-sized payment institution discovers at 9:00 one morning that a failed software update at its card processing provider has stopped transactions for most customers. After two hours, the incident meets the institution’s criteria for a major ICT-related incident, and the team classifies it accordingly.
Within four hours of classification, the compliance officer submits the initial notification to the national authority. The provider restores service by evening, and the institution files an intermediate report within 72 hours with the timeline, customer impact and a preliminary cause. The final report a month later identifies missing rollback testing at the provider.
Using the audit rights in its DORA-compliant contract, the institution requires the provider to introduce staged deployments, and it updates its own exit plan with a tested backup processor. The next outage at the provider affects only a small share of transactions.