The Digital Operational Resilience Act across the EU
DORA is Regulation (EU) 2022/2554, and because it is a regulation and not a directive it applies directly in every member state, with no national transposition to wait for. It has been in force since January 17, 2025. For a firm with entities in several member states that is the useful part: one rulebook, one set of pillars, and national supervisors applying the same text.
Finance Loop covers the German supervision of it, BaFin and TIBER-DE, at DORA in Germany, and the short definition at the DORA regulation in the knowledge hub. What follows is the European frame: who falls in, what the five pillars require, how the oversight of the large providers works, and what the clocks are.
Who is in scope, and who gets a lighter version
The scope is wide on purpose. Credit institutions, payment institutions, electronic money institutions, investment firms, insurers and reinsurers, insurance intermediaries, institutions for occupational retirement provision, management companies, central counterparties, trading venues, central securities depositories, credit rating agencies, administrators of critical benchmarks and crypto-asset service providers are all financial entities under DORA. A firm that holds a MiCA authorization is therefore a DORA entity as well, which catches crypto firms that had not budgeted for an operational resilience program. Finance Loop covers that authorization at the CASP license.
Nobody in scope is exempt from the regulation, and some get a simplified framework. A microenterprise, fewer than ten staff and turnover or balance sheet total of no more than two million euros, follows a streamlined ICT risk management framework: a documented framework, monitoring of the systems, business continuity, identification of third-party dependencies, and lessons from tests and incidents fed back in. The simplification covers documentation, governance and testing. It does not cover incident reporting, which applies the same way at every size, and that asymmetry catches small firms that assumed the lighter regime was lighter throughout.
The five pillars, as the regulation names them
First, ICT risk management: a framework inside the firm's general risk management, covering identification of assets and dependencies, protection, detection, response and recovery, with the management body answerable for it. Second, management and reporting of ICT-related incidents: detect, classify against the regulation's criteria, manage, and report the major ones in three stages. Third, digital operational resilience testing: a risk-based program of vulnerability assessments and scenario tests, with threat-led penetration testing for the firms that reach the threshold, at least every three years. Fourth, management of ICT third-party risk: assess, document, monitor and contract for every provider, including the subcontractors behind it, with concentration risk and an exit arrangement in writing. Fifth, information and intelligence sharing: participation in trusted arrangements for exchanging cyber threat information, which the regulation permits and encourages without compelling it.
The pillar that produces the most work is the third-party one, because it reaches into contracts that were signed years before the regulation existed. The register of information is where that work becomes visible: every contractual arrangement for ICT services, with the function it supports, the provider, its subcontractors and whether the function is critical or important. Firms that treated the register as a reporting exercise found it was the inventory their third-party management had been missing.
The incident clocks: four hours, twenty-four, seventy-two, one month
The reporting sequence has three reports and four deadlines, and the first two run in parallel. The initial notification goes to the competent authority within four hours of the firm classifying the incident as major, and in any case no later than twenty-four hours after the firm detected it. The intermediate report follows within seventy-two hours of the initial notification. The final report is due no later than one month after the intermediate one.
The practical consequence sits in the classification step, not in the reporting. A clock that starts at classification rewards a firm that classifies quickly and punishes one whose process stalls, because the twenty-four-hour deadline from detection runs regardless. A firm that takes a day to decide whether an incident is major has used its entire window on the decision. The firms that handle this cleanly pre-agree the classification thresholds, name who may classify out of hours, and keep the notification template filled in to the point where only the facts of the incident are missing.
Clients have to be told as well, where the incident affects their financial interests. That duty is separate from the supervisory report and is the one that gets forgotten in the first hours.
Critical ICT third-party providers and who supervises them
DORA does something new in EU financial regulation: it reaches past the regulated firms to the providers behind them. A provider that the European Supervisory Authorities designate as a critical ICT third-party provider comes under a direct EU oversight framework, with a lead overseer appointed from among the ESAs. That overseer can request information, conduct investigations and inspections, issue recommendations, and the provider has to respond to them.
The designation follows from how much of the European financial system depends on the provider, which is why the large cloud platforms are the obvious candidates. For a bank, the consequence is indirect but real: a designated provider is being examined on the bank's behalf, and the bank still owns the dependency. The oversight does not transfer the risk. A bank whose core function runs on a designated provider has the same exit plan obligation as before, and the same difficulty producing one. Finance Loop covers that decision at sovereign cloud for banks and cloud computing in banking.
Threat-led penetration testing across member states
Threat-led penetration testing under DORA is a test against the live production environment, using threat intelligence about the actors that would plausibly attack this firm, conducted by testers who meet the regulation's independence and competence requirements. It is not an annual vulnerability scan, and it reaches the systems that support critical or important functions. Firms identified by their authority run it at least every three years.
The national frameworks sit underneath. TIBER-EU is the European framework the member states built their versions on, and Germany's TIBER-DE is the one a Frankfurt firm will deal with, covered at DORA in Germany. For a group spanning several member states the question is whether one test satisfies several authorities, and the answer depends on the entities and the functions in scope, agreed with the authorities before the test and not after it. Pooled testing across entities is permitted where the firms share the provider being tested.
What happens when a firm does not comply
DORA leaves the penalties to the member states, which is where the uniform rulebook stops being uniform. The instruments the national authorities have are administrative fines, orders to cease conduct or to remedy a breach, public statements naming the firm and the breach, and measures against the individual members of the management body. Several member states attach criminal liability under their own law.
For a designated critical provider the regulation sets its own figure: a periodic penalty payment of up to one percent of the provider's average daily worldwide turnover, applied daily until the provider complies with a request from its overseer. That is the number that gets a cloud platform's attention, and it is the clearest signal of what the oversight framework was built to achieve.
What DORA means for a crypto or DLT provider
A crypto-asset service provider authorized under MiCA is a financial entity under DORA, with the full framework behind that status. Two things make this harder than it is for a bank. The dependency stack is unfamiliar to the people writing the resilience framework: a node provider, an indexer, an oracle and a bridge are ICT third parties, and each needs the contractual terms, the monitoring and the exit arrangement that DORA requires. And some of those dependencies have no counterparty to contract with, because a public network has no legal entity to sign.
The workable approach treats the protocol dependency as a risk to be documented and mitigated, and not as a contract to be negotiated: redundancy across providers for the parts that are provider-shaped, and a documented position on what happens if the network itself fails for the parts that are not. Finance Loop covers the regime at MiCA in Europe and the authorization at the CASP license.
What is the Digital Operational Resilience Act?
The Digital Operational Resilience Act is Regulation (EU) 2022/2554, in force since January 17, 2025, which sets uniform requirements for the security of the network and information systems of EU financial entities and of the ICT providers serving them. It harmonizes what had been a patchwork of national guidance into one directly applicable text, and it adds an EU oversight framework over the providers that the financial system depends on most.
Who does DORA apply to?
To twenty categories of financial entity in the EU, from credit institutions and insurers to trading venues, central securities depositories, benchmark administrators and crypto-asset service providers, and to the ICT third-party providers serving them. There is no sector carve-out. A microenterprise follows a simplified ICT risk management framework and reports incidents the same way as a large bank.
How quickly does a major ICT incident have to be reported?
The initial notification goes out within four hours of classifying the incident as major, and at the latest twenty-four hours after detecting it. The intermediate report follows seventy-two hours after that notification, and the final report within one month of the intermediate. Where the incident affects clients' financial interests, the clients have to be informed as well, which is a separate duty from the supervisory report.
What is a critical ICT third-party provider?
A provider that the European Supervisory Authorities have designated as critical, because enough of the EU financial system depends on its services that a failure would be systemic. The designation puts the provider under direct EU oversight with a lead overseer, who can demand information, inspect, and issue recommendations, backed by a daily penalty payment of up to one percent of the provider's average daily worldwide turnover for non-compliance. The designation does not move the risk off the firms using the provider.
Does DORA replace the national cloud outsourcing rules?
For the ICT part, largely yes: DORA's third-party chapter is directly applicable and supersedes the national outsourcing guidance that covered the same ground, which is why firms spent the run-up to 2025 rewriting registers they had built under the older rules. What stays is everything the national rules cover that is not ICT, and the national authority's own supervisory practice in applying the regulation. A firm with entities in several member states still deals with several supervisors reading the same text.
Digital operational resilience and Finance Loop
Finance Loop is the meeting place in Frankfurt for the Risk & Compliance track, where the people who wrote their firm's register of information and ran their first threat-led test compare notes with the ones about to start. Finance Loop members hear how a supervisor actually read a submission, which no guidance document tells them. Finance Loop keeps the discussion on what was implemented and what the authority accepted.
Finance Loop is a professional network and has the goal of driving the adoption of emerging technologies in finance, such as AI, tokenization, stablecoins, and DeFi. Finance Loop helps its members build skills and personal networks in these fields: Investment & Digital Assets, Payments & Digital Money, Digital Infrastructure & Sovereignty, and Risk & Compliance.