Register of Information: What the First Submission Taught 22,000 Financial Entities About Their Own Supply Chains

What the Data Revealed

The Register of Information submission was designed to give NCAs and the ESAs visibility into the ICT third-party risk landscape across the European financial sector. What the data revealed — even accounting for quality issues in the first submission — was illuminating and, in several dimensions, concerning.

Concentration patterns emerged at scale. When register data was aggregated across submitting entities, systemic concentration patterns became visible for the first time. A small number of ICT service providers — cloud platforms, core banking system vendors, payment processors, market data providers, and cybersecurity platforms — appeared in the registers of dozens or hundreds of financial entities simultaneously. This concentration was known anecdotally, but the register provided the first quantitative, sector-wide picture of ICT dependency concentration.

The CTPP designation data foundation. The register data directly informed the ESAs' CTPP designation process. Art. 31 specifies designation criteria including the systemic impact of a provider's failure, the degree of dependence of financial entities on the provider, and the substitutability of the provider's services. The register data — documenting which providers serve which financial entities, for which functions, with what criticality — provided the empirical basis for identifying the 19 providers designated as CTPPs in November 2025.

Data completeness challenges. Many institutions discovered that their procurement records, contract databases, and IT asset inventories were insufficient to populate the register template. ICT service arrangements that had been managed at the department level, shadow IT arrangements, and legacy contracts that predated centralized procurement processes all created gaps in the data. Some institutions reported discovering ICT service arrangements during the register preparation process that had not been previously identified in their risk management frameworks.

The subcontracting chain blind spot. The register template requires documentation of subcontracting arrangements — where the direct ICT provider relies on sub-providers to deliver the service. Many institutions found that they had limited or no visibility into their providers' subcontracting chains. The information was either not contractually required, not provided by the provider, or not requested during the due diligence process. This blind spot is particularly significant in the context of breaches like Evolve Bank (CS06), where the subcontracting chain amplified a single breach into an 18-million-person data exposure.

ESA validation process. The ESAs conducted two rounds of validation on the submitted registers — one in April and one in May 2025. The validation checked for data completeness, format compliance, identifier consistency, and logical coherence. Many institutions received feedback requiring corrections and resubmissions, underscoring the gap between the data institutions thought they had and the data quality the register actually required.

The Data Quality Crisis

When DORA became applicable on January 17, 2025, its Art. 28(3) requirement for financial entities to maintain a "register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers" transformed what had been a theoretical compliance requirement into an operational data challenge of unprecedented scale.

The first submission window opened in April 2025, with national competent authorities setting country-specific deadlines within the month: France on April 15, Germany on April 11, Italy on April 30. According to ESA reports and industry surveys, more than 10,000 EU financial companies submitted their registers during this initial window — the first time the European financial sector had attempted to comprehensively inventory its ICT third-party dependencies in a standardized format.

The results exposed a systemic data quality crisis. According to a Deloitte survey of DORA readiness, 46% of financial entities named the Register of Information as their single hardest DORA requirement — more difficult than resilience testing, more challenging than incident reporting, more operationally complex than any other provision. The difficulty was not conceptual — the requirement is straightforward: document who provides your ICT services. The difficulty was practical: most financial institutions did not know, with the precision required by the register template, the full extent of their ICT third-party dependencies.

McKinsey's analysis reinforced the scale of the challenge: 40% of financial entities reported dedicating more than 7 full-time equivalent staff to the register preparation process. For large financial groups with hundreds or thousands of ICT service arrangements, the data collection effort consumed months of work across procurement, IT, legal, risk management, and compliance teams.

The initial submission process encountered additional friction. The European Commission had initially rejected the draft Implementing Technical Standard (ITS) for the register due to a disagreement between the ESAs and the Commission over the use of Legal Entity Identifiers (LEIs) versus European Unique Identifiers (EUIDs) for entity identification. This regulatory uncertainty delayed finalization of the template and created confusion about which identifier systems to use — a problem for institutions that had already begun data collection using the earlier template version.

The Regulatory Architecture of the Register

The Register of Information is not a standalone compliance exercise — it is the data infrastructure that enables DORA's third-party risk management framework to function at the systemic level.

Art. 28(3) — The Register Obligation

DORA Art. 28(3) requires every financial entity to maintain a register of information covering all contractual arrangements for ICT services provided by third-party providers. The register must include, at minimum:

• The identity of the ICT third-party service provider (LEI or EUID)
• The nature of the ICT services provided
• The functions supported (critical, important, or neither)
• The geographic location of data processing
• The subcontracting arrangements, including sub-providers
• The data types processed or stored
• The contractual start date, duration, and renewal terms

This information, when aggregated across the financial sector, creates the first comprehensive, standardized picture of ICT third-party dependencies in European finance.

Art. 28(9) — NCA Access

Art. 28(9) requires the register to be available to the national competent authority upon request. This means the register is not merely an internal risk management tool — it is a supervisory input that NCAs use for entity-level risk assessment and, when aggregated, for systemic risk analysis. The quality of supervisory oversight is directly dependent on the quality of the register data.

