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

The week

On Friday, January 17, 2025, a European law that had been on the books for more than two years finally started to bite for thousands of financial firms.

The EU Digital Operational Resilience Act, known as DORA, was adopted in December 2022 as Regulation (EU) 2022/2554, entered into force in January 2023 and applied from January 17, 2025. Its purpose is to make sure the financial system can keep running when technology fails, whether from a cyberattack, a software fault or a supplier going down. As a regulation rather than a directive, it applied directly in every member state without national transposition.

Who it covered and what it required

DORA covers a wide range of financial entities operating in the EU, about twenty types in all. They include banks, insurers, investment firms, payment and e-money institutions, asset managers, market infrastructure 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. ICT stands for information and communication technology, the European shorthand for everything from software and data centers to networks and cloud services.

For the financial sector, DORA took precedence over the EU’s general cybersecurity directive, NIS2, which member states had been due to transpose by October 2024. Smaller firms got a lighter ICT risk framework under DORA’s proportionality rules, but the third-party register applied across the board.

The fourth area, third-party risk, is about the outside companies a firm relies on for its technology. Under those 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. Firms in a group keep it at entity level and at sub-consolidated and consolidated levels. The result is a detailed, structured list of every technology supplier, what each one provides and which parts of the business depend on it. Every firm fills it in the same way, so that the lists can be combined.

A format settled late

The format arrived late. The ESAs had drafted the templates in early 2024, but the Commission sent them back that September, chiefly over how providers should be identified. The ESAs responded in October, and the final implementing rule was adopted only at the end of November 2024. The final rule allowed providers to be identified by a legal entity identifier or, for some EU providers, by the European Unique Identifier used in business registers.

Firms therefore had weeks, not months, to finalize data against the settled templates. A voluntary dry run the ESAs organized in 2024 had already shown many submissions failing automated data quality checks. Submissions used a machine-readable format, xBRL-CSV, so files with missing or malformed fields could be rejected automatically.

A separate technical standard on subcontracting ICT services that support critical functions had not been finalized when DORA applied. Firms began with a register whose rules on supply chains were still being argued over.

Where the data went

The common format let supervisors combine the lists. National supervisors collected the first registers in the spring of 2025 and passed them to the European Supervisory Authorities, the three EU-level bodies that oversee banking, insurance and securities markets. In a December 2024 public statement the ESAs had urged firms to prepare, and in February 2025 they published a roadmap for designating critical providers later that year.

And DORA did something new with that data. It created an EU oversight framework for ICT providers designated as critical to the financial sector, with designation based in part on that register data. The lists firms submitted would help regulators decide which large technology companies, such as major cloud providers, were so important to European finance that they should be supervised directly. Each designated provider would have one of the three ESAs as its lead overseer, with powers to request information, inspect and issue recommendations.

The criteria were set in the regulation and a 2024 delegated act. They covered the systemic impact of a provider’s failure, how many systemically important firms rely on it, how many critical functions it supports and how hard it would be to replace. Most of those inputs came straight from the registers.

The same month elsewhere

The United Kingdom took a different route. Its own critical third parties regime, created by the Financial Services and Markets Act 2023, took effect on January 1, 2025. Under it, HM Treasury designates providers and the Bank of England, PRA and FCA oversee them. It did not rest on a standardized register submitted by every firm. In the United States, third-party expectations continued to run through the banking agencies’ 2023 interagency guidance and their examination of service providers.

For a bank’s board, the week’s message was subtle but important. The supplier list in the back office had just become part of a continent-wide map, and the accuracy of that map depended on each firm’s homework.

Of DORA’s requirements, the register of information was the piece most firms underestimated.

It looked like a compliance template: a spreadsheet-like set of tables to fill in and hand over. 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 had become an input to a system-wide map as well as its own record.

That changed the standard of quality. A register good enough to show an examiner is not necessarily good enough to aggregate. An examiner reading one firm’s list can ask questions and fill gaps in conversation. A computer combining thousands of lists cannot. If one bank writes a supplier’s name one way and another bank writes it differently, the computer sees two suppliers.

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.

