DORA Register of Information: how to complete the template under Regulation (EU) 2024/2956

Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) has been directly applicable in all Member States since 17 January 2025 [1]. Unlike the NIS2 Directive, it requires no national transposition law: the European text is binding on its own. One of its most operational pieces — and one of the most demanding in terms of structured data — is the Register of Information (RoI) required by Article 28.3 [1]: a comprehensive inventory of all contractual arrangements with third-party information and communication technology (ICT) service providers.

This article explains exactly what the register requires, how Implementing Regulation (EU) 2024/2956, which sets out the templates, is structured [2], what timeline has applied to the reporting cycle in Spain, and what practical steps make it possible to build the register without discovering gaps at the last moment.

What Article 28 of DORA requires

Article 28.3 of DORA requires financial entities to maintain and update, at individual entity level and — where applicable — at sub-consolidated and consolidated group level, a register of all contractual arrangements relating to the use of ICT services provided by third-party providers [1]. The register is not a free-form document: it must make it possible to identify, among other elements:

• Each ICT provider engaged, whether directly or through a subcontracting chain.
• The functions of the entity that each ICT service supports, distinguishing whether they are critical or important functions.
• The group entities that sign or use each contract.
• Provider assessment elements: substitutability, concentration risk and data location, among others.

The entity must report this information to its competent authority at least annually, and make it fully available to the authority on request [1] [3].

Implementing Regulation (EU) 2024/2956: the mandatory templates

On 29 November 2024 the European Commission adopted Implementing Regulation (EU) 2024/2956, which establishes the implementing technical standards (ITS) with the standardised templates for the register of information [2]. The Regulation was published in the Official Journal of the EU on 2 December 2024 [2], entering into force twenty days after publication (around 22 December 2024), and it is directly applicable, with no scope for national adaptation of the templates' content.

The Regulation is divided into two parts:

• Part I — Templates. Structured forms grouped into families, identified with the prefix B_ followed by a series and template number (for example, B_02.01).
• Part II — Instructions. Column-by-column guidance: the required format for each data field (ISO dates, LEI codes, closed value lists), which fields are mandatory and which conditional, and how to link records across templates using common identifiers [2].

The template families broadly cover:

1. Entity identification (series B_01): data on the reporting financial entity itself, and on group entities where the register is sub-consolidated or consolidated.
2. Contractual arrangements (series B_02): each ICT service contract, with its characteristics and duration, and — notably — its links to intragroup arrangements, so as to trace the full chain from the master contract to the end provider [2].
3. Signing entities (series B_03): which group entities are party to each contract.
4. Users of the ICT service (B_04.01): which group entities actually use each service, beyond who signs it.
5. Third-party providers and the subcontracting chain (series B_05): identification of each provider and, specifically in B_05.02, the mapping of subcontractors in sequential order, limited to those that actually support a critical or important function.
6. Supported functions (B_06.01): which business function of the entity depends on each ICT service, and whether that function is critical or important under the definition in Article 3.22 of DORA [1].
7. ICT service assessment (B_07.01): assessment of substitutability, the impact of a disruption and other concentration-risk factors.
8. Terminology (B_99.01): a table of permitted values and definitions serving as a cross-reference for the other templates.

The underlying logic is that the register is not a list of providers but a graph of relationships: contract → signing entity → user entity → supported function → provider → subcontractor. Any entity that tries to fill in the templates without first mapping that graph internally will discover inconsistencies late, during file validation.

Submission format: plain-CSV

According to the technical reporting specifications published by the European Supervisory Authorities (EBA, ESMA and EIOPA, together "the ESAs"), the required format for the official submission of the register of information is a simplified plain-CSV: one CSV file per template, packaged into a .zip, in accordance with the filing rules and the taxonomy published by the ESAs. This plain-CSV can optionally be validated against the xBRL-JSON metadata of that taxonomy [3]. This is the same format already tested in the 2024 "Dry Run" exercise, and the one that competent national authorities receive from entities and, in turn, forward to the ESAs [3].

