DORA Register of Information: How to Build and Maintain Your Third-Party List
What does Regulation (EU) 2022/2554 require financial entities to record about ICT third parties?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA), which applies to financial entities in the European Union from 17 January 2025, requires every in-scope financial entity to maintain a complete register of all contractual arrangements entered into with ICT third-party service providers. This register is not a simple vendor list: it must contain the specific data fields defined by Commission Implementing Regulation (EU) 2024/2956, and it must be submitted to the relevant national competent authority at the frequency set by the supervisory calendar.
The register is one of the most operationally intensive DORA obligations because it requires data collection from multiple internal owners, harmonisation across group entities, and ongoing maintenance as contracts are signed, amended, or terminated. This article explains the mandatory content, the submission requirements, the classification of critical ICT third parties, and the role of software in keeping the register accurate and submission-ready. It links to NIS2 and DORA, the two regulatory pillars of digital resilience and to the business continuity plan that the DORA register must cover.
Mandatory fields per contract
Commission Implementing Regulation (EU) 2024/2956 defines the data model and templates for the DORA register of information. The templates specify the fields that must be populated for each contractual arrangement, structured across several tables that cover the financial entity, the ICT third-party service provider, the contractual arrangement itself, and the functions and data involved.
Key fields include the Legal Entity Identifier (LEI) of both the financial entity and the ICT provider, the nature of the ICT services provided, the classification of the function supported (critical or important, or other), the contractual arrangement reference, the start and end dates, the sub-outsourcing chain when relevant, and the data storage and processing locations. Fields related to exit strategies and substitutability assessments are also required for arrangements supporting critical or important functions. Every field must be populated with data that is accurate and consistent: data quality errors in identifiers or dates are among the most common reasons submissions are rejected by national competent authorities, as noted in the DORA register guidance published by the European Supervisory Authorities.
Update frequency and supervisor submission
The register must be kept up to date continuously: any new contractual arrangement, amendment, or termination must be reflected without delay. For submission purposes, the financial entity reports to its national competent authority at the frequency set by supervisory guidance, which covers the annual submission cycle and any ad hoc submission triggered by a material change.
Group structures face an additional coordination challenge: a single ICT provider may supply services to several entities within the group, each of which must appear in its own entity-level register while also being consolidated at group level where applicable. The data must be consistent across entities: the same provider identified with the same LEI, the same contract referenced with the same identifier, the same sub-outsourcing chain described in the same structure. Inconsistency within a group submission is a common finding in early supervisory reviews. Managing this across a large group requires a single authoritative data source, not independent spreadsheets held by each entity's operational team.
Classifying critical ICT third parties
DORA introduces the concept of critical ICT third-party service providers (CTPPs). Classification at the EU level is performed by the Joint Committee of the European Supervisory Authorities (ESAs), not by individual financial entities. A provider designated as critical becomes subject to direct supervisory oversight by a Lead Overseer appointed from the three ESAs.
However, financial entities must themselves classify each ICT arrangement by the criticality of the function it supports: critical or important functions on one hand, other functions on the other. This internal classification governs the due diligence required, the exit strategy documentation, and the fields that must be populated in the register. The classification criteria are set out in Commission Delegated Regulation (EU) 2024/1774, which specifies when a function is to be considered critical or important within the meaning of Article 3(22) of DORA. The register must reflect this classification accurately, because supervisors use it to identify which arrangements warrant deeper scrutiny.
How software automates register maintenance
A DORA register that is accurate, consistent, and submission-ready requires a data collection and maintenance process that goes beyond periodic spreadsheet updates. Contracts are signed at different times by different teams; sub-outsourcing chains change when a provider modifies its own supply base; the LEI of a counterpart may change following a restructuring. Without a centralised tool, keeping the register current depends on manual coordination that breaks down at scale.
Optivalue.ai provides a platform that structures the data collection workflows required to build and maintain the DORA register. Contract data is collected from procurement, legal, and IT teams through structured forms aligned with the Commission Implementing Regulation (EU) 2024/2956 templates. The platform validates LEI format, checks for completeness of mandatory fields, and flags inconsistencies across group entities before submission. Change events - new contracts, amendments, terminations - trigger update workflows that route the change to the responsible owner and update the register in a traceable, timestamped manner.
FAQ
Which financial entities must keep a DORA register of information? Regulation (EU) 2022/2554 applies to a wide range of financial entities including credit institutions, payment institutions, e-money institutions, investment firms, insurance and reinsurance undertakings, UCITS management companies, AIFMs, crypto-asset service providers, and central counterparties, among others, as set out in Article 2 of DORA.
What is a Legal Entity Identifier (LEI) and why is it required? The LEI is a standardised alphanumeric code that uniquely identifies a legal entity participating in financial transactions. It is required in the DORA register templates because it enables supervisors to match entries across registers from different financial entities and to cross-reference with other supervisory databases. An entity without an LEI must obtain one before populating the register.
What happens if a field in the register cannot be populated? Commission Implementing Regulation (EU) 2024/2956 specifies which fields are mandatory and which are conditional. Where a field is mandatory and data is genuinely unavailable, the entity must document the reason. Fields relating to sub-outsourcing, for example, require the financial entity to make reasonable efforts to obtain information from its direct ICT provider.
Does the register cover all ICT providers or only those supporting critical functions? The register covers all contractual arrangements with ICT third-party service providers, regardless of whether the function supported is classified as critical or important. The classification affects the depth of due diligence and the fields that must be populated, but the registration obligation itself is universal under Article 28(3) of Regulation (EU) 2022/2554.
How does the DORA register relate to the ICT third-party risk management policy? The register is the operational expression of the ICT third-party risk management policy required by Article 28(1) of DORA. The policy sets the governance framework and the criteria for assessing and classifying ICT providers; the register records the actual contractual arrangements that fall under that framework.
Book a demonstration of Optivalue.ai
<!-- JSON-LD -->
Back to top