SafeDORA — DORA Register of Information validator & xBRL-CSV converter

DORA Register of Information: what has to be submitted

Under Article 28(3) of the Digital Operational Resilience Act (Regulation (EU) 2022/2554), every financial entity keeps a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers. The content and the 15 templates are fixed by Commission Implementing Regulation (EU) 2024/2956 (the ITS on registers of information). Once a year the register is sent to the national competent authority, which forwards it to the European Supervisory Authorities (EBA, EIOPA, ESMA) for the designation of critical ICT third-party providers.

From 2026 onwards the register is reported with a reference date of 31 December of the preceding year, and competent authorities must deliver the registers to the ESAs by 31 March. Each authority sets its own, earlier window. In 2026, for example, the Dutch central bank (DNB) asked for registers by 20 March, BaFin opened its window from 9 to 30 March and the Central Bank of Ireland from 2 to 31 March. The next register has reference date 31 December 2026 and is due in Q1 2027 — check your authority's announcement for the exact dates.

The format: xBRL-CSV (plain-csv) reporting package

The register is not submitted in Excel. The ESAs collect it as a ZIP of CSV files described by the EBA taxonomy (reporting framework 4.0, DORA module DORA010100). Several authorities that converted Excel for firms in 2025 stopped doing so in 2026 — the AFM, for example, now accepts only xBRL-CSV. The package layout used by the ESA sample files:

529900T8BM49AURSDO55.CON_DE_DORA010100_DORA_2026-12-31_20270302101500000.zip
└─ 529900T8BM49AURSDO55.CON_DE_DORA010100_DORA_2026-12-31_20270302101500000/
   ├─ META-INF/reportPackage.json      {"documentInfo":{"documentType":"https://xbrl.org/report-package/2023"}}
   └─ reports/
      ├─ report.json                   extends http://www.eba.europa.eu/eu/fr/xbrl/crr/fws/dora/4.0/mod/dora.json
      ├─ parameters.csv                entityID rs:<LEI>.CON|IND, refPeriod, baseCurrency, decimalsInteger, decimalsMonetary
      ├─ FilingIndicators.csv          B_01.01 … B_99.01, all "true" (empty templates included)
      └─ b_01.01.csv … b_99.01.csv     header row of column codes (c0010 …), drop-down values as EBA codes (eba_GA:DE)

The file name is ReportSubject.CON|IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip: the LEI of the reporting entity, CON for a consolidated or IND for an individual register, the two-letter country code, DORA010100, DORA, the reference date and a 17-digit creation timestamp. The entityID parameter must match the LEI and level in the file name.

The 15 templates

Why registers get rejected — and how SafeDORA checks for it

The ESAs validate in layers. Technical checks on reception reject the whole file: a wrong file name or folder layout, missing report.json, parameters.csv or FilingIndicators.csv, a filing indicator that is not true, an unknown column code, a CSV formatting problem, an empty key field (check 805) or a reference that does not resolve between templates (check 807). Files that pass are then run through DPM technical checks (dates as yyyy-mm-dd, integers, allowed drop-down codes, duplicate keys), the EBA validation rules and LEI/EUID look-ups; those findings come back as data-quality feedback that the authority may ask you to fix.

SafeDORA implements the reception checks it can see in the package, the key and foreign-key constraints defined in the taxonomy (R1–R22), the data types and allowed values of all 15 templates, the active EBA existence and consistency rules, and the ISO 17442 LEI check digits. The most common blocking problems it finds:

• 807 — B_02.02 function not in B_06.01. Every function identifier used in B_02.02 must exist in B_06.01 for the same entity LEI (reference R7).
• 807 — contract + provider not in B_03.02. Each contract reference and provider code pair in B_02.02 needs a B_03.02 row (R17).
• 807 — LEI not in B_01.02. Entities in B_03.01, B_03.03, B_04.01 and B_06.01, and the parent in B_01.02.0060, must be listed in B_01.02. A single typo in one LEI breaks every reference to it.
• 807 — ultimate parent not in B_05.01. B_05.01.0110 refers back to B_05.01 (R18): list the parent as a provider row, or report the provider's own code if it has no parent.
• 805 — empty key. Key fields such as B_02.02.0130/0150/0160 (countries), B_04.01.0040 (branch) and B_02.01.0030 must never be blank. Use the “Not applicable” option or type “Not applicable” where the ESAs' FAQ says so.
• 808 — filing indicator false. All 15 templates must be declared true; a template without data is sent as a CSV with only the header row.

How to use SafeDORA

1. Download the blank Excel template (one sheet per template, EBA drop-downs, key columns marked) or use your own workbook — any sheet named like B_02.02 with a header row of column codes or column names is recognised.
2. Open the workbook here. Fix everything marked Blocking first, then errors, then warnings. Click a template in Templates to see the offending cells highlighted.
3. Check the settings (LEI, CON/IND, country, reference date 2026-12-31) and download the xBRL-CSV package. Re-open the ZIP in SafeDORA to confirm it passes, then upload it to your authority's portal.
4. Next year, open last year's package and convert it to an editable Excel workbook instead of starting from scratch.

Taxonomy version

SafeDORA follows the EBA reporting framework 4.0 DORA module (dora/4.0/mod/dora.json, module version 1.1.0, valid from reference date 31 March 2025 with no end date). The EBA's reporting framework 4.2 left DORA on release 4.0, and the EBA lists amendments to DORA in a later release (4.4, phase 2, from 09/2027). When a new DORA module is published, SafeDORA will be updated; the validation rules and drop-down codes are generated directly from the official taxonomy files.

FAQ