The exact channel each financial entity must use to submit its information to its competent national authority may vary depending on the sectoral supervisor and the reporting cycle; it is advisable to confirm it against the current operational guidance of each supervisor before building the export file. As for the technical format, this should be confirmed against each national authority's specifications, since Implementing Regulation (EU) 2024/2956 does not set a single mandatory technical format but instead refers to the reporting standards of the European Supervisory Authorities.

Timeline: how the reporting cycle has worked

In the first information-gathering cycle of the DORA Register of Information, competent national authorities were required to forward to the ESAs the registers received from financial entities, as part of the process to identify and designate critical ICT third-party providers [4]. The exact timeline for this cycle (data reference dates, submission windows) should be confirmed against the current specifications of the European Commission and the ESAs [4]. Based on that collection exercise, the ESAs carry out criticality assessments and notify ICT providers of their possible designation as critical, opening a period during which the provider may submit representations before the final designation; the exact duration of that period and the notification process should be confirmed against the official ESA communication in force for each cycle.

In Spain, the CNMV has published operational guidance on the register of technology service providers under DORA, addressed to entities under its supervision [5] [6]. Supervision of DORA in Spain is distributed, depending on the type of entity, among the Banco de España (credit institutions), the CNMV (investment services entities and markets) and the Dirección General de Seguros y Fondos de Pensiones (DGSFP, the Directorate-General for Insurance and Pension Funds) (insurers), in coordination with the ESAs. The exact timeline for submission, submission windows and remediation deadlines may vary depending on the cycle and the competent authority; it is advisable to confirm specific dates and deadlines against the current operational guidance of each supervisor (Banco de España, CNMV, DGSFP) before building the export file.

For cycles after the initial one, the ESAs have introduced a more proportionate approach, under which entities without material changes since the previous cycle may confirm that their situation remains unchanged instead of resubmitting the full register, following the instructions of their national authority [3]; the exact scope and conditions for qualifying for this simplification in the current cycle should be confirmed with that authority.

Practical steps for building the register

1. Inventory all ICT service contracts, not just the "big" ones. DORA does not distinguish by contract value, but by whether the service supports a critical or important function. A low-cost contract that sustains an essential function belongs in the register; an expensive one that does not support such a function may not. The first task is therefore functional mapping, not spend analysis.

2. Classify each business function as critical, important or neither. This classification, required under Article 3.22 of DORA [1] and captured in template B_06.01 [2], is what determines which providers and subcontractors fall within the detailed scope of the register (including the subcontracting chain in template B_05.02). It is advisable to document the classification criteria used, as this will be subject to supervisory review.

3. Trace the subcontracting chain only as far as DORA requires, not further. Template B_05.02 only requires mapping subcontractors that actually support a critical or important function [2]. Attempting to map the entire subcontracting chain of every provider, without that filter, multiplies the effort without adding compliance value.

4. Separate the signing entity from the user entity. Templates B_03 and B_04 explicitly require this distinction [2]. In groups with centralised procurement (one subsidiary signs, several use the service), this is a point where registers built "by hand" tend to fail first.

5. Assign an internal owner for the register and its update cycle. The register must be kept up to date, not generated once a year purely for regulatory submission [1]. Every addition, removal or change to an ICT contract — especially one supporting a critical or important function — should trigger an update to the register, with a clear owner (typically in the ICT risk or compliance function) rather than solely in operational IT.

6. Validate the file against the taxonomy before the deadline. Given the structured format (plain-CSV, validatable against the xBRL-JSON metadata of the DORA taxonomy) [3], format errors — data types, malformed LEI codes, broken cross-references between templates — are the most common cause of rejection or of the need for remediation. Reserve time before the submission window closes for this validation, rather than leaving it for the last day of the deadline.

