DORA Third-Party Risk Requirements for Financial Entities

DORA (Regulation EU 2022/2554) became directly applicable on 17 January 2025, and it covers roughly 22,000 financial entities across 20 entity types in the EU, from banks and insurers to investment firms. The regulation is a Regulation, not a Directive, so it applies the same way in every member state with no local watering-down of the core rules. Its third-party risk provisions, Articles 28 through 30, are where most firms are failing right now, and the gap between a program that looks compliant on paper and one that actually holds up under supervisory review comes down to how precisely those articles are read and executed.

DORA closes a gap that existed for years: operational resilience got treated mainly as a capital question, something banks solved with buffers and reserves, while the actual plumbing, the cloud contracts, the outsourced payment processors, the subcontracted data centers, sat outside formal risk governance. The regulation also reaches past EU borders. Non-EU ICT providers serving EU-regulated entities fall inside the framework through their clients' Article 28 duties, and providers formally named as critical face direct oversight from the European Supervisory Authorities regardless of where they're based, with a requirement to stand up an EU subsidiary within 12 months of that designation.

DORA supersedes NIS2's cybersecurity risk management and reporting rules for financial entities. There's also a live intersection with the EU AI Act: Article 9(10) of the AI Act allows AI risk management duties to be folded into risk procedures already required under other EU law, which can mean DORA's ICT risk framework does double duty.

The penalties are where this stops being an abstract compliance exercise. Financial entities face fines up to 10% of annual global turnover or €10 million for serious breaches. Critical ICT providers face periodic penalty payments up to 1% of average daily worldwide turnover. And individual senior managers can be held personally liable for up to €1 million, separate from whatever the institution pays. Some member states set higher ceilings: Italy allows up to €20 million or 10% of turnover, Ireland up to €10 million or 10% of turnover. For anyone running a compliance program, the personal liability piece changes the calculus. A register that's technically filed but full of gaps is a career problem. It's a career problem.

Where third-party risk sits inside DORA's five-pillar structure

DORA is built on five pillars: ICT risk management (Articles 5 to 16), incident management and reporting (Articles 17 to 23), digital operational resilience testing (Articles 24 to 27), ICT third-party risk management (Articles 28 to 30), and information sharing arrangements (Article 45). Pillar four, the third-party piece, carries the highest rate of compliance gaps found in supervisory assessments, and it represents the biggest operational lift for most regulated firms.

The incident reporting timeline lives in Pillar 2, but it reaches directly into how third-party risk gets managed. Firms have to notify regulators within four hours of classifying an incident as major, and major incidents must be reported in full within 72 hours. That means a firm needs pre-defined classification criteria and vendor notification service levels baked into contracts well before an incident happens, not drafted afterward under pressure. Article 30 picks this thread back up later.

Pillar 3, resilience testing, also touches third-party risk directly. Testing critical functions requires proof that third-party dependencies have actually been stress-tested, not just written down in a policy document somewhere. A firm that treats Pillar 4 as its own island, disconnected from incident timelines and resilience testing, still has a structural hole in its compliance posture even if the third-party paperwork looks complete.

What Article 28 requires across the full third-party lifecycle

Article 28(1) sets the foundation: ICT third-party risk has to be managed as a core part of the entity's overall ICT risk framework, not run separately as a procurement function that occasionally talks to risk management. Proportionality applies: the extent and manner of managing that risk should match the entity's size, complexity, and how important its operations are. But proportionality governs how a firm does this, never whether it does this.

Every entity except microenterprises and those under the simplified framework in Article 16(1) must adopt a documented strategy for ICT third-party risk and review it regularly. That strategy needs a multi-vendor approach where it makes sense, and it has to apply at the individual, sub-consolidated, and consolidated levels of the group.

The lifecycle obligations inside that strategy are each their own requirement, not a menu to pick from. Pre-contractual due diligence has to happen before engagement, not as a formality after the ink is dry. Contracts need the mandatory clauses Article 30 spells out. Monitoring has to run continuously, not as a periodic check-in every few quarters. Firms have to submit their Register of Information annually. Exit strategies need to be documented and tested for every arrangement supporting a critical or important function. And sub-outsourcing needs active governance: the financial entity stays responsible for what its provider's providers do downstream.

