The DORA register of information is a dependency map, not a spreadsheet

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Of its five pillars, the one that has generated the most practical work is not testing or incident reporting. It is the register of information: the structured record, required by Article 28(3), of every contractual arrangement a financial entity has with ICT third-party service providers.

Two reporting cycles in, a clear divide has emerged. Some firms treat the register as an annual data-collection exercise owned by procurement, assembled from contract systems in the weeks before submission. Others treat it as the authoritative model of how their critical services depend on technology suppliers. The first approach can produce a file that passes validation. Only the second produces something the firm can use, and it is the second that the regulation was designed to encourage.

What the register actually is

The content and format of the register are fixed by the implementing technical standards adopted as Commission Implementing Regulation (EU) 2024/2956. They define a set of linked templates rather than one table. Read together, the templates describe:

the financial entities in scope and how they relate within a group;
each contractual arrangement and the ICT services it covers;
the ICT third-party providers, identified with legal entity identifiers, and their position in any supply chain of subcontractors;
the functions the financial entity performs, and which of them are critical or important; and
for services supporting critical or important functions, assessments such as substitutability, exit possibilities and the impact of discontinuation.

The structure matters. Because the templates link contracts to providers and providers to functions, the register is, in effect, a relational model of dependency. A spreadsheet that holds the right columns but cannot answer “which critical functions stop if this provider fails?” has the right shape and the wrong substance.

Why supervisors want it

Registers are submitted to national competent authorities and passed to the European Supervisory Authorities. Aggregated across the sector, they show where many financial entities rely on the same providers. On 18 November 2025 the ESAs published their first designations of critical ICT third-party providers under DORA’s oversight framework. That process drew on the information collected through registers, together with a criticality assessment carried out with national authorities.

The implication for individual firms is straightforward. The register is no longer a document that sits in a supervisory archive. It feeds sector-wide analysis of concentration risk, and inconsistencies between what a firm reports and what its supervisor sees elsewhere are increasingly visible.

Check your own authority’s requirements

Submission windows, file formats and validation rules have differed between national competent authorities. Confirm the current reporting instructions with your own authority each cycle rather than relying on last year’s process.

Where registers go wrong

Contracts and architecture describe different worlds

A contract with a cloud provider rarely says which business functions run on it. A contract with a software vendor may cover a dozen modules, some supporting critical functions and some not. Procurement systems know who was paid; architecture records know what runs where. The register needs both, and the join between them is usually manual.

Subcontracting chains are thin

For services supporting critical or important functions, the register reaches into the provider’s own supply chain. Many firms hold only what the provider volunteered at onboarding. Where a SaaS platform runs on a hyperscale cloud and depends on a third-party identity service, all three appear in a resilience scenario, whether or not they appear in the register.

“Critical or important” is decided in the wrong place

The classification of functions as critical or important drives the depth of reporting. When that classification is made during register preparation, under time pressure, it tends to be inconsistent with the classification used for business continuity, impact tolerances and testing. Supervisors notice when the same function is critical in one document and not in another.

Substitutability is asserted, not assessed

Fields describing how easily a provider could be replaced, and whether an exit plan exists, are among the most revealing in the register. “Highly substitutable” is a claim that should be supported by an exit strategy someone has actually examined.

When the SaaS provider in contract 1 itself runs on the cloud provider in contract 2, a single outage can affect both services supporting the same critical function. A register built as a linked model shows this; a flat contract list does not.

Building a register that is also useful

The register can be produced as a by-product of a dependency model the firm maintains for its own reasons. In our experience, the sequence that works is:

Start from functions, not contracts. Agree the list of functions and their criticality once, with business owners, and reuse it across the register, business continuity, impact tolerances and resilience testing.
Map each critical function to the ICT services it needs. Use architecture records and interviews with service owners. This is where hidden dependencies surface: identity services, DNS, monitoring and payment gateways.
Attach contracts to services. Only now bring in procurement data. Gaps appear in both directions: services with no contract on record, and contracts that support nothing anyone can name.
Extend into subcontracting where it matters. For services supporting critical functions, request and record material subcontractors, and refresh this information at renewal.
Assess substitutability with evidence. Tie each assessment to an exit strategy, and test one or two exit strategies a year through tabletop exercises.
Generate the regulatory templates from the model. Treat the submission as an export with validation, not as the master record.

What a good register tells you

A register built this way answers questions boards are starting to ask after high-profile technology outages: Which providers would stop more than one critical function at once? Where are we relying on a single cloud region or a single identity provider? Which of our critical providers depend on the same subcontractor? For which critical functions do we have no credible exit route?

Those answers also feed the rest of DORA. They define the scenarios for digital operational resilience testing, the providers that matter most in incident classification, and the contractual provisions that Article 30 requires for services supporting critical or important functions.

If you treat the register as…	You get	You miss
An annual procurement export	A file that may pass technical validation	Concentration risk, hidden dependencies, inconsistency with continuity planning
A maintained dependency model	A submission plus answers to resilience questions	Very little. The effort shifts from a yearly scramble to steady maintenance

Key takeaways

The register is relational. Its value lies in the links between functions, services, contracts and providers.
Supervisors aggregate it. It informs sector-wide views of concentration risk and the oversight of critical providers.
Classify functions once and reuse that classification everywhere DORA asks for it.
Substitutability needs an exit plan behind it.
Generate the submission from the model, not the other way round.

Sources

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Articles 28 and 30.
Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards on the register of information.
European Supervisory Authorities, joint press release on the designation of critical ICT third-party providers, 18 November 2025.

Our DORA readiness work builds the dependency model first and generates the regulatory templates from it. The result is a submission your supervisor can trust and a map your board can use. Talk to our resilience team before the next reporting cycle.