7. Coordinate with critical ICT providers on information only they can supply. Some fields in templates B_05 and B_07 — for example, elements relating to substitutability or the exact location of data processing within subcontracting chains — require information that the provider must supply contractually. This should be built in as a standard clause in new ICT contracts and in the review of existing ones, rather than discovered while completing the register.

Where HodeiShield fits in

The most costly part of maintaining the Register of Information is not filling in the template once, but keeping it alive: every new provider, every contract renewal or every change of subcontractor must be reflected without rebuilding the inventory from scratch. HodeiShield, Hodeitek's solution for third-party and supply-chain risk, is designed to sustain that kind of provider and dependency inventory on a continuous basis, supporting the third-party ICT risk management process that DORA requires — without replacing the financial entity's own compliance judgement and responsibility, since it remains the entity that certifies the register to its supervisor.

Sources

[1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32022R2554

[2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024 — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=OJ:L_202402956

[3] EBA/ESAs — DORA Register of Information reporting: Questions & Answers (FAQ), 28 de marzo de 2025: https://www.eba.europa.eu/sites/default/files/2025-03/31bb6e60-7d10-4405-a8c5-9f04934630ac/20250328%20-%20DORA%20RoI%20reporting%20FAQ%20(updated).pdf

[4] EBA — Press release: The ESAs announce timeline to collect information for the designation of critical ICT third-party service providers under DORA: https://www.eba.europa.eu/publications-and-media/press-releases/esas-announce-timeline-collect-information-designation-critical-ict-third-party-service-providers

[5] CNMV — Comunicación/guía operativa sobre el registro de proveedores de servicios tecnológicos conforme a DORA (PDF): https://www.cnmv.es/DocPortal/Ciberseguridad/Comunicacion_registro_proveedores_es.pdf

[6] finreg360 — Alerta: La CNMV publica una guía operativa sobre el registro de proveedores de servicios tecnológicos de acuerdo con el reglamento DORA: https://finreg360.com/alerta/la-cnmv-publica-una-guia-operativa-sobre-el-registro-de-proveedores-de-servicios-tecnologicos-de-acuerdo-con-el-reglamento-dora/

[7] CNMV — Portal de ciberseguridad: https://www.cnmv.es/portal/ciberseguridad?lang=en

Sources

• [1] Reglamento (UE) 2022/2554 del Parlamento Europeo y del Consejo (DORA) — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32022R2554
• [2] Reglamento de Ejecución (UE) 2024/2956 de la Comisión, de 29 de noviembre de 2024 (plantillas del registro de información) — EUR-Lex: https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=OJ:L_202402956
• [3] EBA/ESAs — DORA Register of Information reporting: Questions & Answers (FAQ), versión de 28 de marzo de 2025: https://www.eba.europa.eu/sites/default/files/2025-03/31bb6e60-7d10-4405-a8c5-9f04934630ac/20250328%20-%20DORA%20RoI%20reporting%20FAQ%20(updated).pdf
• [4] EBA — Press release: The ESAs announce timeline to collect information for the designation of critical ICT third-party service providers under DORA: https://www.eba.europa.eu/publications-and-media/press-releases/esas-announce-timeline-collect-information-designation-critical-ict-third-party-service-providers
• [5] CNMV — Comunicación/guía operativa sobre el registro de proveedores de servicios tecnológicos conforme a DORA (PDF): https://www.cnmv.es/DocPortal/Ciberseguridad/Comunicacion_registro_proveedores_es.pdf
• [6] finreg360 — Alerta: La CNMV publica una guía operativa sobre el registro de proveedores de servicios tecnológicos de acuerdo con el reglamento DORA: https://finreg360.com/alerta/la-cnmv-publica-una-guia-operativa-sobre-el-registro-de-proveedores-de-servicios-tecnologicos-de-acuerdo-con-el-reglamento-dora/
• [7] CNMV — Portal de ciberseguridad: https://www.cnmv.es/portal/ciberseguridad?lang=en