DORA Register of Information: Your Q1 2026 Submission Guide

The DORA Register of Information (RoI) is not a form you fill in once a year. It is a comprehensive, machine-readable map of your institution's entire ICT supply chain — every third-party provider, every contractual arrangement, every function those arrangements support, every sub-contractor in the chain. The Q1 2026 submission was the second time financial institutions across the EU submitted this data to their national competent authorities, and the first time regulators applied the lessons of the 2025 initial collection.

If your 2026 submission is complete and already submitted, this guide will help you build the processes that make future submissions less painful. If you are still working through your data, it will help you avoid the errors that drew supervisory attention in 2025.

What the Register of Information Actually Is

Article 28(3) of DORA requires all in-scope financial entities to maintain an up-to-date register of all contractual arrangements with ICT third-party service providers. Article 28(9) requires submission of that register — or a relevant part of it — to the competent authority at least annually, and upon request.

The ESAs translated this into a concrete data model through their Implementing Technical Standard (ITS) on the Register of Information, published in final form in early 2024. The ITS defines the exact data fields, the relationship between them, the permitted value sets (controlled vocabularies), and the xBRL-CSV format in which data must be submitted.

The result is a relational dataset. The RoI is not a spreadsheet with one row per provider. It is a set of linked tables where entities, providers, contracts, services, functions, assets, and costs must all be consistent with one another. A change in one table propagates expectations about data in related tables. This relational integrity is precisely what makes automated supervisory analysis possible — and what makes incomplete submissions easy to detect.

The 15 Mandatory Templates

The ITS defines a series of reporting templates that together constitute a complete Register of Information submission. The templates are grouped into logical layers that mirror the structure of your ICT supply chain:

Entity Layer

• Entities maintaining the register. Identifies the legal entity or entities submitting the RoI. For groups submitting on a consolidated basis, this covers the parent and all subsidiaries included in the consolidation perimeter.
• Branch information. Where applicable, identifies branches of the submitting entity operating in other Member States.

Provider Layer

• Third-party ICT service providers. The master list of all ICT providers your entity has contractual arrangements with. Each provider is identified by its Legal Entity Identifier (LEI) where available, plus country of establishment, entity type, and whether it is a CTPP-designated provider.
• Intra-group ICT service providers. Separate template for ICT services sourced from within the same corporate group. Intra-group arrangements are within scope if they support critical or important functions.

Contract Layer

• Contractual arrangements. One row per contract between your entity and a provider. Includes contract reference, start date, notice period, governing law, jurisdiction for dispute resolution, and whether the arrangement covers a critical or important function.
• Annual costs and estimated expenses. Financial data linked to each contract — actual spend for the prior year and estimated cost for the current year. This is the data that feeds concentration risk analysis at sector level.
• Exit strategies. For arrangements supporting critical or important functions: documentation that exit strategies exist, have been tested, and cover the minimum requirements of Article 28(8).

Service Layer

• ICT services received. Breaks each contract down into the individual ICT services delivered. A single contract may cover multiple services (storage, compute, network monitoring, application management) each of which must be listed separately.
• Service level objectives. The contractually agreed SLOs for availability, performance, and recovery for services supporting critical or important functions.

Function and Asset Layer

• Functions supported by ICT services. Maps each ICT service to the business function(s) it supports. Critically, this is where institutions must declare whether each function is critical or important — the designation that determines which DORA obligations apply to the supporting contract.
• ICT assets. The servers, applications, databases, and network components associated with each ICT service. This template was optional in the first 2025 collection; supervisory expectation for 2026 is that significant institutions populate it.
• Data classification. For services involving personal data, classified data, or operationally sensitive data: the categories of data processed and the data protection measures applied.

Sub-outsourcing Layer

• Sub-contractors of critical/important function arrangements. Where your ICT providers sub-contract services supporting your critical or important functions, those sub-contractors must also be registered. This template captures the chain.
• Assessment of sub-contracting chains. For each identified sub-contracting arrangement: your assessment of concentration risk, your approval of the sub-contracting, and the contractual provisions you have in place with your direct provider to govern sub-contractor behaviour.

The fifteenth template covers administrative metadata about the submission itself — version, submission date, contact point — required for NCA processing.

Country-Specific Submission Deadlines: Q1 2026

The ESAs set a framework deadline of Q1 2026 for the second RoI submission, but NCAs retained discretion over the exact date within that quarter. Deadlines varied by jurisdiction:

Always verify the exact deadline with your primary NCA. Deadlines published here reflect guidance available as of Q1 2026 and may have been extended or modified.

xBRL-CSV Format: What It Actually Requires

The xBRL-CSV format specified in the ITS is not a standard CSV file. It is a structured data package built on the XBRL (eXtensible Business Reporting Language) specification, adapted for tabular data. Understanding its components is essential for anyone responsible for assembling the submission.

Package Structure

A valid RoI submission consists of a folder containing:

• A JSON metadata file (report-package.json) describing the report type, reporting period, submitting entity, and the list of included data files
• One CSV file per template being submitted, named according to the taxonomy conventions (e.g., RT.01.01.csv)
• A taxonomy linkbase reference pointing to the ESA-published taxonomy, which defines the meaning of every column in every template

