When IT Is Not Allowed to Fail: DORA and Digital Operational Resilience in Finance

The Hook: A Friday Afternoon When the Payments Freeze

Picture it: a Friday, just before 4 p.m. A mid-sized European bank rolls out a routine update to its core banking system — nothing dramatic, the kind of thing that happens every week. But this time the cloud storage system of the external provider that hosts the transaction database responds with a silent misconfiguration. Within minutes, transfers hang, card payments are declined, and online banking shows blank white pages. The provider does not sit inside the bank's building; it sits in a data center whose operator has customers all across Europe. The bank can do nothing but open a ticket and wait.

Before 2025, this would have been an internal drama, worked through in a post-mortem after the weekend. Since 17 January 2025, it is a cascade of regulatory obligations. The bank must classify the incident, decide whether it qualifies as "major," and then respect a strict clock: an initial notification to the competent authority within a few hours, an intermediate report within 72 hours, a final report within one month. It must be able to prove that its cloud contract contained exit clauses, audit rights, and security requirements. And if the cloud provider is large enough, it is now itself subject to direct supervision by a European authority — regardless of the fact that, formally, it is not a financial institution at all.

This is the world created by the Digital Operational Resilience Act — DORA for short, officially Regulation (EU) 2022/2554. DORA is the EU's attempt to cast an uncomfortable truth into law: a modern financial system is, at its core, an IT system. A bank's solvency is of no use to anyone if its data centers go dark, its service providers fail, or an attacker paralyzes its systems. Financial stability is inseparable from operational resilience — the ability to withstand ICT disruptions, absorb them, and recover from them.

For someone like Sven — a Senior AI Engineer with one foot in cloud architecture and one in IT security — DORA is relevant from two directions. As an engineer building systems for or with financial firms, DORA defines which evidence, contracts, and tests a product needs before it can go into production. And as a service provider, one suddenly becomes part of a supply chain whose regulatory weight at the very top — at the systemically important cloud providers — has grown so heavy that a dedicated, direct EU oversight regime was created for it. This article takes you the whole distance: from the basic idea through the five pillars, the principle of proportionality, and the oversight of critical third-party providers, to the timeline, the sanctions, and what actually happened in 2025/26.

Part 1: Why DORA? From Capital Buffers to Operational Capability

The old logic: money against risk

For decades, financial regulation revolved almost exclusively around financial risk. The Basel framework (Basel II/III), its European implementations, and supervisory practice all essentially asked: does a bank have enough capital to absorb losses from credit, market swings, or defaults? Operational risk — the risk of losses from faulty internal processes, people, systems, or external events — did exist in this world, but it was largely treated the way financial risk is treated: you backed it with capital. An IT outage was a potential loss item against which one held equity.

This logic has a blind spot. Capital helps when money is lost. It does not help when the problem is that the systems simply no longer run. A perfectly capitalized bank whose trading platform has been offline for four hours, whose customers cannot access their money, and whose reporting has failed does not have a capital problem — it has an operational-capability problem. And in a world where payments happen in milliseconds, where trading runs algorithmically, and where a single cloud provider can serve hundreds of financial firms simultaneously, this operational-capability problem has become a systemic risk.

The patchwork before

Before DORA, European regulation of digital resilience was a patchwork. There were guidelines from the European Banking Authority (EBA) on outsourcing management and ICT security, sector-specific rules for insurers, national supervisory requirements such as Germany's BAIT/VAIT, and a mass of overlapping, sometimes contradictory demands. A financial firm operating across borders had to observe slightly different rules in each member state. This was expensive, inconsistent, and left open precisely the gap that carried the greatest risk: the third-party providers. Whoever outsourced a critical function to a cloud provider thereby shifted a risk that the individual supervisor could barely reach anymore, because the provider lay outside its jurisdiction.

The legal nature: a regulation, not a compromise

