DORA Register of Information: What to Include, Template by Template

What the register of information is

Article 28(3) of the Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires financial entities to "maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers". The register must distinguish arrangements that cover ICT services supporting critical or important functions from those that do not.

The format is not up to you. Commission Implementing Regulation (EU) 2024/2956 sets the templates (Article 3(1)), the content (Article 5) and the instructions for every column (Annex I). The register covers all ICT services from direct providers and, for services supporting critical or important functions, the subcontractors that effectively underpin them (Article 3(2)).

The register serves three purposes: your own third-party risk management, supervision by your competent authority, and the designation of critical ICT third-party providers by the European Supervisory Authorities (ESAs), which use the collected registers to see which providers the financial sector depends on.

Who must keep one

Every financial entity in scope of DORA. Article 28(3) has no exemption for microenterprises, and the European Banking Authority has confirmed that entities using the simplified ICT risk management framework of Article 16 must also maintain the register (EBA Q&A 2025_7388). Groups keep it at entity level and at sub-consolidated and consolidated level; the consolidated register includes all financial entities and ICT intra-group service providers in the group (Article 6(2) of the Implementing Regulation).

Not sure where you stand on the rest of DORA? Our DORA compliance checklist lists 59 requirements by article, and the free DORA Compliance Checker scores your readiness across all five pillars.

Reporting: when and to whom

DORA itself requires you to make the full register, or specified sections, available to your competent authority on request, and to report to it at least yearly on new ICT arrangements (Article 28(3)). In practice, authorities collect the whole register every year:

You submit the register to your national competent authority, which forwards it to the ESAs.
From 2026, competent authorities must report the registers to the ESAs by 31 March each year, with a reference date of 31 December of the preceding year. (The first cycle in 2025 used 31 March 2025 as the reference date and a 30 April 2025 deadline.)
Your competent authority sets an earlier national deadline for you, so check its website or circulars rather than working back from 31 March.
Submissions are technical files (the ESAs publish an xBRL-CSV taxonomy, plain-CSV guidance and validation rules), so allow time for validation errors.

The 15 templates

The register is a set of linked tables. Each has a fixed number of columns and as many rows as needed, and each cell takes a single value: where more than one value applies, you add a row (Article 4 of the Implementing Regulation). The tables are tied together by a few keys, mainly the contractual arrangement reference number, the provider's identification code and the function identifier.

Template	What it records
B_01.01	The entity maintaining the register: LEI, name, country, type of entity, competent authority, reporting date
B_01.02	All entities in the scope of consolidation (only your own entity if you are not in a group), including total assets
B_01.03	Branches outside the home country
B_02.01	Each contractual arrangement: reference number, type, overarching arrangement, annual cost
B_02.02	Contract details per ICT service and function: dates, notice periods, governing law, country of service, data storage and processing locations, data sensitivity, level of reliance
B_02.03	Links between intra-group arrangements and external arrangements in the same supply chain
B_03.01	The entity signing each arrangement to receive ICT services
B_03.02	The provider signing each arrangement
B_03.03	Group entities signing arrangements to provide ICT services to other group entities
B_04.01	The entities (and branches) actually using each ICT service
B_05.01	Every provider: direct providers, intra-group providers, relevant subcontractors and their ultimate parent; identifiers, legal name, headquarters country, total annual cost
B_05.02	The ICT service supply chain, with a rank for each provider
B_06.01	Your functions: licensed activity, criticality or importance and the reasons, date of the last assessment, recovery time and recovery point objectives, impact of discontinuing
B_07.01	Assessment of each ICT service supporting a critical or important function: substitutability, last audit, exit plan, reintegration, impact of discontinuing, alternative providers
B_99.01	Your own definitions of the closed-list options you use (for example what "high" impact means for you)

The fields that take the most work

Provider identifiers (LEI or EUID)

Providers that are legal persons must be identified by a valid and active Legal Entity Identifier (LEI) or a European Unique Identifier (EUID), and both where available (Article 3(5)). For services supporting critical or important functions, you must obtain the identifiers of the relevant subcontractors through your direct provider (Article 3(6)). Many smaller software vendors have no LEI, so start asking early and record the EUID where they have one.

Functions and their criticality

Template B_06.01 needs a function identifier for each combination of your LEI, licensed activity and function, so the same function under two licences gets two identifiers. For each, you record whether it is critical or important and why, when you last assessed it, and its recovery time and recovery point objectives. If your business impact analysis does not yet give you those numbers, this is where the gap shows.

Data locations

For each service, B_02.02 asks whether data is stored, where data at rest is located and where it is processed, and how sensitive it is. These answers must match your contracts: Article 30(2)(b) of DORA requires every ICT contract to state where services are provided and data is processed and stored.

The supply chain

Template B_05.02 ranks the providers behind each service. Annex I gives an example: you contract provider X for services A and B, and X uses subcontractor Y for service B. For service A the chain is X (rank 1). For service B it is X (rank 1) and Y (rank 2). Your direct provider is always rank 1 (Article 2), and every provider in the chain shares the contract's reference number.

Assessments for critical or important functions

For services supporting critical or important functions, B_07.01 records how easily you could replace the provider (and why not, if not), when you last audited it, whether an exit plan exists, whether you could bring the service back in-house, the impact of losing it and which alternatives you have identified. These answers come straight from the exit strategies and concentration-risk assessments DORA requires in Articles 28(8) and 29, so the register exposes those gaps too.

How to build it: a practical order

1. List every ICT service you pay for or receive. Start from accounts payable, not from IT's memory: cloud, SaaS, hosting, managed services, software licences with support, data feeds and intra-group IT services. Anything you missed will not be in the register.

2. Map your functions and decide which are critical or important. Assign function identifiers, record the reasons and the recovery objectives. This decides how much detail each contract needs.

3. Collect the contract data. For each arrangement: reference number, type, dates, notice periods on both sides, governing law, annual cost, service and data locations. Gaps here often reveal contracts that do not meet Article 30.

4. Collect provider identifiers and parents. LEI or EUID, legal name, headquarters country and ultimate parent for every provider, plus the subcontractors behind critical services.

5. Complete the assessments. Substitutability, audits, exit plans and alternatives for every service supporting a critical or important function.

6. Write your definitions (B_99.01) and validate. Check that the keys match across templates, every cell has one value, and identifiers are valid, then run the file through your authority's validation before the national deadline.

7. Keep it current. The Implementing Regulation requires the information to be accurate and consistent, reviewed regularly, and errors corrected promptly (Article 3(3)–(4)). Tie updates to your procurement and contract-change process so the register changes when contracts do, and tell your authority in good time before a new arrangement for a critical or important function (Article 28(3) of DORA).

Need a place to start collecting? The DORA Compliance Checklist pack ($34) includes a working third-party ICT provider register (one row per provider: services, criticality, LEI, data locations, subcontractors, exit strategy), plus a gap-assessment workbook, an incident classification matrix and an ICT risk management framework template. It is a working sheet for gathering the information, not the official reporting format; you map it into the 2024/2956 templates for submission.

Common mistakes

Only listing "big" vendors. The register covers all contractual arrangements for ICT services, not only critical ones.
Several values in one cell. Each data element takes a single value; use extra rows instead.
Missing or inactive LEIs. An expired LEI is not "valid and active".
Subcontractors left out for critical services. Those that effectively underpin critical or important functions must be in the supply chain.
Inconsistent keys. A reference number or function identifier that differs between templates breaks the links the authorities rely on.
A once-a-year spreadsheet. The register must be maintained and updated, not rebuilt each spring.