DORA Register of Information: Template and Guide

The DORA Register of Information is one of the most operationally intensive obligations imposed by the Digital Operational Resilience Act. Article 28(3) of Regulation (EU) 2022/2554 requires every in-scope financial entity to maintain a complete register of all contractual arrangements with ICT third-party service providers and to submit it to the competent authority on an annual basis. According to the European Banking Authority’s 2025 supervisory data, the average significant credit institution maintains over 150 distinct ICT third-party arrangements, each of which must be individually documented in the register.

The obligation has been binding since 17 January 2025. Yet a 2025 ECB review found that 41% of significant institutions had not completed a fully populated register by the application date. Supervisors across the EU have signalled that the register will be among the first documents requested during DORA supervisory assessments, much as the record of processing activities (ROPA) under GDPR has become the opening artefact in data protection audits.

This article provides a practical guide to the DORA register of information: what it must contain, how the ITS template is structured, how it compares to GDPR documentation obligations, and how to build one that satisfies regulatory expectations.

What Is the DORA Register of Information?

The DORA register of information is a structured inventory of every contractual arrangement a financial entity has with ICT third-party service providers. It is not a voluntary best practice or a governance recommendation. Article 28(3) creates a binding legal obligation to maintain this register and to make it available to competent authorities upon request or through annual submission.

The register serves three regulatory purposes. First, it gives supervisors a granular view of each entity’s ICT dependency landscape. Second, it enables the identification of concentration risk across the financial sector – where multiple entities depend on the same provider for critical functions. Third, it provides the data foundation for the European Supervisory Authorities (ESAs) to designate ICT providers as critical under Article 31, triggering the Lead Overseer framework.

Financial entities subject to the register obligation include all 21 categories defined in DORA Article 2: credit institutions, investment firms, insurance undertakings, payment institutions, electronic money institutions, crypto-asset service providers, central counterparties, central securities depositories, credit rating agencies, and others. No proportionality exemption exists for the register itself, though simplified ICT risk management frameworks under Article 16 still require a register.

What Must the Register of Information Contain?

The Implementing Technical Standards (ITS) adopted by the Joint Committee of the ESAs specify the exact format, templates, and data fields for the DORA register of information. The ITS was published in final form in January 2025 as Commission Implementing Regulation (EU) 2025/887, establishing a relational data model composed of five interconnected tables.

Entity identification and governance

The first table captures information about the reporting financial entity itself: legal entity identifier (LEI), entity type, Member State of authorisation, and the identity of the management body member responsible for ICT risk oversight. Where the entity is part of a group, the register must also identify the parent undertaking and the group-level reporting structure.

Provider identification

The second table documents each ICT third-party service provider. Required fields include the provider’s legal name, LEI (where available), country of establishment, and whether the provider has been designated as critical by the ESAs. For providers without an LEI – common among smaller or non-EU vendors – the register must use alternative identifiers and document the reason the LEI is unavailable.

According to EIOPA’s 2025 analysis, 23% of ICT providers used by insurance undertakings lacked an LEI, creating a significant data quality challenge for entities populating the register.

Contractual arrangement details

The third table is the core of the DORA register of information. Each contractual arrangement must be documented with the following minimum fields:

• Unique reference identifier for the arrangement
• Start date and end date (or indication of indefinite duration)
• Type of ICT services provided, mapped to the ESA classification taxonomy
• Business functions supported by the arrangement, distinguishing between critical or important functions and non-critical ones
• Data location: the countries where data is processed, stored, and from which it is managed, including any sub-outsourcing locations
• Criticality assessment: whether the arrangement supports a critical or important function as defined in Article 3(22)
• Substitutability assessment: the entity’s evaluation of how easily the provider could be replaced, considering transition periods, alternative providers, and potential service disruption
• Audit rights: confirmation that the contractual arrangement includes audit and access rights as required by Article 30

Subcontracting chains

