DORA’s register of information made every bank a data supplier to EU oversight of its vendors

The week

The EU Digital Operational Resilience Act, adopted in 2022, applied from January 17, 2025. It covers a wide range of financial entities operating in the EU, including banks, insurers, investment firms, payment and e-money institutions and crypto-asset service providers. It sets requirements in five areas: ICT risk management, ICT-related incident reporting, digital operational resilience testing, management of ICT third-party risk, and information sharing. Under the third-party rules, firms must keep a register of information on all contractual arrangements with ICT third-party service providers, in a standardized format set by technical standards. National supervisors collected the first registers in the spring of 2025 and passed them to the European Supervisory Authorities. DORA also created an EU oversight framework for ICT providers designated as critical to the financial sector, with designation based in part on that register data.

Earlier articles in this series covered DORA’s contract requirements, where the constraint was the renewal calendar, and its incident classification standards. The register of information was the piece most firms underestimated. It looked like a compliance template. In practice it was a dataset, submitted in a fixed format, that supervisors would combine across the whole EU financial sector. The European Supervisory Authorities would use it to see which providers the sector depended on and to designate critical ICT providers for direct oversight. A firm’s register was no longer only its own record. It was an input to a system-wide map.

That changed the standard of quality. A register good enough to show an examiner is not necessarily good enough to aggregate. Three data problems stood in the way, and they map to the three things the register records about each arrangement: what the arrangement is and who provides it, which business functions depend on it, and which other companies sit behind the provider. Together they define the register’s content, and each problem is distinct.

Identity: every arrangement, every provider, one identifier

The register covers all contractual arrangements for ICT services, not just large technology contracts. That includes software licenses, cloud services, data feeds, managed services and services provided by other entities in the same group. Many firms found arrangements their vendor management systems had never captured: departmental subscriptions, ICT services bundled inside broader outsourcing contracts, and intragroup services never written up as contracts at all.

Aggregation adds a second requirement: the same provider must be identified the same way by every firm. The standards relied on identifiers such as the legal entity identifier. Vendor master records, built for paying invoices, often held trading names, regional subsidiaries and reseller names instead. One global cloud provider could appear under a dozen names across a group. Cleaning that data was tedious and essential. Keeping it clean needed a process change, so that new arrangements entered the register at purchase, with the identifier, instead of months later.

Dependency: linking arrangements to critical functions

DORA asks firms to identify which arrangements support critical or important functions, and the register records that link. A function is critical or important if its disruption would materially impair the firm’s financial performance, soundness or continuity, or its regulatory compliance.

This is where procurement data meets business operations. Procurement holds contracts. Business units know which services they cannot run without. Business impact analyses gave some firms a head start, but they usually described applications, not the third-party services underneath them. Linking a function to an application, the application to its hosting and support arrangements, and those arrangements to providers was often the slowest part of the work. It also exposed disagreements about which functions were critical at all, which only senior management could settle.

The link has uses beyond compliance. The same mapping drives incident classification, exit planning and resilience testing. A firm that builds it once, in a maintained system, serves all three.

Ownership decides whether the link stays current. Applications are retired, services move between providers and functions are reorganized. If the register team learns of these changes only at the annual refresh, the mapping decays within months. The practical fix is to make the link a required field in the change processes that already exist: architecture review for new applications, procurement approval for new contracts and decommissioning checklists for retirements. Each of those steps then updates the register as a side effect, without a separate data call.

Depth: the subcontracting chain behind each provider

For arrangements supporting critical or important functions, the register asks about subcontractors that effectively underpin the service. A software vendor may host on a large cloud provider and use another firm for support. A failure anywhere along that chain can stop the function.

Many firms found they did not know their vendors’ material subcontractors, and that vendors were not always willing or able to say. DORA gave firms a regulatory reason to ask, and contract terms requiring disclosure of material subcontractors and notice of changes became standard requests. This is where concentration appears. Different vendors often rely on the same few cloud and infrastructure providers, so a firm with ten apparently independent suppliers may depend on two hyperscalers underneath them. Supervisors aggregating registers see that pattern across the sector. Firms should see it first in their own data. A simple query, counting critical functions by the ultimate infrastructure provider beneath each vendor, is often the most revealing single output of the whole register effort.

The register’s logic reaches U.S. institutions too. EU subsidiaries of U.S. banks, asset managers and payment firms fall under DORA, and U.S. technology vendors serving EU clients have felt it through contracts. The function-mapped, subcontractor-aware view of third parties is also what U.S. interagency guidance on third-party risk implies, even without a prescribed format.

With hindsight

The aggregation use arrived on schedule. On November 18, 2025, the European Supervisory Authorities published the first list of critical ICT third-party providers under DORA, saying they had first collected data from financial entities’ registers of information. Their assessment weighed systemic importance, support for critical or important functions and substitutability. Reported designations included major cloud and platform providers. Those providers became subject to direct oversight by a lead supervisor, a new layer in EU financial regulation built in part on data that individual firms had supplied. In the United States, no equivalent register rule emerged, and third-party expectations continued to run through guidance and examination. For EU firms, the register had become a standing data obligation, refreshed and resubmitted, rather than a one-time project.