DORA Register of Information: Turn the 2024 Dry-Run Results Into a Data-Quality Control

The DORA Register of Information is not a 2027 project. The obligation has been operative since January 17, 2025, when the Digital Operational Resilience Act became applicable.

The useful warning comes from the ESAs’ voluntary 2024 dry run. Of the registers that passed the exercise’s initial integration checks, 947 were assessed against 116 data-quality checks and only 6.5% passed every check. That is a precise and limited result: it does not mean the ESAs found 93.5% of all regulated firms in violation, and it does not establish a penalty rate.

It does show that a register assembled from inconsistent vendor, contract, and service data will fail even when the underlying ICT risk program looks reasonable on paper.

TL;DR

• DORA Article 28(3) already requires in-scope entities to maintain and update registers of ICT contractual arrangements.
• Commission Implementing Regulation (EU) 2024/2956 supplies the standard templates and field instructions.
• In the 2024 voluntary dry run, only 6.5% of 947 integrated registers passed all 116 data-quality checks.
• The result is a data-governance signal, not an enforcement verdict or a reason to wait until 2027.
• The practical control is a reconciled source population, field-level validation, an exception queue, and evidence that every correction reached the final reporting file.

What the register obligation requires

DORA Article 28 requires financial entities to manage ICT third-party risk as part of their overall ICT risk framework. Article 28(3) requires registers of information covering contractual arrangements for ICT services at the individual-entity, sub-consolidated, and consolidated levels.

The register must be maintained and updated, made available to the competent authority on request, and used in the applicable reporting process. The annual timetable is not one universal entity-level deadline across the EU: firms must follow the instructions and earlier cutoff set by their own national competent authority. The ESA reporting FAQ says that, from 2026 onward, competent authorities report registers to the ESAs by March 31.

Commission Implementing Regulation (EU) 2024/2956 establishes the standard templates and completion instructions. The templates capture more than a vendor list. They connect:

• the financial entity and group structure;
• the ICT third-party service provider and relevant legal entity;
• the contractual arrangement and ICT service;
• the financial functions supported;
• whether a function is critical or important;
• service locations and data locations;
• subcontracting relationships where required; and
• identifiers and reference data used to join the templates.

That relational structure explains why a single inconsistent identifier can break several downstream records.

What the 6.5% result does—and does not—mean

The ESAs’ published dry-run report describes a voluntary preparation exercise. Participating registers first went through integration checks. The 947 accepted for analysis were then screened against 116 data-quality checks, and 6.5% passed all of them.

Use that result as a control-design benchmark:

1. Integration and data quality are separate gates. A file can be technically readable and still contain inconsistent or incomplete records.
2. One source system is not enough. Procurement, contracts, service inventories, finance records, and legal-entity reference data often describe the same relationship differently.
3. A percentage alone is not a remediation plan. The firm needs a field-level exception log that identifies the source, owner, correction, and evidence for each failed check.
4. The dry run was not a supervisory clearance. Passing technical checks does not by itself prove compliance with DORA’s contracting, concentration, exit, or risk-management requirements.

Unsupported percentages for particular failure causes should not be repeated unless they can be traced to a defined table and denominator in the primary report. The defensible published statistic is the 6.5% all-check pass rate among the 947 integrated registers.

Build a reconciled source population

Start before formatting the regulatory file. Create a base population by reconciling at least three sources:

Add cloud and infrastructure inventories where the application register does not expose hosting dependencies. Compare the result with the canonical fourth-party and subcontractor risk map rather than linking to a duplicate draft.

For the service-level concentration analysis behind those records, use the cloud concentration and continuity evidence guide. The DORA register remains the prescribed record structure; the concentration guide is an implementation aid, not a substitute for the ITS fields.

Every unexplained mismatch becomes an exception. Do not silently drop a record because two systems disagree.

Validate the joins, not just the cells

A reliable control tests both field validity and relationships among templates.

1. Legal-entity and identifier validation

Confirm that the contracting provider, ultimate parent, and service-delivery entity are not being treated as interchangeable. Validate LEIs and other identifiers against authoritative reference data, record the validation date, and define what happens when an entity lacks the expected identifier.

2. Contract-to-service mapping

One contract may cover several ICT services, and one service may support several financial functions. Preserve those relationships explicitly. A free-text label such as “cloud services” is not enough to explain which important business service depends on the arrangement.

3. Critical-function mapping

Document why each supported function is or is not critical or important. Reconcile that decision to the firm’s business impact analysis, operational resilience maps, and ICT concentration assessment. Conflicting classifications are governance exceptions, not formatting errors.

4. Subcontractor lineage

Capture subcontracting information to the extent required by the templates and the arrangement’s risk. The evidence should distinguish confirmed provider disclosures from assumptions. For material gaps, record the request, provider response, escalation, and residual-risk decision.

5. Dates, locations, and controlled values

Validate contract dates, renewal dates, notice periods, countries of service provision, data locations, currencies, and controlled-list values. Normalize them before export rather than repairing the generated file manually.

Use an exception queue that survives the submission

A spreadsheet of red cells is not an operating control. For each failed validation, retain:

• exception ID and affected template/field;
• provider, contract, service, and function identifiers;
• source systems that disagreed;
• issue type and root cause;
• accountable data owner;
• correction and approval evidence;
• retest result and reporting-file version; and
• closure date or documented residual-risk decision.

The key test is reproducibility: an independent reviewer should be able to start with the exception, inspect the source evidence, and confirm the corrected value in the final file.

Retest the exact artifact delivered into the reporting workflow—not an earlier spreadsheet or source-system view. Preserve the immutable version reference or file hash, validation-rule package, run time, results, approved exceptions, correction evidence, and reviewer sign-off. If a correction changes a key identifier, repeat dependent-record and hierarchy checks because one repaired value can expose new orphaned or duplicate records.

This evidence does not turn the 2024 dry-run checks into permanent legal rules. It shows which current technical and business checks were applied to the version actually supplied and how unresolved exceptions were governed.

Treat the register as a living risk artifact

The register should change when the environment changes—not only before an authority’s reporting cutoff. Define triggers for acquisitions, provider changes, contract amendments, new subcontractors, service migrations, criticality changes, terminations, and legal-entity restructurings.

The ESAs also use register data in the critical-provider designation and oversight framework. Their first CTPP designation announcement does not transfer the financial entity’s own responsibility. A provider’s designation is an input to the firm’s risk assessment, not a substitute for contract governance, concentration analysis, resilience testing, or exit planning.

A practical monthly control

A compact recurring control can keep the register usable between reporting cycles:

1. Reconcile newly paid ICT suppliers to the register.
2. Reconcile new and amended ICT contracts to service records.
3. Review application and hosting changes for new provider dependencies.
4. Revalidate identifiers and controlled reference data for changed records.
5. Review open exceptions, aging, and overdue provider responses.
6. Regenerate the reporting package and rerun technical/data-quality checks.
7. Retain the input snapshot, validation output, approvals, and version hash.

The goal is not to achieve a clean file once. It is to make clean register data a byproduct of vendor, contract, and service governance throughout the year.

The Third-Party Risk Management (TPRM) Kit includes vendor, contract, and monitoring artifacts that can support the source-data and exception-management workflow. Regulatory reporting instructions still control where they differ.

Primary sources:

• Regulation (EU) 2022/2554 (DORA), including Article 28
• Commission Implementing Regulation (EU) 2024/2956 — register templates
• ESAs — Key findings from the 2024 DORA dry run
• EBA — Preparations for reporting DORA registers of information
• ESAs — First designation of critical ICT third-party providers