DORA Register of Information: 2026 Practical Guide

The DORA register of information (DORA RoI) is the structured record every EU financial entity must keep of all its contractual arrangements with ICT third-party service providers, flagging those that support critical or important functions. Required by Article 28(3) of DORA and standardised by the 15 templates of Implementing Regulation (EU) 2024/2956, it is collected every year by national competent authorities.

It is not just another annex to the vendor file: the European Supervisory Authorities (ESAs) used these registers to designate the first 19 critical ICT third-party providers on 18 November 2025. And data quality remains the weak spot: in the 2024 dry run, only 6.5% of the registers analysed passed every check. This guide covers what the register contains, why submissions get rejected and how to keep it current.

The 30-second version

• Legal basis: DORA Article 28(3); format set by Implementing Regulation (EU) 2024/2956 (15 templates, from B_01.01 to B_99.01).
• Scope: every ICT services arrangement, intra-group included, at entity level and, for groups, at sub-consolidated and consolidated level.
• Reporting: annual, with a reference date of 31 December of the previous year.
• Rejections: mostly empty mandatory fields, invalid LEIs or EUIDs, and orphan references between templates.
• Method: maintain the register as contracts change, not once a year.

Who must keep a DORA register of information, and at what level?

Article 28(3) of DORA, applicable since 17 January 2025, requires financial entities to:

1. maintain and update the register at entity level and at sub-consolidated and consolidated levels;
2. distinguish arrangements covering ICT services that support critical or important functions;
3. report at least yearly the number of new arrangements, the categories of providers, the type of arrangements and the ICT services and functions provided;
4. make available on request the full register or specified sections of it;
5. inform the authority in a timely manner of any planned arrangement supporting a critical or important function, and when a function becomes critical or important.

Every financial entity in DORA's scope is covered: banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, asset managers. A frequently misread point: Article 28(2) exempts microenterprises and entities under the simplified framework from adopting a formal ICT third-party risk strategy, but Article 28(3) contains no exemption for the register.

In a group, the parent undertaking sets the perimeter, and the consolidated register covers all financial entities and ICT intra-group service providers (Article 6 of Regulation 2024/2956). The register covers every direct provider, plus the subcontractors that effectively underpin a service supporting a critical or important function. And "ICT services" is a broad notion: SaaS, cloud, market data, managed services, licences with maintenance, services provided by a group subsidiary. Registers are collected by each national competent authority (NCA); significant credit institutions supervised directly by the ECB follow the ECB's instructions.

What does it contain? The 15 RoI templates of ITS 2024/2956

Implementing Regulation (EU) 2024/2956 of 29 November 2024, published in the Official Journal on 2 December 2024, lays down the standard templates. Its Annex I describes 15 of them, designed as relational tables: fixed columns, unlimited rows, one value per cell.

The four keys that link the templates

Four keys tie the templates together: the contractual arrangement reference number, the identifier of entities and providers, the function identifier and the type of ICT service (a code from S01 to S19 listed in Annex III). Each key must exist, identically, in the template it refers to: cite a contract in B_07.01 that is missing from B_02.01, and the submission fails.

The hardest data to collect

• Identifiers. Every provider that is a legal person must be identified by a valid and active LEI or by an EUID, and by both where available; financial entities by their LEI only. An LEI has 20 characters (ISO 17442), the last two being check digits computed with ISO/IEC 7064 (MOD 97-10).
• Functions. A dated, justified criticality assessment, plus an RTO and RPO in hours. A "0" means "not defined": a register full of zeros mostly reveals a missing business impact analysis.
• Assessment of critical services: substitutability on four levels, exit plan, possibility of reintegration, alternative providers identified.

How do supervisors use the register?

Nationally, NCAs use it to supervise third-party risk. The French ACPR, for example, said in a January 2026 webinar that it uses the registers to assess third-party risk frameworks, map interdependencies, measure concentration and manage incidents that originate at a third party.

At EU level, NCAs pass the registers to the ESAs every year. The criteria for designating critical providers (Article 31(2)) map directly onto the templates: systemic impact, importance of the entities relying on the provider, reliance for critical or important functions (including through subcontracting) and substitutability.

