DORA register of information: what it is, how to keep it current

What is the DORA register of information?

The DORA register of information is a structured record of every contractual arrangement a financial entity has for ICT services provided by ICT third-party service providers, and of the business functions those services support. Article 28(3) of the Digital Operational Resilience Act (Regulation (EU) 2022/2554) requires financial entities to maintain and update it at entity level and, for groups, at sub-consolidated and consolidated level. It has applied since 17 January 2025 and supervisors collect it every year.

It is more than a contract list. Each arrangement has to be tied to the provider and its legal identifier, the type of ICT service, the functions that depend on it and, for critical or important functions, the subcontractors underneath and how hard the service would be to replace. Those links cut across procurement, IT and the business, which is why the register goes stale so quickly.

What does Article 28 of DORA require?

Article 28 makes ICT third-party risk an integral component of ICT risk within the ICT risk management framework, and the register of information is the record supervisors use to check it. DORA defines a critical or important function as one whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services and activities, or its continuing compliance with its authorisation and financial services law (Article 3(22)). That definition decides how much detail each entry needs.

The duties around the register are:

• Maintain and update a register of information on all contractual arrangements on the use of ICT services provided by ICT third-party service providers, at entity, sub-consolidated and consolidated level (Article 28(3)).
• Make the full register, or the sections requested, available to the competent authority on request (Article 28(3)).
• Report at least yearly on the number of new arrangements, the categories of ICT third-party service providers, the type of contractual arrangements and the ICT services and functions being provided (Article 28(3)).
• 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 (Article 28(3)).
• Keep exit strategies for ICT services supporting critical or important functions, covering provider failure, degraded service and termination of the contract (Article 28(8)).

Which templates make up the register of information?

The standard templates are set by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, the implementing technical standards (ITS) on the register of information. It was published in the Official Journal on 2 December 2024 and entered into force on 22 December 2024. Annex I sets out 15 templates, coded B_01.01 to B_99.01. Each is a table with fixed columns and as many rows as needed, used at entity, sub-consolidated and consolidated level.

They link through shared keys such as the contractual arrangement reference number, the provider's code and the function identifier:

• B_01.01 to B_01.03: the entity maintaining the register, the entities in the scope of consolidation, and their branches.
• B_02.01 to B_02.03: general and specific information on each contractual arrangement, plus the links between intra-group arrangements and those with outside providers.
• B_03.01 to B_04.01: the entities that sign each arrangement on both sides, and the entities that actually use the ICT services.
• B_05.01 and B_05.02: the ICT third-party service providers, and the ICT service supply chain, in which every provider gets a rank (the direct provider is rank 1, its subcontractors rank 2 and above).
• B_06.01: the functions, with the criticality or importance assessment and its reasons, the date of the last assessment, recovery time and recovery point objectives, and the impact of discontinuing the function.
• B_07.01: for ICT services supporting critical or important functions, the substitutability of the provider, the date of the last audit, whether an exit plan exists, whether the service could be reintegrated in-house, and whether alternative providers have been identified.
• B_99.01: the definitions and internal terms the entity used when filling in the templates.

What does the register need for each ICT service?

Most of the effort goes into a few fields the ITS is specific about:

• Identifiers: every ICT third-party service provider that is a legal person needs a valid and active LEI or EUID, and both where available (ITS Article 3(5)). Providers established outside the EU are identified with the LEI. For services supporting critical or important functions, the entity must ensure, through the direct provider, that the relevant subcontractors are identified the same way.
• Subcontracting: the register must include all subcontractors that effectively underpin ICT services supporting critical or important functions, or material parts of them (ITS Article 3(2)).
• Function links: each arrangement in B_02.02 carries a function identifier and the type of ICT service, so every contract must point at a function defined in B_06.01.
• Location and terms: the country where the service is provided, where data is stored and where it is processed, the sensitivity of that data, the governing law, start and end dates, and notice periods on both sides.
• Cost and reliance: the annual expense or estimated cost of each arrangement and of each provider, and the level of reliance on the service where it supports a critical or important function.

Who collects the register of information, and when?

Financial entities submit their registers to their national competent authority, which passes them to the three European Supervisory Authorities (the EBA, EIOPA and ESMA, together the ESAs). Under the ESAs' decision of 8 November 2024 on reporting for the designation of critical providers, the first collection used a reference date of 31 March 2025, with competent authorities sending the data to the ESAs by 30 April 2025. Since then the collection is annual: the reference date is 31 December of the previous year and competent authorities transmit by 31 March.