Exit strategies are the weak link. A 2025 DORA compliance survey found that only 28% of financial entities had tested exit plans in place by the application date, making it the least mature obligation across the whole regulation. That number says something about how firms have approached this so far: due diligence at onboarding gets attention because it's visible and it's the first gate. What happens after, the continuous monitoring, the tested exit plan, the ongoing sub-outsourcing oversight, gets far less. Article 28 doesn't distinguish between the first step and the rest of the lifecycle. Satisfying one and ignoring the others is non-compliance with extra paperwork attached. It's non-compliance with extra paperwork attached.

Article 29 concentration risk: what it requires before signing a contract with a critical provider

Article 29 requires a formal concentration risk assessment before a financial entity signs any contract for a critical or important function. The assessment has to answer three specific questions. Can this provider be replaced without major disruption if the relationship breaks down? Does the entity already have exposure to the same provider, or one closely connected to it, through other arrangements, stacking risk without anyone noticing? Is the subcontracting chain behind this provider complex or opaque enough that the entity can't actually monitor what it's paying for?

Sub-outsourcing depth isn't a hypothetical. A 2025 ECB supervisory review found that significant credit institutions average 2.7 sub-outsourcing layers for critical ICT services, with some chains reaching five tiers. A single vendor relationship carries four layers of exposure, often invisible to whoever signed the original contract.

Commission Delegated Regulation (EU) 2025/532, in force since 22 July 2025, spells out what a financial entity has to determine and assess before letting a provider subcontract a service that supports a critical or important function. Fourth-party risk, in other words, is written into a binding technical standard rather than a matter of internal judgment. It's written into a binding technical standard.

The practical trap here is hidden concentration. It's about hidden concentration: an entity might contract with three or four vendors it considers separate, only to find they all route through the same underlying infrastructure node. That kind of exposure can already be a breach of Article 29 even if nobody drew it that way on an org chart. And because the concentration assessment has to happen before the contract is signed, there's no fixing this after the fact with an amendment. A pre-contractual failure stays a failure.

Article 30 mandatory contract provisions: the baseline set and the enhanced set for critical functions

Article 30 sets two tiers of required clauses. Every ICT contract needs a baseline set: a full description of the services being provided, the locations where data gets processed and stored, service level agreements with both quantitative and qualitative targets, notice periods and reporting duties for material changes, and incident notification requirements that line up with DORA's reporting clocks.

Contracts supporting a critical or important function need more on top of that baseline: enhanced provisions covering audit rights, access arrangements, and continuity planning. These are the mechanism by which a supervisor can later confirm the entity actually has the leverage it claims to have over a critical vendor. They're the mechanism by which a supervisor can later confirm the entity actually has the leverage it claims to have over a critical vendor.

Firms still running legacy contracts with critical vendors that predate January 2025 carry real enforcement exposure the next time a supervisor comes calling. Every contract renewal from 2025 onward has to carry the full Article 30 provision set before signature, which makes retroactive remediation of the existing book of contracts the most urgent task on most compliance calendars right now.

Scale is the real obstacle. Financial institutions often manage well over a thousand ICT-related contracts each, so this is a legal operations and data management exercise, not a matter of rewriting a clause template. It's a legal operations and data management exercise, one that touches procurement systems, legal archives, and vendor relationships that in some cases nobody has revisited in years.

Germany's BaFin acknowledged that not every contract had been brought into line with DORA by the January 2025 deadline, and it called the first year a "year of transformation." That grace period is closing. That grace period is closing, and supervisory tolerance for outstanding contract remediation is narrowing across member states.

None of this works as a static exercise, either. The incident notification and material-change clauses in Article 30 only function as controls if someone is actually watching vendor behavior against them. A clause sitting in a signed PDF that never gets triggered, never gets tracked, is a sentence. It's a sentence.

The Register of Information: what it is, what it requires, and why it is failing at scale

The Register of Information is mandated under Article 28(3) and structured by Implementing Technical Standard ITS 2024/2956. National competent authorities submit it to the ESAs annually by 30 April, with entity-level deadlines set nationally, usually falling in the first quarter of the year.

It helps to be precise about what this actually is. It's a machine-readable xBRL-CSV dataset that supervisors use to map ICT concentration risk across the entire EU financial sector, spotting patterns no single firm could see on its own. It is a machine-readable xBRL-CSV dataset, not a vendor inventory. It is a machine-readable xBRL-CSV dataset that supervisors use to map ICT concentration risk, not a risk register in the internal-audit sense. It is not a procurement database. Firms that treat it as any of those things tend to fail the data quality checks, because the Register demands a level of structural precision those internal documents were never built to provide.

