How to Build Your DORA Register of Information: A Step-by-Step Guide

What Is the Register of Information?

Article 28(3) of the Digital Operational Resilience Act (DORA) requires all EU financial entities to maintain a Register of Information (RoI) documenting every contractual arrangement with ICT third-party service providers. This is not a nice-to-have checklist — it is a legally mandated, structured dataset that must be reported to national competent authorities (NCAs), who then forward it to the European Supervisory Authorities (ESAs).

The RoI is arguably the most operationally demanding DORA requirement. It forces organizations to achieve a level of vendor contract visibility that most have never attempted before. If you have hundreds of ICT vendors, dozens of sub-outsourcing chains, and contracts scattered across business units, building the RoI will be a significant undertaking.

This guide walks through the template structure, country-specific deadlines, practical steps, and the pitfalls that trip organizations up.

The ESA Template Structure

The ESAs (EBA, EIOPA, and ESMA) published a standardized template for the RoI in xBRL (eXtensible Business Reporting Language) format. The template consists of multiple interconnected tables:

Template Components

1. Entity identification (B_01) — Legal entity identifier (LEI), entity name, classification, and consolidation details
2. Contractual arrangements (B_02) — Every ICT service contract: provider identity, start/end dates, contract value, renewal terms
3. ICT services (B_03) — Classification of each ICT service: function supported, criticality assessment, data location
4. ICT third-party service providers (B_04) — Provider details: LEI, jurisdiction, ultimate parent company
5. Sub-outsourcing (B_05) — Sub-contractors used by your ICT providers: full chain documentation
6. Functions identification (B_06) — Critical or important functions supported by ICT services
7. Intra-group arrangements (B_07) — ICT services provided by entities within your corporate group

Key Data Points Per Contract

For each contractual arrangement, you must document:

• Provider LEI (or BIC/national identifier if no LEI)
• Contract start and end dates
• Service criticality assessment (critical/important or not)
• Data storage and processing locations (by country)
• Whether the service supports a critical or important function
• Substitutability assessment
• Sub-outsourcing arrangements and the sub-contractor chain

Reference Date and Submission Timeline

The initial RoI uses a reference date of 31 December 2025 — meaning all data must reflect the state of your ICT third-party arrangements as of that date.

National competent authorities collect the data from financial entities and forward completed registers to the ESAs by 31 March 2026.

Country-Specific Deadlines

Submission deadlines vary by NCA. Here are the key markets:

Country	NCA	Submission Window	Format
Germany	BaFin	9 March - 30 March 2026	BaFin Excel template (converted to xBRL)
Luxembourg	CSSF	Portal opened 11 February 2026	CSSF online portal (xBRL upload)
Netherlands	DNB	February - March 2026	DNB portal (xBRL)
France	ACPR/AMF	March 2026	xBRL direct upload
Ireland	CBI	March 2026	xBRL direct upload
Italy	Banca d'Italia/CONSOB/IVASS	March 2026	xBRL direct upload
Belgium	NBB/FSMA	March 2026	xBRL direct upload

BaFin's Excel Template Option

BaFin offered a pragmatic accommodation: financial entities in Germany can submit their RoI data using a BaFin-provided Excel template. BaFin then converts the data to xBRL format before forwarding to the ESAs. This significantly lowers the technical barrier for mid-sized entities without xBRL reporting capabilities.

If you are a BaFin-supervised entity, download the Excel template from the BaFin website and follow their field-by-field guidance. The Excel format mirrors the ESA xBRL structure but is far more accessible.

Step-by-Step: Building Your Register

Step 1: Inventory All ICT Contracts

Start with a complete inventory of every contract involving ICT services. This includes:

• Cloud infrastructure (IaaS, PaaS, SaaS)
• Managed security services (SOC, MDR, SIEM)
• Data analytics and AI platforms
• Payment processing and transaction systems
• Communication platforms (email, messaging)
• Core banking, insurance, or trading systems