The article first sets out why supervisors wanted the map and how they combine it. It then takes identity, dependency and depth in turn. The remaining sections cover how the work gets done inside a firm and how it differs by type of firm. They follow one bank’s experience, then weigh what a good register buys, how registers decay and a short test for your own.

Why regulators want a map of suppliers

Modern finance runs on a small number of very large technology companies. A bank’s mobile app, its payments processing, its fraud detection and its trading systems may each come from a different vendor, but those vendors often run on the same handful of cloud platforms underneath.

A cloud platform is a company that rents out computing power, storage and software over the internet from huge data centers, so customers do not have to own and run their own machines. The largest of these are often called hyperscalers because of their scale. Renting from them is usually cheaper and more reliable than running your own. But if many banks rent from the same one, a single outage could affect many banks at once.

This is concentration risk. No single bank can see it, because each bank sees only its own suppliers. A regulator that combines everyone’s supplier lists can. That is why DORA’s register is standardized, and why its quality matters beyond any one firm.

A town’s water supply shows the problem. If every household in a town reports which water supplier it uses, the town can see that most homes depend on one reservoir. But only if everyone spells the reservoir’s name the same way, and only if the households that buy bottled water from a company that also draws from that reservoir say so.

What supervisors do with the combined file

The mechanics are simple to describe and hard to do well. Each firm submits its register in a machine-readable format. Automated checks reject files with missing mandatory fields or malformed codes. Accepted files are then matched on provider identifiers, so that every firm’s arrangements with the same provider can be counted together.

From the matched data, supervisors can count how many firms rely on a provider and how many of those firms are systemically important. They can see how many critical or important functions the provider supports, and what firms themselves said about how hard it would be to replace. Those are, almost word for word, the designation criteria DORA sets out.

The same data also lets supervisors look below the famous names. A core banking platform, a market data service or a managed security firm may serve hundreds of smaller institutions. No single one of them is a household name, but a failure would hit many firms at once. Only aggregated, well-identified registers make those mid-tier concentrations visible.

Why the firm cannot opt out of quality

A firm’s register is now judged against its peers. If most banks report a dependency on a given provider and one bank does not, the gap is visible. If a firm reports a service as easy to replace that every peer calls hard to replace, the answer invites questions. A firm’s data is no longer only its own record; it is a contribution to a shared picture that others can check.

Problem one, identity: every arrangement, every provider, one identifier

The register covers all contractual arrangements for ICT services, small ones as well as 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. An intragroup service is one provided by another company in the same corporate family, such as a parent company’s data center serving its European subsidiary. Because it feels internal, it often has no formal contract, yet DORA treats it as a supplier relationship.

Scope edges

Firms spent real time on edge cases. A payment network, a market data terminal, a telecoms line or a software component embedded in a hardware product can each be argued either way. Some answers came from supervisors’ published questions and answers; many were left to firms’ own documented judgment.

The defensible approach is consistency. A firm that writes down its scope rules, applies them across every entity in the group and records the reasoning for borderline cases can explain its register. A firm that decided case by case, in different teams, cannot.

Getting identifiers right

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, or LEI. An LEI is a 20-character code that uniquely identifies a legal entity worldwide.

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. Accounts payable does not care whether an invoice came from a brand name or a regional subsidiary, as long as it gets paid. A regulator mapping concentration cares a great deal.

The identifier itself has mechanics worth knowing. LEIs are issued by accredited local operating units under the Global LEI Foundation and must be renewed each year; a lapsed code still identifies the entity but signals stale reference data. The public LEI database also records parent relationships for many entities. That lets a firm roll a regional subsidiary up to its ultimate parent, which is the level at which concentration matters.

Resellers create a different trap. A firm may contract with a local partner for licenses of a global vendor’s software. The contract counterparty and the provider of the underlying service are then different companies. Recording only the reseller hides the real dependency; recording only the vendor hides the contract. The register needs both, linked.

Some providers, especially small ones, did not have an LEI at all. Firms had to ask them to get one, or use the alternative identifiers the standards allowed. Either way, the request became part of onboarding.

Keeping identity clean

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. The best time to capture a supplier’s identity is the moment someone asks to buy from them.

A monthly reconciliation keeps the gap small. Compare new payees in accounts payable and corporate card data with new register entries, and chase the differences. Most unregistered arrangements show up as payments before anyone thinks to record them.

