DORA Compliance: The Operational Playbook for 2026

If you are a bank, insurer, investment firm, payment institution or crypto-asset service provider operating in the European Union, DORA compliance is no longer a project with a deadline ahead of it — the Digital Operational Resilience Act has applied since 17 January 2025, and 2026 is the year supervisors stop asking whether you have a policy and start asking whether it works. The Act rewires how financial entities govern technology risk, report incidents, test their defences, and — the part most firms underestimate — manage the third parties and cloud providers that now sit underneath nearly every critical function. The genuine exposure for 2026 is not the ICT risk-management framework most firms drafted in 2024. It is the register of information and the concentration-risk obligations buried in the third-party pillar.

DORA is a regulation, not a directive, which matters more than it sounds. It applies directly and uniformly across all 27 member states without national transposition, so there is no local watering-down, no implementation gap to exploit, and no "we're waiting for the UK-style guidance" excuse. The European Supervisory Authorities — the EBA, ESMA and EIOPA, collectively the ESAs — have spent the period since application publishing and refining the technical standards that turn the Act's principles into line-item obligations. Those standards are where the operational work lives.

What DORA compliance actually requires

DORA compliance means demonstrating, on demand and with evidence, that your financial entity can withstand, respond to and recover from all types of ICT-related disruption and threats. The Act covers roughly twenty categories of regulated financial entity — credit institutions, payment and electronic-money institutions, investment firms, insurers and reinsurers, crypto-asset service providers under MiCA, central securities depositories, trading venues, and more. Proportionality is built in: a small payment institution is not held to the same testing intensity as a globally systemic bank, and "microenterprises" get meaningful carve-outs. But the core obligations are universal.

The Act is structured around five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information and intelligence sharing. Each pillar is fleshed out by Regulatory Technical Standards and Implementing Technical Standards. Treating DORA as a documentation exercise is the common failure mode. The regulation is explicitly outcomes-based — a board-approved framework that nobody operationalises will not survive contact with a supervisor reviewing your incident-response timeline after a real outage.

The governance hook is sharp. DORA places ultimate responsibility for ICT risk on the management body — the board and senior executives — not on the CISO or a head of operational risk who can be quietly blamed. Directors must approve the ICT risk-management framework, allocate budget to it, and keep their own knowledge current. That personal-accountability angle is what should be driving 2026 board agendas, and in many firms it still isn't. The shift it forces is cultural as much as procedural: a non-executive director who once treated technology risk as a matter for the audit committee's appendix now has to be able to interrogate it directly, because the supervisor can interrogate them.

Pillar one: ICT risk management, beyond the framework document

The first pillar requires a comprehensive, documented ICT risk-management framework covering the full lifecycle: identification of all ICT-supported business functions and the assets behind them, protection and prevention, detection of anomalous activity, response and recovery, and learning and evolving. Most firms produced this document in 2024. The 2026 test is whether the asset inventory underneath it is real.

You cannot protect what you have not mapped. DORA expects a current, granular inventory of information assets and ICT assets, with the dependencies between them and the business functions they support made explicit. That includes classifying which functions are "critical or important" — a defined term that triggers heavier obligations across testing, third-party management and incident reporting. Getting the critical-or-important classification wrong cascades through every other pillar, because it determines which contracts need the full DORA clause set and which systems face threat-led penetration testing.

Detection and response capabilities have to be more than a SIEM licence. Supervisors will look for defined mechanisms to detect anomalous activity, alerting thresholds that escalate appropriately, business-continuity and disaster-recovery plans that are tested rather than filed, and backup and restoration procedures with restoration objectives that someone has actually proven. Legacy mainframe estates are notoriously hard to fail over on demand, which is precisely the kind of fragility the Act is built to surface — and it is no coincidence that the firms furthest along on the move to cloud-native core banking tend to find recovery testing far less painful, because their platforms were designed to be torn down and rebuilt rather than nursed.

Pillar two: incident reporting on a clock that punishes ambiguity

DORA standardises how financial entities classify and report major ICT-related incidents, and the timelines are tight. The classification criteria — drawn from the relevant RTS — turn on factors such as the number of clients affected, the duration and geographic spread of the disruption, data losses, the criticality of the services hit, and economic impact. Once an incident clears the "major" threshold, a three-report cadence kicks in: an initial notification, an intermediate report as the situation develops, and a final report with root-cause analysis once the incident is closed.