The failure rate in the early rounds was stark. In the 2024 ESA dry-run exercise, only 6.5% of the nearly 1,000 participating firms passed all 116 data quality checks. The failure rate across data quality checks was high, reflecting how poorly most firms' internal records mapped to the Register's structural requirements. EBA implementation monitoring found that 41% of financial entities said they had trouble compiling a complete register by January 2025, mostly because procurement records were fragmented and IT arrangements had grown informally over time, outside any central tracking system. EBA's DORA implementation progress survey put between 60% and 70% of EU financial institutions at "work in progress" status on their Register as of the January 2025 deadline, with only about 30% holding a complete register. Industry monitoring found 46% of financial entities naming the Register the single hardest DORA requirement to meet, pointing to inconsistent vendor metadata, incomplete contract inventories, and confusion over who owns subcontractor and intra-group ICT relationships.

The second annual submission cycle wrapped in March 2026, and the 2025 pilot round exposed something firms already suspected: most lacked the data infrastructure needed to produce complete, accurate submissions.

None of this is really a reporting problem. It's a data infrastructure problem. Nobody can submit accurate regulatory data about vendor relationships they don't maintain continuously, and the Register punishes exactly that gap. A firm that cannot produce a complete, accurate Register almost certainly cannot produce a tested exit strategy for its critical function arrangements either, which overlaps directly with Article 28. Both failures trace back to the same root, a lack of continuously maintained, centralized vendor data.

Critical ICT Third-Party Provider designation and its meaning for firms that use them

In November 2025, the ESAs published the first list of designated Critical ICT Third-Party Providers, 19 in total, including Amazon Web Services, Google Cloud, Microsoft, Oracle, SAP, and Deutsche Telekom. These providers now sit under direct EU oversight: annual risk assessments, on-site inspections, and mandatory reporting, all run by the supervisors rather than left to client due diligence alone.

The ESAs' joint committee set the designation criteria around systemic impact, substitutability, and how heavily significant financial entities rely on the provider. Each designated CTPP gets a Lead Overseer, the ESA carrying the largest aggregate exposure to that provider, whose Article 33 duties include assessing the provider's ICT risk management across nine areas (security requirements, physical security, governance, incident handling, testing, and related domains) and conducting supervisory oversight.

On 15 July 2025, the ESAs published a guide on DORA oversight activities laying out how Joint Examination Teams actually conduct CTPP reviews. It isn't legally binding, but it signals how oversight plays out in practice. The same day, the ECB published its final guide on outsourcing cloud services, setting out its expectations for banks using third-party cloud infrastructure. That guide sits alongside DORA's binding requirements and addresses cloud-specific practices for supervised institutions.

For financial entities relying on a designated CTPP, the consequences are concrete. A Lead Overseer can require a provider to fix deficiencies, and remediation at the provider level can force changes onto every financial-entity client downstream, whether or not that client asked for them. At that point concentration risk becomes a regulatory concern rather than a purely operational one, since supervisors are now cross-referencing entity-level Article 29 assessments against CTPP oversight findings directly. Non-EU CTPPs also have to stand up an EU subsidiary within 12 months of designation, and entities relying on them should be tracking that clock closely, since it isn't automatic.

How enforcement has shifted in 2026 and what regulators are checking

The posture in 2026 is interventionist. Regulators are asking for compliance evidence, not remediation plans, and the framing of DORA's first year as a grace period is over. BaFin's own language moved from calling 2025 a "year of transformation" to signaling, in January 2026, that on-site inspections will intensify and contract remediation needs to finish fast.

What that means in practice: supervisors checking Article 30 compliance are pulling actual contracts and matching them against the mandatory clause list, not accepting a policy document that says the firm intends to comply. Register of Information submissions are being run through the same data quality checks that failed a substantial majority of firms in the 2024 dry run, and a second failed cycle carries more weight than a first one did. Firms holding legacy contracts with critical vendors, especially designated CTPPs, are the most exposed group heading into supervisory reviews, because the gap between what the contract says and what Article 30 requires is now something an examiner can spot in minutes.

The throughline across every section here is the same: DORA rewards continuous, evidenced practice and punishes documentation built to look complete at a single point in time. Exit strategies that were never tested, registers built from fragmented spreadsheets, contracts frozen in older language, these are all the same failure wearing different clothes. The entities treating Articles 28 through 30 as a living operational discipline, rather than a filing exercise, are the ones that will hold up when the next Joint Examination Team or national supervisor comes asking for evidence instead of intentions.