Problem two, 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. Paying customers, settling trades and meeting reporting obligations are typical examples.

This is where procurement data meets business operations. Procurement holds contracts. Business units know which services they cannot run without. The two rarely share a system.

Business impact analyses gave some firms a head start, but they usually described applications, not the third-party services underneath them. A business impact analysis is a standard exercise in which each part of the business records what it needs to keep working and how long it could survive without it. It might say “the payments team depends on the payments platform.” It rarely says which hosting provider, support firm and data feed that platform depends on.

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. Settling them is a governance decision, not a data task, and it belongs at the executive table.

Intragroup services, written down

Intragroup services need the same treatment as external ones. The useful record names the group entity that provides the service, the services it provides, the functions they support and the terms under which they run. Where no contract exists, a service description agreed between the entities, with notice and exit terms, gives the register something real to point to. It also gives the EU entity’s management a basis for overseeing a service it does not control.

The judgment fields

The register also asks firms for judgments about each service supporting a critical function. These include how hard the provider would be to replace, whether an exit plan exists, whether the service could be brought back in-house and what discontinuing it would do. These fields feed straight into the supervisors’ assessment of substitutability.

They are also where firms are most tempted to be optimistic. Marking a service “easily substitutable” reduces the apparent need for an exit plan. Supervisors comparing answers across firms can see when one firm rates a service as trivial to replace while its peers call it very hard. An honest answer, backed by a short rationale, is safer than a convenient one.

The judgment fields connect to other DORA duties. Firms need exit strategies for services supporting critical functions. Before contracting for such services, they must assess whether the arrangement adds to concentration risk. A register that holds these judgments consistently becomes the evidence that those assessments happened.

One map, several uses

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. When a supplier has an outage, the firm can see in minutes which functions are affected. When it plans to leave a supplier, it knows what it must move. When it tests its resilience, it knows what to test.

Incident reporting is the clearest example. DORA’s criteria for classifying major incidents look, among other things, at whether critical services were affected and how many clients were hit. A firm whose register already links a provider to functions can answer within the reporting window. A firm that must reconstruct the mapping during the outage will be late or wrong.

Keeping the link alive

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.

Problem three, depth: the 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.

Where the information comes from

Firms rarely start from nothing. Vendors’ independent assurance reports, such as SOC 2 reports, usually name the subservice organizations the vendor relies on. Many vendors publish lists of subprocessors because EU data protection law already requires them to disclose who processes personal data on their behalf. Neither source is complete for DORA purposes, but together they give a first draft that the vendor can be asked to confirm.

Contracts do the rest. DORA sets out key provisions that contracts with ICT providers must contain, with more for services supporting critical functions. These include clear service descriptions, locations of data processing, notice periods, exit assistance and the firm’s access and audit rights. Many vendors responded with standard DORA addenda, which made negotiation faster but also more uniform. A firm that needs more, such as notice before a change of hosting provider, has to ask for it specifically.

When a vendor will not say

Some vendors decline to name subcontractors, citing security or commercial confidentiality. A firm has several options short of walking away. It can record the gap honestly, with a date by which it expects an answer, rather than leaving the field blank or guessing. It can raise the request formally at renewal, when its bargaining position is strongest.

For its own concentration analysis, it can also make a cautious assumption. Treating an undisclosed hosting arrangement as if it ran on the provider most common among its other vendors is crude. It still prevents an unknown from being counted as diversity.

For services supporting critical functions, silence should also feed the vendor’s risk rating. A provider that cannot describe its own chain is telling the firm something about how it would behave in an incident. Persistent refusal is a reason to plan an exit, even if the firm never uses it.

How deep to go

The register records the chain of subcontractors in order, but it does not ask for every link. The test is whether a subcontractor effectively underpins the service. A hosting provider beneath a payments platform clearly does. A firm that supplies the vendor’s office cleaning clearly does not. Between those poles, firms should write down their materiality rule and apply it the same way across vendors.

Going deeper has diminishing returns. Second-tier subcontractors are usually where concentration appears; third-tier detail is often unknowable and adds little. The effort is better spent keeping the first two tiers current.

What depth reveals

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. It answers a question boards often ask and rarely get a straight answer to: if one big provider went down, how much of our business would stop?