Art. 29 — Concentration Risk Feed

The register data is the primary input for Art. 29 concentration risk assessment. Only with comprehensive register data can NCAs — and the ESAs at the aggregate level — identify:

• Providers that appear in a critical mass of financial entities' registers (indicating systemic concentration)
• Geographic concentration of data processing (indicating jurisdictional risk)
• Single-provider dependencies for critical functions across multiple entities (indicating substitutability risk)
• Subcontracting chain overlaps (indicating hidden concentration through shared sub-providers)

Art. 31 — CTPP Designation Input

The register data directly feeds the CTPP designation process under Art. 31. The designation criteria — systemic impact, dependence degree, substitutability, and effect of provider failure — require quantitative data on how many financial entities use each provider, for which functions, and with what criticality. Without the register, the ESAs would have to rely on market estimates and provider self-reporting. With the register, they have entity-reported, standardized data that enables evidence-based designation decisions.

The ITS Controversy

The initial European Commission rejection of the register ITS over the LEI vs. EUID identifier issue highlighted a governance challenge in DORA's implementation. The register's value depends on consistent entity identification — if different member states use different identifier systems, cross-border concentration analysis becomes impossible. The eventual resolution established LEI as the primary identifier, but the delay created practical challenges for institutions that had begun data collection under the earlier draft.

Proportionality Challenges

Art. 4 of DORA establishes the principle of proportionality — requirements should be applied in a manner that is proportionate to the entity's size, risk profile, and complexity. For the Register of Information, proportionality creates a tension: smaller entities with fewer ICT third-party arrangements face a simpler data collection task, but they may also have fewer resources (the 7+ FTE finding from McKinsey primarily affects larger institutions). For micro-entities, simplified register templates may be necessary — but simplified templates reduce the data available for systemic risk analysis.

Lessons From the First Submission and Forward Path

The April 2025 Register of Information submission was a watershed moment for DORA implementation — not because it was perfect, but because it revealed the true state of the European financial sector's understanding of its own ICT supply chain dependencies.

Key Findings

1. Institutional self-awareness gap. The most significant finding was not any specific data point but the aggregate discovery that most financial institutions did not have a comprehensive, accurate picture of their ICT third-party dependencies before the register forced them to create one. Shadow IT, departmental procurement, legacy contracts, and informal service arrangements all contributed to a gap between what institutions thought they knew about their ICT supply chains and what the register process revealed.

2. Subcontracting visibility deficit. The register's requirement to document subcontracting chains exposed a structural blind spot: most financial entities had limited contractual rights or practical ability to identify their providers' sub-providers. This visibility deficit means that the first submission's picture of ICT dependencies is incomplete — the hidden subcontracting layer remains partially opaque, even after the register exercise.

3. Cross-border data processing complexity. Many financial groups discovered that their ICT service arrangements involved data processing across multiple EU and non-EU jurisdictions. Mapping these geographic data flows — and assessing the regulatory implications of each — was one of the most time-consuming aspects of the register preparation.

4. Concentration patterns confirmed. Even with data quality limitations, the aggregated register data confirmed what the industry suspected: a small number of providers serve a large proportion of the financial sector for critical functions. This finding directly supported the CTPP designation process and validated DORA's concentration risk framework.

5. Resource intensity confirmed. The 7+ FTE finding from McKinsey was not an outlier — many large financial groups reported similar or higher resource commitments. The register is not a one-time compliance exercise but an ongoing maintenance obligation, and institutions must build sustainable processes for keeping the register current as ICT service arrangements change.

Forward Path

The April 2025 submission was the first iteration. The register is designed as an ongoing, maintained dataset — not a point-in-time snapshot. Going forward:

• Annual updates: Institutions must keep their registers current, updating for new ICT service arrangements, terminated contracts, and changes in service scope or criticality.
• Quality improvement: The ESAs' two validation rounds established a feedback loop. Subsequent submissions should benefit from clearer guidance, improved templates, and institutional learning from the first submission experience.
• Analytical use: NCAs and the ESAs will increasingly use register data for supervisory risk assessment, concentration risk analysis, and CTPP oversight. The analytical value of the register grows with each submission cycle as data quality improves and time-series patterns become visible.
• Subcontracting deepening: The DORA subcontracting RTS (Delegated Regulation 2025/532) will drive deeper visibility into subcontracting chains in subsequent submissions, addressing the most significant gap identified in the first round.

Implications for Financial Entities

The Register of Information is not a box-checking exercise — it is the foundational data layer for DORA's entire third-party risk management framework. Institutions that treat it as a compliance burden rather than a risk management asset will be at a disadvantage when NCAs use the register data for supervisory assessments, when concentration risk events occur, and when the quality of register data becomes a factor in supervisory examinations.

The practical recommendation is to invest in the register as permanent infrastructure: automated data collection from procurement systems, contract databases, and IT asset inventories; dedicated ownership within the risk management function; and regular reconciliation processes that ensure the register reflects the institution's actual ICT supply chain, not a stale snapshot from the last submission cycle.