On 18 November 2025, the ESAs published the first list of critical ICT third-party providers: 19 names, including Amazon Web Services, Microsoft, Google Cloud, Oracle, SAP, IBM, Accenture, Capgemini, Orange and Deutsche Telekom. The list is updated yearly (Article 31(9)). A provider poorly identified in your register is a provider poorly aggregated in the European analysis.

When and how is the register submitted?

The ESAs' decision on the collection (ESA 2024 22) sets the principle: annual reporting, a reference date of 31 December of the preceding year, and transmission from NCAs to the ESAs by 31 March. The first year was an exception.

The format. The reporting package is a .zip archive with one CSV file per template plus JSON metadata, in xBRL-CSV ("plain CSV" in EBA terms). The EBA publishes the data point model (DPM), taxonomy, validation rules and FAQ on its DORA preparation page. The Excel-to-CSV conversion tool provided during the dry run is no longer maintained: each entity chooses its own solution. Each NCA runs its own portal (OneGate for the ACPR in France, eDesk for the CSSF in Luxembourg), and some offer a test environment. Use it, and submit early.

Which errors get a register rejected?

Three public sources tell the same story. In the 2024 dry run (ESAs report of 17 December 2024), missing mandatory fields accounted for about 86% of failed checks. For the first official submissions, the EBA's April 2025 overview (updated in May) lists foreign key violations, missing primary keys, LEIs not found in the GLEIF database, and widespread malformed EUIDs: 58,170 with an invalid format, against 2,717 found in the EU business registers interconnection system. For the 2026 campaign, the ACPR cited wrong reference dates, badly structured archives and files not encoded in UTF-8.

Note that a register accepted one year can be rejected the next. For 2026, Luxembourg's CSSF announced that it would apply the same validation rules to more fields.

How to build and maintain the register in 7 steps

Step 1 — Appoint an owner

The register combines data nobody holds alone: contracts (procurement), services (IT), criticality and recovery objectives (business continuity), concentration (risk), clauses (legal). Appoint one register owner and one person accountable for each data block.

Step 2 — Inventory every ICT arrangement

Reconcile three sources: the contract database, accounts payable and the application inventory. The gaps reveal SaaS subscriptions paid by card, forgotten framework agreements and services provided by a subsidiary without a written contract.

Step 3 — Collect and verify identifiers

For each provider: LEI checked against the public GLEIF database, EUID if registered in the EU, headquarters country, ultimate parent. Make these data a contractual obligation, including for critical subcontractors: the ESAs warned as early as 2024 that provider identifiers may not be immediately available.

Step 4 — Link each service to the functions it supports

A function is critical or important when its disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its compliance (DORA Article 3(22)). Reuse the list from your BIA, with its RTOs and RPOs: this is where the register meets the business continuity plan, which should carry the same functions and the same recovery objectives.

Step 5 — Map the subcontracting chain

For each critical service, obtain from the direct provider the list of subcontractors whose failure would affect the security or continuity of the service, and assign them a rank. Delegated Regulation (EU) 2025/532 specifies what the entity must assess before accepting such subcontracting.

Step 6 — Assess substitutability, exit and alternatives

Can the provider be replaced? Can the service be brought back in-house? Is an alternative identified? Answering "yes" to the exit plan question is a commitment: the plan must exist, be documented and be tested.

Step 7 — Check, submit, then maintain continuously

Before each submission: completeness, format, key uniqueness, cross-references, then a test submission. After that, tie updates to the contract lifecycle: new arrangement, amendment, termination, change of data location, new subcontractor, function reclassified as critical (which must also be notified to the authority). A quarterly reconciliation with accounts payable catches what slipped through.

Register, Article 30, concentration and exit: one file

Article 30 clauses. Every ICT services contract must describe, among other things, the services, the subcontracting conditions, where services are provided and data processed, service levels, and termination rights with notice periods. For critical or important functions, it must add quantified service levels, tested business contingency plans at the provider, audit rights and exit strategies. Several register columns are filled directly from these clauses: notice periods, governing law, country of provision, data location. A field you cannot fill often points to a missing clause. For digital product suppliers, the Cyber Resilience Act contract clauses come on top.

