DORA Register of Information: Complete Guide

DORA Article 28 establishes the framework for ICT third-party risk management. At its core is the Register of Information: every in-scope financial entity must maintain a register recording all contractual arrangements with ICT third-party service providers, whether those services are directly provided or delivered through sub-contracting arrangements for functions classified as critical or important. The register is not a static inventory prepared once for the competent authority — it is a living document that must be updated whenever a new contractual arrangement is entered into, an existing one is modified, or a critical function classification changes.

The legal requirement for the register's format is set out in Commission Implementing Regulation (EU) 2024/2956, which was published in October 2024 and became applicable on 17 January 2025 alongside DORA itself. The Implementing Regulation specifies the exact template, including the data fields to be completed for the register at entity level and at the level of each individual contractual arrangement. The ESAs published Q&As to clarify specific requirements, and national competent authorities have incorporated RoI completeness and accuracy as a primary focus in their supervisory reviews.

The RoI serves two distinct purposes in the DORA framework. First, it is the foundation of the financial entity's ICT third-party risk management programme — you cannot conduct concentration risk analysis, assess exit feasibility, or evaluate critical function dependency without a complete picture of your ICT supply chain. Second, it enables competent authorities and the ESAs to assess sector-wide ICT concentration risk and identify which ICT providers are systemically important enough to warrant designation as Critical ICT Third-Party Providers (CTPPs) subject to direct ESA oversight.

Commission Implementing Regulation (EU) 2024/2956 specifies the register in two parts: an entity-level section covering the financial entity itself, and a contractual arrangement section covering each ICT service provider relationship.

Entity-Level Information

For each financial entity maintaining the register, the following must be recorded:

1. Legal name of the financial entity and its Legal Entity Identifier (LEI).
2. Type of financial entity (credit institution, insurer, investment firm, etc.) as defined in DORA Article 2.
3. Member state of authorisation or registration.
4. Name of the competent authority responsible for the financial entity.
5. Whether the entity is part of a group, and if so, the group identifier.
   
   

Contractual Arrangement Information

For each contractual arrangement with an ICT third-party service provider, the register must capture:

The sub-contracting requirement is consistently the most challenging field to complete accurately. DORA does not require financial entities to map their entire ICT supply chain to infinite depth — the obligation extends to material sub-contractors supporting critical or important functions. However, determining which sub-contractors are material requires the financial entity to have asked the question of their ICT providers, and many providers are reluctant to disclose their own supply chains in detail.

The distinction between critical and important functions, and non-critical ICT services, is fundamental to the Register of Information. Not every ICT provider needs to be managed to the same standard: DORA's most stringent requirements for contractual provisions (Article 30), exit planning, and sub-contracting oversight apply specifically to services that support critical or important functions. Getting the classification wrong — either by over-classifying and creating unmanageable compliance obligations, or by under-classifying and leaving critical services outside the DORA framework — is a significant risk.

DORA Article 3(22) defines a 'critical or important function' as a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the continued compliance of a financial entity with the conditions and obligations of its authorisation, or its other obligations under applicable financial services law. This definition is deliberately broad: it encompasses not just core banking or insurance activities, but also the operational infrastructure, compliance systems, and data management processes on which those activities depend.

Classification Framework

The practical test for critical/important function classification is to ask: if this ICT service was unavailable for 24 hours, 48 hours, or one week, would it affect the firm's ability to serve clients, meet regulatory obligations, or operate core processes? Services that fail this test in any scenario should be classified as supporting critical or important functions. Borderline cases should be escalated to the TPRM function and documented with a rationale — the classification decision itself is evidence that competent authorities will review.

For detailed guidance on managing critical ICT third-party providers and the CTPP oversight regime, see /resource-hub/dora-critical-ict-third-party-providers.

Completing the Register of Information for the first time requires a structured data gathering exercise that most financial entities have found more complex than anticipated. The challenge is not the template itself — the fields specified in Commission Implementing Regulation (EU) 2024/2956 are specific but not technically complex. The challenge is that the data needed to populate it is scattered across procurement records, contract management systems, shadow IT inventories, business unit records, and, in some cases, the institutional memory of individual staff.

