Background

What Is the Register of Information?

Article 28(3) of DORA requires every financial entity in scope to maintain a register of information on all contractual arrangements with ICT third-party service providers. This is not a policy document or a risk assessment. It is a structured dataset that records every ICT service arrangement your organisation has in place, who provides it, what business functions it supports, and whether those functions are critical or important.

The purpose of the register is twofold. First, it gives the financial entity itself a complete view of its ICT dependency landscape, which is essential for concentration risk analysis under Art. 29 and for the broader third-party risk management framework under Art. 28-44. Second, it provides national competent authorities (NCAs) with a standardised way to assess ICT third-party risk across the financial sector.

The register must be maintained at all times, not assembled on an ad hoc basis when a supervisor asks for it. Art. 28(3) explicitly states that the register shall be kept up to date. This means it must reflect current contractual arrangements, current provider details, and current sub-outsourcing chains. Changes to any of these must be reflected in the register promptly.

The format and content of the register are defined by Implementing Technical Standards published by the EBA, specifically ITS 2024/2956. This standard defines the exact data fields, entity types, and relationships that the register must contain. Submissions to NCAs must follow this schema.

Data requirements

What Data the RoI Must Contain

The ITS 2024/2956 schema defines the Register of Information as a set of linked tables covering entities, contractual arrangements, ICT services, functions, and sub-outsourcing relationships. The data requirements are extensive and specific. Here are the main categories.

1
Entity Identification
LEI, name, jurisdiction, entity type

Every entity referenced in the register must be identified using a Legal Entity Identifier (LEI) where available, along with the entity name, country of registration, and entity type. This applies to the reporting financial entity itself, all ICT service providers, and all sub-contractors in the chain. The LEI is the primary key used by NCAs to link data across entities and jurisdictions.

2
Contractual Arrangements
Contract details, dates, governing law

Each ICT third-party arrangement must be recorded with its contract reference, start date, end date (or whether it is open-ended), renewal terms, notice period, and governing law. The register must identify which arrangements relate to critical or important functions (CIFs) and flag whether the arrangement is substitutable. This data feeds directly into concentration risk assessments and exit planning under Art. 28(8).

3
ICT Services and Functions
Service description, CIF mapping, data locations

For each contractual arrangement, the register must describe the ICT services provided and map them to the business functions they support. Where the supported function is a critical or important function, this must be explicitly flagged. The register must also record where data is processed and stored, including the specific countries and whether personal data is involved. This is essential for assessing data residency compliance and cross-border risk.

4
Sub-Outsourcing Chains
Sub-contractors, chain depth, CIF involvement

Where an ICT service provider sub-contracts part of the service, the register must capture the full sub-outsourcing chain. Each sub-contractor must be identified (LEI, name, jurisdiction), and the register must record which parts of the service are sub-contracted and whether the sub-contracted service supports a critical or important function. Art. 29(2) requires entities to assess the risks arising from these chains, and the register provides the data needed to do so.

Key dates

Submission Timeline and NCA Requirements

The Register of Information has a defined submission history and ongoing obligations that financial entities must be aware of.

17 January 2025
Completed
DORA became enforceable
All DORA obligations took effect, including the requirement to maintain the Register of Information at all times under Art. 28(3). Entities were expected to have their registers populated and ready for supervisory review from this date.
30 April 2025
Completed
First NCA submission deadline
The first reference date for Register of Information submissions to national competent authorities. Entities submitted their complete register in the ITS 2024/2956 format. This was the first major DORA reporting milestone and highlighted data quality issues across the sector.
Ongoing
Continuous
Maintain and submit on request
The register must be maintained at all times and submitted to the NCA on request. Some NCAs have established annual submission cycles, typically with a reference date of 31 December and submission due in Q1 of the following year. Your NCA may also request ad hoc submissions as part of supervisory reviews or thematic exercises. The register should always be submission-ready.
Practical issues

Common Challenges

Building and maintaining the Register of Information is one of the more operationally challenging DORA requirements. Based on the experience of the first submission cycle, these are the issues that most commonly arise.