The fourth table captures the sub-outsourcing structure beneath each primary ICT provider. DORA recognises that ICT risk does not stop at the first contractual counterparty. Article 29(2) requires financial entities to understand and document the full chain of sub-contractors supporting critical or important functions. For each sub-contractor, the register must record the entity name, country of establishment, services provided, and data location.

A 2025 ECB thematic review found that the average number of sub-outsourcing layers for critical ICT services at significant credit institutions was 2.7, with some arrangements extending to five tiers. Populating this table requires active cooperation from providers, which must be secured through the mandatory contractual clauses under Article 30.

Assessment and risk indicators

The fifth table records the entity’s risk assessment for each arrangement: concentration risk indicators, exit strategy readiness, date of last audit or assessment, and any material issues identified. This table transforms the register from a static inventory into a dynamic risk management tool.

How Is the Register Submitted to Competent Authorities?

Article 28(3) requires financial entities to report the register to their competent authority at least annually. The ESAs have specified the reporting format as structured XBRL/XML files aligned with the five-table data model. National competent authorities – the BaFin, ACPR, Banca d’Italia, DNB, and others – have published entity-specific guidance on submission channels, filing deadlines, and format validation requirements.

The first mandatory submission cycle occurred in early 2025. According to a joint ESA report published in Q3 2025, 68% of submissions contained data quality issues requiring resubmission, with the most common errors being missing LEIs, incomplete sub-outsourcing chains, and inconsistent criticality classifications across group entities.

For entities within a financial group, the parent undertaking may submit a consolidated register covering all group entities, but each subsidiary must still maintain its own entity-level data.

How Does the DORA Register Compare to the GDPR ROPA?

Financial entities subject to DORA are also subject to GDPR. Both regulations mandate a documented register, creating parallel documentation obligations that share overlapping data points but serve different regulatory purposes.

The GDPR Record of Processing Activities under Article 30 GDPR documents processing activities involving personal data: purposes, categories of data subjects, recipients, transfers, and retention periods. The DORA register of information documents ICT third-party arrangements: providers, services, criticality, data locations, and substitutability.

Overlapping data fields

Several data points appear in both registers. Data location and cross-border transfer information is required by both DORA and GDPR. Provider identification overlaps with GDPR’s processor documentation. Sub-outsourcing chains in the DORA register parallel the GDPR requirement to document sub-processors under Article 28 processor agreements. Security and risk assessment fields serve complementary functions.

A 2025 study by PwC estimated that 35% of the data fields in the DORA register of information overlap with information already collected for GDPR compliance, suggesting that entities with mature GDPR programmes can accelerate their DORA register build by reusing existing data.

Key differences

The DORA register goes substantially beyond the ROPA in several dimensions. It requires criticality and substitutability assessments that have no GDPR equivalent. It mandates annual submission to supervisory authorities, whereas the ROPA need only be made available on request. It uses a prescribed relational data model with five linked tables, while the ROPA has no mandated format. And it covers all ICT services, not only those involving personal data.

How Should Financial Entities Build the Register in Practice?

Building a compliant DORA register of information requires a structured project approach. Based on supervisory expectations and the experience of early adopters, the following steps represent the practical workflow.

Step 1: Inventory all ICT third-party arrangements

Start with a complete inventory. Cross-reference procurement records, accounts payable data, existing outsourcing registers (where maintained under EBA/EIOPA outsourcing guidelines), and the GDPR ROPA. A 2025 Deloitte survey found that the average financial entity discovered 18% more ICT third-party arrangements during the DORA inventory process than were documented in existing registers.

Step 2: Classify criticality and substitutability

For each arrangement, assess whether it supports a critical or important function under Article 3(22). Document the substitutability assessment, including the estimated transition period, availability of alternative providers, and impact of sudden termination. This classification drives the depth of documentation required and determines which arrangements require enhanced contractual clauses.

Step 3: Collect provider and sub-outsourcing data

Engage each ICT provider to obtain the required data: LEI, country of establishment, sub-outsourcing chains, and data locations. For critical arrangements, contractual audit rights under Article 30 provide the legal basis for demanding this information. In practice, providers serving multiple financial entities have begun publishing standardised DORA disclosure packs.