Initial Build: Four-Stage Approach

Stage 1 — Discovery. Compile an initial inventory of all ICT providers from procurement records, accounts payable data, software licensing registers, and cloud service agreements. Add to this any ICT services identified through business unit interviews — particularly services procured directly by business units without central IT involvement.

Stage 2 — Classification. For each provider identified, determine whether the service supports a critical or important function. Document the basis for the classification. Where the classification is not clear-cut, escalate to the TPRM function for a formal decision. All CIF-supporting services must be flagged in the register.

Stage 3 — Data completion. For each contractual arrangement, gather the full set of fields specified in Commission Implementing Regulation (EU) 2024/2956. For CIF-supporting services, contact ICT providers to obtain sub-contracting information. For contracts that predate DORA, assess whether the contractual provisions meet Article 30 requirements and initiate renegotiation where they do not.

Stage 4 — Validation. Review the completed register for internal consistency (are all CIF services properly flagged? Are all LEIs correct?), and submit to the competent authority in the required format.

Ongoing Maintenance

The register must be updated in real time as the ICT supply chain changes. This requires embedding RoI update obligations into three processes: the procurement approval process (no new ICT contract without RoI update); the contract management process (renewals, amendments, and terminations must trigger an RoI review); and the critical function classification review (changes in business operations may affect which ICT services support critical functions). Annual competent authority submissions require a validated point-in-time snapshot, but the register itself should never be out of date.

Technology is essential for maintaining the register at scale. A spreadsheet-based register is adequate for initial build but degrades rapidly as the number of providers grows, as sub-contracting relationships evolve, and as multiple teams contribute updates without version control. A TPRM platform that integrates with the RoI template and provides automated change tracking is the operational foundation for a register that will pass supervisory review.

For an overview of vendor assurance automation tools that can support RoI maintenance, see /blog-hub/vendor-assurance-automation-software.

Financial entities must submit the Register of Information to their competent authority under two circumstances: on request at any time, and as part of the annual reporting obligation under DORA Article 28(3). The annual submission must be made by 31 January of each year, covering the register as at the preceding 31 December. The ESAs have specified the submission format: the register must be submitted in the format specified in Commission Implementing Regulation (EU) 2024/2956, typically as a structured data file.

For financial groups, the group-level submission requirement means that a parent entity must co-ordinate the registers of all subsidiaries within scope. Where different subsidiaries share ICT providers — a common arrangement in integrated financial groups — the register captures the relationship at the individual entity level, not at group level. Each subsidiary's register must independently identify its ICT providers, even where those providers are shared across the group.

The ESAs use submitted registers to identify ICT concentration risk across the financial sector as a whole — identifying which ICT providers are used by significant numbers of financial entities across multiple jurisdictions, and therefore qualify for designation as Critical ICT Third-Party Providers subject to direct oversight. Accuracy in the register submission matters not only for individual entity compliance but for the integrity of the sector-wide oversight framework.

Supervisory reviews and the ESAs' published Q&As identify the following as the most frequent issues in RoI compliance.

1. Incomplete sub-contracting data. Financial entities have populated their own provider rows but have not captured the sub-contracting chains for CIF-supporting services. Article 28(3) requires this information for services supporting critical or important functions.
2. Incorrect critical function classification. Services are classified as non-critical without documented rationale, or without applying the Article 3(22) test systematically. Competent authorities are asking entities to justify their classification decisions.
3. Missing or incorrect LEIs. Legal Entity Identifiers are required for both the financial entity and its ICT providers. Many smaller ICT providers do not have LEIs or have LEIs that differ from the entity name in the contract.
4. Stale data. The register reflects the state of the supply chain at the date of initial build, not the current state. New providers added after initial completion are not captured; terminated contracts are not removed.
5. Inconsistent service classifications. The service type classification categories in Commission Implementing Regulation (EU) 2024/2956 are specific. Financial entities that have used their own classification systems rather than the regulatory categories must remap their data before submission.

For guidance on the full DORA Article 28 framework and how it connects to the rest of the DORA requirements, see /resource-hub/dora-compliance-guide.