Registers are submitted as an xBRL-CSV reporting package built to the EBA's data point model, not as a spreadsheet. The ESAs said they would not provide a template or conversion tool for the official submission, and the EBA runs technical validation and data quality checks on every file, with feedback that can require a resubmission.

In Ireland, the Central Bank of Ireland collects registers through the Central Bank Portal. For the 2026 collection, registers with a reporting date of 31 December 2025 were due in a window from 2 to 31 March 2026, as a zipped XBRL OIM-CSV package under EBA DPM 4.0. The Central Bank warned that the EBA would run further data quality checks in April 2026, with examples such as a dummy code for a provider's ultimate parent or a provider name entered as "not applicable".

On the same annual cycle, the next collection uses a reference date of 31 December 2026. Each competent authority sets its own submission window, so check its DORA page early in the year.

What do the ESAs use the registers for?

The EBA describes three uses: financial entities monitor their own ICT third-party risk, competent authorities supervise ICT and third-party risk management, and the ESAs designate the critical ICT third-party service providers (CTPPs) that are subject to EU-level oversight. DORA requires the ESAs to publish and update the list of CTPPs yearly (Article 31(9)).

On 18 November 2025 the ESAs published the first list of designated CTPPs, naming 19 providers. They started from the data in financial entities' registers, then ran a criticality assessment with competent authorities based on systemic importance, the role in supporting critical or important functions and the substitutability of services. A missing subcontractor or a wrong identifier in your register is therefore not only a local data error: it feeds the evidence behind EU-level oversight decisions.

Why is the register so hard to keep current?

The ESAs ran a voluntary dry run in 2024. Of the 947 registers that passed the initial data integration checks, 6.5% passed every data quality check, and missing mandatory information accounted for 86% of all data errors. Identifiers for entities and providers were the other common failure. Missing fields, more than wrong ones, point to a data-assembly problem: the information usually exists somewhere in the organisation, just not in one place.

The register joins data that different teams own. Contracts, costs and notice periods sit with procurement and legal. The ICT services and the systems that deliver them sit with IT and engineering. Functions and their criticality sit with the business and risk teams. Subcontractors often sit with nobody, because they appear in a provider's annex or sub-processor list rather than in any internal system.

Even a register that was right on the reference date drifts. Common causes:

• A team adopts a new SaaS tool or cloud service under an existing agreement or on a company card, so no new contract reaches procurement.
• A workload moves to another region or provider, changing where data is stored and processed while the contract record stays the same.
• A provider adds or swaps a subcontractor and tells you by email, or by updating a page on its website.
• A re-architected system leaves a critical or important function depending on a service classed as non-critical.
• A contract is renewed on new terms or lapses, and the register still shows the old dates and notice periods.

How do you build a register that stays current?

The approach that holds up is to treat the register as a view over live operational data with contract fields attached, rather than as a document rebuilt every spring. Give it one accountable owner, with a named owner for each group of fields, and work in this order:

• Start from functions. List the business functions, assess which are critical or important, and record recovery time and recovery point objectives. This is template B_06.01 and the anchor for everything else.
• Map each function to the ICT services and systems behind it: the applications, the infrastructure they run on, the identity provider, monitoring and the SaaS tools in the path. A dependency map shows third parties a function relies on that no contract list would.
• Link each ICT service to its contract and provider: reference number, LEI or EUID, type of ICT service, dates, notice periods, data locations and annual cost.
• Capture the supply chain for every service that supports a critical or important function. Ask direct providers for the subcontractors that underpin it, with their identifiers, and record each one's rank.
• Assess substitutability and exit. For each of those services, record whether it could be replaced or reintegrated, the date of the last audit and whether an exit plan exists, and keep this consistent with your Article 28(8) exit strategies.
• Review on every change, not once a year. Trigger an update when a new service or provider appears, a contract is signed, renewed or ended, a workload changes region, a provider changes subcontractors, or a function is reassessed. It also flags when Article 28(3) requires you to tell the competent authority about a planned arrangement for a critical or important function.
• Validate early: run the EBA's published validation rules well before the window opens, and check that every identifier is valid and active.

How does the register relate to NIS2 supply-chain security?

For financial entities covered by DORA, DORA is a sector-specific Union legal act in relation to NIS2 (NIS2 recital 28). Under NIS2 Article 4(1), where a sector-specific act imposes risk-management or incident-notification requirements at least equivalent in effect, the matching NIS2 provisions, including supervision and enforcement, do not apply. Recital 28 names DORA's ICT third-party risk rules among those that apply instead, so for a bank or insurer the register of information sits under DORA. Our NIS2 vs DORA guide covers the wider split.