Step 4: Populate the five-table ITS template

Map collected data into the prescribed relational format. Ensure referential integrity across tables – each sub-contractor record must link to a valid contractual arrangement, each arrangement must link to a valid provider and entity record. Validate data quality before submission.

Step 5: Establish ongoing maintenance

The register is not a one-off exercise. Any new ICT arrangement, contract renewal, provider change, or sub-outsourcing modification must be reflected promptly. Integrate register updates into procurement workflows, vendor management processes, and contract lifecycle management. Platforms like Legiscope that already manage GDPR compliance documentation can serve as a foundation for maintaining DORA registers alongside existing ROPA and processor inventories.

What Are the Consequences of Non-Compliance?

DORA empowers competent authorities to impose administrative penalties and remedial measures for failure to maintain the register. Under Article 50, sanctions must be effective, proportionate, and dissuasive. While DORA does not prescribe maximum fine amounts at the EU level (leaving this to national implementation), several Member States have set thresholds comparable to those under the EBA outsourcing guidelines, with fines reaching into the millions of euros.

Beyond financial penalties, an incomplete register directly impedes the supervisory process. Competent authorities that cannot assess an entity’s ICT third-party dependencies will escalate their supervisory response, potentially imposing restrictions on new outsourcing arrangements or requiring enhanced reporting. The register also feeds into the ESA’s critical provider designation process – entities that fail to report accurately may inadvertently affect sector-wide supervisory outcomes.

According to the ECB’s 2025 supervisory priorities communication, ICT third-party risk management, including the register of information, is one of three focus areas for on-site inspections in the 2025-2026 cycle.

How Does the Register Fit Within the Broader DORA Compliance Framework?

The register of information does not exist in isolation. It is one component of the comprehensive DORA compliance framework that financial entities must implement across all five pillars. The register data feeds directly into the ICT risk management framework (Article 6), informs the incident reporting process by identifying affected providers, and supports the exit strategy and business continuity planning requirements.

For entities also navigating the EU compliance stack – DORA, GDPR, NIS2, and the AI Act – the register of information represents one of several overlapping documentation obligations that benefit from a unified compliance architecture. Consolidating vendor and provider data across regulatory frameworks reduces duplication and improves data quality.

When evaluating tools to manage this process, the DORA compliance software buyer’s guide provides a structured comparison of platforms supporting register management, gap analysis, and supervisory reporting.

Frequently Asked Questions

Who must maintain a DORA register of information?

All 21 categories of financial entities defined in DORA Article 2 must maintain the register. This includes credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, electronic money institutions, crypto-asset service providers authorised under MiCA, central counterparties, central securities depositories, and others. No size-based exemption exists for the register obligation.

How often must the register be submitted to the competent authority?

The register must be submitted at least annually. Article 28(3) requires reporting to the competent authority, and the ESAs have specified the submission format through Implementing Technical Standards. National authorities may require more frequent updates in specific circumstances.

Can the GDPR ROPA replace the DORA register of information?

No. While there is meaningful overlap in data fields – particularly around provider identification, data locations, and sub-processing chains – the DORA register requires information that has no GDPR equivalent, including criticality assessments, substitutability evaluations, and the prescribed five-table relational format. Entities should build the DORA register as a distinct artefact, leveraging ROPA data where applicable.

What format must the register follow?

The ESAs adopted Implementing Technical Standards specifying a relational data model with five interconnected tables. Submissions must use the structured format (XBRL/XML) prescribed by the relevant competent authority. Free-form spreadsheets or documents do not satisfy the reporting requirement.

Does the register cover only cloud providers?

No. The DORA register of information covers all contractual arrangements with ICT third-party service providers, regardless of the delivery model. This includes cloud infrastructure, SaaS applications, managed security services, payment processing platforms, data analytics providers, network services, and any other ICT service obtained from a third party.