DORA was adopted on 14 December 2022 and entered into force on 16 January 2023. Its legal form is decisive: DORA is a regulation, not a directive. An EU regulation applies directly and uniformly in all member states, without first having to be transposed into national law. This distinguishes DORA fundamentally from the NIS2 Directive, whose concrete shape varies from country to country and whose transposition has been delayed in many states. Under DORA, in essence, the same text applies everywhere. After a two-year preparation phase, DORA has been applicable since 17 January 2025 — without the staggered transition periods the EU AI Act uses. From the cut-off date, the full catalogue of obligations applied.

The core idea: resilience instead of perfection

DORA's central conceptual turn is this: you cannot prevent failures, so you must learn to survive them. DORA does not demand that systems never fail — that would be naive. It demands that a financial firm always knows which ICT risks it carries, that it detects and reports disruptions quickly, that it regularly tests whether its defenses actually hold, that it keeps its providers' risks under control, and that it learns from the incidents of others. From this turn follow the five pillars that form the core of the regulation.

Part 2: The Scope — Who Is Affected

Before we reach the pillars, it is worth looking at whom DORA actually applies to — because the scope is deliberately broad. DORA covers roughly twenty categories of financial entities: credit institutions (banks), payment and e-money institutions, investment firms, trading venues, central counterparties, central securities depositories, management companies, insurance and reinsurance undertakings, insurance intermediaries, crypto-asset service providers, credit rating agencies, crowdfunding service providers, and more. From the global conglomerate to the small payment institution, practically the entire regulated financial sector falls under it.

At the same time — and this is the real innovation — DORA covers the ICT third-party providers of these firms. Cloud providers, data-center operators, software houses, providers of data-analytics and security services: as soon as they deliver critical ICT services to financial firms, their contracts, their security commitments, and their fault tolerance become the object of regulation. The largest and most systemically important among them are even placed under direct European supervision (more on this in Part 5). And the scope reaches beyond the EU's borders: a provider based outside the EU that delivers critical services to an EU financial firm can likewise be drawn into the regulatory pull.

Part 3: The Five Pillars in Detail

You can picture DORA as a building on five pillars. Each pillar addresses a different aspect of operational resilience; together they carry the roof of operational capability.

Pillar 1: ICT risk management — responsibility moves upward

The first pillar requires a comprehensive, documented framework for ICT risk management: the financial firm must identify its information- and communication-technology assets, protect them, detect disruptions, respond to them, and recover from them. These five verbs — identify, protect, detect, respond, recover — are no accident; they mirror the structure of established security frameworks such as the NIST Cybersecurity Framework, so a firm already working to such standards will meet something familiar here.

Perhaps the most important and sharpest innovation of this pillar concerns not the technology but responsibility. DORA assigns ultimate responsibility for ICT risk management expressly to the management body — the board, the executive management. Cyber resilience is thereby explicitly a matter for the top, not something to be delegated to the IT department and then forgotten. Management must approve the framework, oversee it, and — this is the tender spot — possess sufficient knowledge of its own to be able to assess ICT risks at all. I am of the opinion that this upward shift of responsibility is the culturally most powerful provision of the entire regulation, because it lifts ICT security out of its niche and turns it into a boardroom question.

Pillar 2: Incident reporting — the clock is ticking

The second pillar harmonizes how ICT-related incidents are recorded, classified, and reported. The first step is always classification: is an incident "major"? Technical standards define criteria for this, such as the number of affected clients, the duration and geographic spread of the disruption, data loss, and economic impact. Only when an incident crosses these thresholds does the reporting duty bite in full — and then a strict clock begins, with three stages:

• Initial notification: within four hours of classification as major, and no later than 24 hours after becoming aware of the incident. Classification itself must occur without undue delay — so you cannot stop the clock by deliberately declining to classify an incident.
• Intermediate report: within 72 hours of the initial notification, with updated details — even if nothing has changed in the status.
• Final report: within one month of the intermediate report, with root-cause analysis, remediation measures, and an impact assessment.