Concentration risk (Article 29). Before entering into a critical arrangement, the entity checks whether it would make it dependent on a provider that is not easily substitutable, or multiply critical arrangements with the same or closely connected providers. Group arrangements by identifier and ultimate parent, and concentrations appear; with hand-typed names ("AWS", "Amazon Web Services EMEA"), they stay invisible.

Exit strategies (Article 28(8)). For services supporting critical or important functions, the entity needs documented, tested and periodically reviewed exit plans, so that it can leave a provider without disrupting its business. This is business continuity: third-party failure is one of the unavailability scenarios a business continuity plan must cover.

Spreadsheet or dedicated tool?

A workbook is enough for an entity with a few dozen contracts and no group to consolidate. Beyond that, fifteen tabs kept consistent by hand become unmanageable, and the register turns into a copy of procurement, IT and continuity data that drifts the day after submission. The real question is not the tool but where the data lives. See also: spreadsheet vs ResiPlan.

What ResiPlan does, concretely

• Register assembled from existing data, with no re-keying: suppliers, contracts, critical or important functions and their provider mappings feed the templates.
• Pre-submission validation checks: required fields, allowed values, LEI format and check digits (ISO 17442), country codes, orphan references between templates.
• Migration: import of an existing register file.
• Group view: consolidated group-level register and a concentration view by provider.
• Contracts: an Article 30 contractual clauses checklist for each contract.
• Export of the register to Excel and CSV.

Business data is hosted in the European Union. To be clear: software does not make anyone compliant and certifies no one, and ResiPlan does not submit anything to the authorities on your behalf. Explore the register of information module or start a free 7-day trial, no credit card.

Checklist: is your register ready for the next submission?

• A register owner and one accountable person per data block are appointed.
• The inventory has been reconciled with accounts payable and the application inventory.
• Every financial entity has a valid LEI; every provider that is a legal person has a verified LEI or EUID, and its ultimate parent is identified.
• Each service is linked to its functions, with a dated and justified criticality assessment.
• RTOs and RPOs come from the BIA, and no "0" hides an unknown value.
• Subcontractors underpinning critical services are listed with their rank.
• Every "yes" on the exit plan question matches a documented, tested plan.
• Completeness, format and cross-reference checks pass without errors.
• A test submission has been made in your authority's test environment.

For a broader diagnosis: the DORA readiness checklist and the vendor risk quick check.

FAQ

Does every ICT provider need an LEI?

Providers that are legal persons need a valid and active LEI or an EUID, and both where available. Financial entities can only be identified by their LEI. Only individuals acting in a business capacity may be identified by another code, prefixed with the country code.

Do non-critical providers have to be in the register?

Yes. The register covers every arrangement on the use of ICT services. The distinction only changes the level of detail: the B_07.01 assessment and the listing of subcontractors apply only to services supporting critical or important functions.

Are intra-group arrangements in scope?

Yes. ICT intra-group service providers are providers in their own right. When an IT subsidiary buys services from a third party on behalf of the group, template B_02.03 links the intra-group contract to the external one so that the whole chain is visible.

When is the next submission?

Under the ESAs' decision, the next cycle uses a reference date of 31 December 2026, with transmission to the ESAs by 31 March 2027. Each NCA sets its own collection window, usually in the first quarter: in 2026, France's ran from 1 January to 31 March. Watch your supervisor's announcements from the end of the year.

How long does it take to build the register?

It depends on the number of arrangements, how readily providers supply identifiers and whether an up-to-date BIA exists. In practice, an entity with a clean contract database and a recent BIA can produce a first register in a few weeks; a group starting from scattered spreadsheets should plan for several months.

Further reading

• DORA 2026 Guide: Obligations for Financial Entities
• DORA 2026: First Audit Cycle, What to Expect
• DORA vs NIS2: which applies to your organisation?
• Business Continuity Plan: 8-Step Guide for 2026
• Business impact analysis guide

A register of information is not a yearly deliverable: it is a snapshot, on a given date, of supplier relationships you manage all year round.