DORA Register of Information Template

"Do you have an Excel template?" is the first question every team asks — and the honest answer is that no single official file exists. Here's what actually defines the template, how to build a working one, and how to validate it before you file.

In short — There is no official DORA register of information Excel template. The binding structure is the EBA's 15-table taxonomy (Commission Implementing Regulation (EU) 2024/2956), filed as xBRL-CSV, not a free spreadsheet. A usable working template mirrors those 15 tables, their foreign keys and closed-list values — then gets converted and validated before submission.

Why there's no official Excel template

The DORA Register of Information isn't submitted as a spreadsheet a supervisor opens and reads. It is filed in xBRL-CSV, a machine-readable format defined by the EBA, built from the taxonomy and the DPM (Data Point Model) dictionary. So when people ask for "the template," what they actually need isn't a file to download and fill in — it's a data model: a fixed set of tables, columns, formats and permitted values that any submission has to match, whatever software produced it.

Looking for an Excel template is looking for the wrong object. What matters is the structure, and whether it holds together end to end.

That distinction matters because the exact filing deadline is an annual obligation whose precise date should be confirmed with your national competent authority — in France, the AMF or ACPR via OneGate — rather than assumed from a template you found online, since the taxonomy version, and sometimes the calendar, can change from one reporting cycle to the next.

What the real template contains: 15 tables, 8 groups

The structure set by Commission Implementing Regulation (EU) 2024/2956 covers eight areas: entity information, contractual arrangements, signatories, service usage, ICT providers, functions, assessments and definitions — 15 templates in total (the B_xx.xx tables), each with its own fields, formats and closed lists. B_02.01 (arrangements — general information) is the hub: every contractual arrangement gets a unique reference there, reused as a foreign key by most of the others. Full breakdown of every table and how they connect: the 15 templates of the register.

Building your working file before conversion

Most teams still start in a spreadsheet, and that's fine — as long as it's built to survive the conversion step rather than becoming a dead end. A working file that actually maps onto the EBA structure typically:

• uses one tab per relevant table (at minimum B_01.01, B_02.01, B_02.02, B_03.01/B_03.02, B_05.01, B_05.02, B_06.01, B_07.01);
• reuses the same reference columns across tabs — arrangement ID, provider code, function ID — so the relationships between tables can be checked before conversion;
• respects closed-list values exactly as defined in the EBA's DPM dictionary (country codes, entity types, criticality flags) instead of free text;
• formats every date in ISO 8601 (YYYY-MM-DD);
• records each provider's LEI only after checking it against GLEIF, since an invalid or mistyped LEI is one of the most common rejection causes.

Once the data is clean, it still has to be packaged as xBRL-CSV and checked for consistency — that's the difference between a spreadsheet that looks complete and a register that actually gets accepted for processing.

Example: one entry across the template

Take a simple case — a contract with a cloud provider hosting the core banking platform. Here's how a single arrangement plays out across several linked tables (values below are fictional, illustrative only):

Break one link in that chain — an ARR-2026-014 missing from B_02.01, an F-014 absent from B_06.01 — and the whole submission is rejected, even though every individual field looks correctly filled in. That's the foreign-key logic covered in detail in the 15 templates, and it's exactly what a step-by-step walkthrough like how to fill the register is built to prevent.

Where the official structure is defined

• the annexes of Commission Implementing Regulation (EU) 2024/2956, which describe every table and field;
• the EBA's taxonomy and DPM dictionary, which set the columns, formats and permitted values;
• the packaging format itself: the xBRL-CSV package.

None of these publish a ready-made spreadsheet — they publish the rules a submission has to satisfy, whatever tool produced it.

Pitfalls of templates found online

The stakes of getting the structure right are real: in the EBA/ESAs' 2024 dry run, only 6.5% (ESAs, 2024) of submissions passed without technical issues — and most causes were structural, not gaps in the underlying due-diligence data. Templates circulating online tend to reproduce the same failure modes:

• an outdated version of a prior taxonomy release, with columns or values that no longer match the current DPM;
• an Excel export mistaken for the final deliverable, when the filing itself must be xBRL-CSV;
• a template that ignores the links between tables, producing a file that reads fine row by row but breaks under cross-table validation.

Frequently asked questions

← The complete DORA register guide · Pre-submission checklist → · Lire en français →