DORA Register of Information: What It Is and How to Get It Right

The DORA register of information is one of the most data-heavy obligations in the Digital Operational Resilience Act. It requires every in-scope financial entity to keep a structured, up-to-date record of all its contractual arrangements for ICT services provided by third parties, and to share it with supervisors.

Financial entities have now completed their first two annual reporting cycles, in 2025 and 2026. Many found that the hard part was not filling in templates but finding accurate, consistent data about contracts, providers and the functions they support.

This guide explains who must keep the register, what the technical standards require, the levels at which it must be kept, what data it contains, how submission works, and the data-quality issues that most often cause rejections.

What the register is and who must keep it

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 28(3) requires financial entities, as part of their ICT risk management framework, to maintain and update a register of information on all contractual arrangements for the use of ICT services provided by ICT third-party service providers.

The obligation applies to the wide range of financial entities within DORA’s scope. That includes credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings, institutions for occupational retirement provision, fund managers, credit rating agencies and crowdfunding service providers, among others.

The register covers all ICT service arrangements, not only those supporting critical or important functions. However, it must distinguish between arrangements that support critical or important functions and those that do not, and it captures more detail about the former.

What Article 28(3) requires in practice

• Maintain and update the register at entity level and, where relevant, at sub-consolidated and consolidated levels.
• Report at least yearly to competent authorities on the number of new ICT arrangements, the categories of providers, the types of contractual arrangements and the ICT services and functions provided.
• Make the full register available on request, or specified sections of it, to the competent authority.
• Inform the competent authority in a timely manner about any planned arrangement for ICT services supporting critical or important functions, and when a function has become critical or important.

The ITS and the standard templates

The format of the register is set by Commission Implementing Regulation (EU) 2024/2956, adopted on 29 November 2024 and in force since 22 December 2024. These implementing technical standards (ITS) establish standard templates, prepared by the European Supervisory Authorities (EBA, EIOPA and ESMA), so that registers are comparable across the EU. You can read the ITS on EUR-Lex.

Each template is a table with a fixed set of columns and an open number of rows. The templates are linked by keys, such as the contractual arrangement reference number and provider identifiers, so the register works like a relational database rather than a single spreadsheet.

Entity, sub-consolidated and consolidated levels

The DORA register of information must be kept at three levels where applicable:

• Entity level. Every financial entity keeps a register covering all its own ICT arrangements.
• Sub-consolidated level. Where a sub-group is subject to consolidated supervision, the parent of that sub-group keeps a register covering the entities within it.
• Consolidated level. The ultimate parent undertaking keeps a register covering the whole group within the scope of consolidation under the relevant sectoral rules.

Groups must keep the information consistent across levels. A contract recorded at entity level should appear with the same identifiers and values in the consolidated register. In practice, most groups maintain one central dataset and generate each level from it, rather than building separate registers by hand.

What data the register contains

The templates collect a large number of data points, but they fall into a few clear groups:

• Entity data. Names, legal entity identifiers (LEIs), entity type, country, competent authority and branch information.
• Contract data. Contract reference numbers, type of arrangement, start and end dates, notice periods, governing law, and annual expense or estimated cost.
• Provider data. Provider name, identifier, type of person, country of headquarters, ultimate parent and total annual expense.
• Service data. The type of ICT service, where data is stored and processed, and the sensitivity of the data involved.
• Function data. The business functions supported, whether they are critical or important, and their recovery objectives.
• Supply chain data. Subcontractors that effectively underpin ICT services supporting critical or important functions, and their rank in the chain.
• Assessment data. Substitutability, reintegration and exit plan information, and the impact of discontinuing the service.

Identifiers are central. The ITS require a valid and active LEI or a European Unique Identifier (EUID) for providers that are legal persons, with the LEI required for providers established outside the Union.

Submission to competent authorities and the ESAs

Financial entities submit their registers to their national competent authorities. The authorities then pass the data to the ESAs, which use it to assess which ICT providers should be designated as critical ICT third-party service providers (CTPPs) and overseen at EU level.

How the cycles have worked so far

