The DORA Register of Information (ROI)

The Register of Information is the documentary backbone of DORA's third-party pillar. Mandated by Article 28(3) of Regulation (EU) 2022/2554, and given precise structure by Commission Implementing Regulation (EU) 2024/2956, it is the single artefact that supervisors examine first when assessing a financial entity's ICT third-party risk management.

This article explains what the Register is, the structure the ITS prescribes, what data goes in each part, the common errors that cause submission rejections, and how to build and maintain it. For the broader third-party context, start with DORA Third-Party Oversight, and for the full DORA picture, the complete NIS2 and DORA compliance guide.

As always - this is not to be considered legal advice. The ESAs continue to issue guidance and template updates affecting the Register — verify the current ITS version before submission.

What the Register of Information is

Article 28(3) DORA requires every financial entity to maintain, at entity, sub-consolidated, and consolidated levels, a Register of Information covering all contractual arrangements for the use of ICT services provided by ICT third-party service providers.

The Register is not an internal document of the entity's own design. Commission Implementing Regulation (EU) 2024/2956 — the Implementing Technical Standard (ITS) — prescribes the exact structure: a set of interlinked templates, defined data fields, and standardised values. Financial entities must produce the Register in this format because the ESAs aggregate Registers across the EU to map ICT concentration risk at the systemic level. A non-standard Register cannot be aggregated, which is why submissions in the wrong format are rejected.

Two functions, then. For the entity, the Register is the inventory underpinning its own third-party risk management. For the supervisor, it is structured data feeding EU-level oversight — including the identification of which providers should be designated critical ICT third-party providers.

Why the Register is harder than it looks

A financial entity's first encounter with the Register usually produces the same realisation: the data the ITS demands is more granular, and more interlinked, than any existing vendor list.

The Register is not a flat spreadsheet of "supplier name, service, cost." It is a relational structure of linked templates. A single ICT service from a single provider may require entries across multiple templates — the contractual arrangement, the provider's identification, the entity making use of it, the function it supports, and the assessment of whether that function is critical or important. Each entry uses prescribed identifiers (notably the Legal Entity Identifier, LEI) and standardised category values.

The practical consequence: building the Register is a data-modelling exercise before it is a data-entry exercise. Entities that approach it as "fill in the spreadsheet" discover late that they cannot, because they have not collected LEIs for their providers, have not classified their functions, or have not linked contracts to the specific entities using them.

The structure of the ITS templates

Commission Implementing Regulation (EU) 2024/2956 organises the Register into a set of related templates. The structure groups information into several areas:

Entity and group information

Templates identifying the financial entity (or entities, in a group) maintaining the Register — legal name, LEI, type of financial entity, competent authority, and the hierarchy of entities where the Register is maintained at sub-consolidated or consolidated level.

Contractual arrangements

Templates describing each contractual arrangement for ICT services — a reference for the arrangement, the type of arrangement, the relationship between linked arrangements (for example, where one master agreement governs several services), start and end dates, notice periods, and governing law.

ICT third-party service providers

Templates identifying each provider — legal name, the provider's LEI (or alternative identifier where no LEI exists), country, the type of provider, and information on the provider's own subcontractors where ICT services supporting critical or important functions are subcontracted.

ICT services

Templates describing the ICT services themselves — the type of service, classified against the ITS's standardised taxonomy of ICT service types, and a description of the service.

Function identification and criticality

Templates linking each ICT service to the function it supports within the financial entity, and recording the entity's assessment of whether that function is critical or important. This is the classification that drives obligations across DORA Pillar 4, and it must be recorded here.

Assessments

Templates capturing assessments associated with the arrangement — for arrangements supporting critical or important functions, information including the date of the last risk assessment, the substitutability of the provider, the existence and testing of exit plans, and whether the provider has been identified as contributing to concentration risk.

The templates are interlinked by reference keys. A change in one template — a provider's LEI, a function's criticality classification — can require consistent updates across others. This is why the Register is best maintained as structured data, not as disconnected spreadsheet tabs.

Key data fields and where entities struggle

A few fields cause disproportionate trouble.

Legal Entity Identifier (LEI)

The ITS requires the LEI for the financial entity and, for providers, the LEI where one exists. Many smaller ICT providers do not have an LEI. The ITS provides for alternative identification in defined cases, but the entity must establish, provider by provider, whether an LEI exists and obtain it. Leaving LEI fields blank or guessing values is a frequent cause of submission rejection.

ICT service type taxonomy

Services must be classified against the ITS's standardised taxonomy of ICT service types. Free-text service descriptions do not satisfy the requirement — the standardised category must be selected. Entities that have described their services in their own language must map every service to a prescribed category.

Function criticality

Each service is linked to a function, and each function carries a critical-or-important assessment. This is not a field the entity can leave for later — it is the field that determines which DORA Pillar 4 obligations apply to the arrangement. An unclassified function is an incomplete Register entry.

Subcontracting chains

For ICT services supporting critical or important functions, the ITS requires information on the provider's subcontractors in the chain. Obtaining accurate subcontracting information depends on the provider's cooperation, and the contractual provisions of Article 30 are what compel that cooperation. Entities that did not secure subcontracting disclosure in their contracts struggle to complete this part of the Register.

Submission and the supervisory dimension