The answer is uncomfortable more often than not, and it does not always call for change. Large cloud providers are often more resilient than the alternatives. Concentration is a fact to manage, with tested recovery arrangements and realistic exit plans, rather than a finding to eliminate at any cost.

How the work actually gets done inside a firm

A register project cuts across teams that do not usually sit together, so the division of labor matters.

Procurement and vendor management own the list of contracts. They are usually the starting point, and usually discover that their system was designed to pay suppliers rather than to describe them.

Finance and accounts payable hold the most complete record of who the firm actually pays. Comparing payments with the contract list is one of the quickest ways to find arrangements nobody registered, such as subscriptions paid on corporate cards.

Technology and architecture teams know which applications run where, which hosting and support services sit behind them and which systems talk to which. They are the bridge between a contract and a business function.

Business units know what they cannot live without. Their input decides which functions are critical, and therefore which arrangements need the deeper subcontractor detail.

Risk and compliance usually coordinate the effort and submit the result, but they cannot create the data on their own. Where a firm leaves the register entirely to compliance, it tends to end up with a well-formatted file built on guesses.

The firms that found the work least painful had one thing in common: a single shared system, or at least a single shared set of identifiers, that each of these teams updated as part of its normal job. The register then became a report drawn from that system rather than a separate document assembled by hand. That design choice, more than any technology product, determined whether the second year was easier than the first.

Measures that show whether it is working

A handful of measures tell a register owner whether the data is healthy. The share of providers recorded with a valid identifier is the first. The share of critical-function arrangements with subcontractor detail is the second. The time between contract signature and register entry is the third. The number of automated validation errors at each submission is the fourth.

Each measure has an owner, and each points to a fix. Missing identifiers point to onboarding. Missing subcontractors point to contract terms. Slow entry points to procurement workflow. Validation errors point to the reporting pipeline.

The pipeline deserves its own attention. Supervisors published the validation rules their systems apply to incoming files. Running those same rules internally, well before the deadline, turns a rejected submission into an ordinary data quality ticket. It also shows which source system produced each error, so the fix lands where the bad data starts rather than in a spreadsheet patched the night before.

How it differs by type of firm

Large banking groups face the register at three levels: each legal entity, sub-consolidated and consolidated. Their hardest problem is usually intragroup services, where a shared service company or a non-EU parent provides technology to dozens of entities. Each of those services needs to be recorded as an arrangement, even where no contract exists.

Payment institutions, e-money firms and fintechs have fewer contracts but are often built entirely on third-party cloud and software services. Nearly every function they have is critical, and nearly every arrangement needs subcontractor detail. Their register is short, but every line in it is deep.

Asset managers often rely on fund administrators, custodians and portfolio management platforms whose ICT services are bundled into broader outsourcing. Separating the ICT component from the service contract is their typical difficulty.

Insurers carry long-lived legacy platforms and policy administration systems, often run by outsourcers. Their registers tend to reveal old contracts with thin terms, which DORA’s contractual requirements force them to reopen.

Crypto-asset service providers came into scope as the EU’s crypto-asset markets regime took effect. Many had never maintained a formal supplier inventory and built one from scratch.

U.S. groups with EU subsidiaries must comply in those subsidiaries. Technology provided by the U.S. parent is an intragroup ICT service under DORA and must be registered and governed accordingly. That often forces a conversation between the EU entity’s management and the group’s central technology function about notice, exit and audit rights.

Technology vendors are not directly regulated by the register rules, unless designated as critical. They feel it through customer demands for identifiers, subcontractor lists and contract addenda. Vendors that prepared a standard DORA response pack spent less time on each request.

One bank, from invoice names to subcontractors

Suppose a mid-sized bank operates in three EU countries. Its vendor management system lists about 150 technology suppliers, all of them recorded under the names on their invoices.

When the register project starts, the team discovers more arrangements than it expected: marketing’s analytics subscriptions, a data feed bought by the treasury desk, and services from the parent group’s shared data center that were never written up as contracts. It also finds that one large cloud provider appears under several different names, through direct contracts, a regional subsidiary and two resellers.

