The DORA register of information: Why it is actually a data quality problem

Part 5 of 7 of our DORA series: The register of information is not a downstream reporting task, but a test for the quality of a bank's vendor, contract, and functional data. The previous parts explain DORA at a glance, the exit plan, cloud dependency, and an exit option for customer engagement workloads. This article shows why the resilient answer to the register obligation lies in data governance.

The register maps a supply chain, not a file storage system

Article 28(3) of DORA obliges financial entities to maintain and annually report a register of information in relation to all contractual arrangements on the use of ICT services. The Implementing Regulation (EU) 2024/2956 specifies this requirement with 15 reporting templates and firmly defined register contents. This is much more than a central contract list: The register links entities, contracts, services, functions, data locations, and supply chains in a structured view (DORA, Art. 28; ITS 2024/2956).

The logic is relational. B_02.02 contains contract-specific details, B_05.01 the provider, B_05.02 the ICT supply chain, B_06.01 the function, and B_07.01 assessments such as substitutability and the last audit. The direct service provider is rank 1 in the supply chain, while downstream entities are rank 2 or higher. Anyone who maintains these relationships only in scattered spreadsheets, procurement files, and emails may be able to fill in individual fields. However, this does not create a consistent and auditable overall view (ITS 2024/2956).

This is precisely why the quality dimensions mentioned in the ITS are so helpful: accuracy, completeness, consistency, integrity, uniformity, and validity. They translate a regulatory requirement into an operational data quality mandate. The question is not just: "Has the form been submitted?" It is: "Can the institution clearly explain for each outsourced ICT service which contract supports which function, who delivers in the chain, and what dependency arises from this?"

The dry run shows: The problem starts before the reporting

The ESA dry run makes the scale visible. Out of 947 analyzed registers, only 6.5% passed all 116 data quality checks; 93.5% or 886 registers contained at least one error. Over 235,000 errors were identified across more than 9,275,000 data points. This is not an indication of individual typos, but of systemic gaps between sources, responsibilities, and validation (ESAs Dry Run Summary Report).

The error structure points the way to remediation. Missing mandatory fields accounted for 86% of the errors, invalid LEIs for 6.5%, invalid DPM values for 4%, and duplicates and invalid dates for 2.8%. Missing information was particularly frequent in B_02.02; B_05.01 and B_07.01 were also conspicuous. This means that the weak points lie precisely where contract, provider identity, and risk or substitutability assessment come together (ESAs Dry Run Summary Report).

The consequence for management is clear: a reporting team cannot permanently repair missing source attributes on the day of submission. If a contract process does not capture a binding data location, a standardized service type, or a traceable functional assignment, the gap will reappear in the register. If a vendor master database does not maintain a verified identifier, every subsequent evaluation will be unreliable.

Five data objects that must be merged

A resilient register requires a functional data model that works independently of the final CSV or Excel export. In practice, having a clear owner for each object has proven successful.

The common key strategy is crucial. For legal entities, the ITS requires the 20-digit LEI according to ISO 17442 or the EUID; for third-country providers, the LEI is intended. If both identifiers are available, both must be provided. In the dry run, around 9,000 invalid LEIs were identified for financial entities and around 6,000 for ICT third-party service providers; registers without LEIs are rejected (ITS 2024/2956; ESAs Dry Run Summary Report).

These identifiers are not just technical mandatory fields. They prevent the same service provider from being listed multiple times under slightly different names or the supply chain from ending at an ambiguous entity. The same applies to controlled value lists: the ITS distinguishes, for example, between IaaS, PaaS, and SaaS, as well as infrastructure/hosting and on-premise software. A free-text field "Cloud" is therefore not sufficient when comparability and consolidation are required later (ITS 2024/2956).

From reporting date project to ongoing control cycle

The target state is a register that is updated by events, not an annual clean-up effort. New contracts, renewals, subcontractor changes, location changes, functional changes, and audits must each trigger a clear data and approval step. This shifts the work from manual remediation to preventive quality assurance.

A pragmatic control cycle consists of four steps. First, mandatory attributes are captured at the source and validated against reference data. Second, contract, provider, and functional data are linked via stable keys. Third, a data quality monitor validates completeness, value ranges, duplicates, and relationship rules before reporting. Fourth, the business-responsible departments receive an exception list with a deadline and verification requirement. The register thus becomes a management tool for outsourcing risks, not an archive.

The existing EBA guidelines support this view: they require, among other things, details on personal data, countries, and data locations, cloud service and deployment models, as well as substitutability, alternative providers, time criticality, and annual budget. These are attributes that are only reliable if they are maintained within the ongoing outsourcing and risk management processes (EBA/GL/2019/02).

The next cycle is a quality window

In Germany, the first live round had a reference date of March 31, 2025; BaFin-supervised institutions were expected to submit via the MVP portal by April 28, 2025. From 2026 onwards, submission to the ESAs is scheduled by March 31 with a reference date of December 31 of the previous year. For the second cycle, a submission window from March 1 to 31, 2026, and a remediation period until April 30, 2026, were communicated. Crucially: The obligation is only considered fulfilled once the ESAs accept the submission (BaFin Technical Article; Central Bank of Ireland).

This should prompt institutions not only to work on the taxonomy. A test run is more sensible: Can the bank explain the origin, owner, supply chain, location, functional reference, and assessment for a sample of contracts without manual research? The answer reveals the maturity of the underlying data management more reliably than a formally filled file.

This discipline is also relevant for customer engagement architectures. For instance, a CDP and data governance layer must transparently handle consent, lineage, and PII protection. Acceleraid describes real-time aggregation from CRM, core banking, and card processing for its platform, as well as consent management, data lineage, role-based access, and PII protection. This is not to say that the platform replaces the DORA register; rather, it shows which governance capabilities at the data foundation also count for register quality (Acceleraid Platform).

The next question in the series is what happens when not only data fields, but underlying AI models or their providers are concentrated. This is the topic of Part 6 on AI providers as a concentration risk. Part 7 then provides the necessary assessment logic for critical and important functions.

The DORA series at a glance

• Part 1: DORA for Banks: What the EU Regulation Covers and How It Works

• Part 2: The Exit Plan under DORA: What It Must Contain and Why It Must Be Tested

• Part 3: Cloud Dependency of European Banks: How to Get Away from AWS, Microsoft, and Google if Necessary

• Part 4: Exit Option for Customer Engagement Workloads: Securing CDP, Personalization, and Campaigns in Compliance with DORA

• Part 5: The DORA Register of Information: Why It Is Actually a Data Quality Problem (this article)

• Part 6: AI Providers as a New Concentration Risk: What DORA Means for Model Dependencies

• Part 7: Critical or Important? Risk Levels from Core Banking to CRM, Data Lake, and CDP

Illustration: AI-generated. AI-assisted content: In creating our articles, we use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers. Topics, professional alignment, and final approval remain with our team.