The operational problem is the initial-notification window. It is measured in hours from the moment you classify an incident as major, not from when you finish investigating it. Firms that have not pre-built the reporting workflow — the templates, the decision tree for classification, the named individuals who can authorise a submission outside business hours — will miss the window during the exact event that draws supervisory attention. You do not want to be designing your incident-classification logic at 2 a.m. during a live outage.

DORA also opens the door to voluntary reporting of significant cyber threats, and it harmonises reporting so that a firm operating across several member states is not duplicating notifications into incompatible national templates. The direction of travel — and the ESAs have signalled this — is toward a single EU reporting hub over time. For 2026, the practical task is dry-running the classification decision against last year's actual incidents to see which would have tripped the major threshold, then timing how fast your team could have filed. That exercise tends to be sobering: the gap between "we have a procedure" and "we can execute it inside the window with the right person awake" is usually wider than the programme team assumed.

Pillar three: resilience testing and threat-led penetration testing

Every in-scope entity must run a digital operational resilience testing programme proportionate to its size and risk profile: vulnerability assessments, scans, gap analyses, penetration testing, and tests of business continuity and recovery. That baseline is annual for critical systems. The headline obligation, though, applies to the larger and more systemically important firms: threat-led penetration testing, or TLPT.

TLPT under DORA is modelled closely on the TIBER-EU framework that several European central banks already ran, and it is a different animal from a routine pen test. It uses real threat intelligence to simulate the tactics, techniques and procedures of genuine adversaries, against live production systems, with a "red team" attacking while only a small "white team" inside the firm knows the exercise is underway. Tests must be conducted at least every three years by qualified, independent testers, and critically, the scope has to include the ICT third-party providers that support critical or important functions — your testing cannot stop at your own perimeter when the function lives in someone else's cloud.

That third-party scoping is where TLPT collides with commercial reality. Bringing a hyperscaler or a critical SaaS vendor into a live red-team exercise requires contractual cooperation rights that many legacy agreements simply do not contain. Firms that signed cloud contracts before DORA without right-to-test clauses are now renegotiating from a weak position. Building the testing calendar for 2026 means first confirming which providers are in scope, then confirming you have the contractual standing to test them. A mature RegTech stack earns its keep here as a tracking layer, mapping which obligations attach to which provider — but no tooling can manufacture a right to test that the underlying contract never granted.

Pillar four: the third-party register and the obligation firms keep underestimating

The fourth pillar is the one that quietly decides whether your 2026 supervisory engagement goes smoothly or badly. DORA's third-party risk management obligations require financial entities to maintain a complete register of information on all contractual arrangements for the use of ICT services, and to keep it current. This is not a vendor spreadsheet. The ESAs prescribe the register's structure in granular detail through a dedicated Implementing Technical Standard, with a defined data model, standardised templates and specific reference codes — including the requirement that each provider be identified by a Legal Entity Identifier (LEI) and that the supply chain be mapped down through subcontractors who support critical or important functions.

The reason firms underestimate this is that it looks like an administrative task and is actually a data-engineering one. The register must distinguish arrangements that support critical or important functions from those that do not, capture the chain of subcontracting, and reconcile cleanly against your contract repository and asset inventory. National competent authorities have already been collecting these registers, and incomplete or internally inconsistent submissions are a visible, early supervisory red flag — precisely because they reveal a firm that does not actually know what its technology supply chain looks like. If your register and your asset inventory disagree about which systems are critical, you have surfaced exactly the blind spot DORA was written to expose.

Beyond the register, the pillar mandates a hard set of contractual provisions for any arrangement supporting a critical or important function: full access, inspection and audit rights for the firm and its supervisors; clear service-level descriptions with measurable targets; data location and processing terms; cooperation in TLPT; assistance during incidents; and — the one that triggers the most painful renegotiations — executable exit strategies, with documented and tested plans to move off the provider without disrupting the business. Pre-DORA cloud contracts almost universally lack a workable exit clause, and writing one that genuinely functions rather than merely aspires is hard. Embedded-finance arrangements inherit the same problem in a less obvious form: a firm building customer-facing products on a banking-as-a-service partner's rails is, in DORA's eyes, leaning on an ICT third party whether or not it files the relationship under that heading. We traced where those rails are heading in our work on B2B embedded finance; the regulatory tail attached to them is exactly this clause set.

