Register of Information
Register of Information (RoI): the mistakes that caused submissions to fail in 2025
Format, governance, incomplete data: why many DORA register of information submissions failed in 2025, and how to avoid it.

The register of information — the RoI — is one of the most concrete, and most dreaded, points of DORA. It is the document that lists all your contractual arrangements with ICT service providers. It is submitted annually to the supervisor, which forwards it to the European authorities to identify critical ICT third-party providers (CTPPs).
The first submission campaign, in 2025, was revealing: many institutions stumbled. And rarely for the reasons they imagined. Here are the most frequent causes of failure, as they emerge from the regulator's feedback, and how not to repeat them.
Mistake #1 — Underestimating an unusual technical format
The RoI is not a classic office document. It is submitted in xBRL-CSV format (known as « plain CSV »), filed via the OneGate portal in a specific technical envelope — and not through the usual reports tab, but through a dedicated deposit from the home page.
This unusual format caught many filers off guard. The operational lesson is clear: you must carry out a test submission in the homologation environment before the actual deadline. Discovering the validation rules on submission day means risking a technical rejection with no margin to correct.
Mistake #2 — Not anticipating the scale of internal governance
The regulator's second observation is subtler: producing a quality RoI mobilises far more people than expected. You need to gather information that lives in different departments — legal (the contracts), procurement (the providers), IT (the technical services and their criticality), compliance (the link to critical functions).
Many entities approached the RoI as a late data-entry exercise, when it actually requires cross-functional governance and collection organised upstream. Without that, you end up with a patchy register, assembled in a rush.
Mistake #3 — Incomplete or poor-quality data
This is the crux. The RoI expects precise information for each provider: identification (legal name, LEI or equivalent identifier, country of establishment), service description, classification of supported functions (critical/important or not), location of data and processing centres, key contractual clauses.
Several pitfalls recur:
- Missing or incorrect identifiers. An LEI (or an EUID) is required for providers that are companies. Omissions and invalid codes are a classic cause of rejection.
- Incomplete asset mapping. Shadow IT, locally developed applications and interconnections with subsidiaries frequently escape the inventory.
- Standalone vs framework contract confusion. The register expects this distinction, and it is often poorly filled in.
- Misunderstood provider scope. You must declare all ICT providers whose service the entity uses, regardless of who signs the contract.
The ACPR has, moreover, set up a team dedicated to analysing the quality of submitted data. Completeness and consistency are no longer optional.
Mistake #4 — Forgetting concentration analysis
The RoI is not just an inventory: it serves to identify concentration risks, i.e. situations where several critical functions depend on the same provider, or a limited number. This analysis must also cover cascading subcontracting. A register that lists providers without allowing this reading misses its purpose.
Mistake #5 — Treating the RoI as a one-off exercise
The RoI is submitted annually, but it must live all year round. Every new provider, every amendment, every change of criticality must be reflected in it. Entities that start from a frozen file for each campaign start from scratch and reintroduce the same mistakes. Those that maintain a continuous register submit an already-clean document.
What distinguishes a successful submission
In summary, a successful RoI submission rests on four reflexes: anticipate the format and test in homologation, organise cross-functional collection, guarantee data quality and completeness, and keep the register alive rather than rebuilding it each year.
Where Axenia fits in. Axenia structures your register of information from your existing data, links each contract to its provider and to the functions it supports, highlights concentrations, and keeps everything up to date on a continuous basis — turning the annual submission from a dreaded chore into a simple extraction.
Go further
Pillar guide: DORA register of information: complete guide.
This article summarises public feedback on the implementation of DORA and does not constitute legal advice. Refer to the official texts and to your competent authority's FAQ.
