DORA Is In Force: What the EU's Digital Operational Resilience Act Means for Third-Party ICT Risk

On January 17, 2025, the European Union's Digital Operational Resilience Act — DORA — became fully applicable. For the EU financial sector, it marked the end of a multi-year preparation period and the start of one of the most detailed and demanding third-party risk regimes ever written into law. For everyone else, DORA is worth understanding even if you are not directly in scope: it is the clearest signal yet of how regulators intend to govern the relationship between organizations and their technology vendors.

Where many regulations gesture vaguely at "managing third-party risk," DORA is explicit about what that means in practice. It tells financial entities exactly what to inventory, what to test, what to report, and what to put in their vendor contracts. That specificity is why DORA matters far beyond Frankfurt and Dublin.

What DORA Is

DORA is formally EU Regulation 2022/2554. It entered into force in January 2023 and became applicable on January 17, 2025. Its goal is to ensure that financial entities can withstand, respond to, and recover from information and communication technology (ICT) disruptions — whether those disruptions originate inside the organization or, increasingly, inside its technology suppliers.

The scope is broad. DORA applies to some 20 categories of financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, trading venues, and more — and, critically, it reaches into their ICT supply chain by establishing direct EU oversight of the most important technology providers serving the sector.

DORA is built on five pillars: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Two of those pillars — third-party risk management and resilience testing — are where DORA breaks the most new ground.

The Third-Party Provisions That Change the Game

1. The Register of Information

DORA requires every in-scope financial entity to maintain a comprehensive "register of information" documenting all of its contractual arrangements with ICT third-party service providers — at the individual, sub-consolidated, and consolidated levels. This is not a one-time exercise: the registers must be kept current and reported to supervisory authorities, with the first major reporting cycle taking place in 2025.

This single requirement forces a discipline that many questionnaire-driven programs never achieve: actually knowing, completely and accurately, who all of your technology vendors are and what they do for you. You cannot manage a vendor portfolio you have never fully inventoried.

2. Oversight of Critical ICT Third-Party Providers (CTPPs)

DORA's most novel feature is that it does not regulate only financial entities — it reaches their vendors. The European Supervisory Authorities can designate certain providers as Critical ICT Third-Party Providers (CTPPs) and place them under direct EU oversight, complete with a Lead Overseer empowered to make recommendations and request information. The intent is explicit: to address the systemic concentration risk that arises when a handful of major cloud and technology providers underpin much of the financial system.

3. Threat-Led Penetration Testing (TLPT)

DORA mandates a tiered program of digital operational resilience testing. For the most significant entities, this includes Threat-Led Penetration Testing — advanced, intelligence-driven red-team exercises modeled on the established TIBER-EU framework, to be performed at least every three years. Crucially, this testing can extend to the ICT third-party providers that support critical functions. DORA effectively codifies the principle that you cannot take a vendor's security on faith — resilience has to be demonstrated through real-world testing, not asserted in a document.

4. Mandatory Contractual Requirements

DORA specifies clauses that must appear in contracts with ICT providers supporting critical functions: clear service descriptions, data location and access provisions, incident assistance obligations, audit and access rights, cooperation with supervisors, and structured exit strategies. It also requires financial entities to assess and monitor subcontracting chains — pushing oversight beyond direct vendors into the fourth-party layer. This aligns closely with the contractual discipline we cover in our guide to vendor breach-notification obligations.

Why DORA Matters Even If You're Not a European Bank

It would be a mistake for a U.S. SaaS company or a mid-market manufacturer to dismiss DORA as someone else's problem. There are three reasons it reaches further than its formal scope.

First, it flows downhill through contracts. If you are a technology vendor serving any in-scope EU financial entity, your customers are now contractually obligated to impose DORA-aligned requirements on you — audit rights, incident cooperation, data provisions, exit support. You will feel DORA through your customers' procurement and vendor-management teams whether or not the regulation names you directly.

Second, it is a template. DORA represents the direction of travel for third-party risk regulation globally. The same themes — complete vendor inventories, concentration-risk awareness, demonstrated resilience, and contractual rigor — are appearing in regulatory frameworks across jurisdictions, part of the broader regulatory convergence reshaping the field. Building a program that could satisfy DORA is a reasonable way to future-proof against what is coming elsewhere.

Third, the requirements are simply good practice. Knowing every vendor you depend on, understanding your concentration exposure, testing resilience instead of assuming it, and writing strong contracts are not bureaucratic box-checking — they are the controls that would have blunted nearly every major supply chain breach of the past decade.

Getting Ahead of It

The organizations that adapted to DORA most smoothly were the ones that already had the fundamentals in place: a maintained vendor inventory, a tiering scheme that flagged providers supporting critical functions, contractual templates with the right clauses, and a way to express vendor risk in terms leadership could act on. The ones that struggled were those still treating TPRM as an annual questionnaire exercise.

You do not need an enterprise budget to build these foundations. The same capabilities DORA implicitly demands — a complete vendor register, risk tiering, concentration analysis, and quantified risk reporting — are exactly what a modern TPRM platform provides. DORA simply made them mandatory for one sector first. The rest will follow.