The oversight regime: cloud concentration risk goes supranational

Reaching past the regulated firm to its suppliers is the structurally novel move DORA makes. It establishes a Union-level oversight framework for ICT third-party providers designated as "critical" — Critical Third-Party Providers, or CTPPs. The hyperscale cloud platforms, and a small number of other systemically important technology vendors, are being designated as CTPPs and brought under direct oversight by a Lead Overseer, one of the three ESAs, with powers to issue recommendations, conduct inspections, request information, and to levy penalties for non-cooperation. This is the first time EU financial regulators have supervised unregulated technology suppliers directly rather than only through the firms that buy from them.

The motivation is concentration risk, and it is not hypothetical. A large share of European financial-services workloads runs on a very small number of cloud providers. When one of those providers has a regional outage, it does not take down one bank — it can degrade payments, trading and core banking across dozens of institutions simultaneously, turning an idiosyncratic vendor failure into a systemic event. The 2024 CrowdStrike incident, which grounded flights and froze systems globally from a single faulty software update, was a vivid demonstration of exactly the single-point-of-failure dynamic the CTPP regime is designed to monitor. DORA cannot ban concentration, but it can make supervisors see it and require firms to plan for it.

For an individual financial entity, the practical consequence is that you must now assess and document concentration risk in your own ICT estate: how much of your critical capability depends on a single provider, a single region, or a single technology, and what your realistic options are if that dependency fails. Stacking critical workloads on one hyperscaler without a credible multi-region or multi-cloud contingency is now a documented governance decision your board owns — and a question a supervisor is entitled to ask. There is a quiet pull toward exactly this kind of concentration: when speed wins deals, as it does in the fast-credit decisioning behind modern AI underwriting, teams default to whichever cloud platform their models already run on, and the dependency deepens without anyone formally choosing it.

Pillar five: information sharing, the one most firms ignore

Lightest in obligation and easiest to neglect, the fifth pillar is also the cheapest to satisfy — which is why so many evidence packs leave it blank. DORA explicitly permits — and encourages — financial entities to share cyber-threat intelligence among themselves: indicators of compromise, tactics, techniques and procedures, alerts and tools. It does this within trusted communities and with safeguards for the protection of commercially sensitive and personal data, removing some of the competition-law and liability anxieties that historically made firms reluctant to share what they were seeing.

This is voluntary, not mandatory, which is exactly why it tends to fall off the programme. But the firms that join sectoral information-sharing arrangements — and document that participation — gain two things: earlier sight of threats actually circulating against European financial institutions, and a defensible position that they took reasonable, current steps to inform their defences. For 2026, the low-cost move is to formalise participation in an existing threat-sharing community rather than building anything new, and to record how that intelligence feeds your detection and risk processes. It is the cheapest pillar to satisfy and the one most likely to be empty in a firm's evidence pack.

The 2026 DORA compliance checklist

Pull the year's work into a sequence a board can actually track. First, fix the register of information. Validate every entry against the prescribed ITS data model, confirm LEIs for all providers, map subcontractors that support critical or important functions, and reconcile the register against both your contract repository and your asset inventory until they agree. This is the single highest-value piece of work and the most common point of failure.

Second, re-run the critical-or-important classification across all business functions, because that classification drives testing scope, contractual requirements and reporting thresholds — get it wrong and everything downstream is wrong. Third, audit your ICT contracts for the mandatory DORA clauses, prioritising access and audit rights, exit strategies, and TLPT cooperation, and schedule renegotiation for the gaps. Fourth, dry-run incident classification and reporting against real incidents from the past year, time your initial-notification workflow, and name the people who can file out of hours.

Fifth, build the resilience-testing calendar, confirming whether you are in TLPT scope and, if so, whether you hold the contractual standing to test in-scope third parties. Sixth, document concentration risk across cloud providers, regions and technologies, with board sign-off on the residual exposure. Seventh, formalise threat-intelligence sharing. The firms that will have an uncomfortable 2026 are not the ones missing a policy document — those are easy to write. They are the ones whose register of information cannot survive a supervisor cross-referencing it against the systems that actually run the bank. Start there, because that is where the questions will start.