DORA Supply-Chain Reporting: When Granularity Creates Noise

DORA Register of Information: lessons from the field, part 1

Somewhere in Europe, a compliance officer at a mid-sized investment firm is trying to document Google’s supply chain. Not Google’s supply chain in general, but the chain for one specific ICT service, connected to one contractual arrangement and filtered for the subcontractors that effectively underpin a service supporting a critical or important function.

She may need to repeat this exercise for other Google services her firm relies on, each potentially classified as a different type of ICT service and each potentially involving a different set of material subcontractors. She does not control Google’s infrastructure. She cannot fully observe it. Yet the Register of Information asks her organisation to map what can be known, rank the chain and keep it current.

She is not alone. Organisations across Europe are engaged in similar exercises, independently, for many of the same providers. The register is intended to help organisations and supervisors understand ICT third-party and concentration risk. What it may produce is something quite different.

The mismatch is structural

Over the past year, we have worked with organisations across different regulatory regimes on their registers of information. What we have found is not a compliance gap in the conventional sense. The organisations are engaged, resourceful and motivated to get this right. The friction is structural. It sits between what the register asks for and what can realistically be known, obtained and reported with any consistency.

These structural mismatches matter for two reasons. The first is internal. The Register of Information should be one of the most valuable records an organisation maintains: a living map of its ICT dependencies and the risks they carry. When the reporting requirements diverge from how risk is assessed and managed, the register becomes a parallel compliance construct rather than an operational record. That is a waste.

The second reason is supervisory. Information gaps and inconsistencies at entity level do not cancel each other out when aggregated. They compound. The risk is not simply that individual registers are incomplete. It is that the aggregated picture at ESA level appears more reliable than the underlying data warrants.

Why B.05.02 creates repeated supply chains

The supply-chain requirement is where this tension is most visible. Implementing Regulation (EU) 2024/2956 uses template B.05.02 to identify and link providers belonging to the same ICT-service supply chain.

The chain is not recorded once for the provider as a consolidated counterparty. Providers in the same chain share a contractual-arrangement reference number and a type of ICT service. Each provider receives a rank. For ICT services supporting a critical or important function, the chain includes subcontractors whose disruption would impair the security or continuity of the service.

This structure means that a provider delivering several services can appear in several distinct supply chains. Different contractual arrangements, service types and material subcontractors can produce different B.05.02 records even when the same global provider sits at the centre.

Many smaller and mid-sized entities have relatively straightforward provider relationships. A typical supplier may provide one, two or three material services. From a continuity-risk perspective, these organisations often assess the supplier at an aggregated level: can this provider fail, what would happen if it did, how substitutable is it, and what is the exit path? Granular service-level supply chains are not always where the risk meaningfully resides.

A Google example shows the problem

Consider an organisation that uses Google Workspace for internal collaboration, Google Cloud Platform for infrastructure and Gemini for AI-assisted development. The services can fall into different ICT-service categories, support different functions and rely on different material parts of Google’s subcontractor ecosystem.

The first practical question is how a mid-sized firm obtains sufficient subcontractor information from Google. Assume that happens. It is still not enough to know the provider’s subcontractors in general. The organisation must determine which subcontractors effectively underpin each relevant service, place them in the correct chain and rank their position.

Now imagine 200 organisations across Europe, all using Google Workspace, all independently attempting to determine and report the material supply chain for that service. Each must obtain disclosures, interpret whether disruption would impair service continuity or security, classify the service and report the chain with the required ranking.

They are all measuring substantially the same thing. They may all measure it differently.

Aggregation does not remove subjectivity

Small differences in materiality judgements can compound rapidly. Two organisations using the same service for similar functions may submit materially different supply chains, not necessarily because one is wrong, but because the available information and the required judgement do not produce one deterministic answer.

When the ESAs aggregate this data across hundreds of reporters for the same provider, the resulting picture may not be a sharp photograph of the provider’s infrastructure dependencies. It can become a composite of subjective, independently produced interpretations. More Impressionist painting than engineering blueprint.