Mapping functions takes longer. The payments team, the lending team and the finance team each have their own view of what is critical. The executive committee spends an afternoon agreeing on a list. Once agreed, each critical function is traced to its applications, and each application to its suppliers.

Some of those conversations are uncomfortable. The head of one business line argues that a reporting function is critical because a regulator relies on it; another argues the opposite. The disagreement is healthy. It forces the bank to say out loud what it would protect first in a crisis, a question many firms had never formally answered.

Then the bank asks its critical-function vendors to name their material subcontractors. Several of them rely on the same cloud provider the bank already uses directly. The bank’s “diverse” supplier base turns out to rest on a narrow foundation. Nothing has gone wrong, but the board now sees, for the first time, a concentration it had not known about, and can discuss what to do about it before a supervisor raises it.

The options are not all expensive. The bank might ask one vendor about alternative hosting, build a tested exit plan for another, or simply accept the concentration knowingly and strengthen its recovery arrangements. What matters is that the choice is made deliberately.

The second year

The second cycle shows whether the first was built to last. If the bank kept its spreadsheet and disbanded the project team, the refresh starts again from invoices. If it moved identifiers into the vendor master, made the function link a field in architecture review and reconciled payments monthly, the refresh is mostly a review of changes.

The difference also shows up between cycles. When a payments vendor announces a change of hosting provider, the second bank sees within a day which functions are affected and whether its exit plan still holds. The first bank learns of it at the next refresh, if at all.

What a good register buys

Regulatory standing. A poor-quality register is visible to supervisors in a way a poor internal spreadsheet never was, because it is compared against everyone else’s. A supplier that every other bank reports, but yours does not, is a question waiting to be asked.

Resilience. The map that satisfies DORA is the same map a firm needs to respond to a supplier outage, plan an exit or test its recovery. Building it well is not overhead; it is infrastructure for the operations team.

Negotiating position. Knowing how dependent you are on a provider, directly and indirectly, informs every renewal discussion and every decision about whether a second supplier is worth paying for.

Cost of doing it twice. A register built by hand for a deadline has to be rebuilt by hand for the next one. Fixing identifiers and mapping functions once, in a system that stays current, pays back every year at the refresh. It pays back again whenever an incident or exit plan needs the same information in a hurry.

Reach beyond the EU. 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.

Across U.S. charters, the position is uneven. The federal banking agencies can examine many banks’ technology service providers directly under the Bank Service Company Act. The National Credit Union Administration has no comparable authority over credit unions’ vendors. A U.S. credit union therefore relies more on its own inventory and contracts than a bank does, which makes a register-style dataset more valuable to it, not less.

The case that it is just paperwork

The strongest objection runs like this. Supervisors already knew which hyperscalers dominate European finance. Designating them did not need thousands of firms to fill in templates. The register is a snapshot that goes stale on submission, and vendors will not reveal subcontractors anyway.

Each point has some truth. The famous names were never in doubt, and some vendors did resist disclosure. But the objection misses where the value lands. Aggregated data shows mid-tier concentrations nobody had mapped, and it gives supervisors comparable evidence for each designation. Most of the benefit, though, stays with the firm: the map is what lets it handle an outage, an exit or an incident report on time.

Staleness is a fair criticism of registers built by hand. It is much weaker against registers drawn from systems that teams update in their normal work. The objection is best read as an argument for building the register properly, not for minimizing it.

A living dataset, and how it decays

A firm in good shape treats the register as a living dataset with a named owner. Every supplier carries a proper identifier. New arrangements enter at the point of purchase. Critical functions are agreed by senior management and linked to applications and suppliers in one maintained system. Vendors supporting critical functions are contractually required to disclose material subcontractors and notify changes. And the firm runs its own concentration analysis before anyone asks.

Evidence a supervisor or auditor will look for

Supervisors and internal auditors will look for more than the file. They will expect the documented scope rules and materiality rule for subcontractors. They will want the management body’s approval of the list of critical functions. They will check the reconciliation between payments and the register, and the record of changes between submissions. A clean file with no trail behind it invites the question of how it was produced.

The management body itself carries responsibility under DORA for ICT risk, including third-party risk. A short annual paper on the register, covering coverage, data quality measures and the concentration analysis, gives the board something concrete to approve.

The usual ways it goes wrong:

