ESMA Register of Information: The Art. 28(3) Data Challenge That Caught the Sector Off Guard

The Data Reality

The register of information requirement under DORA Art. 28(3) revealed a fundamental data management gap across the European financial sector. According to industry surveys, regulatory publications, and financial press reporting:

Data discovery challenges:

• Incomplete inventories: Many institutions discovered that their procurement and vendor management systems did not capture all ICT third-party arrangements. Shadow IT, departmental SaaS subscriptions, and legacy agreements that had auto-renewed for years were frequently missing from central records.
• Classification difficulty: DORA requires entities to classify which ICT services support "critical or important functions." This classification requires collaboration between business units (who understand function criticality) and IT/procurement (who understand the service landscape). According to industry reports, this cross-functional classification exercise was among the most time-consuming aspects of register preparation.
• LEI availability: The ITS template requires Legal Entity Identifiers for ICT service providers where available. According to industry feedback reported by ESMA, many smaller ICT providers — including niche SaaS vendors and regional IT service companies — did not have LEIs, creating data gaps in the register.
• Sub-outsourcing visibility: DORA Art. 29(1) requires financial entities to take into account the risks arising from sub-outsourcing arrangements. Populating the register with sub-outsourcing chain information required engagement with ICT providers who were not always willing or able to disclose their sub-contracting arrangements in the detail required.

Operational complexity:

According to publicly available ESMA guidance and industry association communications:

• The register template contains multiple interrelated data tables that must be internally consistent. A contractual arrangement must link to the correct entity, the correct provider, the correct services, and the correct functions — creating a complex relational data model that many institutions managed in spreadsheets rather than purpose-built systems.
• Group-level consolidation — aggregating registers from multiple subsidiaries and branches — introduced additional complexity around data standardization, deduplication, and consistency validation.
• The requirement for ongoing maintenance (the register must be "kept updated") means this is not a one-time exercise but an ongoing data governance discipline.

The Register Requirement

DORA Art. 28(3) requires financial entities to maintain and keep updated "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 not merely an internal governance tool — it is a supervisory instrument that competent authorities can request and that feeds into the ESAs' oversight of critical ICT third-party service providers.

The European Supervisory Authorities (ESMA, EBA, EIOPA) developed an Implementing Technical Standard (ITS) specifying the templates and standardized formats for the register of information. According to ESMA's published guidance, the ITS defines a detailed data model with multiple interrelated tables covering:

• Entity information: The financial entity itself and its group structure
• Contractual arrangements: All agreements with ICT third-party service providers, including main contracts, amendments, and sub-arrangements
• ICT services: The specific ICT services provided under each arrangement, including service descriptions, delivery models, and geographic locations
• Functions supported: Mapping of ICT services to the business functions they support, with criticality/importance classification
• ICT third-party service providers: Identification of all providers, including Legal Entity Identifiers (LEIs) where available, and sub-contractors in the supply chain

According to ESMA's published timeline, the first submission of the register was structured to occur in 2025, with financial entities required to report to their national competent authorities, who would in turn transmit the data to the ESAs.

The scale of the challenge:

According to industry estimates reported in financial press and regulatory publications:

• A typical mid-size bank may have 200-500 ICT third-party arrangements
• Large banking groups may have thousands of arrangements across subsidiaries
• Many arrangements had never been centrally documented or classified according to DORA's taxonomy
• Sub-outsourcing chains (where a provider sub-contracts part of the service) were often invisible to the financial entity

How DORA's Requirements Drive the Solution

The register of information challenge illustrates a broader pattern in DORA implementation: the regulation's requirements are precise enough to expose gaps that looser frameworks missed, but this precision creates significant implementation effort.

The ITS Template Architecture

According to ESMA's published ITS specifications, the register template is structured around several interconnected data tables:

• Table B.01: Entity-level information (the reporting financial entity)
• Table B.02: Contractual arrangement details (contract ID, start/end dates, provider, renewal terms)
• Table B.03: ICT service details (service type, delivery model, data processing locations, personal data handling)
• Table B.04: Function identification (mapping services to business/operational functions)
• Table B.05: ICT third-party service provider details (legal entity information, LEI, jurisdiction)
• Table B.06: Sub-outsourcing arrangements (sub-contractors and their services)

The interrelationships between these tables create a normalized data model that requires referential integrity. For example, every ICT service in B.03 must reference a valid contractual arrangement in B.02, which must reference a valid provider in B.05 and support identified functions in B.04.

Practical Implementation Approaches

Based on publicly reported industry approaches and regulatory guidance:

Data collection strategies:

• Top-down from procurement/contract management systems (captures formal agreements but misses shadow IT)
• Bottom-up from IT asset management and network discovery (captures operational reality but may miss contractual details)
• Hybrid approaches combining both, with reconciliation to identify gaps

Classification methodology:

• Business function mapping workshops involving business, IT, risk, and compliance stakeholders
• Criticality assessment against DORA's "critical or important function" criteria
• Impact analysis to determine which ICT service failures would materially affect function delivery

Ongoing maintenance:

• Integration with procurement workflows (new ICT contracts trigger register updates)
• Periodic reconciliation against IT asset inventories
• Change management processes for contract amendments, renewals, and terminations

Sector-Wide Outcomes

Based on publicly available regulatory communications, industry reporting, and financial press coverage:

ESMA's role and published guidance:

• ESMA published detailed guidance on the register of information template, including technical specifications, validation rules, and frequently asked questions. These publications are available on ESMA's website.
• ESMA worked with national competent authorities to establish the data collection infrastructure and submission processes.
• According to ESMA communications, the register data would serve dual purposes: supervisory oversight of individual institutions and identification of critical ICT third-party service providers for the ESA-level oversight framework (DORA Art. 31-44).

Industry feedback (publicly reported):

• Financial industry associations across the EU reported that the register of information was among the most operationally intensive DORA requirements to implement, according to their public position papers and consultation responses.
• Data quality concerns were widely reported — many initial register submissions were expected to be incomplete or contain inconsistencies, particularly around sub-outsourcing chains and function classification.
• Technology vendors reported significant demand for solutions to automate register data collection, validation, and submission.
• Several large financial groups reported multi-month projects specifically dedicated to the register, involving teams from IT, procurement, risk, compliance, and business lines.

Supervisory expectations:

According to public communications from multiple European supervisory authorities:

• Supervisors acknowledged that the first submission cycle would be a learning exercise for both institutions and authorities.
• The emphasis was on good-faith effort and demonstrable progress rather than perfect data quality in the initial cycle.
• However, supervisors also communicated that the register is an ongoing requirement and that data quality expectations would increase over time.
• The register data would be used to identify systemically important ICT third-party providers, potentially triggering the oversight framework provisions of DORA Art. 31-44.

The Art. 28(3) register experience demonstrates that DORA's third-party risk provisions are among the regulation's most operationally demanding requirements, requiring sustained data governance effort rather than a one-time compliance project.