The first DORA Register of Information collections in 2025 taught the industry an uncomfortable lesson: the hard part is not the legal analysis, it is relational data quality. Registers bounced on lapsed LEIs and broken keys far more often than on substance. With the ESAs publishing an explicit list of validation checks, 116 in the current cycle, passing has become an engineering problem with an engineering solution.
What is the DORA Register of Information and who must file it?
The Register of Information (RoI) is the structured, machine-readable inventory of every contractual arrangement a financial entity holds with ICT third-party service providers, required by Article 28(3) of DORA. Nearly all EU-regulated financial entities, banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, must maintain it and submit it through their competent authority.
The format is fixed by Implementing Regulation (EU) 2024/2956, and the data feeds two supervisory machines: national oversight of your ICT third-party risk, and the ESAs' designation of critical ICT third-party providers. Annual collections have run since 2025; reference dates and submission windows are set through national competent authorities, so confirm the current calendar with yours rather than reusing last year's dates.
If you sell software or cloud to financial entities, you are the row, not the filer: customers will ask for your LEI, your subcontractor chain, and your exit support. That supplier-side view is covered in DORA for Non-Banks: The Operational-Resilience Work Nobody Scoped.
How is the register structured?
The implementing technical standard defines a set of linked relational templates, 15 in the package used for the first collections, covering the filing entity, contractual arrangements, ICT providers, their supply chains, and the functions each service supports. Templates join through shared keys: LEIs, contract reference numbers, ICT service-type codes, and function identifiers. Break a key and validation fails.
The template families, roughly:
- ▸B_01.x, the entity or group maintaining the register and the entities in scope.
- ▸B_02.x, contractual arrangements: general terms, service-level detail, intra-group arrangements.
- ▸B_03.x, the links between entities and arrangements.
- ▸B_04.01, the entities signing the arrangements.
- ▸B_05.x, ICT providers and their subcontracting chain, with a rank per link.
- ▸B_06.01, the entity's functions and their criticality assessment.
- ▸B_07.01, ICT services supporting critical or important functions, including substitutability and exit-related fields.
Service types come from a fixed taxonomy (S01 through S19 in the current annex). Filing formats differ by authority, some accept plain CSV packages, others expect xBRL-CSV through supervisory portals, so check your NCA's filing rules and verify template names against the current ITS annexes, not a consultant's slide.
What are the 116 data-quality checks?
Ahead of each collection the ESAs publish the exact validation checks registers must pass, a list of 116 checks in the current cycle, split into blocking errors that cause rejection and non-blocking warnings. They test file structure, referential integrity across templates, code-list membership, and business logic such as criticality consistency. Download the current list from the ESAs' DORA pages.
The checks cluster into five families:
- ▸Structural: files present, columns matching the taxonomy, correct encoding and separators.
- ▸Referential: every contract reference in a link template must exist in the arrangement template; every provider referenced must exist in the provider template; no orphan rows.
- ▸Domain: LEIs valid against ISO 17442, country codes against ISO 3166, currencies against ISO 4217, dates in ISO 8601.
- ▸Conditional completeness: fields that become mandatory depending on entity type, provider type, or criticality flags.
- ▸Business logic: a service flagged as supporting a critical or important function must carry the corresponding assessment fields; start dates cannot postdate end dates.
The list evolves between cycles and checks have been tightened, so pin the version you validate against and diff each new release before you rebuild.
Which checks fail most often?
Public feedback from the ESAs' 2024 voluntary dry run and the 2025 collections points to a stable failure pattern: missing or lapsed provider LEIs, broken contract-reference keys across templates, misuse of the service-type taxonomy, malformed dates, and empty subcontracting chains. These are data-plumbing defects, not legal ones, good news, because plumbing is fixable.
- ▸Identifier failures: non-EU SaaS vendors without an LEI, LEIs that lapsed at GLEIF, or the wrong identifier type where the ITS prescribes a hierarchy of acceptable codes.
- ▸Broken keys: a contract renamed in one template but not the others; duplicates introduced by copy-paste; keys regenerated on every export so nothing joins across cycles.
- ▸Taxonomy misuse: tagging everything with one generic service type, or cramming several service types into a single row where the design expects one row per service type per arrangement.
- ▸The Excel round-trip: leading zeros stripped, dates silently localized, separators swapped, spreadsheets corrupt registers with great reliability.
- ▸Missing subcontractors: procurement never captured the chain beneath the direct provider, so rank-two-and-beyond rows are simply absent.
How do you remediate a failing register?
Stop hand-editing the submission files. Fix the sources instead: pick one system of record each for contracts, vendors, and functions; make the contract reference number an immutable spine; regenerate the templates from those sources with a pipeline; and run the published checks locally until blocking errors reach zero, before your authority runs them for you.
A remediation sequence that works:
- ▸Triage by check ID: group the rejection report by rule, not by row, one root cause typically explains dozens of failures.
- ▸Assign column owners: legal owns contract dates, procurement owns providers and chains, IT owns service mappings, risk owns criticality assessments.
- ▸Repair identifiers first: validate every LEI against the GLEIF API and chase vendors for missing or lapsed registrations, vendor lead time is measured in weeks, so start early.
- ▸Stabilize keys: contract references live in the contract system and never get invented at export time.
- ▸Regenerate, never patch: the submission package is a build artifact; if it is wrong, fix the source and rebuild.
This is the same evidence-as-code philosophy we apply to ISMS tooling in ISO 27001 Evidence as Code: Building an ISMS Engineers Don't Hate.
How should you automate validation before submission?
Encode every published check as an executable test against your generated package: schema assertions, join checks for referential integrity, code-list membership against the ISO and ESA lists, and live LEI status lookups against GLEIF. Run the suite in CI on every register rebuild so a defect surfaces in a pull request, not in a supervisor's rejection letter.
- ▸Keep register source data in version control or a small database schema, every change reviewed, every reference date a tagged snapshot.
- ▸A few hundred lines of Python with pandas covers most of the checks; data-quality frameworks in the Great Expectations style work as well.
- ▸Where your authority expects xBRL-CSV, validate the package with taxonomy tooling before upload rather than treating the portal as your first test run.
- ▸Keep the rejection-to-resubmission history: it is audit evidence of a functioning control, and DORA supervision rewards exactly that.
What governance keeps the register clean between collections?
Make updates event-driven: a new ICT contract, a renewal, a subcontractor change, or an exit each triggers a register change with a named owner and a deadline measured in days, not quarters. Reconciling quarterly against accounts payable and your SSO application inventory catches the vendors nobody registered before the annual collection does.
- ▸The register is the index into the rest of DORA: pre-contract due diligence, concentration-risk analysis, and exit strategies for critical functions all hang off its rows, the operational side is covered in DORA in Practice: What Resilience Really Asks of Your Stack.
- ▸Vendor onboarding should not close until register fields are complete, the same gate NIS2 entities are building for supplier due diligence, described in NIS2 Supply-Chain Security in 2026: Who Is in Scope, How to Vet Vendors, and How to Build Auditable Software.
- ▸Smaller entities can fold this into one compliance calendar, see The 2026 SME Cybersecurity Checklist for GDPR, NIS2 and DORA.
How TuniCyberLabs helps
We build register pipelines end to end: source-system integration, the full published check list as an executable validation suite, GLEIF-backed identifier hygiene, and the governance hooks that keep the register current between collections. If your last submission bounced, or you would rather the first one did not, our engineering services cover it.