Groups often have entities on both sides. Where a group entity is outside DORA but in NIS2 scope, NIS2 Article 21(2)(d) requires supply chain security, including the security aspects of its relationships with direct suppliers and service providers. The underlying data is largely the same: which suppliers you rely on, for what, and what depends on them. Keep one supplier and dependency record and produce both views from it. See NIS2 supply-chain security for the NIS2 side.

How Alexus AI helps

Alexus AI is a Dublin-built operational intelligence platform that keeps a live, self-maintaining map of what you run and what breaks when it fails. For a register of information, that covers the part that drifts fastest: which systems each service runs on, what depends on it, and which third-party services it relies on, as seen through read-only connectors to the cloud, monitoring, ITSM and code tools you run. Alexus also keeps the incident and change record, so when a workload moves or a new dependency appears, you can see what changed and who approved it.

Alexus does not hold your contracts, legal identifiers or costs, and it does not produce a DORA register today. DORA-specific outputs, including a register of information export in the ESA templates, are planned, not built. The inventory already exports to Excel, which can feed the systems and dependencies side of your register. Alexus does not make you compliant: it provides the operational evidence your register depends on. See Alexus for FinTech and our DORA page, or talk to us about becoming a design partner. This guide is general guidance, not legal advice.

Frequently asked questions

Does the DORA register of information cover every ICT contract?

Yes. Article 28(3) of DORA covers all contractual arrangements on the use of ICT services provided by ICT third-party service providers, not only critical ones, and intra-group arrangements are recorded too. The depth differs: for ICT services supporting critical or important functions, the register must also list the subcontractors that effectively underpin the service and include an assessment of substitutability, exit plans, reintegration and alternative providers in template B_07.01.

What format is the DORA register of information submitted in?

Registers go to the competent authority as an xBRL-CSV reporting package built to the EBA's data point model, normally a zipped set of CSV files, not an Excel workbook. The Central Bank of Ireland specifies XBRL OIM-CSV under EBA DPM 4.0, uploaded through its portal. The ESAs said they would not provide a template or conversion tool for official submissions, so firms build the package themselves or with a tool.

When is the DORA register of information due each year?

Under the ESAs' decision of November 2024, registers are collected annually with a reference date of 31 December of the previous year, and competent authorities pass them to the ESAs by 31 March. National deadlines fall before that and each competent authority sets its own window. In Ireland the 2026 window ran from 2 to 31 March 2026. The next collection uses a reference date of 31 December 2026.

Do ICT third-party providers need an LEI for the DORA register?

Providers that are legal persons need a valid and active LEI or an EUID, and both where available, under Article 3(5) of Implementing Regulation (EU) 2024/2956. Providers established outside the EU are identified with the LEI. The financial entity submitting the register also needs a valid LEI. For services supporting critical or important functions, the entity must ensure through the direct provider that underpinning subcontractors are identified the same way.

How is the register of information used to designate critical ICT providers?

The ESAs use the data in financial entities' registers as the starting point for designating critical ICT third-party service providers (CTPPs) under Article 31 of DORA, followed by a criticality assessment with competent authorities. The first list, published on 18 November 2025, named 19 providers. DORA requires the list to be updated yearly, so the quality of each year's registers feeds the next designation round.

Can a CMDB or asset inventory serve as the register of information?

Not on its own. The register needs contract data a CMDB does not hold: reference numbers, legal identifiers, costs, governing law and notice periods. But a CMDB or dependency map that stays current supplies the part that drifts fastest: which systems deliver each ICT service, which functions depend on them, and which third-party services sit in the path. Joining the two keeps the register accurate between annual submissions.

Sources

• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), EUR-Lex
• Commission Implementing Regulation (EU) 2024/2956: standard templates for the register of information, EUR-Lex
• EBA: Preparations for reporting of DORA registers of information
• ESAs Decision on reporting of information for CTPP designation (ESA 2024 22, 8 November 2024)
• ESAs: DORA dry run exercise summary report (ESA 2024 35, December 2024)
• ESAs: designation of critical ICT third-party providers under DORA (press release, 18 November 2025)
• Central Bank of Ireland: Reporting Registers of Information
• Directive (EU) 2022/2555 (NIS2), EUR-Lex