DORA Register of Information: How to Build and Report It

The Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554 — imposes a broad set of requirements on financial entities to manage their ICT-related risks. Among these, the Register of Information (RoI) stands out as one of the most operationally demanding obligations. It requires financial entities to create and maintain a comprehensive, structured register of every contractual arrangement they hold with ICT third-party service providers. This is not a high-level vendor list or a procurement spreadsheet. It is a detailed, multi-table data structure with over 60 mandatory fields, designed to give supervisory authorities granular visibility into the financial sector's dependence on ICT third parties.

This article explains what the RoI is, why it exists, what data it requires, where that data comes from, how to compile it, and how to keep it current. It also addresses the most common mistakes organisations make when building their RoI — and how to avoid them.

What Is the Register of Information?

The Register of Information is the mechanism through which DORA operationalises its ICT third-party risk management requirements at the reporting level. Under Article 28(3) of DORA, financial entities must maintain and keep up to date — at entity level and at sub-consolidated and consolidated levels — a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.

The RoI serves multiple purposes simultaneously:

• Internal governance: It provides the financial entity's management body with a complete picture of ICT third-party dependencies, enabling informed decision-making about concentration risk, exit planning, and business continuity
• Supervisory transparency: It gives competent authorities (NCAs) the ability to assess an individual entity's ICT third-party risk profile without conducting a full on-site inspection
• Systemic risk analysis: When aggregated across entities, RoI data enables the ESAs (EBA, ESMA, EIOPA) to identify systemic concentrations on specific providers — which directly feeds the Critical ICT Third-Party Provider (CTPP) designation process
• Incident response support: During an ICT incident affecting a major provider, the RoI enables rapid identification of all financial entities and functions potentially impacted

The RoI is not optional, not discretionary, and not limited to "significant" third-party arrangements. Every contractual arrangement for ICT services — regardless of size, value, or perceived importance — must be captured. The criticality or importance assessment determines the depth of information required (particularly for sub-outsourcing), but the baseline registration obligation applies to all ICT service arrangements.

Legal Basis: Article 28(3) and the Implementing Technical Standards

DORA Article 28(3) establishes the obligation to maintain the RoI. However, the detailed structure, data fields, and reporting format are specified in the Implementing Technical Standards (ITS) developed by the ESAs. Commission Implementing Regulation (EU) 2024/2956 — published in December 2024 — provides the definitive template that all financial entities must follow.

The ITS specifies a multi-table relational data model. This is a critical point that many organisations miss: the RoI is not a single flat spreadsheet. It is a structured, interlinked set of tables, each with defined data fields, validation rules, and relational keys. The tables are designed to be machine-readable and aggregatable across entities, which is essential for the ESAs' systemic analysis function.

The key tables in the ITS template include:

• Table B.01 — Entity-level information: Identifies the reporting financial entity (LEI, name, entity type, Member State, consolidation scope)
• Table B.02 — Contractual arrangement information: Captures each contract with an ICT third-party service provider (contract reference, start/end dates, renewal terms, governing law, notice period)
• Table B.03 — ICT third-party service provider information: Identifies each provider (LEI or alternative identifier, name, registered country, ultimate parent)
• Table B.04 — ICT service information: Describes the ICT services provided under each contract (service type, function supported, criticality assessment)
• Table B.05 — Data and processing location information: Specifies where data is stored and processed (country, region, on-premises vs. cloud)
• Table B.06 — Sub-outsourcing information: Documents the sub-outsourcing chain for services supporting critical or important functions

Each table references others through foreign keys — for example, a service in Table B.04 references a contract in Table B.02 and a provider in Table B.03. This relational structure is what distinguishes the RoI from a conventional vendor register and what makes it significantly more complex to build and maintain.

Mandatory Data Fields

The sheer number and specificity of data fields in the RoI template is what makes this obligation operationally challenging. Across all tables, the ITS requires over 60 distinct data fields, many of which are not typically captured in existing vendor management systems, procurement databases, or contract repositories.

Entity Identification Fields

Both the financial entity and the ICT third-party service provider must be identified using Legal Entity Identifiers (LEIs) where available. Where a provider does not have an LEI, an alternative identifier must be used along with a code indicating the identifier type. The entity's ultimate parent — where different from the direct contracting entity — must also be identified. This requirement catches many organisations off guard, as their vendor databases typically record only the trading name of the provider, not its legal entity structure.

Contract-Level Fields

Each contractual arrangement must be documented with its reference number, type of arrangement (standard contract, framework agreement, intra-group arrangement), start and end dates, renewal terms, notice period for termination, and governing law. For arrangements supporting critical or important functions, additional fields capture whether the contract includes audit rights, performance targets (SLAs), data location restrictions, and exit provisions.

