The Register of Information (RoI) is one of the most concrete and auditable obligations under the Digital Operational Resilience Act (DORA - EU Regulation 2022/2554). Article 28.3 requires every financial entity in scope to maintain a detailed register of all contractual arrangements with ICT third-party service providers - and to report it annually to their competent authority.
For many organisations, this is the first requirement that moves from policy documents into structured, machine-readable data. Getting it right is essential.
What is the Register of Information?
Under DORA Article 28.3, financial entities must maintain a register that documents every contractual arrangement involving ICT services provided by third parties. This includes cloud hosting, software-as-a-service platforms, managed security services, data processing, network infrastructure, and any outsourced ICT function that supports critical or important operations.
The RoI is not a one-time exercise. It is a living document that must be updated whenever contracts change, new providers are onboarded, or existing arrangements are modified or terminated.
Why it matters
The European Supervisory Authorities (ESAs) - the EBA, EIOPA, and ESMA - use the RoI data to build a picture of systemic ICT concentration risk across the European financial sector. This data directly feeds into the process for designating Critical Third-Party Providers (CTPPs) under DORA Articles 31-44.
Financial entities are required to submit their RoI annually in a structured format defined by the ESAs. Incomplete or inaccurate submissions may trigger supervisory follow-up and are a clear indicator of weak third-party governance.
Required data fields
The EBA's reporting templates define the mandatory data structure. At a high level, each record in the register must include:
- Entity identification - LEI code, entity name, entity type, and competent authority
- Service provider details - provider name, LEI (where available), jurisdiction, whether the provider is an intra-group entity
- Contract information - contract reference, start date, end date or renewal terms, governing law
- ICT services description - type of service, whether it supports a critical or important function, business functions supported
- Criticality assessment - impact analysis if the service were disrupted or compromised
- Sub-outsourcing chain - any sub-contractors involved in delivering the service, including their jurisdiction and the nature of the sub-outsourced component
- Data location - where data is stored and processed, including any cross-border transfers
- Exit strategy - documented substitutability assessment and transition plan
Common challenges
Building the RoI from scratch exposes several operational gaps that many financial entities underestimate:
Scattered vendor data
Contract details often sit across procurement systems, legal repositories, IT asset management tools, and individual spreadsheets. There is rarely a single source of truth for all ICT third-party relationships.
Legacy contracts
Older contracts may lack the data fields DORA now requires - criticality assessments, sub-outsourcing disclosures, or data processing locations. Retrofitting this information requires coordination between legal, procurement, and IT teams.
Sub-contractor mapping
Understanding the full sub-outsourcing chain is one of the most difficult aspects. Many providers use sub-processors that the financial entity has limited visibility into. DORA requires this visibility, and achieving it often means renegotiating contract terms or sending due diligence questionnaires to existing providers.
Ongoing maintenance
The RoI is not a one-time project. Every new contract, renewal, amendment, or termination must be reflected in the register. Without a structured process, the data becomes stale within months.
A practical approach to building your RoI
Based on our experience working with financial entities across the EU, we recommend the following approach:
- Start with critical functions - Identify your critical or important business functions first, then map the ICT services that support them. This gives you immediate visibility into your highest-risk dependencies.
- Centralise contract data - Bring all vendor and contract information into a single structured format. Do not attempt to maintain the RoI in spreadsheets long-term.
- Engage providers early - Send data collection requests to your key ICT providers. Many will have prepared DORA-specific disclosure packs. For those that have not, use a standardised questionnaire.
- Establish update triggers - Define clear processes for when the register must be updated: new contract, amendment, renewal, provider change, or sub-outsourcing change.
- Validate against ESA templates - Before submission, validate your data against the official ESA reporting structure to avoid formatting errors or missing fields.
How DoraLytics helps
DoraLytics includes a purpose-built Register of Information module that automates much of this process. Vendor and contract data entered through the Third-Party Risk Management module feeds directly into the RoI, with all mandatory ESA data fields pre-mapped. When it is time to submit, you can export the register in the required format with a single action - no manual reformatting required.
DORA has been in force since January 17, 2025. Financial entities must have their Register of Information operational and be prepared for the annual reporting cycle. Check with your national competent authority for specific submission windows.
Further reading
- DORA Regulation full text (EU 2022/2554) - EUR-Lex
- EBA - Register of Information reporting templates and guidance
Want to simplify your DORA compliance?
See how DoraLytics can help you build and maintain your Register of Information with automated data collection and ESA-format export.
Explore DoraLytics