Reports run through harmonized templates defined in technical standards (RTS 2025/301 and ITS 2024/2956), so an incident in Frankfurt is reported in exactly the same structured way as one in Dublin or Milan. Late or omitted reporting is a sanctionable breach. For engineering practice, this pillar means above all one thing: the technical ability to quickly detect an incident, determine its scope, and document it cleanly is no longer optional; it is the precondition for meeting a statutory deadline at all. Whoever only knows after three days how many clients were affected has long since missed the 4-hour deadline.

Pillar 3: Resilience testing — from vulnerability scan to red team

The third pillar requires a financial firm not merely to claim its digital resilience, but to test it regularly. At the basic level, this means an annual program of vulnerability assessments, security evaluations, network security reviews, and similar measures for all affected firms.

For the most significant institutions, however, DORA goes considerably further and requires Threat-Led Penetration Testing (TLPT) at least every three years. TLPT is no ordinary pen test. It is a structured, intelligence-led red-team attack that examines whether an institution's detection and response capabilities actually work under realistic attack conditions. The decisive features: the test is based on genuine threat intelligence produced by an external threat-intelligence provider; it runs against live production systems and critical functions, not a test environment; and it can even bring critical third-party providers into its scope.

TLPT was not invented from nothing. It builds on the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming), developed by the European Central Bank, and effectively casts it into binding law for the designated institutions. The difference from a classic pen test is also one of scope: whereas a pen test usually examines a bounded part of a system, TLPT targets the organization's entire defensive chain — people, processes, and technology alike. For security engineers this is the pillar that shapes the profession most directly, because it turns "security" from an assertion into a recurring, measurable proof.

Pillar 4: Third-party risk — the heart of DORA

If DORA has one pillar that sets it apart from everything that came before, it is the fourth. It addresses exactly the gap the old patchwork left open: the risk that arises when a financial firm outsources critical ICT functions to third parties. The core obligations are concrete and incisive.

First, every financial firm must maintain a register of information — a complete, structured overview of all contractual arrangements with ICT third-party providers. This register is to be submitted to the competent authorities annually (in practice by 31 March). It forces firms to know, in the first place, whom they depend on — a question that, before DORA, astonishingly many could not answer cleanly.

Second, DORA prescribes minimum contractual content for agreements with ICT third-party providers. Contracts covering critical or important functions must, among other things, contain clear service descriptions, data-protection and security requirements, audit rights (the financial firm and the supervisor may inspect), rules on subcontracting, and — especially important — exit strategies. A financial firm must be able to prove that it can leave a provider in an orderly fashion in an emergency and migrate or replace the function without the operation collapsing. With this, DORA attacks the problem of lock-in head-on: a critical dependency with no escape route is simply no longer permissible under DORA.

Third, the firm must keep an eye on concentration risk. If a single cloud provider carries several critical functions, or if half the industry uses the same provider, a systemic cluster risk arises that DORA wants to make visible and limit.

Pillar 5: Information sharing — the voluntary pillar

The fifth pillar is the lightest. It encourages financial firms to share threat information within trusted communities — indicators of attack, tactics, techniques, and procedures of adversaries. The idea is simple: cyberattacks rarely strike only one target; what hit one bank yesterday hits the next one tomorrow. If institutions share their findings, the resilience of the whole industry rises. Unlike the other four pillars, information sharing is voluntary — DORA creates the legal framework and the permission, but obliges no one to take part.

Part 4: The Principle of Proportionality

At this point a legitimate question arises: should a small payment institution with fifteen employees really deploy the same apparatus as a globally systemic mega-bank? DORA answers this with the principle of proportionality. The obligations are meant to stand in proportion to a firm's size, risk profile, and complexity.

