The DORA Register of Information, Explained

The Register of Information (RoI) is the single most operationally demanding deliverable in DORA's third-party chapter — a Deloitte survey found that 46% of financial entities rated it the hardest DORA requirement to satisfy. It is not a document; it is a machine-readable relational dataset that maps every ICT contractual arrangement your entity holds, who provides it, what it supports, and where the dependency chain leads.

Supervisors care about it for one reason: the RoI is the primary data source the European Supervisory Authorities (EBA, EIOPA, ESMA) use to designate Critical ICT Third-Party Providers (CTPPs) and to map systemic concentration risk across the EU financial system. Aggregated 2025 register data directly fed the designation of 19 CTPPs in November 2025.

Why the Register of Information matters

The RoI serves four regulatory purposes that all cascade from the same dataset:

• Supervisory oversight — lets competent authorities identify systemic dependencies across the sector.
• Entity risk management — supports your own third-party and concentration risk assessment.
• CTPP identification — feeds the ESA criticality assessment under Article 31.
• Concentration-risk analysis — reveals sector-wide reliance on a handful of providers (more than 65% of EU entities rely on at least two of AWS, Azure and Google Cloud for critical functions).

The 15 templates: a relational data model

ITS (EU) 2024/2956 defines 15 inter-linked templates. They are not independent spreadsheets — they form a relational model where a change in one table propagates expectations into the others. That relational integrity is exactly what makes automated supervisory cross-checking possible, and why incomplete submissions are easy to detect. The templates group into six layers:

The xBRL-CSV format and controlled vocabularies

Each submission is an xBRL-CSV report package containing a metadata JSON file (report-package.json), one CSV file per template named to ESA conventions, and references to the published ESA taxonomy. Coded fields will not accept free text — you must use:

• ISO 3166-1 alpha-2 country codes (DE, FR, NL …)
• ISO 4217 currency codes (EUR, USD …)
• 20-character LEI codes (ISO 17442) for every legal entity and provider
• ESA service-type taxonomy codes for ICT service classification

Submission deadlines: the Q1 2026 cycle

Each financial entity submits its register to its national competent authority (NCA) by the national deadline; the NCA then consolidates and submits to the ESAs by 30 April. The first cycle's entity deadline was 30 April 2025. For the second annual cycle, most authorities set the entity deadline at the end of Q1 2026:

Always confirm your own NCA's exact date and channel. Deadlines and submission portals are set nationally and can differ from the dates above. The 2026 cycle is more proportionate than 2025: a subset of entities must submit full data, while entities with no material change can confirm their situation is unchanged — subject to NCA instructions.

How to build and submit your register: 6 steps

The mistakes that got 2025 submissions rejected

Supervisors reported that, in the first cycle, 35–50% of contracts in the majority of banks had at least one mandatory field missing or invalid. The recurring failure modes were:

• Missing or invalid LEIs — roughly a third of submissions.
• Aggregating contracts by provider instead of one record per arrangement.
• Over-conservative criticality — classifying arrangements as non-critical to shrink scope.
• Empty sub-outsourcing templates for large cloud providers.
• Blank exit-strategy fields for critical arrangements (both a validation error and a substantive non-compliance).
• Inconsistent reference dates across templates.

For the 2026 cycle, NCAs run automated cross-referencing: inconsistencies between two entities reporting on the same provider, providers absent from registers, or sub-outsourcing chains that "don't exist" for major cloud providers are flagged immediately, with supervisory follow-up likely.

The link to CTPP oversight

The register is the funnel into the EU oversight framework. The ESAs aggregate register data, identify providers that meet the Article 31 criticality criteria, and designate them as Critical ICT Third-Party Providers. In November 2025, 19 providers were designated, each assigned a Lead Overseer (EBA, EIOPA or ESMA). Designated CTPPs must report major ICT incidents to their Lead Overseer within 2 hours and can face periodic penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance (Article 35(6)).

If one of the 19 CTPPs appears in your register, you must: verify your contracts carry the mandatory Article 30 clauses, tag the concentration risk explicitly, keep a tested exit strategy, and report the relationship to your management body. See the full list and what it means in our CTPP designations guide and the third-party risk pillar.