Learn
Since January 17, 2025, the Digital Operational Resilience Act (DORA) has been fully enforceable across the European Union. For compliance officers at banks, insurers, investment firms, and other financial entities, one obligation has proven more operationally demanding than almost any other: maintaining and filing the Register of Information (RoI) under Article 28(3).
The RoI is not a simple spreadsheet exercise. It requires financial entities to document every contractual arrangement with ICT third-party service providers in a structured, machine-readable format defined by the European Supervisory Authorities (ESAs). The format is xBRL-CSV - not Excel, not PDF, not a Word document. And the data model spans 15 interconnected templates covering everything from entity identification to sub-outsourcing chains.
This guide is designed for the compliance officer who needs to understand exactly what the RoI contains, how the filing process works, where institutions most commonly fail, and what tools can eliminate the manual burden. Whether you are preparing for your first submission or refining your process after the initial 2025 reporting cycle, this is the reference you will come back to.
Key Takeaway
The Register of Information is not a one-time filing. Under Article 28(3) of DORA, financial entities must maintain it on a continuous basis and submit it to their National Competent Authority (NCA) upon request - or according to regular filing schedules set by each NCA. Getting your data architecture right from the start is essential.
📚
Understanding the Scope
What the DORA Register of Information Contains
The Register of Information is mandated by Article 28(3) of Regulation (EU) 2022/2554 (DORA). It requires each financial entity to maintain a complete register of all contractual arrangements with ICT third-party service providers. But the regulation goes further than a simple vendor list: the RoI must capture the full chain of ICT service delivery, including sub-outsourcing relationships, the business functions supported, and the criticality assessments associated with each arrangement.
The ESAs - EBA, EIOPA, and ESMA - published Implementing Technical Standards (ITS) under Article 28(9) that define the exact structure of the RoI. These ITS (Commission Implementing Regulation (EU) 2024/2956) specify 15 template tables, referenced as S.01.01 through S.99.01, that together form the complete data model.
The templates are not independent. They form a relational structure: entity identifiers in S.01.01 link to contractual arrangements in S.02.01, which link to ICT services in S.04.01, which link to functions and processes in S.05.01. Understanding this relational model is essential for producing a valid submission.
Entity-Level vs. Group-Level Reporting
Financial entities that are part of a group may need to report at both entity and consolidated levels. Templates S.01.01 and S.01.02 handle the entity and branch identification respectively, while S.02.01 through S.02.03 capture the contractual arrangements at individual entity and group level. Groups with complex structures often need to coordinate across multiple subsidiaries to avoid duplication and ensure consistent entity coding.
The data points span several categories of information:
Entity Identification
LEI codes, entity types, NCA identifiers, branch structures, and the entity's classification under DORA (credit institution, insurer, AIFM, etc.)
Contractual Arrangements
Contract identifiers, start/end dates, renewal terms, governing law, notice periods, and links to the ICT services provided under each contract
ICT Service Provider Details
Provider identification (LEI or other), jurisdiction, parent company, ultimate group, and whether the provider holds EU authorizations
Service & Function Mapping
ICT service types (per ESA taxonomy), the critical or important functions they support, data processing locations, and substitutability assessments
Sub-outsourcing Chains
Full identification of sub-contractors providing ICT services on behalf of the direct provider, including their jurisdictions and the services they sub-provide
Risk & Criticality Assessments
Whether the arrangement supports a critical or important function, concentration risk indicators, exit strategy availability, and last audit date of the provider
💻
Technical Requirements
The xBRL-CSV Format Requirement
This is where the DORA Register of Information diverges sharply from previous regulatory reporting exercises. The ESAs have mandated that RoI submissions use the xBRL-CSV (Extensible Business Reporting Language - CSV) format. This is not a conventional CSV file that you can produce in Excel. It is a structured data package defined by the XBRL Open Information Model (OIM), consisting of multiple interconnected components.
An xBRL-CSV report package contains:
Anatomy of an xBRL-CSV Report Package
1. JSON Metadata File (report.json) - Defines the report structure, maps each CSV table to its corresponding XBRL taxonomy entry point, specifies the reporting entity, reporting period, and declaration metadata. This is the “manifest” of the entire package.
2. CSV Data Files (one per template) - Each of the 15 templates produces a separate CSV file with precise column headers matching the ESA taxonomy. Column names are not human-readable labels but taxonomy-derived identifiers (e.g., ei0036 for LEI code).
3. XBRL Taxonomy Reference - The package references the official ESA DORA RoI taxonomy published on the EBA website. This taxonomy defines every data point, its data type, validation rules, and relationships to other data points.
4. ZIP Packaging - The entire package (JSON metadata + CSV files) is packaged in a ZIP archive for submission to the NCA’s filing portal.
“The choice of xBRL-CSV was deliberate. The ESAs need machine-readable, validated data to perform cross-entity concentration analysis and identify systemic ICT third-party risk across the EU financial sector. Excel submissions cannot deliver the consistency and validation that regulatory oversight requires.”
- ESA Joint Committee rationale, Policy Statement on DORA ITS
Why does this trip up most institutions? Because xBRL-CSV requires three things that compliance teams rarely have in-house:
1
Taxonomy Expertise
Understanding the XBRL data model, dimension members, and typed domains
2
Data Engineering
Producing clean, normalized CSV with exact column headers and data type conformance
3
Validation Tooling
Pre-submission validation against ESA filing rules and cross-table consistency checks
Institutions that attempt to produce xBRL-CSV manually - assembling CSV files and hand-crafting the JSON metadata - consistently encounter validation failures. The ESA taxonomy includes over 200 validation rules, many of which are cross-table (e.g., every provider referenced in S.04.01 must exist in S.03.01). A single missing reference or incorrect data type will cause the entire filing to be rejected.
📋
Template Reference
All 15 Register of Information Templates
The following table provides a complete reference for every template in the ESA ITS. Understanding each template's purpose and how they interconnect is foundational to building a compliant RoI.
| Template | Name | Purpose | Fields | Level |
|---|---|---|---|---|
| S.01.01 | Entity maintaining the register | Identifies the reporting financial entity (LEI, name, type, NCA) | 14 | Entity |
| S.01.02 | List of entities within scope | Branches and entities covered by the register (for group reporting) | 18 | Entity/Group |
| S.02.01 | Contractual arrangements - general | Core contract data: identifier, type, start/end dates, overarching contract link | 22 | Entity |
| S.02.02 | Contractual arrangements - specific | Detailed terms: governing law, country, currency, annual cost, notice period | 19 | Entity |
| S.02.03 | Contractual arrangements - at entity using ICT services level | Maps which entities within the group use each contract | 8 | Group |
| S.03.01 | ICT third-party service providers | Provider identification: LEI, name, headquarters country, parent entity, group structure | 16 | Entity |
| S.03.02 | ICT third-party service providers - intragroup | Identifies providers that are within the same corporate group as the reporting entity | 6 | Group |
| S.04.01 | ICT services provided | Service types (per ESA taxonomy), links to contracts and providers, service descriptions | 15 | Entity |
| S.04.02 | ICT services provided - at entity using ICT services level | Maps ICT services to the specific entities within a group that consume them | 6 | Group |
| S.05.01 | Functions identification | Business functions and processes supported by ICT services, criticality assessment | 17 | Entity |
| S.05.02 | Functions identification - at entity using ICT services level | Links functions to specific group entities that rely on them | 6 | Group |
| S.06.01 | Assessment of ICT concentration risk | Substitutability assessment, exit strategy existence, alternative providers, impact analysis | 12 | Entity |
| S.06.02 | Assessment of ICT concentration risk - at entity level | Entity-specific substitutability and impact data within a group context | 8 | Group |
| S.07.01 | ICT service supply chain | Sub-outsourcing chains: sub-contractors, their services, jurisdictions, criticality flags | 20 | Entity |
| S.99.01 | Additional information | Free-text explanations, clarifications, and supplementary notes for any template | 4 | Entity |
Key Takeaway
The total field count across all 15 templates exceeds 190 data points. For a mid-sized bank with 50 ICT contracts and sub-outsourcing chains, this can translate to thousands of individual data cells that must be internally consistent and taxonomy-compliant.
🛠
Filing Workflow
Step-by-Step Filing Process
Filing the Register of Information is a multi-phase process that involves operational, technical, and governance steps. Below is the end-to-end workflow from initial data gathering to NCA submission.
Step 1: ICT Contract Inventory & Data Collection
Compile a comprehensive list of all ICT third-party service provider contracts. This includes cloud services, software licences, managed infrastructure, data centre hosting, payment processing platforms, cybersecurity services, and any other arrangement involving ICT services as defined by DORA. For each contract, gather the data points required by templates S.02.01 and S.02.02: contract reference numbers, dates, costs, governing law, and notice periods.
Step 2: Provider Identification & Due Diligence
For every ICT provider, obtain their Legal Entity Identifier (LEI) from the GLEIF database. If the provider does not have an LEI (common for smaller or non-EU providers), use the ESA-prescribed alternative identification approach - a combination of entity name, registration number, and country code. Map out each provider's corporate structure: parent entity, ultimate parent, and whether they are part of your own corporate group (for intragroup reporting in S.03.02).
Step 3: Service & Function Mapping
Map each ICT service to the ESA's ICT service type taxonomy. Then link each service to the business functions and processes it supports (template S.05.01). This is where the critical or important function (CIF) assessment takes place: determine whether each function is critical or important as defined under DORA Article 3(22), and record data processing locations by country. This step typically requires input from business line owners, IT architecture teams, and risk management.
Step 4: Sub-outsourcing Chain Documentation
Request from each ICT provider a disclosure of their sub-outsourcing arrangements. Under DORA, you must document the full ICT service supply chain (template S.07.01). This is often the most challenging data collection exercise, as providers may be reluctant to disclose sub-contractors or may have incomplete visibility into their own supply chains. Contractual clauses requiring disclosure are essential - and should have been negotiated when onboarding providers.
Step 5: Concentration Risk Assessment
Complete the concentration risk templates (S.06.01 and S.06.02). For each critical ICT service arrangement, assess: Is the provider substitutable? Do alternative providers exist? Is an exit strategy documented and tested? What would be the operational impact of a sudden provider failure? These assessments feed directly into your DORA-mandated ICT risk management framework.
Step 6: xBRL-CSV Package Assembly
Transform your collected data into xBRL-CSV format. This involves generating the individual CSV files for each applicable template (with exact taxonomy column headers), constructing the JSON report metadata file (report.json), and packaging everything into a valid ZIP archive. All cross-references between tables must be consistent - every entity ID, contract ID, and provider ID must match exactly across templates.
Step 7: Pre-Submission Validation
Run your xBRL-CSV package through a validation engine before submitting to your NCA. The ESA taxonomy includes over 200 validation rules covering data types, mandatory fields, cross-table referential integrity, enumeration values, and business logic checks. Submitting an invalid package results in rejection and delays. Some NCAs provide their own validation tools; third-party XBRL software vendors also offer validators.
Step 8: NCA Submission & Internal Governance
Submit the validated package to your National Competent Authority through their designated filing portal. Ensure internal governance sign-off before submission - typically from the CIO, CISO, or head of third-party risk management. Retain a copy of the submission, the validation report, and all supporting documentation. Under Article 28(3), the register must also be available for ad-hoc requests from the NCA, so your internal records should be continuously maintained.
⚠️
Pitfalls to Avoid
Common Mistakes and How to Avoid Them
Based on the first reporting cycles and feedback from NCAs across EU member states, the following five errors are the most frequently encountered. Each one can result in filing rejection or supervisory follow-up.
| # | Mistake | Why It Happens | How to Avoid It |
|---|---|---|---|
| 1 | Broken cross-table references | Provider IDs in S.04.01 don't match S.03.01 entries, or contract IDs in S.02.02 don't exist in S.02.01. Often caused by manual data entry across multiple spreadsheets. | Use a single-source database model where entity, contract, and provider identifiers are generated once and referenced everywhere. Automated cross-table validation is essential. |
| 2 | Missing or invalid LEI codes | Providers without active LEIs, expired LEIs, or incorrect LEI formatting. The GLEIF database changes regularly - LEIs lapse if not renewed annually. | Validate all LEIs against the GLEIF API before filing. For providers without LEIs, use the ESA alternative identification framework consistently and document the reason. |
| 3 | Incomplete sub-outsourcing data | Providers fail to disclose sub-contractors, or the information provided is too vague. Template S.07.01 requires specific identification of each sub-contractor. | Embed sub-outsourcing disclosure requirements into all ICT contracts. Conduct annual surveys of major providers. Where gaps remain, use S.99.01 to document limitations explicitly. |
| 4 | Incorrect ICT service type codes | Using free-text descriptions instead of the ESA enumeration values. The taxonomy defines specific service type codes; any value outside the closed list is invalid. | Map every ICT service to the ESA service type taxonomy during the data collection phase. Use dropdown/enumeration controls in your data collection tool to prevent free-text entry. |
| 5 | Malformed xBRL-CSV metadata | The report.json file references incorrect taxonomy entry points, uses wrong period specifications, or has structural JSON errors. Institutions assembling packages manually are especially prone. | Use validated templates or software that auto-generates the JSON metadata. Never hand-edit the report.json file. Run the xBRL-CSV package through an OIM-compliant validator before submission. |
Supervisory Note
NCAs have indicated that incomplete or rejected RoI submissions will be treated as a compliance gap under DORA. Repeated filing failures may trigger enhanced supervisory attention, including on-site inspections focused on ICT third-party risk management. The register is not a “best effort” document - it is a regulatory obligation with supervisory consequences.
📅
Regulatory Calendar
Critical Dates for 2026 RoI Filing
The DORA Register of Information operates within a specific regulatory timeline. Financial entities must understand both the EU-level deadlines and their own NCA's specific filing windows. The following timeline captures the key milestones.
| Date | Milestone | Significance |
|---|---|---|
| 17 Jan 2025 | DORA fully enforceable | All obligations under Regulation (EU) 2022/2554 became applicable, including Article 28 register requirements |
| Q2 2025 | Initial NCA collection cycles | Multiple NCAs opened their first RoI collection windows for supervised entities. ESAs began aggregating cross-border data |
| H2 2025 | ESA feedback & taxonomy updates | ESAs published data quality feedback and minor taxonomy corrections based on initial submissions |
| Q1 2026 | Annual register update deadline | Entities must ensure their register reflects all contractual changes from 2025, including new contracts, terminations, and modifications |
| Apr 2026 | 2026 NCA filing window opens | Most NCAs expected to open their 2026 annual collection window (exact dates vary by NCA - check your NCA portal) |
| 30 Apr 2026 | ESA annual information request | ESAs may request the register from financial entities at entity or group level per Art. 28(3), second subparagraph, for designation exercises |
| Ongoing | Continuous maintenance obligation | The register must be kept up to date at all times - any new ICT contract, termination, or material change must be reflected promptly |
NCA-Specific Deadlines
Filing windows and deadlines vary by National Competent Authority. BaFin (Germany), ACPR (France), DNB (Netherlands), and the Central Bank of Ireland each set their own submission timelines. Always check your NCA's official DORA portal for the exact dates applicable to your entity. Some NCAs require quarterly updates; others request annual submissions with ad-hoc requests possible at any time.
⚡
Platform Capabilities
How Venvera Automates the Register of Information
Venvera was purpose-built for DORA compliance, with the Register of Information as a core capability - not an afterthought bolted onto a generic GRC platform. The platform's data model mirrors the ESA ITS template structure, which means the information you enter during normal DORA compliance operations flows directly into RoI reporting without rekeying, reformatting, or manual transformation.
Native xBRL-CSV Export
One-click generation of the complete xBRL-CSV report package (ZIP archive with CSV data files and JSON metadata), validated against the latest ESA taxonomy before download.
ESA Entity & Service Codes
Built-in reference data for all ESA enumeration values: entity types, ICT service type codes, country codes, NCA identifiers, and function categorizations. No manual code lookups required.
Sub-outsourcing Chain Mapping
Visual supply chain builder that captures multi-tier sub-outsourcing relationships. Each link in the chain maps directly to S.07.01 data points with automatic referential integrity.
Cross-Table Validation Engine
Real-time validation of all 200+ ESA filing rules as you enter data. The platform flags broken references, missing mandatory fields, and invalid enumeration values before you ever attempt to export.
LEI Validation & Lookup
Integrated GLEIF LEI validation that checks LEI format, active status, and entity name matching. Flags expired or lapsed LEIs before they cause filing rejections.
Continuous Register Maintenance
When you add a new ICT provider, modify a contract, or update a business function mapping in Venvera, the register updates automatically. No separate “register update” process needed.
Concentration Risk Dashboard
Visual analytics showing ICT concentration across providers, jurisdictions, and service types. Feeds directly into S.06.01 and S.06.02 template data with substitutability scoring.
Group-Level Consolidation
For financial groups, Venvera supports multi-entity reporting with automatic generation of group-level templates (S.01.02, S.02.03, S.04.02, S.05.02, S.06.02) from entity-level data.
Key Takeaway
With Venvera, the Register of Information is a by-product of your daily DORA compliance operations - not a separate reporting project. The same data you use for ICT risk assessments, vendor due diligence, and gap analyses feeds the RoI automatically.
📈
Approach Comparison
Manual Spreadsheets vs. Purpose-Built Platform
Many institutions started their DORA RoI journey using Excel templates. While spreadsheets can work for very small entities with a handful of ICT contracts, they rapidly become unmanageable - and risky - as complexity grows. Here is how the two approaches compare across the dimensions that matter most for filing success.
| Dimension | Manual (Excel/Spreadsheets) | Automated (Venvera) |
|---|---|---|
| xBRL-CSV generation | Requires external tooling or developer support to convert spreadsheet data into valid xBRL-CSV format | Native one-click export, pre-validated against ESA taxonomy |
| Cross-table validation | Manual checking or custom VBA macros; error-prone at scale | Real-time automated validation of 200+ rules as data is entered |
| Sub-outsourcing chains | Difficult to model multi-tier relationships in flat spreadsheets | Visual chain builder with automatic S.07.01 population |
| Continuous maintenance | Requires discipline to update spreadsheets with every contract change | Register updates automatically as operational data changes |
| Group consolidation | Manual aggregation from multiple entity spreadsheets; high duplication risk | Automatic consolidation from entity-level data with deduplication |
| Audit trail | Limited or no change tracking; version control via file names | Full audit log of every data change, with timestamps and user attribution |
| Time to file | Weeks of preparation per submission cycle | Minutes - export the data you already maintain |
🔭
Looking Ahead
Regulatory Context and What Comes Next
The DORA Register of Information is not an isolated obligation. It is the data foundation for the ESAs' broader oversight framework for ICT third-party risk in the EU financial sector. Understanding where the RoI fits in the bigger picture helps compliance teams prioritize and prepare.
Critical ICT Third-Party Provider (CTPP) Designation. Under Article 31 of DORA, the ESAs will use RoI data - aggregated across all EU financial entities - to identify ICT providers that are “critical” to the financial sector. These CTPPs will be subject to direct ESA oversight, including on-site inspections and binding recommendations. The quality and completeness of your RoI submission directly influences whether your providers are correctly assessed in the designation process.
Supervisory convergence. The ESAs are working toward greater harmonization of NCA filing processes. Expect filing portals, validation rules, and submission formats to converge over the next two years, reducing (but not eliminating) NCA-specific variations. Early adopters of structured, taxonomy-compliant data management will adapt more easily.
Taxonomy evolution. The ESA DORA RoI taxonomy will evolve. As the regulatory framework matures, expect additions to capture emerging areas such as AI service provision, quantum-safe cryptography requirements, and cross-border data transfer mechanisms under evolving EU data protection law. Building on a flexible, structured data platform - rather than rigid spreadsheets - provides the adaptability needed for future changes.
“The register of information is not a paperwork exercise. It is the supervisory community’s window into the ICT risk landscape of the EU financial sector. Entities that treat it as a compliance checkbox will find themselves at a disadvantage when supervisors begin using RoI data to drive on-site examinations and thematic reviews.”
- EBA Supervisory Convergence Report, 2025
Summary: Your 2026 RoI Filing Checklist
- Ensure all ICT third-party contracts are documented with complete data points per ESA ITS templates S.01.01 through S.07.01
- Validate all provider LEI codes against the GLEIF database and use ESA alternative identification where LEIs are unavailable
- Map every ICT service to the ESA service type taxonomy and link to supported business functions with criticality assessments
- Document sub-outsourcing chains to the full extent of available information and note gaps in S.99.01
- Generate the xBRL-CSV package using validated tooling - never hand-assemble the JSON metadata
- Run pre-submission validation against all 200+ ESA filing rules before uploading to your NCA portal
- Obtain internal governance sign-off and retain submission records
- Maintain the register continuously - do not treat it as an annual exercise
Published March 2026 · Updated for the 2026 ESA taxonomy and NCA filing cycles · venvera.com
