The Register of Information Deadline: Why 46% of Firms Called It Their Hardest DORA Challenge
The First Real Test of DORA Compliance
The Register of Information is DORA's most data-intensive deliverable. Art. 28(3) requires every financial entity to "maintain and update at entity level and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." The Implementing Technical Standard (ITS) specifying the exact template and data fields was published by the ESAs — and it is not a simple spreadsheet.
March 31, 2025 was the reference date: the snapshot moment at which every contractual arrangement with an ICT third-party service provider had to be captured. Submission windows vary by member state — France set April 15, Germany April 11, Italy April 30 — and the data collection deadline was universal. Over 10,000 European financial companies are expected to submit register entries during the April-May 2025 cycle.
The Deloitte European Survey found that 46% of financial institutions named the Register of Information as their single hardest DORA requirement. Not the ICT risk management framework. Not resilience testing. Not incident reporting. The register — a data collection and classification exercise — topped the difficulty ranking. Understanding why requires examining what the register actually demands.
What the Register Actually Requires
Figure 1: The Register of Information data flow — from three reconciled sources through seven interconnected register sections to three critical downstream processes.
The ITS template is a multi-tab structure with interconnected data points. It goes far beyond a vendor list:
| Register Section | Key Data Points | Complexity Driver |
|---|---|---|
| Entity identification | LEI, entity type, group structure, consolidation level | Multi-entity groups must file at entity AND consolidated level |
| Contractual arrangements | Contract reference, start/end dates, governing law, renewal terms | Many institutions lacked centralized contract repositories |
| ICT third-party provider details | Provider LEI/EUID, jurisdiction, parent company, sub-outsourcing chain | The LEI vs. EUID dispute delayed ITS finalization; many providers lack LEIs |
| ICT services description | Service type, function supported, data processed, processing location | Mapping services to business functions required cross-functional coordination |
| Criticality assessment | Critical/important function determination, substitutability, exit strategy status | Only 34% of institutions had pre-existing criticality frameworks |
| Risk assessment data | Concentration risk indicators, dependency analysis | Art. 29 requires quantitative concentration analysis |
| Sub-outsourcing information | Sub-contractor identity, service scope, location | Providers often resist disclosing sub-outsourcing arrangements |
For a mid-size bank with 200-300 ICT vendor relationships, populating this register required collecting data from every vendor relationship, classifying each service against business functions, making criticality determinations that crossed organizational boundaries, and ensuring consistency across what might be dozens of legal entities within a banking group.
McKinsey's finding that 40% of firms dedicate more than 7 full-time employees to DORA compliance becomes understandable when the register alone requires sustained data collection, validation, and maintenance effort.
The LEI vs. EUID Controversy
The register's development was not smooth. The European Commission initially rejected the draft ITS on the Register of Information, in part due to a dispute over identifier requirements. The ESAs proposed using the Legal Entity Identifier (LEI) as the primary identifier for ICT third-party service providers. The Commission pushed for the European Unique Identifier (EUID) as an alternative or supplement.
The issue was not technical — it was practical. Many ICT service providers, particularly smaller ones and those headquartered outside the EU, do not have an LEI (annual cost: approximately EUR 70-100). The EUID, linked to EU company registers, was not universally available across all member states at the required quality level. The result was a compromise: LEI preferred where available, EUID as fallback, with provisions for entities lacking both.
This seemingly administrative dispute had real consequences. The ITS finalization was delayed, compressing the time available for institutions to implement compliant data collection processes. Institutions that had built their data pipelines around LEI-only identification had to retrofit EUID support. Those that had waited for finalization found themselves with weeks, not months, to populate their registers.
The Two Rounds of ESA Validation
The ESAs have announced two rounds of validation checks on submitted registers — the first scheduled for April 2025, the second for May 2025. Based on preparation exercises and supervisory guidance, several common deficiency patterns are expected to emerge:
Completeness gaps. Many submissions covered only the institution's most obvious vendor relationships — the core banking provider, the cloud platform, the payment processor — while omitting the long tail of ICT service providers whose services, while individually less critical, collectively support important business operations. Art. 28(3) does not limit the register to critical providers; it covers "all contractual arrangements on the use of ICT services."
Criticality classification inconsistencies. Institutions within the same banking group sometimes classified identical services differently — the same cloud platform rated as supporting a "critical function" in one entity and a "non-critical function" in another, despite providing identical capabilities. The ESAs flagged inconsistencies that suggested the criticality assessment was performed independently at entity level without group-level coordination.
Sub-outsourcing opacity. The sub-outsourcing fields were among the most sparsely populated. Institutions reported difficulty obtaining sub-outsourcing information from providers, particularly for SaaS products where the underlying infrastructure (cloud platform, CDN, database services) was treated by the provider as proprietary architecture information.
Cross-reference failures. The register's multi-tab structure requires internal consistency — a contractual arrangement referenced in the services tab must match the entity identified in the provider tab, which must link to the risk assessment in the concentration tab. Automated validation checks caught cross-reference failures that manual compilation processes had not.
A Practical Framework for Register Management
Figure 2: Three-phase register management framework. Phase 3 is continuous — every new contract, renewal, or sub-outsourcing change triggers a register update.
The institutions best positioned for the submission cycle share common approaches. The following framework synthesizes best practices from institutions that began preparation early:
Phase 1: Data Foundation (Weeks 1-4)
Inventory reconciliation. Start from three independent sources and reconcile: accounts payable (who are we paying for IT services?), IT asset management (what systems do we run and who provides them?), and procurement/legal (what contracts do we have?). The intersection of these three datasets is your initial register perimeter.
Provider outreach. For each identified provider, request: legal entity name and identifier (LEI/EUID), jurisdiction of incorporation, parent company, sub-outsourcing arrangements, data processing and storage locations. Template the request — providers are receiving identical inquiries from every client.
Function mapping. Map each ICT service to the business function it supports. This requires business unit involvement — IT alone cannot determine whether a service supports a "critical or important function" as defined in Art. 3(22).
Phase 2: Criticality Assessment (Weeks 5-8)
| Assessment Criterion | Question | DORA Reference |
|---|---|---|
| Function criticality | Does the ICT service support a function whose disruption would materially impact the entity's financial performance, service continuity, or regulatory obligations? | Art. 3(22) |
| Substitutability | Can the service be replaced within the entity's recovery timeline? Are alternative providers identified? | Art. 29(2)(a) |
| Concentration exposure | What share of the entity's critical services depends on this provider or its corporate group? | Art. 29(2)(b)-(c) |
| Data sensitivity | What is the classification of data processed/stored by this service? | Art. 30(2)(c) |
| Geographic risk | Where is data processed? Are there jurisdiction-specific risks? | Art. 30(2)(c) |
Phase 3: Ongoing Maintenance (Continuous)
The register is not an annual filing. Art. 28(3) requires it to be "maintained and updated." Every new vendor engagement, contract renewal, service change, or sub-outsourcing notification requires a register update. Institutions that treat the register as a point-in-time exercise will fail the second submission cycle.
Change triggers requiring register update:
- New ICT service provider contract signed
- Existing contract renewed, amended, or terminated
- Provider changes sub-outsourcing arrangements
- Service scope changes (e.g., new data types processed, new functions supported)
- Provider corporate structure changes (merger, acquisition, divestiture)
- Criticality assessment changes (function reclassified, new dependency identified)
- Data processing location changes
What the Register Feeds: Beyond Compliance
The Register of Information is not an isolated deliverable. Under DORA's architecture, it feeds three critical downstream processes:
Concentration risk assessment (Art. 29). The register data is the input for quantitative concentration analysis. Without accurate register data, institutions cannot calculate HHI indices, identify single points of failure, or assess provider substitutability. Art. 29 requires institutions to "take into account" concentration factors "when performing the identification and assessment of risks" — this presupposes that the register data exists and is current.
Critical ICT third-party provider designation (Art. 31-44). The ESAs use aggregated register data from across the EU to identify ICT third-party service providers on which the financial sector depends systemically. The register submissions are the empirical basis for Lead Overseer designation decisions. Inaccurate register data distorts the designation process — and may result in critical providers escaping oversight or non-critical providers being incorrectly flagged.
Supervisory review (Art. 28(9)). NCAs receive the register data and use it for ongoing supervisory assessment of the institution's third-party risk management. Inconsistencies, gaps, or stale data in the register become supervisory findings — not because the register itself is the compliance obligation, but because an inadequate register indicates inadequate third-party risk management.
Common Failure Modes and How to Avoid Them
Based on preparation exercises and early submissions, the most common failure modes are:
Treating it as a one-off project. Institutions that staffed the register as a project — with a defined end date and temporary resources — successfully submitted but immediately fell behind as vendor relationships changed. The register requires permanent operational capability.
Separating register management from risk management. Institutions where the compliance team owned the register and the risk team owned the risk assessment produced internally inconsistent outputs. The register and the risk assessment must share a data model and governance process.
Relying on provider self-reporting without verification. Providers have incentives to minimize disclosed complexity. Sub-outsourcing disclosures are particularly unreliable without independent verification. Cross-reference provider disclosures against technical architecture reviews, audit reports, and public infrastructure information.
Manual compilation. Institutions that compiled the register in spreadsheets were unable to maintain cross-reference integrity, automate change detection, or produce the multi-tab format required by the ITS without significant manual effort at each submission cycle. Platform-based approaches that enforce data relationships and automate formatting reduce both effort and error rates.
Ignoring the consolidation requirement. Art. 28(3) requires the register "at entity level and at sub-consolidated and consolidated levels." Banking groups with multiple regulated entities must produce consistent registers that aggregate without contradiction. This requires group-level governance of criticality classifications, provider identifiers, and service descriptions.
The Register as Strategic Asset
The institutions that derived the most value from the register exercise were those that reframed it. Not as a compliance burden, but as the first comprehensive map of their technology dependency landscape.
Before the register, most institutions could not answer basic questions: How many distinct ICT service providers support our critical functions? What is our concentration exposure to our three largest providers? If a major cloud platform experienced a multi-region outage, which of our services would be affected and in what sequence? Where is our customer data actually processed and stored — not where contracts say it should be, but where it actually resides?
The register, populated accurately and maintained continuously, answers all of these questions. It transforms third-party risk management from a periodic assessment exercise into a continuous governance capability. It provides the data substrate for concentration risk monitoring, exit strategy planning, and incident impact assessment.
For institutions approaching the register with this strategic lens, the EUR 2-5 million DORA compliance investment generates a return that extends well beyond regulatory compliance. It produces operational visibility that supports third-party contract renegotiation, vendor risk scoring, and incident impact assessment — visibility that competitors operating on spreadsheets and memory still lack.
This analysis reflects the Register of Information requirements under DORA Art. 28(3) and associated ITS as applicable in Q1-Q2 2025. Submission deadlines and validation processes vary by member state.