What is DORA?

The full answer

DORA is Regulation (EU) 2022/2554, the EU's binding legal framework for ICT operational resilience across financial services. It applied from January 17, 2025 to a wide population: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, insurers, and more. More than 20 entity types are in scope. Proportionality provisions exist for microenterprises, but almost every regulated financial institution in the EU is covered.

The regulation has five pillars.

ICT risk management requires a board-approved framework with asset inventories, threat classification, and documented recovery procedures. This isn't an IT department concern; DORA explicitly places accountability at management-body level.

Incident reporting sets binding timelines. When a firm classifies an event as a major ICT-related incident, it has 4 hours to submit an early warning to the national competent authority, 72 hours for an intermediate report, and 30 days for a final root-cause analysis. The ESAs' classification thresholds, published as regulatory technical standards in January 2025, define what "major" means in practice.

Resilience testing requires basic tests at least annually for all in-scope firms, and Threat Led Penetration Testing (TLPT) every three years for firms designated as significant. TLPT uses the TIBER-EU framework and requires board authorization.

Third-party risk management is where DORA goes further than most prior guidance. Firms must register all ICT third-party contracts, include specific resilience clauses in new and renewed agreements, and assess concentration risk. Cloud infrastructure providers, core banking vendors, and managed security service providers are all covered. Critical Third-Party Providers face direct supervision by the European Supervisory Authorities under a new oversight regime.

Voluntary intelligence sharing lets firms exchange threat information with peers and regulators under a legal safe harbor.

On penalties: DORA Article 50(4)(b) sets a maximum of 2% of global annual turnover for non-compliant financial entities. Critical Third-Party Providers face periodic payments of up to 1% of average daily worldwide turnover for up to six months, imposed directly by the ESAs under Article 35.

The EBA's DORA hub tracks implementing technical standards and regulatory Q&A as they are finalized.

Why this matters

Before DORA, ICT resilience expectations came from supervisory guidelines. The EBA's 2019 Guidelines on ICT and Security Risk Management were authoritative, but not directly enforceable as binding law. DORA changed that. It's a directly applicable EU regulation, with specific timelines, defined penalty structures, and no need for member state transposition.

The 4-hour early warning deadline is aggressive. Most banks don't have automated incident classification, which means the clock starts running the moment a human makes a judgment call about severity. Firms that haven't built structured triage workflows face the same operational gap as those without automated tooling for sanctions screening: the manual process can't keep pace under pressure.

Third-party risk is the other immediate pressure point. Article 28 requires a complete register of ICT third-party contracts. This is now a standard item in regulatory examination preparation. Examiners reviewing ICT vendor registers alongside AML controls and governance documentation is already happening in practice.

DORA also applies to AI systems. Any AI model used in fraud detection, credit decisioning, or AML transaction monitoring is an ICT system under DORA. Resilience testing, incident reporting, and third-party oversight requirements apply to these models. That puts DORA in direct intersection with the EU AI Act, which began applying in phases from August 2024. Compliance teams at firms using AI in regulated processes are managing two overlapping EU frameworks simultaneously, and the governance requirements for each are not fully harmonized.

TLPT for significant institutions is expensive and operationally intensive. Exercises require a threat intelligence provider, a vetted red team, and board authorization. Results are confidential, but regulators can request access. Doing this under regulatory pressure after a supervisory finding is far harder than running a planned exercise.

The enforcement path for serious non-compliance follows the same track as other regulatory failures. A major ICT incident not reported on time, or a TLPT finding left unremediated, can escalate through the same process as an AML examination failure: public censure, fines, and in systemic cases, a monitorship.

Related questions

• What triggers a regulatory exam?
• Who needs to comply with the EU AI Act?
• When does the EU AI Act take effect?
• What happens when a bank fails an AML exam?
• What is a monitorship and when is one imposed on a bank?

Related concepts and regulations

• Can AI be used for AML transaction monitoring?
• How does sanctions screening work?
• What is perpetual KYC?
• How often should customer risk ratings be refreshed?