DORA Register of Information Guide

The Register is a relational model

The templates link entities, providers, contractual arrangements, ICT services, supported functions and subcontracting chains through identifiers. A record that looks correct on its own can still invalidate the submission if the record pointing at it uses a different identifier.

• Entities in scope, each with an LEI
• Providers, identified by LEI or an equivalent code
• Contractual arrangements, including intragroup
• ICT services per arrangement, with function and criticality
• Subcontracting chains behind critical or important functions

The fields that break submissions

Most rejections are structural rather than substantive: missing or malformed identifiers, country codes outside the expected list, dates that disagree between the arrangement and the service, and criticality flags with no matching function record.

These are trivial individually and uncontrollable by hand once you pass a few dozen providers, because every procurement or architecture change silently invalidates part of the file.

Completeness versus correctness

A completeness score tells you how much of the Register is populated. It does not tell you whether the populated values are right. Run both: a completeness measure per template and a validation pass covering format, referential integrity and internal consistency.

Keeping it aligned between cycles

Attach Register maintenance to the events that change it: a new contract signed, a service decommissioned, a subcontractor added, an entity restructured. If those events update the underlying records, the Register is always current and the submission becomes an export.

Answering provenance questions

Supervisors ask where a value came from, who changed it and when. Keep field-level lineage so every Register value traces back to a source record and a change event.