The register of information is one of the most concrete DORA deliverables, and one competent authorities can ask to see. Under Article 28, every in-scope financial entity must maintain a structured record of all its ICT third-party arrangements. Here is how to build a credible first draft without boiling the ocean.
What the register is for
The register is the backbone of DORA's third-party-risk pillar. It gives your board and your supervisor a single, structured view of who you depend on for ICT services, which of those dependencies support critical or important functions, and how each arrangement is governed. It is also the dataset the European Supervisory Authorities use to identify systemically important providers for the oversight framework.
Start with the arrangements that matter
You do not need a perfect register on day one; you need an accurate one that grows. Begin with the arrangements supporting critical or important functions, core banking or payments hosting, key data providers, and anything whose failure would stop you serving clients. Capture, for each:
- the provider's legal name and identifier (LEI where available),
- the type of ICT service and the function it supports,
- whether it supports a critical or important function,
- contract start and end dates,
- sub-outsourcing, and
- whether an exit strategy is documented.
Our TPP register generator builds a first-draft register in the EBA structure from exactly these fields.
The mistakes we see most
- Treating it as a one-off. The register is a living record. A new SaaS tool or a changed sub-processor means the register changes too.
- Ignoring sub-outsourcing. Sub-outsourcing is where concentration and exit risk often hide. Record the chain, not just the direct provider.
- No owner. Without a named owner and a review cadence, the register drifts out of date within a quarter.
- Skipping concentration analysis. Article 29 expects you to assess concentration risk before entering new arrangements.
Keeping it current
Wire register updates into your procurement and change processes so a new ICT contract cannot go live without a register entry. Review the whole register at least annually, and whenever a critical arrangement changes materially.
The submission format is stricter than a spreadsheet
A first draft can live in a spreadsheet, but the version you eventually submit cannot. Commission Implementing Regulation (EU) 2024/2956 sets out the actual templates: 15 tables grouped into eight areas covering entity information, contractual arrangements, signatories, service usage, ICT providers, functions, and risk assessments. Competent authorities collect registers in xBRL-CSV format built on the EBA's reporting taxonomy, with coded fields (LEI codes for providers, ISO country and currency codes, standardised ICT service-type codes) rather than free text. The register has an annual reference date of 31 December, and entities report to their competent authority by 31 March the following year, so the fields you choose for a first draft are worth mapping straight to the ITS template structure rather than reworking them later.
For a full view of your third-party-risk maturity, and the other four pillars, run the DORA Readiness Score, or read the complete compliance checklist.
Frequently asked questions
Does the DORA register of information have to be in a specific file format?
How often must the register of information be submitted?
What does the register template actually cover?
Sources
- Regulation (EU) 2022/2554 (DORA), Article 28, EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2956 (ITS on register-of-information templates), EUR-Lex.
- European Banking Authority, Implementing Technical Standards to establish the templates for the register of information.
Last updated: 17 July 2026.