• 2024 dry run. The ESAs ran a voluntary dry run in 2024 so that entities and authorities could test templates and tools.
• 2025 first cycle. Competent authorities had to report registers to the ESAs by 30 April 2025. Each authority set its own earlier deadline for entities.
• CTPP designation. On 18 November 2025, the ESAs announced the first designation of critical ICT third-party providers, using data from the registers as the starting point.
• 2026 cycle. National authorities again set their own collection windows. For example, Luxembourg’s CSSF collected registers between 11 February and 31 March 2026, covering arrangements contracted until 31 December 2025.

Submissions use the ESAs’ data point model and reporting framework, typically in xBRL-CSV format through the authority’s portal. The EBA’s register of information page publishes the validation rules, technical guidance and FAQs. Always check your own competent authority’s instructions for dates, format and portal access, as these vary.

Common data-quality issues

Automated validation rules check every submission, and the rules have been extended over time. Submissions that passed in one cycle can fail in the next. The most common problems include:

• Invalid or lapsed identifiers. LEIs that are not active, missing EUIDs or the wrong identifier type for a provider.
• Broken links between templates. Contract references or provider codes that appear in one template but not in the related one.
• Duplicated keys. The same contract reference number used for different arrangements, or the same arrangement recorded twice.
• Free text instead of codes. Values entered in words where the data point model expects a code from a defined list.
• Missing mandatory fields. Empty values for costs, dates, countries or function criticality.
• Incomplete supply chains. Subcontractors supporting critical or important functions left blank or not linked to the right service.
• Wrong format. Files that do not follow the required reporting format or naming conventions.

Practical steps to build your DORA register of information

1. Define scope and ownership. Confirm which entities in the group are in scope and who owns the register at each level, usually a joint effort between procurement, IT, risk and compliance.
2. Inventory ICT arrangements. Pull contracts from procurement, finance and IT systems. Include intra-group services, cloud subscriptions and smaller contracts that are easy to miss.
3. Map functions. Link each ICT service to the business functions it supports and document whether those functions are critical or important.
4. Collect provider data. Obtain LEIs or EUIDs, headquarters, ultimate parent and, for critical or important functions, key subcontractors. Build these requests into onboarding and contract renewal.
5. Clean and standardise. Deduplicate providers and contracts, apply the code lists from the data point model and set unique reference numbers.
6. Validate before you submit. Run the published validation rules on your data early, fix errors and leave time for resubmission.
7. Keep it live. Update the register whenever a contract is signed, changed or ended, not just before the annual deadline. Notify the competent authority of planned arrangements for critical or important functions.
8. Use the register for risk management. Review concentration risk, exit readiness and provider assessments using the same data.

How Enactia helps

Enactia is a governance, risk and compliance platform that supports DORA as one of its frameworks. It helps you manage the third-party data and risk processes behind the register.

• Vendor and third-party management. Keep a central repository of ICT providers, run due diligence and risk assessments, and track certifications with vendor and third-party management.
• Risk management. Record ICT concentration, substitutability and exit risks in enterprise risk management and link them to providers and controls.
• Compliance assessments. Assess your DORA readiness and map controls to other frameworks such as NIS2 and ISO 27001 through Compliance Universe.
• Evidence management. Store contracts, exit plans and assessment evidence in one repository for supervisors and auditors.

Frequently asked questions

Does the DORA register of information cover all ICT contracts?
Yes. It covers all contractual arrangements for ICT services provided by ICT third-party service providers, including intra-group providers. Arrangements supporting critical or important functions require more detailed information.

How often must the register be submitted?
DORA requires financial entities to report at least yearly to competent authorities and to provide the register on request. Each competent authority sets its own annual collection window and reference date.

Which identifiers are required for ICT providers?
The ITS require a valid and active LEI or EUID for providers that are legal persons. Providers established outside the Union must be identified with an LEI.

What format is used for submission?
Registers are reported using the ESAs’ data point model and validation rules, generally in xBRL-CSV. Check your competent authority’s portal and instructions for the exact requirements.

What is the register used for?
Supervisors use it to monitor ICT third-party risk at each entity, and the ESAs use it to identify and designate critical ICT third-party service providers for EU-level oversight.

Conclusion: treat the register as live data

The register is not a one-off reporting exercise. Entities that treat it as a live dataset, updated as contracts change and linked to their third-party risk management, find each annual submission easier and gain a clearer view of their ICT dependencies.

Want to see how Enactia can help you manage ICT third-party risk and DORA compliance? Contact us or book a demo with our team.