DORA register of information: why almost no one passes first time
In the 2024 dry run by the European Supervisory Authorities, 1,039 entities submitted their ICT third-party Register of Information, and of the 947 registers that reached analysis only 6.5% passed all the data quality checks. The Register is not a project you close: it is an annual obligation, and the figure shows the problem is not understanding what is asked, but sustaining data quality at scale.
What the register of information is, and why it returns every year
DORA (Digital Operational Resilience Act) is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. It requires EU banks, insurers and investment firms to withstand ICT disruptions and threats, respond to them and recover. It has applied since 17 January 2025.Read more → DORA (Regulation (EU) 2022/2554), fully applicable since 17 January 2025, requires in its Article 28(3) the maintenance of a Register of Information: the structured inventory of every contractual arrangement with ICT service providers. The format is set by Implementing Regulation (EU) 2024/2956, and the entity reports it to its competent authority at least once a year: in the first window, the ESAs decision set 31 March 2025 as the reference date and competent authorities were to forward the registers to the ESAs by 30 April 2025 at the latest.The operational consequence many entities underestimate: it is not a one-off deliverable. Every year you have to rebuild a register consistent with the entity's contractual reality at that moment. Whatever is not versioned gets redone by hand.
The anatomy: one register, many linked templates
The Register is not a table. It is a set of interrelated templates, each describing one face of the same map:
| Template | What it holds |
|---|---|
| Entity | The obliged entity and its group. |
| Contractual arrangements | Each contract with an ICT provider, with its unique reference. |
| ICT providers | The third parties, identified by LEI or EUID. |
| Subcontracting | The chains of subcontractors that sustain the service. |
| Functions | The entity functions each arrangement supports, and their criticality. |
The integrity of the whole hinges on one key: the contractual arrangement reference number, which links the templates to each other. If that reference is inconsistent, the relationships break and the register no longer reconciles. In the dry run, however, 86% of the failures were missing mandatory information, according to the ESAs report, and the most frequent gap was the identification codes of ICT providers and their parent undertakings.
Why it fails: what the dry run taught
The ESAs' dry run is the best available thermometer of the real difficulty. The numbers, over the registers that reached analysis:
| Metric | Result |
|---|---|
| Participating entities | 1,039 in a voluntary, "best effort" exercise (ESA 2024 35). |
| Quality checks | 116 per register (ESA 2024 35). |
| Passed all of them | 6.5% of the 947 registers analysed (ESA 2024 35). |
| With at least one error | 886 of those 947 (ESA 2024 35). |
| Of those failing, fewer than 5 errors | Half of them (ESA 2024 35). |
The bar is not intent, it is data quality
That 93.5% failed a check in the ESAs dry run does not mean entities did not take it seriously. It means an "almost correct" register is not a submittable one: half of those that failed did so on fewer than 5 of 116 checks. The distance between "almost" and "valid" is exactly the one that is hard to close by hand.
What makes a register submittable
The lesson of the dry run is not "try harder." It is that quality at scale is built with architecture, not last-minute manual reviews:
- Structured, versioned data. The register as a relational model, not a spreadsheet rebuilt every April. Last year's is the starting point for this year's, with its history.
- Guaranteed referential integrity. The arrangement reference number links the templates by design, so an inconsistency never reaches the submission.
- Validation before you send. The ESAs' quality checks run against the register in your system, not discovered by the authority. The error is fixed before, not after.
- Identifiers validated at source. LEI and EUID formats are checked when the provider is entered, not on rejection.
The Register rewards those who treat it as live data
Whoever keeps the Register as a system (structured, versioned, continuously validated) reaches each annual window with the work nearly done. Whoever rebuilds it in a spreadsheet every April repeats the dry run result.
Conclusion: the register is a data problem, not paperwork
The Register of Information looks like a form and is, in fact, a recurring data-quality discipline. The ESAs' dry run made it clear: the concept is understood, what is hard is consistency at scale, year after year. The entity that treats the Register as live data (versioned, with referential integrity and validation before submission) turns an annual obligation into a routine. The one that treats it as a document does not.
If you are preparing your next Register of Information or want to harden this year's, at BlueUP we work DORA operational resilience as data, not documents. Start by assessing your maturity with the DORA Calculator, review the full frame in the practical DORA guide, or let's talk about your case.
Related reading
- DORA for fintech and insurtech: a practical guide and 90-day checklist — How this pillar fits a 90-day plan for growing entities.
- DORA 2026: a practical guide for financial institutions — The frame this obligation comes from.
- Anatomy of a DORA incident: from first signal to notification — DORA's other operational axis, incident response.