Register of Information
DORA register of information: complete guide
The 13 DORA register templates (Regulation 2024/2956), four join keys, reporting levels, and a practical method to maintain and submit the RoI.
The register of information (RoI) is the mandatory register that every financial entity in scope of DORA must keep and update. It lists contractual arrangements with ICT third-party service providers.
The concrete legal basis for structure and format is Commission Implementing Regulation (EU) 2024/2956 (29 November 2024), under Article 28(3) and (9) of Regulation (EU) 2022/2554. The register is provided to the competent authority on request or under the modalities it defines. It also feeds the annual designation of critical ICT third-party providers by the European Supervisory Authorities (EBA, EIOPA, ESMA).
This pillar guide maps the register: purpose, composition, how data joins together, and how to run it operationally. Satellites cover mandatory fields, xBRL-CSV format, common filing mistakes and an operating model.
Who is in scope
Credit institutions, payment institutions, investment firms, crypto-asset service providers, insurers, asset managers, and the other financial-entity types listed in Article 2 of DORA — more than twenty categories coded in the register (e.g. eba_CT:x639 for asset management companies, eba_CT:x300 for payment institutions).
Three reporting levels
- Individual entity — each financial entity keeps its own register
- Sub-consolidated — the parent of a sub-group keeps the sub-group register
- Consolidated — the ultimate parent keeps the group register
For many mid-sized French actors (asset managers, payment / e-money institutions), the individual-entity level is the realistic starting point. Multi-entity (branches, intra-group, consolidation) adds full templates (B_01.02, B_01.03, B_02.03, B_03.03) that should not be improvised the week before filing.
The 13 templates: the real structure
The register is not “one Excel of vendors”. It is a 13-template data model (B_01.01 to B_99.01) in Annex I of Implementing Regulation 2024/2956, cross-linked by shared keys.
| Code | Purpose |
|---|---|
| B_01.01 | Entity maintaining the register |
| B_01.02 | Entities in the consolidation scope |
| B_01.03 | Branches outside the home country |
| B_02.01 | Contractual arrangements — general information |
| B_02.02 | Contractual arrangements — specific information (central template) |
| B_02.03 | Intra-group arrangements linked to external ones |
| B_03.01 | Signing entities (client side) |
| B_03.02 | Signing ICT providers |
| B_03.03 | Group entities providing ICT intra-group |
| B_04.01 | Entities (or branches) using the ICT services |
| B_05.01 | ICT provider identity sheets (direct, subcontractors, ultimate parents) |
| B_05.02 | Supply chains (subcontracting ranks) |
| B_06.01 | Internal functions supported by ICT services |
| B_07.01 | ICT service assessments (substitutability, audit, exit plan) |
| B_99.01 | Internal terminology for closed lists |
B_02.02 is the operational core: one row per combination of arrangement × using entity × provider × function × ICT service type. One contract covering three functions and two service types can generate up to six rows.
Four keys that must never drift
- Contractual arrangement reference number — internal ID assigned by the entity
- Financial-entity LEI — 20 characters,
^[A-Z0-9]{18}[0-9]{2}$ - ICT provider identification code — LEI or EUID first (strict rules by jurisdiction / natural person)
- Function identifier —
F1,F2… unique per (entity LEI + licensed activity + function name)
If these keys change every campaign, the register is rebuilt rather than maintained.
What the register forces you to know
Beyond a vendor list, the model requires among other things:
- Arrangement typology: standalone, overarching (framework), or subsequent/associated — with a mandatory link to the overarching arrangement when relevant
- 19 ICT service types (S01–S19), from project management to cloud SaaS
- Functions with criticality, RTO/RPO in hours, disruption impact
- Data location at rest and processing location, sensitivity, governing law — especially for critical or important functions
- Subcontracting chain with rank (1 = direct) and recipient at the previous rank
- Assessments: substitutability, reason if not substitutable, date of the last audit performed or mandated by the entity, exit plan, reintegration feasibility
Location / notice / sensitivity / dependency fields in B_02.02 become mandatory only if the service supports a critical or important function (assessed in B_06.01). Misclassifying criticality breaks the rest of the register.
Timeline and supervisory purpose
- 22 December 2024: Implementing Regulation 2024/2956 enters into force
- 2025: first national dry-run reporting exercises
- Submission date: set by each competent authority (in France: ACPR / AMF by entity type)
The goal is not only to deposit a file. The register lets European authorities see ICT dependency concentrations across the Union. An incomplete or technically invalid register risks both rejection and a wrong concentration reading.
Four-step method
- Governance — owner (often compliance/risk) + contributors (legal, procurement, IT, business)
- Stabilize referentials — entity → functions → providers → arrangements → chains/assessments
- Validate substance and packaging — EBA validation rules + xBRL-CSV package checks
- Maintain continuously — every new provider, amendment or criticality change updates the living model; filing becomes a dated extract
Cluster articles
- Mandatory fields of the DORA register
- XBRL-CSV format
- 2025 filing mistakes
- Operating model / template
Axenia’s role. Axenia structures the register from your contracts, third parties and functions, keeps keys stable, and prepares exports in expected formats — so the annual filing is an extraction, not a rebuild.
Educational summary based on Implementing Regulation (EU) 2024/2956 and DORA. Not legal advice. Always check your competent authority’s instructions and the EBA taxonomy / validation files in force.