DORA in practice: what the register of information actually demands

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025. Of its many obligations, the register of information is one of the least glamorous and one of the most important. It may look like a contract inventory. In practice it is the dataset supervisors use to see how financial entities depend on ICT providers. At European level, the three European Supervisory Authorities (EBA, EIOPA and ESMA) used it as the basis for designating critical ICT third-party providers (CTPPs). Competent authorities sent the first registers to the ESAs by 30 April 2025. On 18 November 2025 the ESAs published a list of 19 designated CTPPs, drawn in part from that data.

For practitioners, the register therefore matters twice over. A firm's own data shapes how its supervisor sees its third-party risk. Combined with everyone else's, it also shapes the oversight regime that sits above the largest providers. Poor data weakens both.

What must be recorded

Article 28(3) of DORA requires financial entities to keep and update a register of information on all contractual arrangements for the use of ICT services provided by ICT third-party service providers. The register is kept at entity level and, for groups, at sub-consolidated and consolidated level. It must separate arrangements that support critical or important functions from all others. Firms report on these arrangements to their competent authority at least once a year and must make the full register available on request.

DORA defines a critical or important function in broad terms. It is a function whose disruption would materially impair the firm's financial performance, or the soundness or continuity of its services. It also covers a function whose failure would materially impair the firm's ability to meet its authorisation conditions or its other obligations under financial services law. ICT services are defined widely too: digital and data services delivered through ICT systems on an ongoing basis, including hardware as a service.

The detail sits in Commission Implementing Regulation (EU) 2024/2956. It was dated 29 November 2024, published in the Official Journal on 2 December 2024, and entered into force on 22 December 2024. It sets out a family of standard templates, numbered B_01.01 to B_07.01, plus a closing B_99.01 that holds the terminology and closed lists. In plain terms, the templates capture:

• the reporting entity, the entities within its consolidation scope, and its branches outside the home country;
• each contractual arrangement, including links between intra-group arrangements and the external contracts behind them;
• who signs each contract, who uses each service, and which ICT provider delivers it;
• the ICT service supply chain, including subcontractors and their rank in the chain;
• the firm's functions, and which ICT services support them;
• an assessment of services that support critical or important functions, including matters such as substitutability.

Two provisions in the implementing regulation need particular attention:

• Identifiers. Each ICT provider that is a legal person must be identified by a valid and active Legal Entity Identifier (LEI) or a European Unique Identifier (EUID), and by both where both exist.
• Subcontractors. The register must cover all ICT services from direct providers. It must also cover every subcontractor that effectively underpins services supporting critical or important functions, or material parts of them. For those subcontractors, the firm must work through its direct provider to obtain their identifiers.

The ESAs' FAQ adds that intra-group providers are in scope. For intra-group services, firms should record at least the first subcontractor outside the group, even where no critical or important function is involved.

Where firms struggle in practice

Data quality. The ESAs ran a voluntary dry run in 2024 and analysed 947 registers. Only 6.5% passed every data quality check. Missing mandatory information made up the large majority of failures, and the most frequent gap was missing identifiers for ICT providers and their parent undertakings. Many errors were technical rather than substantive: wrong file names and package structures, broken links between tables, duplicate keys and badly formatted CSV files. These can still cause a submission to be rejected outright. Supervisors have also signalled that the bar is rising. The Luxembourg CSSF warned firms ahead of the 2026 collection that the ESAs now apply their validation rules to more data fields, so a register accepted in 2025 could be rejected in 2026.

Identifiers. Invalid LEIs were a notable category in the dry run, often because national registration numbers had been entered in their place. The ESAs' testing observations describe avoidable EUID errors as well, such as an LEI entered in the EUID field or EUIDs in the wrong format. Getting identifiers for non-EU providers, and for subcontractors several steps away from the firm, is harder still.

Mapping services to functions. The register requires a defensible link between each ICT service and the functions it supports. In the dry run, function identifiers and service types were often missing from the template that holds contract-level detail. That gap usually points to an upstream problem: the firm has not agreed and documented its list of critical or important functions in a form that procurement and IT can use.

Subcontracting chains. Firms depend on their direct providers to disclose material subcontractors. Providers do not always do so promptly or consistently. Older contracts may give the firm no right to ask.

Ownership. The data needed sits in at least three places. Procurement holds contracts, IT holds service and asset information, and risk or operational resilience teams hold the assessment of functions. Where no one owns the register end to end, it tends to be rebuilt each year in a spreadsheet just before the deadline.

What good evidence looks like

A register that will stand up to supervisory scrutiny usually shows the following:

1. A named owner. One accountable owner, with documented input from procurement, IT, legal and risk, and a sign-off before each submission.
2. A documented basis for functions. An approved list of critical or important functions with the rationale behind each classification, kept consistent with business continuity and impact analysis work.
3. Checked identifiers. LEIs and EUIDs verified against the official sources (GLEIF and the EU business registers), with a log of exceptions and follow-up with providers.
4. Contract clauses for subcontractor data. Standard clauses that oblige providers to disclose material subcontractors and keep that information current, with a plan to amend legacy contracts at renewal.
5. Validation before submission. The ESAs' published validation rules and technical package run before filing, with a record of errors found and fixed.
6. Upkeep during the year. Updates triggered by onboarding, renewal, change and exit processes, rather than an annual collection exercise.
7. A clear group reporting route. For groups, a documented position on which entity reports at which level, with checks that entity-level data matches the consolidated register.

Closing

The register of information is easy to treat as a reporting chore, but supervisors do not treat it that way. It is how they see concentration risk across the sector, and the CTPP designations show it has real consequences. Firms that use it as a working record of their ICT dependencies will find it easier to submit and easier to defend. Firms that rebuild it each year in spreadsheets will keep finding the same gaps in identifiers, subcontractors and function mapping that the 2024 dry run revealed.