What are the odds that this exercise, performed independently by organisations with different capabilities, resources and interpretive frameworks, produces data that is both consistent across reporters and accurate enough to support meaningful supervisory conclusions?

What the 2024 dry run tells us

The ESAs’ 2024 dry run provides a useful reference point, though it tested the draft reporting package on a voluntary, best-effort basis and should not be treated as a direct test of the final B.05.02 requirement.

Of the 947 registers that passed integration checks and were analysed, only 6.5% passed all 116 data-quality checks. Missing mandatory information accounted for 86% of the recorded data-quality failures. The ESAs expected significant issues in a preparatory exercise and concluded that sufficient quality in the official reporting was achievable with further work. Even so, the results show how quickly quality problems arise before adding more interpretive freedom.

The point is not that the dry run proves supply-chain aggregation will fail. It does not. The point is that a reporting architecture dependent on repeated, entity-level interpretation should be evaluated not only for formal granularity, but also for the consistency of the data it produces.

The objective is legitimate; the architecture is the problem

None of this diminishes the regulatory objective. Concentration risk in ICT provision is real, and supervisory authorities are right to seek visibility into the dependencies beneath Europe’s financial system. The difficulty lies not in the ambition, but in the architecture.

The current framework disperses analytical responsibility for supply-chain mapping across entities that do not control the infrastructure they are asked to describe. It asks them to work at a level of granularity, by contractual arrangement and service type, that introduces substantial interpretive freedom. The result can be a dataset that is expensive to produce, difficult to maintain and inconsistent when aggregated.

A supplier-level alternative

A more coherent approach would situate more of the supply-chain reporting at supplier level. In practice, this could mean establishing a consolidated map of the material subcontractor ecosystem of the ICT provider, then linking service-specific differences only where they are known and decision-relevant.

This would bring reporting closer to how many organisations manage risk. Firms often assess concentration, substitutability and exit risk at provider level. A supplier-level supply-chain map could reinforce that governance instead of creating a separate analytical construct for each service line.

It could also reduce duplicated effort. A firm using several services from one global provider would establish the common provider ecosystem once, then document material service-level variations, rather than reconstructing the entire picture for every service.

Most importantly from a supervisory perspective, it could improve comparability. When many organisations rely on the same provider, a shared supplier-level foundation reduces the interpretive space. Divergence would still occur, but it would be easier to distinguish genuine differences in dependency from differences in how an identical ecosystem was sliced.

Consistency can matter more than granularity

Given the variance inherent in service-level materiality assessments, the marginal precision gained by forcing repeated segmentation may be illusory. A consolidated supplier-level dataset, consistently reported, could produce a clearer and more actionable picture of systemic concentration risk than a fragmented service-level alternative.

The objective is not to create the most granular database possible. It is to give organisations and supervisors reliable sight of structural vulnerabilities in the ICT landscape supporting Europe’s financial system. If granularity generates noise rather than clarity, calibration is a question of prudence, not concession.

This is not an argument for reducing transparency. It is an argument for situating transparency at the level where it is most stable, comparable and useful for decisions.

Continue with part 2: One Contract, How Many Countries?, which examines the service-country field and proposes an operational test for deciding which countries belong in the register.

The DORA guide places the Register of Information in the wider operating model. Ariadnah helps organisations connect suppliers, services, functions, contracts and reporting evidence so the register remains useful between submissions.

Book a Discovery Call to discuss the supplier or register relationships that are still being reconstructed by hand.

Primary sources

Implementing Regulation (EU) 2024/2956: definitions, ranking and instructions for Register of Information template B.05.02.
ESAs 2024 DORA dry-run summary report: participation, data-quality results, lessons and recommendations.
EBA Register of Information reporting resources: current reporting materials, validation information and supporting documents.

This article presents the author’s analysis of the reporting architecture. Financial entities remain responsible for applying DORA and Implementing Regulation (EU) 2024/2956 as adopted.