Data Data Collection
Gathering LEI codes for all providers and sub-contractors, many of which may not have an LEI or may have multiple entities under different LEIs
Identifying all ICT third-party arrangements, including shadow IT and informal arrangements that procurement may not have visibility of
Obtaining sub-outsourcing chain information from providers who may be reluctant or slow to disclose their sub-contractor details
Mapping Function and Service Mapping
Mapping ICT services to the critical or important functions they support, especially where a single provider supports multiple functions or a function depends on multiple providers
Determining the correct CIF classification for each function, which requires input from both business and IT stakeholders
Recording data processing locations accurately, particularly for cloud services that may process data across multiple regions
Quality Validation and Data Quality
Passing the 85+ EBA validation rules, which check data completeness, format correctness, cross-field consistency, and referential integrity across the linked tables
Maintaining data quality over time as contracts change, providers merge, and sub-outsourcing arrangements evolve
Reconciling data from multiple internal sources (procurement, legal, IT, business units) into a single consistent register
Platform

How to Build and Maintain Your RoI

The Register of Information is not a one-off deliverable. It is a continuously maintained dataset that must be accurate, complete, and submission-ready at all times. The most effective approach is to use a purpose-built tool that structures the data according to the ITS schema from the start.

ITS 2024/2956 Schema Built In

DORA GRC structures the Register of Information according to the EBA ITS 2024/2956 schema natively. Entity types, relationship types, and data fields match the standard exactly. You enter data once and it populates the register automatically. No spreadsheet mapping required.

85-Rule Validation Engine

Before you submit to your NCA, run the built-in validation engine. It checks all 85+ EBA rules covering completeness, format, cross-references, and logical consistency. Errors are flagged with the specific rule reference and a clear description of what needs to be fixed. This prevents rejection or rework after submission.

Provider and Sub-Contractor Management

The provider register feeds directly into the RoI. When you add a provider, update a contract, or record a sub-outsourcing chain, the register is updated automatically. Concentration risk analysis (Art. 29) uses the same data, so there is no duplication. Learn more about DORA third-party risk management.

Export in NCA Submission Format

Export the complete Register of Information as an EBA-format file ready for NCA submission. The export includes all linked tables, entity identifiers, and relationship references in the structure your supervisor expects. For a broader view of DORA compliance requirements, see our complete guide.

For a full list of features across all five pillars, see the features page.

Frequently asked questions

Register of Information FAQ

What is the DORA Register of Information?
The DORA Register of Information is a structured dataset that financial entities must maintain under Art. 28(3) of EU Regulation 2022/2554. It records all contractual arrangements with ICT third-party service providers, including which business functions they support, whether those functions are critical or important, and the sub-outsourcing chains involved. The format is defined by EBA ITS 2024/2956 and must be submitted to national competent authorities on request. It serves both as an internal management tool for understanding ICT dependencies and as a supervisory reporting mechanism.
When is the RoI submission deadline?
The first Register of Information submission to NCAs was due by 30 April 2025. Going forward, entities must maintain the register at all times and submit it on request. Some NCAs have established annual submission cycles, typically with a reference date of 31 December and submission due in Q1 of the following year. Ad hoc requests from supervisors can come at any time, so the register must always be submission-ready. Check with your specific NCA for their submission calendar and any additional requirements.
What data does the Register of Information require?
The RoI requires data across several linked categories as defined by ITS 2024/2956. This includes: entity identification (LEI codes, names, jurisdictions) for the reporting entity, all providers, and all sub-contractors; contractual arrangement details (reference numbers, dates, governing law, substitutability); ICT service descriptions and how they map to business functions; critical or important function classification; data processing and storage locations; and the full sub-outsourcing chain for each arrangement. The schema contains over 80 fields across multiple linked tables. Each field has specific format requirements that are checked by the EBA validation rules.
How do I validate my RoI before submission?
The EBA has published 85+ validation rules that check data completeness, format correctness, cross-field consistency, and referential integrity across the linked tables. You should run these checks before every submission. Common validation failures include missing LEI codes, inconsistent entity references across tables, incorrect date formats, and orphaned relationships where a sub-contractor record references a contract that does not exist. Purpose-built DORA software like DORA GRC includes a built-in validation engine that runs all checks automatically, flags errors with the specific rule reference, and provides guidance on how to fix each issue. Manual validation using spreadsheets is possible but error-prone given the number and complexity of the rules.