Service-Level Fields

For each ICT service provided under a contract, the RoI must record the type of ICT service (using the ESA taxonomy), the business function it supports, whether it supports a critical or important function, the date of the most recent criticality assessment, and the substitutability assessment (how easily the service could be replaced). This level of granularity requires close collaboration between IT, business units, and risk functions — it cannot be completed by procurement alone.

Data Location Fields

DORA's data location requirements are notably specific. For each ICT service, the RoI must record where data is stored at rest, where data is processed, and which countries or regions are involved. For cloud-based services, this means understanding not just the primary data centre location but also failover regions, backup locations, and any temporary processing locations used during incident response. Many organisations discover that they lack this level of visibility into their cloud providers' infrastructure.

Sub-Outsourcing Fields

For ICT services supporting critical or important functions, the RoI must document the full sub-outsourcing chain. This means identifying every entity in the chain — from the direct provider through any sub-contractors — along with their roles, the services they provide, and the data locations at each level. This is typically the most difficult data to obtain, as it requires contractual rights to request sub-outsourcing information from providers and active processes to collect and verify that information.

RoI Data Fields Reference Table

The following table summarises the key categories and representative data fields required across the RoI template tables. This is not exhaustive but provides a practical reference for understanding the scope of data collection required.

Where the Data Comes From

One of the most common questions organisations face when starting their RoI build is: where do we actually find all this data? The answer is that no single system or function holds all the information required. Building the RoI is inherently a cross-functional exercise that draws from multiple data sources across the organisation.

Procurement and Vendor Management Systems

These are the natural starting point for identifying contractual relationships. However, procurement systems typically record purchase order data, invoice amounts, and vendor contact information — not the legal entity structure, sub-outsourcing chain, or data processing locations required by the RoI. Procurement data provides the initial universe of providers but must be significantly enriched.

Contract Repositories

Contract management systems or document repositories contain the actual contractual terms — start and end dates, renewal clauses, governing law, notice periods, and (where present) audit rights and exit provisions. However, many organisations have incomplete or decentralised contract archives, particularly for older arrangements or those managed outside of formal procurement processes (such as IT-initiated SaaS subscriptions).

IT Asset Management and CMDB

Configuration Management Databases and IT asset management tools can provide information about which ICT services are in use, which business applications they support, and basic infrastructure details. However, mapping from a CMDB entry to the specific contractual arrangement and provider legal entity requires manual correlation in most organisations.

Business Continuity and Risk Functions

Criticality assessments — determining which ICT services support critical or important functions — are typically owned by business continuity management, operational risk, or a dedicated outsourcing risk function. These assessments provide the critical/important function flag that determines the depth of information required in the RoI. If your organisation has not yet conducted these assessments, this is a prerequisite to completing the RoI.

Direct Provider Engagement

For data that the financial entity does not hold internally — particularly data processing locations, sub-outsourcing chains, and provider legal entity structures — direct engagement with the ICT third-party service provider is required. This is where contractual audit rights and information request clauses become operationally important. Providers are not obligated to disclose sub-outsourcing information unless the contract requires it, which means organisations that did not negotiate these clauses may face data gaps.

Mapping Sub-Outsourcing Chains

Sub-outsourcing chain documentation is the single most challenging aspect of the RoI for most financial entities. The challenge is both contractual and operational.

The Contractual Challenge

