DORA explained: the EU's digital operational resilience rulebook

DORA is the Digital Operational Resilience Act, Regulation (EU) 2022/2554. It is the EU's directly applicable rulebook for keeping the financial sector running when its technology is under stress, and it has applied since 17 January 2025. Unlike a certification standard, there is nothing to get certified against: DORA is law, and the Articles plus their technical standards (the RTS and ITS) are the requirements.

That one difference trips a lot of teams up. There is no Annex A to pick from and no Statement of Applicability to sign off. What applies to you is driven by three things: your entity type, whether a given service supports a critical or important function, and your size tier. So the first real task is not writing policies, it is working out which obligations actually bite for you.

Who DORA covers

DORA reaches almost the whole financial sector: banks, insurers and reinsurers, investment firms, payment and e-money institutions, crypto-asset service providers, fund and asset managers, trading venues, credit rating agencies and more. If you are a financial entity operating in the EU, assume you are in scope until you have checked otherwise.

It also reaches the ICT providers that serve those entities. The ones the European Supervisory Authorities designate as critical fall under a dedicated EU oversight framework, with the supervisors able to look straight through to the provider.

The five pillars

• ICT risk management: a framework your management body owns and reviews, covering governance, identification, protection, detection, response and recovery, backup, learning and communication (Articles 5 to 16).
• Incident management and reporting: classify ICT-related incidents against set materiality criteria and report the major ones to your competent authority on a staged timeline (Articles 17 to 23).
• Digital operational resilience testing: a risk-based programme that covers every system supporting a critical or important function, plus advanced threat-led penetration testing for the entities that meet the thresholds (Articles 24 to 27).
• ICT third-party risk: keep a Register of Information on every ICT contract, assess concentration risk, hold the mandatory contract clauses, and have tested exit plans (Articles 28 to 44).
• Information sharing: a voluntary pillar that lets entities exchange cyber-threat intelligence with their peers (Article 45).

What a supervisor expects now

Because DORA already applies, the questions are no longer hypothetical. A competent authority will expect a documented ICT risk framework signed off by your management body, a complete and current Register of Information it can ask for at any time, and the ability to get an initial incident report out within hours of classifying something as major.

The organisations that are comfortable right now are the ones that stopped treating these as separate spreadsheets. The register feeds third-party risk, the incident classifier feeds reporting, the testing programme feeds the evidence, and one control set underneath maps across to ISO 27001, ISO 22301, NIS2 and NIST CSF so you are not doing the same work five times.

DORA is not a certificate you earn once. It is an operating state you have to stay in, and prove, every day.