Concretely, DORA provides a simplified ICT risk-management framework for small and non-interconnected firms. And the most demanding instrument, threat-led penetration testing (TLPT), applies in any case only to the institutions expressly designated for it by the authorities on the basis of their significance — not to everyone. Proportionality is therefore not a loophole but a deliberate calibration: the regulation's severity should be greatest where the potential harm to the financial system is greatest. Even so, a noticeable core of obligations remains for smaller houses — the basic idea that ICT risk is a matter for the top, and that you must know your providers, applies to all.

Part 5: The Oversight of Critical ICT Third-Party Providers — DORA's Sharpest Sword

Here DORA becomes genuinely novel in regulatory terms. Until now, a financial supervisor could only ever reach the supervised financial firm itself, not its suppliers. If a thousand banks use the same cloud provider and that provider has a problem, that is a systemic risk — but the provider itself had been invisible to financial supervision. DORA closes this gap by placing the most significant providers under direct European oversight.

The designation: who becomes "critical"?

The three European Supervisory Authorities (the ESAs: EBA for banking, ESMA for capital markets, EIOPA for insurance) assess ICT third-party providers and designate the systemically important ones as Critical ICT Third-Party Providers (CTPPs). Article 31(2) of DORA names four criteria that work together: the systemic importance of the financial firms depending on the provider, the degree of the provider's substitutability, its cross-border activity, and the degree of its interconnectedness with the financial sector. A provider must satisfy all relevant criteria, not just one.

In November 2025 the ESAs published the first list of designated CTPPs: 19 providers were named and have since been subject to direct EU oversight. Among them are the big names one would expect — the leading cloud hyperscalers and several specialized IT and data-service providers. Notable about the first round is the cloud concentration: a substantial share of the 19 CTPPs are generic cloud-infrastructure providers, and the supervisors have pointed out that a large portion of EU financial firms run critical functions on several of the major cloud providers. This very cluster risk was one of the main reasons DORA created third-party oversight in the first place.

The Lead Overseer and its powers

For each CTPP, one of the three ESAs is appointed as Lead Overseer — roughly by sector focus: the EBA for banking-oriented providers, ESMA for capital-markets and post-trade, EIOPA for insurance-specific providers. The Lead Overseer examines whether the CTPP has appropriate risk-management and governance structures in place to ensure the resilience of its services. It can request information, conduct investigations and on-site inspections, and issue binding recommendations.

And here lies the sharpest sword: if a CTPP does not follow these recommendations, the Lead Overseer can impose periodic penalty payments — up to 1% of the provider's average daily worldwide turnover, for each day of non-compliance, over a period of up to six months. For one of the world's largest cloud providers, that is a number with considerable deterrent potential. For the first time, then, a European authority can give a global technology corporation direct instructions on operational security, with financial force — not via the detour of the financial customer, but immediately.

For 2026 — the year in which this article is written — the phase of the first comprehensive examinations has begun; for several providers the first binding recommendations are expected over the course of the year. DORA has thus moved from a rulebook into lived supervisory practice.

Part 6: Timeline and Sanctions

The timeline

The sanctions

DORA largely leaves enforcement against financial firms to the national competent authorities (in Germany, BaFin), which impose effective, proportionate, and dissuasive sanctions. The orders of magnitude are considerable: for breaches, financial firms can face fines that, in serious cases, are keyed to a percentage of worldwide annual or daily turnover; for individual responsible persons and smaller entities, fixed maximum amounts in the millions come into play. For the CTPPs, the periodic penalty payments already mentioned apply — up to 1% of average daily worldwide turnover.

More important than the raw number is the systematics: DORA sanctions not only the successful attack or the spectacular outage, but already the absence of the required structures — a register not kept, a contract without an exit clause, a missed reporting deadline, a test not run. You can therefore incur DORA fines without a single customer ever having noticed an outage. This is deliberate: the regulation wants to compel resilience before the emergency arrives, not to settle accounts only after the fact.

Part 7: DORA in Context — Neighbors in the Regulatory Web

