How to complete your DORA register of information
The register of information is DORA's most concrete deliverable — and the one national authorities collect first. It's also where most firms lose time, because it's not a list, it's a set of interlinked tables that have to be internally consistent. This guide walks the whole thing: what it is, the tables and the fields, how to fill it in order, the traps that bounce a submission, and how to keep it current.
In one line: the register is a structured inventory of every ICT third-party arrangement — 60+ fields across linked tables. Build it in the right order, keep the references consistent, and it passes; do it ad-hoc in a spreadsheet and it bounces.
What the register actually is
Under DORA's third-party risk rules, every financial entity must maintain a register of information covering all contractual arrangements for the use of ICT services. It records who your ICT providers are, what they do for you, how critical that is, where your data sits, and how the chain of sub-outsourcing runs. It feeds straight to your supervisor, who validates it against a published rule set — so structure and consistency matter as much as content.
The tables, in plain English
The official template isn't one sheet — it's a set of linked tables. The ones that matter most:
| Table | What goes in it |
|---|---|
| Entity & group | Your own entity (and group, if relevant), each identified by LEI. |
| Contractual arrangements | Every ICT contract — reference, dates, term, governing law. |
| ICT third-party providers | Each provider, by LEI, with type of service. |
| Functions supported | The business functions each service supports, and whether they're critical or important. |
| Assessments & sub-outsourcing | Criticality assessment, data locations, and the sub-outsourcing chain. |
The tables reference each other — a contract points to a provider, a provider points to the functions it supports. Break a reference and the whole register fails validation.
How to fill it, in order
- List your entities and get the LEIs right — yours and your providers'. A missing or wrong LEI is the single most common bounce.
- List every ICT contract. Don't forget the small ones — monitoring tools, email, KYC vendors all count.
- Map each contract to the function it supports, and flag which functions are critical or important.
- Assess criticality consistently — the same logic across providers, documented.
- Capture sub-outsourcing — who your providers rely on in turn (the chain supervisors care about most).
- Check the references line up across every table before you submit.
The traps that bounce a submission
- Invalid or missing LEIs for providers.
- Contracts that reference a provider not listed in the provider table (broken links).
- Inconsistent criticality between tables.
- Missing data-location or sub-outsourcing fields for critical services.
- Free-text where a controlled value (a code from the taxonomy) is required.
Spreadsheet or tool?
The EBA Excel template is free and fine for a handful of contracts. But it doesn't enforce the relationships between tables, so the consistency checks fall on you — and that's exactly what authorities validate against. A guided builder enforces the structure as you go, so you fix errors before submission, not after a bounce.
Build a register that passes — free
Start the free register builder →Keeping it current
The register is a living document. Add new providers, update changed contracts, and re-assess criticality as it shifts — and keep it ready to produce on request. A register that was right in January and never touched since is a finding waiting to happen.
Common questions
What is the DORA register of information?
A structured inventory of all your ICT third-party contractual arrangements — 60+ fields across interlinked tables covering providers, contracts, the functions supported, criticality, data locations and sub-outsourcing.
Is there an official template?
Yes, an Excel/CSV template via the EBA. It works but is error-prone by hand, because the tables must stay consistent and authorities validate against a long rule set.
Who has to file one?
Every financial entity in scope of DORA — including crypto CASPs, payment and e-money institutions, investment firms and more.
General information, not legal advice. Confirm the current requirement against DORA (Regulation (EU) 2022/2554), the relevant ITS/RTS and your national competent authority before you rely on it.