The DORA Information Register

The DORA Information Register: Purpose and Scope

Art. 28(3) of DORA (EU Regulation 2022/2554) requires financial entities to maintain and keep up to date a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This register is a cornerstone of the third-party risk management framework and serves both internal risk management and supervisory oversight purposes.

The information register is not a one-time documentation exercise. It must be a living document that is updated whenever contractual arrangements change, new providers are onboarded, or existing arrangements are terminated. Financial entities must report the register to the competent authority at least annually.

What Must Be Recorded

The ESAs have published Implementing Technical Standards (ITS) that specify the exact data fields for the information register. At a high level, the register must capture information across several categories:

Entity-Level Information

• Legal entity identifier (LEI) and name of the financial entity
• Group structure and the entity's position within it
• The competent authority responsible for supervision

Contractual Arrangement Details

• Unique reference number for each contractual arrangement
• Type of contractual arrangement (cloud, on-premise, managed service, etc.)
• Start date, end date, and notice periods
• Whether the arrangement supports a critical or important function
• Cost and pricing model of the arrangement

Provider Information

• Legal name, LEI, and registration details of the provider
• Location of the provider's headquarters and relevant operational centres
• Whether the provider is designated as a Critical Third-Party Provider (CTPP) under Art. 31
• Information on sub-contractors or sub-outsourcing chains

Service and Data Information

• Description of the ICT services provided
• Business functions and processes supported by the arrangement
• Data processing and storage locations (countries)
• Data classification levels of data handled by the provider
• Whether the service involves personal data processing under GDPR

Risk and Contingency Information

• Assessment of the substitutability of the provider
• Identification of alternative providers or internal capabilities
• Exit strategy details, including transition timelines
• Date of the last risk assessment for the arrangement
• Audit and inspection results, where applicable

Annual Reporting to Supervisory Authorities

Financial entities must report the information register to the competent authority at least annually. The authority may request the register at any time, so it must be kept current on an ongoing basis. The reporting format and transmission channels are specified in the ITS published by the ESAs.

Supervisory authorities use the register data for several purposes:

• Identifying systemic concentration risk across the financial sector
• Assessing individual entity's third-party risk profiles
• Supporting the designation of Critical Third-Party Providers (CTPPs)
• Planning supervisory activities and inspections

Failure to maintain an accurate and complete register or to submit timely reports can result in administrative penalties. See our DORA Penalties page for details.

ITS Requirements and Data Model

The Implementing Technical Standards published by the Joint Committee of the ESAs define a structured data model with multiple interlinked tables. The register is organised into several layers:

The data model is relational: a single provider may appear in multiple contractual arrangements, and a single arrangement may support multiple business functions. This requires careful data management to avoid inconsistencies.

Practical Implementation

Building the information register from scratch is a substantial undertaking. Here is a pragmatic approach:

Step 1: Inventory All ICT Arrangements

Start by collecting all contracts, purchase orders, and informal arrangements involving ICT services. This includes cloud subscriptions, SaaS licences, managed services, consulting arrangements, and any service where a third party processes, stores, or has access to the entity's data or systems. Many entities are surprised by the volume: mid-sized banks typically have 100-300 ICT third-party arrangements.

Step 2: Classify by Criticality

Not all arrangements require the same level of detail. Arrangements supporting critical or important functions demand enhanced due diligence, specific contractual clauses (Art. 30), and more granular register entries. Start your classification by assessing the impact of a disruption of each service on the entity's business operations.

Step 3: Populate the Register

Work through the ITS template systematically. For critical-function arrangements, all data fields must be completed. For non-critical arrangements, a reduced set of fields is required. Coordinate with procurement, legal, IT, and business departments to gather the necessary data.

Step 4: Establish Maintenance Processes

The register must be kept up to date. Establish processes so that any new arrangement, termination, or material change triggers an update. Integrate register maintenance into your procurement and vendor management workflows.

Common Challenges

• Incomplete provider information: Many providers are reluctant to disclose sub-outsourcing chains or exact data locations. Contractual clauses under Art. 30 give you the leverage to require this information.
• Shadow IT: Business departments may use SaaS services without IT or procurement awareness. A thorough discovery process is essential.
• Group complexity: For financial groups, the register must capture arrangements at the consolidated level, adding significant complexity.
• Data quality: The relational data model requires consistent use of identifiers (especially LEIs). Maintaining data quality across hundreds of entries requires tooling support.

Managing the information register in spreadsheets is technically possible for small entities but becomes unmanageable at scale. A GRC tool like Kopexa provides structured templates, relational data management, and automated reporting capabilities aligned with the ITS data model.

For the broader context of third-party risk management, see our ICT Third-Party Risk page. For a step-by-step compliance guide, see our DORA Checklist.