• Treating it as a once-a-year form. Data assembled in a rush for the deadline decays straight afterward.
• Trusting the accounts payable list. Invoice names are not identities.
• Forgetting the family. Intragroup services are often the largest blind spot.
• Stopping at the first layer. Without subcontractors, concentration stays hidden.
• Leaving “critical” undecided. Without an executive decision, the mapping never settles.
• Optimistic substitutability. Calling a service easy to replace without an exit plan to prove it is a claim peers’ data can contradict.
• Recording resellers only. The contract counterparty is not always the provider the firm depends on.

Testing your own register

Five direct questions show quickly whether a register is a living dataset or an annual form. Each maps to one of the three problems or to the ownership that keeps them solved.

1. Who owns our register of information, and is it maintained continuously or rebuilt each year?
2. How many of our suppliers are recorded with a legal entity identifier rather than a trading name?
3. Do intragroup technology services appear in the register, even where no formal contract exists?
4. Which functions have we agreed are critical or important, and who signed that off?
5. If our largest cloud or infrastructure provider failed, which critical functions would stop, counting the vendors that run on it?

A firm with crisp answers to all five holds a map it can use. One without them holds a file that someone else will read more carefully than it did.

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. The supplier lists firms had compiled in the spring had become the starting point for one of the most significant regulatory decisions under the law.

The process between spring and November followed the roadmap the ESAs had published in February. National supervisors passed the registers up, the ESAs matched and analyzed them, and providers that appeared to meet the criteria were notified. Under DORA, a provider facing designation can submit a reasoned statement before the decision is final. The registers therefore had to support conclusions that a large, well-advised technology company might contest.

Their assessment weighed systemic importance, support for critical or important functions and substitutability. Substitutability simply means how easily a financial firm could switch to another provider if it had to. A service that is used widely, underpins essential functions and would be hard to replace is exactly the kind of dependency regulators worry about most.

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. For the first time, the companies behind much of European finance’s technology were answerable to financial supervisors in their own right as well as through the contracts of their customers.

What designation set in motion

Designation started a standing regime rather than ending a process. Each lead overseer could request information, run general investigations and inspections, and issue recommendations to its providers. Designated providers pay oversight fees. A designated provider based outside the EU must set up an EU subsidiary within a year of designation.

The regime also loops back to the financial firms. National supervisors follow up on whether firms using a designated provider take account of the overseers’ findings. In the last resort, DORA lets them require firms to suspend or end the use of a provider that fails to address recommendations. For firms, that made the register’s exit-plan and substitutability fields more than formalities.

That outcome put the quality of each firm’s register in a new light. Every correctly identified supplier and every mapped subcontractor had contributed to the picture regulators used. Errors and gaps, multiplied across thousands of firms, would have blurred it.

What held up, and what remains unclear

The core argument held up. The register turned out to be an input to EU oversight, exactly as its design implied, and it was used within the first year. Firms that had treated it as paperwork found that its contents were being relied on for a decision with real consequences.

Some things remain harder to judge from outside. The ESAs have not published firm-level data, so how much the subcontractor detail and the mid-tier dependencies shaped the list is not public. How many firms’ registers were rejected or resubmitted for quality reasons is also not something we can verify. The rules on subcontracting critical functions also took time to settle after DORA applied, which limited how far depth could be standardized in the first cycle.

Beyond the EU

In the United States, no equivalent register rule emerged, and third-party expectations continued to run through guidance and examination. American institutions with EU operations still had to comply, and many U.S. technology vendors were drawn in through their European clients.

The United Kingdom kept to its own critical third parties regime, in which the Treasury designates providers and the regulators oversee them. A provider serving both markets could face two oversight frameworks with different designation routes. For groups operating in both, a single well-identified supplier dataset served both conversations.

For EU firms, the register had become a standing data obligation, refreshed and resubmitted, rather than a one-time project. Leaders who treated it as a living map of their dependencies gained something useful for running the business. Those who treated it as an annual form faced the same scramble each year, with less to show for it.

By late 2026 the practical question had moved on. It was no longer whether the register mattered, but whether each firm’s copy was good enough to rely on during its own outage, exit or incident report. The firms best placed were those whose register was a by-product of normal work rather than a project.