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. 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
Digital Operational Resilience Act: reglamento UE 2022/2554 sobre resiliencia operativa digital. Exige a entidades financieras de la UE resistir, responder y recuperarse de incidentes TIC. En vigor desde 17 enero 2025. Leer más → 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 must submit it to its competent authority at least once a year (the first window closed in 2025, with a 30 April reference date).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. There, and in provider identification (a valid LEI/EUID format), is where most errors cluster.
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 (voluntary, "best effort" exercise). |
| Quality checks | Around 116 per register. |
| Passed all of them | 6.5%. |
| With at least one error | 93.5% (886 of 947 analysed). |
| Of those failing, fewer than 5 errors | ~50%. |
The bar is not intent, it is data quality
That 93.5% failed a check 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.