ESA Taxonomy and Controlled Vocabularies

Every column that accepts a categorical value — country codes, entity types, service categories, function classifications, contract type codes — must use the exact code values defined in the ESA taxonomy. Using a plain text description where a code is required, or using a national variant code instead of the ESA taxonomy code, causes a validation failure.

Common examples:

• Country codes: ISO 3166-1 alpha-2 (e.g., DE, FR, NL) — not country names
• Currency codes: ISO 4217 (e.g., EUR, USD) — not currency symbols
• Legal entity identifiers: 20-character LEI codes from the Global LEI Foundation — not company registration numbers
• ICT service types: the ESA taxonomy code list — not free-text descriptions

Validation Before Submission

The ESAs publish a validation ruleset alongside the taxonomy. Before submitting, every institution should run their package through the XBRL validator to catch:

• Structural errors (missing required fields, wrong data types)
• Referential integrity violations (a contract record referencing a provider ID that does not exist in the provider template)
• Controlled vocabulary violations (invalid code values)
• Business rule violations (e.g., a contract flagged as covering a critical function with no corresponding exit strategy entry)

2025 vs 2026: What Changed in Supervisory Expectations

The first RoI submission in 2025 was, for most regulators, primarily a scoping exercise. Supervisors wanted to understand the shape of the data — how many providers, what types of services, how concentrated the supply chain. The threshold for acceptability was relatively low: a structurally valid submission that covered the main providers, even if incomplete in some fields.

For the 2026 submission, expectations have materially increased in four areas:

1. Completeness: Every ICT Arrangement, Not Just the Obvious Ones

The 2025 submissions revealed a consistent pattern: large, well-known providers (AWS, Azure, Salesforce, SAP) were universally included. Smaller, more specialised providers — network monitoring vendors, security operations centre services, data analytics platforms, payment gateway operators — appeared in some submissions and not others. In 2026, supervisors expect completeness across the full spectrum of ICT providers, not just the top ten by spend.

2. Function Classification: Rigorous Criticality Assessments

In 2025, many institutions classified most functions as non-critical to reduce their compliance burden. Supervisors are now comparing criticality assessments against business impact analyses and incident histories. An institution that classifies its core banking platform as supporting a non-critical function, but then reports a major ICT incident affecting that same platform, creates an obvious inconsistency that triggers review.

3. Sub-outsourcing Chain Depth

The sub-contracting templates were sparsely populated in 2025. For 2026, supervisors expect material sub-contracting chains — especially for cloud providers who sub-contract to specialist hyperscaler infrastructure — to be documented. Claiming that your cloud provider has no material sub-contractors is no longer a credible position for institutions using major public cloud platforms.

4. Cost Data Accuracy

Annual costs are now cross-referenced against financial statement data where available. Significant discrepancies between reported ICT spend per the RoI and ICT-related cost disclosures in annual reports generate follow-up queries. The cost templates should be reconcilable to your management accounts.

The Most Common Errors from the 2025 First Collection

The ESAs and national supervisors published informal feedback on the 2025 collection identifying recurring data quality issues. The most frequently cited:

Missing LEIs

Approximately one-third of provider entries in the 2025 first collection either omitted the LEI entirely or used a provisional or lapsed LEI. Every in-scope ICT provider that is a legal entity must have a valid, active LEI. Institutions should run their provider list against the Global LEI Foundation database as a basic pre-submission check.

Inconsistent Function IDs Across Templates

The function identifier assigned in the function template must match exactly the function ID referenced in the contract and ICT service templates. Many submissions contained typographic variations (spaces, capitalisation differences) that broke the relational integrity of the submission.

Aggregated Contracts Instead of Individual Arrangements

Some institutions submitted a single contract record per provider, aggregating multiple distinct contractual arrangements. The ITS requires one record per contractual arrangement. A provider with five separate service contracts — cloud storage, compute, managed security, disaster recovery, professional services — requires five contract records.

Free-Text Where Codes Are Required

As noted above: using descriptive text instead of controlled vocabulary codes. Common examples: writing "Cloud Computing" instead of the taxonomy code for cloud services; writing "France" instead of FR; writing "not applicable" in a date field instead of leaving it null.

Exit Strategy Fields Left Blank for Critical Arrangements

Article 28(8) requires exit strategies for critical arrangements. The ITS exit strategy template fields are mandatory for any contract flagged as covering a critical or important function. Blank exit strategy entries for critical contracts are a business rule violation and a substantive compliance gap.

Cut-Off Date Inconsistencies

The RoI must reflect the state of your contractual landscape as of the reporting reference date. Institutions that used different reference dates across different templates — some templates reflecting January-end data, others March-end — produced internally inconsistent submissions that supervisors cannot reconcile.

The RoI as a Living Register

The most operationally significant shift in perspective required by DORA is treating the Register of Information as a continuously maintained system rather than an annual reporting exercise. Article 28(3) says the register must be "up-to-date." That word carries real implications.

Every material change to your ICT supply chain should trigger an update to the RoI:

