What is the Register of Information (RoI)?
The RoI is essentially a detailed catalogue or register that financial entities covered by DORA must maintain and submit, containing information about their contractual arrangements with ICT third-party service providers (TPSPs).
- Under Article 28(3) of DORA, financial entities must keep up-to-date records of the contractual arrangements on the use of ICT services provided by ICT third-party service providers.
- The detailed template, layout and content requirements have been specified via Implementing Technical Standards (ITS) in the form of Commission Implementing Regulation (EU) 2024/2956 (adopted 29 November 2024) which sets out the standard templates for the register of information.
- The RoI must be maintained at different levels of consolidation (entity, sub-consolidated, consolidated) depending on the organisational structure of the financial entity.
In short: the RoI is about transparency regarding which ICT third-party service providers a financial institution uses, what services are provided, the contractual terms, the risks, and so on.
Why does the RoI matter?
There are several reasons why this register is a key piece of DORA compliance and broader operational resilience:
1. Visibility & oversight of third-party ICT risk
Financial entities increasingly rely on external ICT service providers (cloud, data centres, software, telecommunication, etc). These dependencies create risk: the failure or compromise of a third-party can ripple into the financial entity and the broader financial system. DORA acknowledges this and puts in place rules to monitor and manage these dependencies.
The RoI is the instrument by which supervisors and the European Supervisory Authorities (ESAs) gain visibility into the landscape of these third-party relationships. For example, the Dutch supervisory authority notes: The information register is requested annually … so that the ESAs can determine which ICT service providers should be placed under supervision as critical ICT service providers.
2. Basis for designating critical ICT third-party service providers (CTPPs)
One of the major aims of DORA is to enable the ESAs to designate critical ICT third-party service providers—i.e., those whose disruption could have systemic impact on the EU financial sector.
The RoI provides the data feed for that designation process: the ESAs rely on the registers collected by national competent authorities to identify which providers may meet the critical-provider thresholds.
3. Regulatory compliance & risk management
From the financial entity’s perspective, compiling the RoI forces structured mapping of ICT third-party contracts, the nature of services, risk assessments, and so on. This supports better ICT third-party risk management, and helps meet DORA’s broader requirements around ICT risk management, incident reporting, resilience testing.
Failure to comply (late submission, incomplete register) may lead to regulatory consequences (fines, increased scrutiny) and reputational risk.
Who needs to comply with the RoI requirement (and when)?
Affected entities
The RoI requirement applies to financial entities under DORA. That includes banks, insurance companies, investment firms, payment institutions, e-money institutions, crypto-asset service providers, and other types of entities as listed in DORA’s scope.
It is not limited to the smaller back-office providers; it covers the broader supply chain of ICT third-party service providers (cloud providers, data centres, software vendors, telecoms, analytics, etc)
Key deadlines
- The main regulation (DORA) entered into application on 17 January 2025. eiopa.europa.eu+1
- The deadlines for the first submission of the RoI vary by Member State, but many authorities set early-to-mid April 2025. For example: Ireland: 1-4 April 2025.
- The implementing regulation on the templates (EU 2024/2956) was published in Official Journal and enters into force 20 days after publication (22 December 2024) – so the template specifications are legally binding.
Submission and maintenance
- The register must be made available to national competent authorities (and via them to ESAs) on an annual basis (or as required).
- The register must cover the relevant organisational levels: entity, sub-consolidated group, consolidated group.
What information must the RoI contain?
The content requirements are quite extensive. According to the ITS / Implementing Regulation, the register includes (for each ICT third-party service provider contract) details such as:
- Identification of the financial entity maintaining the register (with LEI or equivalent).
- Identification of the ICT third-party service provider: name, headquarters, legal entity identifier (LEI) or European Unique Identifier (EUID) or other code if none exists.
- Type of services provided (cloud, data centre, software, telecom, etc).
- Which functions / units within the financial entity receive the services, other group entities impacted.
- Contractual value or cost of the contract (or estimation) with that ICT third-party.
- Ranking of the ICT third-party service provider in the supply chain (i.e., whether the provider is subcontracting further, or whether the provider itself is critical etc).
- Some indication of whether the contract supports a critical or important function and whether sub-contracting is permitted, and if so under what conditions.
- Reporting level: entity / sub-consolidated / consolidated.
In short: the RoI is a fairly heavy piece of data-collection.
Practical Challenges & Key Considerations
Compiling and submitting the RoI is non-trivial. Here are some of the main issues and things to watch out for:
Data Collection & Inventory
- Entities need to map all their ICT third-party service providers and contractual arrangements. That means capturing services, providers, contract values, units served, whether the provider is subcontracting, etc. The scale can be large especially for organisations with many ICT suppliers.
- Because the register requires identifiers (LEI/EUID) for third-party providers, if a provider does not have one, the entity must find an alternative valid identifier rather than leaving it blank or using a dummy code.
System & Format Requirements
- The template is technically specific: many supervisors require the register to be submitted in plain csv (XBRL OIM-CSV) format in accordance with the data point model v4.0 for DORA RoI.
- Entities should expect validation rules, technical checks by the competent authority, and feedback loops. The European Banking Authority (EBA) has produced sample files, taxonomy, validation rules, etc.
Timing & Scope
- The deadline (first submission) is tight for many. Entities that have not already started mapping may struggle.
- While the first submission is at a point in time (e.g., as at 31 March 2025 in some jurisdictions) the obligation to continuously maintain the register means that updates, changes in contracts, terminations must be reflected.
Down-the-supply-chain complexity
- One of the open issues is how far down the supply chain the entity needs to map (i.e., subcontractors of the ICT third-party provider). Some ambiguity remains in practice.
- Entities will likely need to engage with their ICT providers, request data, build internal systems / processes to update the register regularly.
Resource & cost impact
- According to some sources, the burden is significant: the sheer volume of contracts, data points, and the need for continuous update means organisational resources, system investment, external support may be required.
Opportunities & Strategic Benefits
While the RoI requirement might seem like just a compliance burden, it also brings opportunities for financial entities:
- Better ICT third-party risk management: By undertaking the mapping and maintaining the register, firms build clearer visibility of who their critical providers are, what services they deliver, where dependencies lie. That helps in resilience planning, incident response, business continuity.
- Competitive differentiator: Firms that can demonstrate strong ICT third-party oversight and compliance may benefit from stronger stakeholder/market trust. One article noted the register requirement could constitute a competitive advantage.
- Regulatory readiness & systematisation: The process encourages firms to build or upgrade data systems, governance, process controls around third-party ICT providers. That supports wider digital operational resilience beyond just the register.
- Improved transparency with providers: The requirement will encourage better contractual governance with ICT providers (e.g., clarity on sub-contracting, service scope, oversight).
Steps to Prepare – A Practical Checklist
Here is a suggested roadmap for financial entities preparing for the RoI under DORA:
- Understand the scope
- Determine whether your entity is within scope of DORA and the RoI requirement (financial entity type, size, group structure).
- Identify whether you need entity-level, sub-consolidated, consolidated register submissions.
- Inventory your ICT third-party service providers
- List all ICT service providers under contract (cloud, data centre, software, telecom, analytics, IT consulting, etc).
- For each, capture key contract details: service type, contract value, which functions/business units use them, whether subcontracting is permitted.
- Identify legal identifiers of providers (LEI, EUID or equivalent). If providers lack an LEI/EUID, determine an alternative valid identifier.
- Assess and map supply chain/risk ranking
- Determine if the provider’s services support a critical or important function in your operations.
- Map whether the provider is itself dependent on further subcontractors (and to what extent).
- Rank the provider in your supply chain and identify major dependencies/vulnerabilities.
- Set up the register template & data collection
- Use the template specified in ITS/Implementing Regulation (EU 2024/2956).
- Ensure you can produce the register in the required format (plain csv/XBRL OIM-CSV) and respect validation rules.
- Build internal tools/processes for data collection, validation, update, audit.
- Governance, maintenance & update process
- Assign responsibility (who owns the register, updates it, ensures accuracy).
- Set review frequency (e.g., quarterly, upon every new contract, termination, major change).
- Integrate with your ICT third-party risk management framework and incident response/business continuity planning.
- Submission to competent authority
- Check local Member State deadline and submission process (online portal, format).
- Ensure documentation is complete, valid identifiers included, all contracts captured.
- Monitor for feedback from the authority, validation checks, corrections required.
- Continuous improvement
- Use insights from the register (which providers are high-risk, concentration of services, critical dependencies) to strengthen resilience.
- Benchmark against peers and best practice.
- Monitor updates in DORA/ESAs guidance, technical standards, supervisory expectations.
Final Thoughts
The Register of Information under DORA may at first glance look like a heavy compliance requirement—but in many respects it’s a lever for improved operational resilience in a digital-intensive financial world.
- It formalises the visibility of the ICT third-party landscape (which has been a pain-point for many firms).
- It supports supervisory oversight and macro-resilience of the EU financial sector (by feeding data to the ESAs for designation of critical providers).
- It forces internal disciplines (inventory, contracts, governance, risk ranking) that benefit the organisation beyond mere checkbox compliance.
If you are working in a financial entity in the EU with ICT outsourcing/third-party dependencies, your next steps should include: mapping your provider ecosystem, checking your data flows/contracts, understanding the local submission process and format requirements, and building continuous monitoring/update mechanisms.
Delaying the RoI exercise can be risky—not only from a regulatory deadline perspective but also because late mapping means less time to identify risk concentrations and address them proactively.