Common mistake: Only including "technology" contracts. DORA's definition of ICT services is broad — any digital service that supports your business operations counts. Marketing automation, HR platforms, and even office productivity suites may be in scope.

Step 2: Classify Service Criticality

For each contract, assess whether the ICT service supports a critical or important function. DORA Article 3(22) defines these as functions whose disruption would materially impair:

• Financial performance
• Soundness or continuity of services
• Compliance with regulatory obligations

Services supporting critical or important functions require deeper documentation, including substitutability assessments and exit strategies.

Step 3: Collect Provider Information

For each ICT third-party provider, gather:

• Legal Entity Identifier (LEI) — required for all providers that have one
• Jurisdiction of incorporation — country where the provider is legally established
• Ultimate parent company — the top of the corporate ownership chain
• Data processing locations — every country where your data is stored or processed

Common mistake: Not having LEI codes for smaller providers. If a provider does not have an LEI, you may use a BIC code or national registration number, but document why an LEI is unavailable.

Step 4: Map Sub-Outsourcing Chains

This is where most organizations struggle. DORA requires you to document not just your direct ICT providers but their sub-contractors — the full chain of outsourcing.

For example: if your cloud provider uses a third-party data centre operator, and that operator uses a separate network provider, the entire chain must be documented.

Practical approaches:

• Request sub-outsourcing disclosures from providers as part of due diligence
• Include contractual clauses requiring notification of sub-outsourcing changes
• Use provider audit reports (SOC 2, ISO 27001) to identify sub-processors

Step 5: Assess Concentration Risk

DORA specifically targets ICT concentration risk — the danger of over-reliance on a single provider. As you build your RoI, flag:

• Providers supporting multiple critical functions
• Providers with limited substitutability
• Geographic concentration (e.g., all data in a single country)

Step 6: Populate the Template and Submit

With all data collected, populate the ESA template (or your NCA's specific format). Validate the data for completeness — NCAs will reject incomplete submissions.

Key validation checks:

• Every provider has an LEI or documented alternative identifier
• All critical function assessments are completed
• Sub-outsourcing chains are documented to at least one level
• Data locations are specified at the country level
• Contract dates are accurate and current

Repurposing Existing Vendor Inventories

If you already maintain a vendor management system or third-party risk management platform, you have a significant head start. Most TPRM platforms track:

• Vendor identity and classification
• Service descriptions and criticality
• Contract metadata
• Risk assessment results

The gap typically lies in:

• Sub-outsourcing details — most TPRM platforms don't track the full chain
• LEI codes — often not collected in standard vendor onboarding
• Data location granularity — DORA requires country-level specificity
• xBRL format — you'll need to export your data into the ESA template structure

A compliance platform like ArvexLab can bridge this gap by maintaining your vendor inventory in a format that maps directly to the DORA RoI template fields.

Common Pitfalls

1. Underestimating Sub-Outsourcing Complexity

Most organizations know their direct providers but have limited visibility into sub-contractors. Start requesting this information early — providers may need weeks to compile it.

2. Missing Intra-Group Arrangements

If your organization receives ICT services from other entities within your corporate group, these must be included in the RoI. Intra-group arrangements are not exempt.

3. Inconsistent Criticality Assessments

Different business units may classify the same provider differently. Establish a centralized criticality assessment methodology before populating the RoI.

4. Stale Contract Data

Contracts that have been renewed, amended, or terminated may not be reflected in your records. Verify all contract metadata against actual signed agreements.

5. Ignoring Non-Traditional ICT Services

Cloud-based HR platforms, marketing automation tools, and even physical security systems with digital components may qualify as ICT services under DORA's broad definition.

Maintaining the Register

The RoI is not a one-time exercise. Financial entities must maintain it on an ongoing basis and be prepared to submit updated versions when requested by their NCA. Build processes to:

• Update the register when new contracts are signed or existing ones are amended
• Review sub-outsourcing arrangements at least annually
• Reassess service criticality when business functions change
• Validate provider data (LEI, jurisdiction, data locations) periodically

FAQ