Competent authorities collect Registers from financial entities and the ESAs aggregate them. The 2024 and 2025 dry-run exercises run by the ESAs surfaced consistent themes in the errors entities made — data quality problems, inconsistent identifiers, incomplete function classification, and format non-compliance.

The practical lessons from those exercises:

• Format compliance is binary. A Register that does not conform to the ITS structure cannot be processed. Validate against the ITS schema before submission.
• Identifier consistency matters. The same provider must be identified consistently across all templates. Inconsistent LEIs or names break the relational links.
• Completeness is assessed. Blank mandatory fields, unclassified functions, and missing subcontracting data are flagged.
• The Register is a living obligation. It must be kept current and made available to the competent authority on request — not assembled once for an annual submission and then left to drift.

Building and maintaining the Register — a practical approach

For an SME financial entity, a workable approach:

1. Inventory every ICT third-party arrangement. Start from contracts, accounts-payable records, and system access lists — not memory. The Register must be complete.
2. Collect identifiers early. Obtain the LEI for your own entity and for every provider that has one. This is the slowest data-collection task; start it first.
3. Classify functions before services. Decide which of your business functions are critical or important. Every ICT service then inherits a classification from the function it supports.
4. Map services to the ITS taxonomy. Translate your own service descriptions into the prescribed ICT service type categories.
5. Model the Register as structured data. Whether in a database, a dedicated GRC tool, or a carefully designed linked-spreadsheet workbook, treat the templates as a relational structure with consistent reference keys.
6. Secure subcontracting disclosure. For critical-or-important arrangements, the Article 30 contractual provisions are what give you the right to subcontracting information. Use them.
7. Validate before submission. Check against the ITS schema. Catch format and completeness errors before the competent authority does.
8. Assign ownership and a review cadence. The Register is a living document. A named owner and a defined update trigger — new contract, contract change, provider change, criticality re-assessment — keep it current.

A small financial entity with a modest number of ICT arrangements can maintain the Register in a well-structured workbook. As the number of arrangements grows, or as the entity operates at sub-consolidated or consolidated level, dedicated tooling becomes worthwhile — but the tooling decision should follow the data model, not precede it.

📨 The Register of Information ITS has gone through revisions, and ESA dry-run feedback keeps refining expectations. Risk Letters tracks the updates. Free weekly briefing.

How the Register connects to the rest of DORA

The Register is not a standalone compliance artefact. It is wired into the rest of DORA:

• Pillar 1 (Article 8 identification) feeds the Register — every ICT third-party dependency identified in the risk management framework belongs in the Register. See DORA ICT Risk Management Framework Explained.
• Pillar 4 (Articles 28 to 30) is operationalised through the Register — the critical-or-important classification recorded in the Register determines which contractual and oversight obligations apply. See DORA Third-Party Oversight.
• The oversight framework (Articles 31 to 44) consumes the Register — aggregated Registers help the ESAs identify which providers to designate as critical ICT third-party providers.

A well-built Register is therefore not paperwork. It is the data layer that makes the rest of DORA Pillar 4 auditable.

Frequently asked questions

Is there an official Register of Information template? Yes. Commission Implementing Regulation (EU) 2024/2956 prescribes the structure, templates, and data fields. The ESAs have also published supporting tools and validation resources.

Can I keep the Register in a spreadsheet? For a small number of arrangements, a carefully structured workbook can work — but it must replicate the relational structure of the ITS templates with consistent reference keys. As arrangements grow, dedicated tooling becomes worthwhile.

What if my ICT provider has no LEI? The ITS provides for alternative identification in defined cases. Establish, provider by provider, whether an LEI exists; obtain it where it does; use the prescribed alternative where it does not. Do not leave the field blank or guess.

How often must the Register be updated? It must be kept current and available to the competent authority on request. In practice, update it on every triggering event — new contract, contract change, provider change, criticality re-assessment.

Do all ICT arrangements go in the Register, or only critical ones? All contractual arrangements for ICT services provided by ICT third-party service providers. The Register distinguishes between those supporting critical or important functions and those that do not, but both are recorded.

What happens if my Register fails the format check? A Register that does not conform to the ITS structure cannot be processed by the competent authority. Validate against the ITS schema before submission to catch format and completeness errors first.

Does the Register need subcontractor information? For ICT services supporting critical or important functions, yes — information on the provider's subcontractors in the chain is required. The Article 30 contractual provisions are what give you the right to obtain it.

The bottom line

Three takeaways:

1. The Register is structured data, not a spreadsheet list. Model it as a relational structure with consistent identifiers before you start data entry.
2. Function criticality is the keystone field. It determines which DORA obligations attach to each arrangement — classify functions early.
3. It is a living obligation. A named owner and defined update triggers keep the Register current; supervisors expect it to reflect reality on the day they ask.

For how the Register sits within DORA's third-party pillar, see DORA Third-Party Oversight. For the Pillar 1 identification process that feeds it, see DORA ICT Risk Management Framework Explained.

---

Sources & further reading

• Regulation (EU) 2022/2554 — DORA — Article 28(3) (Register of Information obligation)
• Commission Implementing Regulation (EU) 2024/2956 — ITS prescribing the Register of Information templates and data fields
• Joint Committee of the European Supervisory Authorities — Register of Information dry-run exercise reports and supporting tools
• ESA guidance on Register of Information data quality and submission