When the European Supervisory Authorities (ESAs) conducted their dry run of the DORA Register of Information (RoI) submissions, the results were sobering: only 6.5% of submissions met the expected quality standards. That means 93.5% of financial entities failed to submit a compliant Register of Information.
If you're a CISO, compliance officer, or risk manager at a financial entity, this statistic should be both alarming and strangely comforting. Alarming because the deadline is real. Comforting because you're clearly not alone in struggling with this.
Let's break down what happened, why it happened, and most importantly — how to fix it before the next submission window.
The ESA Dry Run: What Happened
Under DORA Article 28(3), financial entities are required to maintain and submit a Register of Information covering all contractual arrangements with ICT third-party service providers. The ESAs — comprising the EBA, EIOPA, and ESMA — organized a dry run exercise to test financial entities' readiness to submit this register.
The exercise used the official EBA templates, which comprise 15 interconnected spreadsheet tabs covering everything from entity identification and ICT services to risk assessments and contractual details. Entities were asked to complete and submit their registers in the prescribed format.
The results painted a clear picture: the vast majority of submissions contained significant data quality issues that would render them non-compliant. The ESAs noted problems ranging from basic formatting errors to fundamental misunderstandings of what data was being requested.
What Went Wrong
The failure wasn't due to negligence. Most financial entities genuinely tried to comply. The problems were structural:
Data Quality Issues
Many entities simply didn't have the underlying data in good shape. ICT asset inventories were incomplete, contractual details were scattered across departments, and third-party information hadn't been centralized.
Complex Template Structure
The official EBA template is a 15-tab spreadsheet with complex inter-tab relationships. Many fields reference other tabs, and the logic for which rows to include isn't immediately obvious. This isn't a template you can fill in intuitively.
Lack of Practical Guidance
While the regulatory text and ITS are available, they don't provide worked examples or step-by-step guidance on filling in the templates. Entities were left to interpret ambiguous field definitions on their own.
The 6 Most Common Errors
Based on publicly available feedback from the ESAs and our own analysis of the template requirements, here are the six errors that tripped up most financial entities:
1. Missing Mandatory Fields
The most basic and most common error. The templates contain dozens of mandatory fields across multiple tabs. Many entities left fields blank, either because they didn't have the data or didn't realize the field was required. Pay particular attention to fields like the unique identification code for each contractual arrangement, the LEI of the entity, and the nature of the ICT services provided. Every mandatory field needs a valid entry — "N/A" or blank cells will fail validation.
2. Incorrect LEI Formats
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code that follows the ISO 17442 standard. Many submissions contained LEIs with incorrect check digits, wrong lengths, or used alternative identifiers (like national registration numbers) where an LEI was required. Every entity and every ICT third-party provider that has an LEI must have it entered correctly. Use the GLEIF database to verify each LEI before submission. For providers without an LEI, there are specific procedures to follow — don't just leave the field blank.
3. Inconsistent Data Across Templates
The 15 tabs in the RoI template are interconnected. An entity referenced in Tab B01 must appear consistently in Tab B02 and all subsequent tabs where it's relevant. Many submissions had mismatched entity names, different LEIs for the same provider across tabs, or contractual arrangement references that didn't link up. This is perhaps the most difficult error to catch manually because it requires cross-referencing data across many tabs simultaneously.
4. Wrong Classification Codes
Several fields require values from predefined code lists — for example, the type of ICT services, the criticality classification, and the country codes. Many entities used free-text descriptions instead of the prescribed codes, used outdated code lists, or simply picked incorrect classifications. The ITS includes specific taxonomies and code lists that must be followed exactly. A cloud hosting service classified as "data analytics" will fail validation, even if the provider also offers analytics services.
5. Missing Contractual Details
The register requires detailed contractual information: start dates, end dates, notice periods, governing law, and data processing locations. Many entities hadn't extracted these details from their actual contracts, or their contracts didn't contain the granularity that DORA expects. This often reveals a deeper problem — contracts with ICT providers that pre-date DORA may not contain the required clauses, requiring renegotiation or amendment.
6. Incomplete Risk Assessments
The register includes fields related to risk assessment and criticality of ICT services supporting critical or important functions. Many entities either hadn't completed these assessments or hadn't mapped them to the specific format required by the template. This error is particularly consequential because it suggests a gap not just in reporting, but in the underlying risk management process that DORA requires.
How to Fix It: A Step-by-Step Approach
The good news is that these errors are fixable. Here's a practical approach, in order of priority:
Build Your Data Foundation First
Before touching the templates, make sure you have a complete inventory of all ICT third-party arrangements. Involve procurement, legal, and IT. You need contract details, provider information, service descriptions, and data processing locations centralized in one place.
Validate All LEIs
Go through every entity — your own and all third parties — and verify LEIs against the GLEIF database. For providers without an LEI, document the alternative identifier correctly according to the ITS specifications.
Use the Correct Code Lists
Download the latest code lists from the EBA and map each ICT service to the correct classification. Don't guess — cross-reference the ITS definitions for each code.
Cross-Reference Between Tabs
After completing each tab, systematically verify that entity names, LEIs, contractual references, and service descriptions are consistent across all tabs. This is tedious but essential — ideally, automate this check using formulas or validation rules.
Complete Risk Assessments
Ensure that every ICT service supporting a critical or important function has a documented risk assessment. The RoI template requires specific criticality classifications — these must be backed by your actual risk assessment process.
Run a Self-Validation Before Submission
Before submitting, run through every mandatory field, verify all code values, check cross-tab consistency, and validate all identifiers. Consider having a second person review the entire register end-to-end. Catching errors before submission is far better than being flagged by your NCA.
Looking Ahead
The ESA dry run was a learning opportunity, not a penalty. But the real submissions will carry regulatory consequences. Financial entities need to treat the Register of Information not as a one-time reporting exercise, but as a living document that requires ongoing maintenance and governance.
The entities that succeed will be those that invest in the underlying data quality and processes, not just the template itself. Building a solid ICT third-party register is foundational to everything else DORA requires — from incident reporting to third-party risk management to digital operational resilience testing.
Start now, start systematically, and don't try to do it alone with the raw EBA templates. Use tools that provide guidance, validation, and structure — it will save you significant time and reduce the risk of errors.