DORA explained in 8 minutes (without the legalese)
DORA is the EU's answer to a simple question: when a bank's payments app goes down because an outsourced cloud vendor had an incident, who is accountable? Since 17 January 2025, the answer is unambiguous — the bank is. And the bank now has to prove, with paperwork, that its vendors are up to the job. That paperwork is what arrives in your inbox.
What DORA actually is
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is a single rulebook that covers how financial entities in the European Union manage technology risk. It replaces a patchwork of national rules and EBA/EIOPA guidelines with one binding text that applies the same way in Dublin, Frankfurt, Madrid and Helsinki.
The word "regulation" matters. Unlike a directive (which each country translates into its own law), a regulation is law on the day it enters into force. There is no Irish DORA or German DORA — just DORA. The Central Bank of Ireland, BaFin, the AMF and the other supervisors are tasked with enforcing the same text.
Who it applies to
Two broad groups, and the boundary between them is where most of the confusion lives.
Financial entities — the obvious targets. Banks, insurance companies, investment firms, asset managers, payment institutions, e-money institutions, crypto-asset service providers, credit rating agencies, central counterparties, trading venues. Around 22,000 entities across the EU fall in this bucket. They must comply directly: governance, risk framework, incident reporting, testing, the lot.
ICT third-party service providers— and this is where you, the SaaS founder, come in. DORA does not regulate you directly (with one exception we'll get to), but it forces your financial customers to push the entire framework down to you through contract. If you sell hosting, observability, data analytics, AI, KYC tooling, payroll, anything that touches a regulated entity, you will see DORA in your next renewal.
The exception: providers that supervisors classify as Critical Third-Party Providers (CTPPs)— typically the hyperscalers — fall under direct EU oversight via the Joint Oversight Framework. AWS, Microsoft, Google, IBM and a handful of others have been designated. If you're reading this article, you are almost certainly not a CTPP.
The five pillars, in plain language
The regulation has five thematic chapters. Knowing what each one asks of you helps decode any vendor questionnaire — every question maps back to one of these.
1. ICT risk management (Art. 5–16)
The entity must have a documented framework for identifying, protecting against, detecting, responding to and recovering from ICT risks. The board has to sign it. The CISO has to maintain it. As a vendor, you'll be asked to show that your own risk framework is mature enough to plug into theirs.
2. Incident reporting (Art. 17–23)
Major ICT-related incidents have to be reported to the competent authority within tight deadlines — an initial notification within 4 hours of classification, then intermediate and final reports. As a vendor, you need to be able to notify your financial customer fast enough that they can meet their own deadline. Most contracts now demand notification within 2 hours of you detecting a major incident.
3. Digital operational resilience testing (Art. 24–27)
Annual tests of critical systems. The largest entities also have to do threat-led penetration tests (TLPT) every three years, run against a real production environment by certified red teams. If you operate a system that supports a critical function for a large bank, expect to be in scope of their TLPT — which means someone with a contract will, lawfully, try to hack you.
4. ICT third-party risk (Art. 28–30)
The chapter that produces the most paperwork. The entity must maintain a Register of Information listing every ICT vendor (Art. 28), classify which functions are critical or important (Art. 28 again), include specific clauses in every contract (Art. 30), and have an exit plan for each critical vendor. We have a full article on Article 30 — most of the work landing on vendors comes from this chapter.
5. Information sharing (Art. 45)
Voluntary, lower-stakes: entities can join sector-wide threat-intelligence sharing arrangements. This rarely shows up in vendor questionnaires; mention it here only for completeness.
The deadlines that actually matter
| Date | What happens |
|---|---|
| 17 Jan 2025 | DORA enters into force. Everything above is now law. |
| 30 Apr 2025 | First Register of Information due to national supervisors, in xBRL-CSV format. ~94% of dry-run submissions failed. |
| Q3 2025 → ongoing | Vendor renegotiation wave. Banks start sending Article 30 contract addenda to every ICT supplier. |
| Q1 2027 | Next annual RoI submission cycle. By now the bar will be higher and supervisors will reject for less. |
What this means for you, concretely
If you sell ICT services into the EU financial sector, three things are likely to happen in the next six months:
- A bank or insurer client sends you a questionnaire of 30–80 questions covering governance, security, BCP, sub-outsourcing and exit. They want it back in two weeks.
- Their procurement team sends a contract addendum amending your existing MSA to add Article 30 clauses. You have to sign or renegotiate.
- They ask whether your sub-processors are EU-resident and whether you can guarantee data does not leave the EEA.
None of this is optional for them, so it stops being optional for you. The good news is that 80% of the answers don't change between clients — answer once, reuse forever.
Where to go next
Read DORA Article 30: the contract clauses your bank will demand to understand what lands in your inbox next. If you're on the financial-entity side and dreading the RoI deadline, the xBRL-CSV guide is for you.
This article references Regulation (EU) 2022/2554 of the European Parliament and of the Council, published in the Official Journal on 27 December 2022. Article numbers cited are from the consolidated text. Nothing here is legal advice — confirm with a qualified compliance officer or counsel before acting.