• New provider onboarded: add provider, contract, services, and function mapping records
• Contract renewed or renegotiated: update contract terms, SLOs, and cost data
• Provider terminated: mark contract as ended; do not delete — historical records must be retained
• Function criticality reassessment: update function classification and cascade implications to related contract and exit strategy records
• New sub-contracting arrangement identified: add sub-contractor record and update chain assessment
• Provider acquires another provider: update LEI, legal entity data, and ownership chain

Institutions that batch all changes into a pre-submission rush in January face a fundamentally different data quality challenge than those that maintain the register in near-real-time. The former approach consistently produces the errors described above. The latter makes submission a near-automatic export.

Automation: How Leading Institutions Are Managing Their RoI

Manual maintenance of a multi-template xBRL-CSV dataset at the scale of a large bank or insurer is not sustainable. The institutions that achieved high-quality 2025 submissions — and are better positioned for 2026 and beyond — invested in one or more of the following approaches:

Source of Truth Integration

Rather than maintaining a standalone RoI spreadsheet, leading institutions link RoI data directly to their existing systems of record: the IT asset management (ITAM) system for assets and services, the contract management system for contractual data, the vendor risk management platform for provider information, and the business continuity system for criticality assessments. The RoI becomes an automated output of existing data rather than a manual parallel dataset.

Automated LEI Validation

Integrate a LEI lookup API (the Global LEI Foundation provides one) into the onboarding workflow for new ICT providers. Every new provider is automatically checked against the LEI database at onboarding, not six weeks before the submission deadline.

xBRL Package Generation

Several GRC (Governance, Risk and Compliance) platforms now offer DORA RoI modules that generate the required xBRL-CSV package directly from their data models, applying the ESA taxonomy and running the validation ruleset before export. For institutions without integrated GRC platforms, purpose-built DORA RoI tools from specialist vendors are available at materially lower cost.

Continuous Validation

Run the ESA validation ruleset against your RoI data monthly, not only pre-submission. Monthly validation catches referential integrity issues as they arise from individual data updates, rather than revealing a cascade of errors in the final pre-submission week.

Eight Steps to a Clean Q1 2027 Submission (Starting Now)

The 2026 submission is complete. The question is how to make the 2027 submission better — and less stressful. The foundation is built in the months immediately after submission, not in the months before.

1. Conduct a post-submission review. Before institutional memory fades, document every data quality issue encountered during 2026 preparation: missing LEIs, unclear function classifications, contracts discovered late, disagreements about criticality. These are your roadmap for process improvement.
2. Establish a change control process for the RoI. Define who is responsible for updating the register when a new ICT arrangement is entered, modified, or terminated. The most common failure mode is not malice or incompetence — it is that nobody had clear ownership of the update trigger.
3. Map your provider list to LEIs now. For every provider without a valid LEI in your current dataset, start the LEI application process or the verification process. LEI applications take time; starting in March gives twelve months of runway before the next submission.
4. Revisit your function criticality assessments. If your 2026 submission classified a large proportion of functions as non-critical, stress-test those classifications against your business continuity data and recent incident history. Supervisors will be looking at this in examination.
5. Map your sub-contracting chains. Request sub-contracting disclosure from all ICT providers supporting critical or important functions. Most major cloud providers publish their sub-processor lists; map these against your RoI service records.
6. Integrate RoI data with your vendor onboarding process. New provider onboarding should automatically generate a draft RoI entry. This is a process design question, not a technology question — it requires coordination between procurement, IT, legal, and compliance.
7. Run the ESA validation ruleset quarterly. Set a recurring calendar item for Q2, Q3, and Q4 validation runs against your live RoI data. Fix issues within 30 days of discovery.
8. Test your third-party risk scoring methodology. The RoI captures what providers you have and what services they provide. The risk analysis layered on top of that data — which providers represent concentration risk, which contracts lack adequate exit strategies — is where supervisors focus in examination. Use a structured scoring approach to prioritise monitoring efforts.

What Comes Next: The 2027 Submission and Beyond

The ESAs have indicated that future RoI submissions will have progressively higher data quality expectations. The roadmap includes:

• More granular ICT asset data. The asset template, optional in 2025 and expected for significant institutions in 2026, is likely to become mandatory for all in-scope entities from 2027 onwards.
• Real-time update requirements. The ESAs are exploring whether material changes to the RoI should be notified to NCAs within a defined timeframe (potentially 30 days) rather than waiting for the annual submission cycle.
• Cross-border group submissions. Groups with entities in multiple Member States currently submit to each NCA separately. Harmonised group submission protocols are under development through the Joint Committee.
• Integration with incident reporting data. Supervisors will increasingly expect consistency between the provider information in your RoI and the ICT provider references in your incident reports. Mismatches will generate automated queries.

The Register of Information is not a compliance checkbox. It is the foundational dataset for the entire DORA supervisory framework. Institutions that invest in maintaining it as a genuine, accurate, living record of their ICT landscape will find that it becomes a useful internal risk management tool as well as a regulatory deliverable. Those that treat it as an annual form-filling exercise will spend increasing effort managing supervisory queries, and decreasing credibility with the authorities that matter most.