DORA does not stand alone. It is part of a whole wave of European digital regulation, and its family relationships help place it.

The nearest neighbor is the NIS2 Directive, which regulates cybersecurity for "essential" and "important" entities across many sectors — from energy through health to digital infrastructure. Here the principle lex specialis derogat legi generali applies: DORA is the more specific law for the financial sector and takes precedence over NIS2 within its scope. A financial firm fulfills its sector-specific resilience obligations through DORA, not NIS2. Whoever has understood the logic of NIS2 will recognize in DORA the same underlying idea — reporting duties, risk management, responsibility of the leadership — only in a form tailored to the financial sector, directly applicable, and unusually detailed.

Also interesting is the substantive proximity to post-quantum cryptography: DORA's demand for continuous ICT risk management also captures the long-term risk that today's encryption will be broken by future quantum computers — a risk known under the label "harvest now, decrypt later." And DORA's incident-and-threat logic maps directly onto microarchitectural attack classes such as Spectre and Meltdown, where a seemingly harmless hardware optimization became a systemic weakness. Not least, DORA's demand for uninterrupted operational capability touches the very distributed systems whose consensus and time mechanisms are treated elsewhere in the vault.

Cross-References in the Vault

• NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany — the nearest relative in the regulatory web; DORA as lex specialis of the financial sector.
• The Pyramid of Risk: How the EU AI Act Tames Artificial Intelligence – and Why It Concerns the Whole World — another risk-based EU digital law, the same regulatory philosophy.
• Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer — a long-term risk that DORA's ICT risk management must also cover.
• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution — how an optimization becomes a systemic weakness.
• How Machines Come to Agree: Distributed Consensus from FLP to Paxos to Raft — the technical foundation of the fault tolerance that DORA demands in regulatory terms.
• Clocks That Know Their Own Uncertainty: Google Spanner, TrueTime, and Mastering Time in the Cloud — cloud infrastructure and consistency, the technical bedrock beneath the third-party pillar.

The Central Takeaway

If you take a single thing from this article, take this: DORA shifts the question from "Is the system secure?" to "Can you prove you will survive a failure — and do you know whom you depend on to do it?" Resilience is not a property you establish once, but one you continuously demonstrate — through documented risk-management structures, through fast and honest incident reports, through real tests against real production systems, and through a supply chain you can exit in an orderly way when it matters.

For daily engineering practice, this means very concretely: treat observability, incident documentation, and exit capability not as tiresome compliance appendages but as first-class design requirements. A system that cannot quickly say how many users a disruption affects cannot meet a 4-hour deadline. An architecture that clamps onto a single provider with no escape route is no longer buildable under DORA. And a team whose leadership delegates ICT risk to "IT" has missed the regulation's core cultural message. DORA, read correctly, is less a bureaucratic discipline than an engineering one: it forces you to build resilience in from the start, rather than to assert it after the fact.

Reflection Question

DORA makes exit capability from a critical dependency an obligation — a financial firm must be able to leave a cloud provider in an orderly way in an emergency. Think of a system you are working on right now, or one you know: if your most important external provider failed tomorrow, or you had to leave it for regulatory reasons — how long would the migration take, and do you even know that precisely enough to prove it to a supervisor?

Sources

• Application of the Digital Operational Resilience Act (DORA): Key considerations – DLA Piper
• Five Pillars Explained: Digital Operational Resilience Act (DORA) – Bizzdesign
• The European Supervisory Authorities designate critical ICT third-party providers under DORA – European Banking Authority
• Designation of critical ICT third-party providers under DORA: What does it mean for regulated firms? – DLA Piper
• DORA Incident Reporting: 4h/72h/1M Timelines & Templates – regulation-dora.eu
• DORA Threat-Led Penetration Testing (TLPT): Articles 26–27 Requirements – financialregulations.eu
• DORA act penalties, regulation, and compliance framework – Avenga

← All articles