DORA Article 30(2)(a) requires that contractual arrangements on the use of ICT services include the obligation for the ICT third-party service provider to provide the financial entity with information on sub-outsourcing. However, many existing contracts — particularly those signed before DORA entered into force — do not contain such provisions. Financial entities must either renegotiate contracts to add these clauses or use alternative mechanisms (such as information requests under DORA's framework) to obtain the data.

The Operational Challenge

Even when contractual rights exist, obtaining accurate sub-outsourcing information is difficult. Major cloud providers, for example, may rely on dozens of sub-processors for specific functionalities — data centre operations, content delivery, monitoring, backup — and the chain can be several levels deep. The financial entity must not only obtain the list of sub-contractors but also understand what services each provides, where data is stored or processed at each level, and how the chain would change if the primary provider were to substitute a sub-contractor.

Practical Approach

The most effective approach is a structured provider engagement programme that prioritises critical and important function providers first. This involves:

• Identifying all ICT service arrangements supporting critical or important functions (the threshold for sub-outsourcing disclosure)
• Reviewing existing contracts for sub-outsourcing disclosure provisions
• Issuing structured information requests to providers — using a standardised questionnaire aligned to the ITS data fields
• Validating provider responses against publicly available information (e.g., cloud provider sub-processor lists)
• Establishing ongoing notification mechanisms for sub-outsourcing chain changes

Organisations that delay this provider engagement until late in their RoI build consistently find that providers have long response times — particularly hyperscalers processing requests from thousands of financial entity clients simultaneously — and the data gap becomes a blocking issue.

Criticality and Importance Assessment

The criticality assessment is the gating mechanism that determines the depth of RoI data required for each ICT service arrangement. DORA Article 3(22) defines a "critical or important function" as a function the disruption of which would materially impair the financial performance, soundness, or continuity of services and activities of the financial entity, or the disruption, malfunction, or failure of which would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation.

For arrangements supporting critical or important functions, the RoI requires additional data fields — including sub-outsourcing chains, exit plan availability, substitutability assessments, and more detailed data location information. For non-critical arrangements, the baseline data fields still apply, but the sub-outsourcing and enhanced data requirements do not.

The criticality assessment must be documented and dated. It should be reviewed at least annually or when there is a material change in the service arrangement. Common mistakes include defaulting all services to "non-critical" (which will not withstand supervisory scrutiny) or defaulting all services to "critical" (which creates unnecessary data collection burden and dilutes genuine risk focus).

How to Compile the RoI Step by Step

Building the RoI is a multi-phase project that typically takes three to six months for a medium-complexity financial entity. The following step-by-step approach has proven effective across our advisory engagements.

Step 1: Establish the Perimeter

Begin by defining the reporting perimeter — which legal entities within the group are in scope, and at which consolidation level the RoI will be reported. For groups, the RoI must be maintained at entity, sub-consolidated, and consolidated levels, which means coordination across subsidiaries and branches.

Step 2: Build the Provider Universe

Extract the complete list of ICT third-party service providers from procurement systems, contract repositories, IT asset inventories, and shadow-IT discovery tools. Apply the DORA definition of "ICT services" broadly — it includes not only infrastructure and application providers but also data analytics providers, ICT consultancy services, and ICT support services. The typical financial entity has significantly more ICT third-party arrangements than initially expected.

Step 3: Enrich Provider Data

For each provider, obtain the LEI (from the GLEIF database), identify the legal entity structure, and determine the ultimate parent company. Map each provider to its relevant contractual arrangements. Resolve any discrepancies between the provider entity named in the contract and the entity that actually delivers the service.

Step 4: Map Services to Functions

For each contractual arrangement, document the specific ICT services provided and the business functions they support. This requires collaboration between IT (which understands the technical service) and business units (which understand the function the service supports). Apply the ESA's ICT service taxonomy to categorise each service.

Step 5: Conduct Criticality Assessments

Assess each ICT service arrangement against the "critical or important function" definition. Document the rationale, the date of the assessment, and the reviewer. This assessment determines the scope of additional data required — particularly sub-outsourcing and data location detail.

Step 6: Collect Enhanced Data for Critical/Important Arrangements

For arrangements supporting critical or important functions, launch provider engagement to collect sub-outsourcing chain data, detailed data location information, and exit plan availability. Use standardised questionnaires aligned to the ITS template fields. Allow adequate time — provider response times of four to eight weeks are common.

Step 7: Populate the ITS Template

Map all collected data into the ITS template tables, ensuring referential integrity between tables (contract references linking to provider IDs, service descriptions linking to contract references, etc.). Run validation checks for mandatory fields, data format compliance, and logical consistency.

Step 8: Management Body Review and Approval

Present the completed RoI to the management body for review. The RoI is a governance tool as well as a reporting mechanism — management should understand the concentration risks, the critical dependencies, and the exit plan status for the entity's most important ICT third-party arrangements.

Submitting the RoI to Authorities

The RoI must be submitted to the competent authority upon request. There is no fixed annual submission date in DORA itself, but competent authorities are expected to establish regular reporting cycles. The ESAs also collect RoI data to support the CTPP designation process and broader systemic risk monitoring.

Submission format is specified in the ITS — financial entities should expect to submit data in a structured, machine-readable format (XML or similar) rather than as a PDF or spreadsheet attachment. This means the RoI must be maintained in a format that can be exported to the ITS schema at any time, which has implications for the tooling and data management approach used to maintain the register.

Key submission considerations include:

• Timeliness: Competent authorities may set short turnaround times for submission requests. Entities that maintain a current, complete RoI can respond quickly; those that rely on manual assembly will struggle
• Data quality: Submissions will be subject to automated validation. Incomplete mandatory fields, inconsistent references, and formatting errors will cause rejection
• Consolidation: Group-level RoI submission requires aggregation of data from multiple entity-level registers — this coordination effort should not be underestimated
• Versioning: The RoI is a living document. Entities should maintain version control and an audit trail of changes to demonstrate ongoing maintenance

Ongoing Maintenance

The RoI is not a project with a defined end date — it is an ongoing operational obligation. Financial entities must keep the register up to date as their ICT third-party landscape evolves. This requires embedded processes, not periodic refresh exercises.

Trigger-Based Updates

The RoI should be updated whenever a material change occurs to an ICT service arrangement. Triggers include: new contracts signed, existing contracts terminated or renewed, provider mergers or acquisitions (which may change the legal entity or ultimate parent), changes to data processing locations, changes in the sub-outsourcing chain, changes in criticality assessment results, and regulatory reclassification of the financial entity itself.

Periodic Reviews

In addition to trigger-based updates, a scheduled periodic review — at least annually — should validate the accuracy and completeness of the RoI. This review should include reconciliation against procurement records, re-validation of LEIs and provider legal entity structures, re-assessment of criticality, and confirmation that data location information remains current.

Governance and Ownership

Clear ownership of the RoI is essential. The most effective model assigns a dedicated RoI owner — typically within the outsourcing management, third-party risk management, or operational resilience function — with accountability for data quality, timeliness, and completeness. This owner coordinates with procurement (for contract data), IT (for service data), risk (for criticality assessments), and business units (for function mapping). Without clear ownership, the RoI degrades rapidly as changes go unrecorded.

Common Pitfalls and How to Avoid Them

Having supported numerous financial entities through their RoI build programmes, we have observed consistent patterns of difficulty. The following are the most common pitfalls — and how to avoid them.

Pitfall 1: Treating the RoI as a One-Time Data Collection Exercise

Many organisations approach the RoI as a project — collect the data, populate the template, submit it, and move on. This approach fails because the ICT third-party landscape is dynamic. Contracts are signed and terminated continuously, providers change their sub-outsourcing arrangements, data centres are added or decommissioned, and criticality assessments evolve. Organisations that build the RoI as a one-time exercise find it outdated within months and face a significant refresh effort before each supervisory request.

Solution: Build operational maintenance processes from the start. Integrate RoI updates into the contract lifecycle management process, the provider onboarding process, and the periodic risk review cycle.

Pitfall 2: Failing to Capture Sub-Outsourcing Chains Early

Sub-outsourcing data is the hardest data to obtain. Providers may be reluctant to disclose, contracts may lack the required provisions, and response times can be lengthy. Organisations that leave sub-outsourcing data collection to the final phase of the build consistently miss deadlines.

Solution: Initiate provider engagement for sub-outsourcing data as early as possible — ideally in parallel with the internal data collection phase. Prioritise providers supporting critical or important functions.

Pitfall 3: Inconsistent or Missing LEIs

The LEI is the primary identifier for both financial entities and providers in the RoI. Many providers — particularly smaller or non-financial entities — do not have LEIs. Even when LEIs exist, the LEI recorded in the procurement system may not match the legal entity that actually delivers the service (e.g., the contract is with a holding company, but service delivery is from an operating subsidiary). Inconsistent LEI usage undermines the referential integrity of the RoI.

Solution: Use the GLEIF LEI search to validate all LEIs before populating the RoI. Where providers lack LEIs, use the alternative identifier framework specified in the ITS and document the identifier type clearly.

Pitfall 4: Incomplete Criticality Assessments

Some organisations default all services to "non-critical" to minimise the data collection burden. This is both a compliance risk (supervisory authorities will challenge assessments that appear insufficiently rigorous) and a governance risk (management lacks visibility into genuine dependencies). Conversely, marking all services as "critical" creates unnecessary data collection requirements and operational overhead.

Solution: Apply a structured criticality assessment methodology aligned to DORA's definition. Document the criteria, the assessment rationale, and the review date. Ensure the assessment is performed by personnel with knowledge of the business function the ICT service supports — not by procurement in isolation.

Pitfall 5: Relying on Existing Systems Without Gap Analysis

Organisations often assume that their existing vendor management system, procurement database, or GRC tool can produce the RoI with minimal modification. In practice, these systems rarely contain the specific data fields required by the ITS — particularly data location granularity, sub-outsourcing chain data, ESA service taxonomy classifications, and substitutability assessments. Attempting to force-fit existing data into the ITS template results in significant gaps.

Solution: Conduct a detailed data field gap analysis between the ITS template requirements and the data available in existing systems before starting the build. This analysis identifies exactly which fields require new data collection and which can be sourced from existing sources.

Frequently Asked Questions