What Is DORA: Operational Resilience Rules for Finance

Illustration for: What Is DORA, Operational Resilience Rules for Finance

For decades the European financial system has run on companies no financial regulator could touch. A bank’s core ledger, its payments processing, its trading connectivity and increasingly its entire infrastructure sit with technology suppliers who held no banking licence and answered to no supervisor. When one of them failed, the regulator could only question the bank, which would explain, accurately and uselessly, that the problem was somebody else’s outage. The Digital Operational Resilience Act is the EU’s decision to stop supervising the map and start supervising the territory.

What DORA is and who it catches

DORA is Regulation (EU) 2022/2554. It entered into force in January 2023 and has applied since 17 January 2025, so at the time of writing the industry is past the compliance deadline and into the harder business of living with it. Because it is a regulation rather than a directive, it applies directly in every member state with no national transposition, which means no local variations to arbitrage and no waiting for domestic legislation.

The scope list runs to around twenty categories of financial entity. Banks, insurers and reinsurers, investment firms, payment and e-money institutions, fund managers, trading venues, central counterparties, crypto-asset service providers and more. Proportionality is built in, with lighter expectations for microenterprises and a simplified risk framework for the smallest firms, but the direction is unmistakable. If you are regulated as a financial entity in the EU, DORA almost certainly applies to you.

The genuinely novel part is the other half of the scope. DORA also reaches the ICT providers themselves. Suppliers whose failure could shake the sector can be designated as critical third-party providers and placed under direct oversight by the European Supervisory Authorities, with a lead overseer, inspection powers, and periodic penalty payments of up to one per cent of average daily worldwide turnover for non-cooperation. The cloud providers that half of European finance runs on were, for the first time, brought inside the regulatory perimeter. That is the change everything else hangs from.

The five pillars

The regulation organises its requirements into five areas, and the structure is worth learning because every DORA conversation is really about one of these.

Infographic of a roof labelled DORA supported by five pillars for risk, incidents, testing, vendors and intelligence sharing

The five pillars as five duties. The first four are mandatory, the fifth is encouraged, and the fourth is the one that changed the industry.

ICT risk management. Entities need a documented framework covering identification, protection, detection, response and recovery, owned explicitly by the management body. Not delegated to a supplier, not outsourced to a consultancy’s binder. The board carries it, and the board can be held to account for it.

Incident reporting. ICT incidents must be classified against set criteria, and major ones reported to the competent authority on a tight cadence, an initial notification within hours of classification, an intermediate report as the picture firms up, and a final report with root cause. Readers of an earlier post in this series on NIS2 reporting will recognise the pattern, staged reports on clocks that are far too short to design mid-incident.

Resilience testing. Every entity needs a testing programme, from vulnerability scanning upward. Significant entities must run threat-led penetration testing every three years, aligned with the TIBER-EU framework, with real adversary simulation against live production systems. This is a long way beyond an annual pentest of the customer portal.

Third-party risk. Contracts with ICT providers must contain specified provisions on access, audit, exit and subcontracting, concentration risk must be assessed before signing, and every arrangement must be recorded in a register of information. More on that register below, because it deserves its own section.

Information sharing. The one voluntary pillar. Entities are encouraged to exchange threat intelligence within trusted communities. It is the least discussed pillar and, in my view, the one that will quietly compound in value while nobody is watching.

The register that told firms who they really were

The register of information is a complete inventory of every contractual arrangement for ICT services, mapped to the business functions it supports, flagged for criticality, with the subcontracting chain recorded beneath each provider. Regulators began collecting registers in spring 2025, and the exercise was widely described as painful. That description misses the point.

The pain was diagnostic. Firms discovered contracts nobody owned, fourth parties nobody had heard of, and critical functions resting on a single supplier’s single data centre. A register that is embarrassing to compile is a register that needed compiling. This series has argued before that security and compliance data is a target map of your organisation, and the register is exactly that, which is also why it deserves careful custody. But the map is worth drawing, because you cannot defend dependencies you have not written down, and before DORA most firms genuinely had not.

What this means for UK organisations

DORA is EU law and the UK has not adopted it, but a UK firm can still be caught three ways. The first is through EU subsidiaries or branches that are themselves in scope. The second is by providing ICT services to EU financial entities, whereupon your customers’ DORA obligations arrive by contract. The third is through group policies that adopt DORA as the single standard, because running two frameworks is worse than running the stricter one everywhere.

The UK’s own answer is recognisably parallel and philosophically different. The FCA and PRA operational resilience regime asks firms to identify their important business services, set impact tolerances for disruption, and demonstrate they can stay within them, with the transition period having ended in March 2025. It is outcome-led where DORA is prescriptive. Alongside it, the critical third parties regime created under the Financial Services and Markets Act 2023 gives UK regulators their own power to oversee designated suppliers directly. The two systems rhyme, and a firm straddling both should build once to the stricter requirement rather than twice to each.

The honest counterarguments

The compliance burden is real and unevenly felt. A tier-one bank absorbs DORA into existing programmes. A fifty-person fund manager faces the same five pillars with a fraction of the resources, and proportionality clauses soften this less than their drafters hoped. The costs are certain and immediate, the benefits diffuse and delayed.

Paperwork is not resilience. A firm can hold a beautiful register, a tested framework and a folder of contractual clauses and still fall over, because documents do not fail over, systems do. The risk of DORA becoming an evidence-production industry is genuine, and anyone who lived through accreditation regimes has seen that movie.

Overlap creates friction. Financial entities were already touched by NIS2, national outsourcing rules and sector guidance. DORA takes precedence for finance as the more specific law, but untangling which regime governs which obligation has consumed real legal budget that built no resilience at all.

These deserve honest answers rather than dismissal. The burden argument is strongest, and the best response is that DORA mostly mandates things a well-run firm needed anyway, an incident process, tested recovery, known dependencies. The paperwork risk is a choice. Firms that treat the register as a dependency management tool get value from it, and firms that treat it as a filing obligation get filing.

Where this lands

Come back to that opening picture, the regulator who could see the bank but not the technology the bank actually runs on. DORA closes that gap from both ends, obligations on the firms and oversight of the suppliers, and whatever you think of the drafting, the underlying judgement is sound. A financial system that depends on a handful of technology providers should know that it does, should write the dependency down, and should decide deliberately what to do about it. That is all DORA really demands, dependency by dependency, in a register with your name on it. A firm that knows exactly who it runs on, and has chosen its exposures with its eyes open, has made a decision. A firm that finds out during an outage has made one too, just not deliberately, and DORA exists because far too much of the sector was in the second camp.