Learn
I want to be honest with you about something upfront: there is no single document from the EBA, ESMA, or EIOPA that tells you everything you need to know about the DORA Register of Information in one place. The requirements are spread across the main DORA regulation text, the Joint Technical Standards, the ITS on registers of information, the xBRL taxonomy documentation, NCA-specific portal guidance, and a series of Q&As that the ESAs have published in response to industry questions — some of which clarify things that the original texts left genuinely ambiguous.
This guide is the document I wish had existed when compliance teams started working on their first submissions. It pulls everything together: what the Register of Information actually is, who has to submit it, what data goes into each of its 15 tables, how the tables relate to each other, what the submission process looks like from start to finish, and what year-round maintenance looks like once your first submission is behind you.
By the time you finish reading this, you'll have a complete mental model of the RoI — not just enough to fill in a template, but enough to understand why each field exists, what the regulator is trying to see, and where the traps are for teams who are working through this for the first time.
📋 What this guide covers: The legal basis and purpose of the Register of Information, who must submit and at what level, a table-by-table breakdown of the data model, the submission process and format requirements, ongoing maintenance obligations, and the most common mistakes teams make when building their register for the first time.
📌 Jump to section
⚡ TL;DR
The DORA Register of Information is a structured, relational dataset covering your ICT third-party providers, contracts, services, and their links to your critical internal functions. It must be submitted to your NCA annually in xBRL-CSV format. It is not a vendor list, not a risk register, and not a control framework — it is a specific regulatory reporting output with 15 interconnected tables, 200+ fields, and 117 EBA validation rules. Managing it in Excel is possible for small registers but breaks down quickly as complexity grows.
What Is the DORA Register of Information?
The Register of Information (RoI) is one of the central operational requirements of the Digital Operational Resilience Act. It is defined under Article 28(3) of DORA, with detailed technical specifications set out in the Implementing Technical Standards (ITS) on registers of information published jointly by the EBA, ESMA, and EIOPA.
At its core, the RoI is a comprehensive, structured record of every ICT third-party service provider your organisation relies on — and a precise mapping of what those providers do, which contracts govern the relationship, and which of your internal business functions depend on their services. Regulators use this data for two primary purposes: to understand the concentration of risk across the financial system (if one cloud provider fails, which institutions are affected and how severely?), and to assess individual institutions' operational resilience and third-party risk governance.
What it is not is equally important to understand. The RoI is not:
- A vendor risk register — it doesn't capture risk scores, risk ratings, or risk mitigation measures for each provider. That's a separate DORA obligation.
- A contract management system — it captures specific structured data fields about contracts, but it's not a document repository for the contracts themselves.
- A compliance control framework — it doesn't track whether you've implemented the required ICT security controls. That's your ICT risk management framework under Articles 5–15.
- A one-time audit artifact — it's a live register that must be maintained continuously and updated within defined timeframes whenever something material changes.
⚠️ A common misconception
Many compliance teams initially approach the RoI as an extension of their existing third-party risk management program — essentially a structured export of their vendor register. This leads to problems. The RoI has a specific relational data model with mandatory fields and inter-table dependencies that don't map neatly onto vendor lists built for internal risk management purposes. Building the RoI correctly requires starting from the DORA data model, not from your existing vendor data.
Who Must Submit — and at What Level?
Article 28(3) of DORA requires all financial entities within scope of the regulation to maintain and submit a Register of Information. The full list of in-scope entities is defined in Article 2(1) and includes:
🏦 Credit institutions
💳 Payment institutions
📈 Investment firms
🪙 Crypto-asset service providers
🛡️ Insurance undertakings
📊 Central counterparties
🏛️ Trade repositories
📋 Management companies
Micro-enterprises — defined under EU law as entities with fewer than 10 employees and annual turnover under €2 million — benefit from proportionality provisions and are exempt from certain requirements, but the RoI obligation is not one of the areas where micro-enterprise exemptions fully apply. Check the ESA's proportionality guidance for your specific entity type.
Individual, sub-consolidated, and consolidated submissions
For financial groups, the ITS specifies three possible submission levels. Understanding which applies to your structure is essential before you start building your register — because the answer determines the scope of data you need to collect and how entities within the group relate to each other in the data model.
| Submission level | Who submits | What it covers | Key considerations |
|---|---|---|---|
| Individual | Each in-scope legal entity | ICT arrangements of that entity only | Default requirement for all in-scope entities; standalone firms always submit at this level |
| Sub-consolidated | Parent of a sub-group | ICT arrangements of the sub-group's entities combined | Applies where a sub-group parent is itself an in-scope financial entity; data must be aggregated across all subsidiaries in scope |
| Consolidated | Ultimate EU parent undertaking | All in-scope entities across the group | Most complex — requires harmonised data collection across all jurisdictions and entity types in the group; each entity's B00 record must identify its role in the group structure |
Groups may need to produce all three levels simultaneously — individual submissions from each entity, sub-consolidated submissions from sub-group parents, and a consolidated submission from the ultimate EU parent. Each submission must be a coherent, self-consistent data package that passes validation independently.
The Data Model: 15 Tables Explained
The RoI data model is the heart of the requirement and the part that most guides and templates explain least well. Understanding it properly — not just what each table contains, but how the tables relate to each other — is what separates teams who build the register correctly the first time from teams who spend months in a resubmission loop.
Think of the data model as a set of concentric rings. At the centre is your organisation and its critical functions. Moving outward, you document the ICT services that support those functions, the contracts that govern those services, the providers who deliver them, and the sub-contractors those providers rely on in turn.
The 15 RoI tables at a glance
B00
Reporting entity
The financial entity (or group of entities) submitting the register. Establishes the identity anchor for all other tables.
B01
ICT Third-Party Service Providers
The master list of all external ICT providers — including legal entity name, LEI, country of establishment, and headquarters location. Every provider referenced anywhere in the register must have a record here.
B02
Contractual Arrangements
One record per contract with an ICT provider. Captures contract reference, start and end dates, notice periods, governing law, contract value, and whether the contract covers critical or important functions.
B03
ICT Services
Individual ICT services delivered under each contract. A single contract can cover multiple services. Each service record links to its contract (B02), its provider (B01), and the internal functions it supports (B06).
B04
Sub-Contracted ICT Services
ICT services that your primary provider sub-contracts to third parties. Captures the sub-contractor identity and the services affected. This is the table most commonly left incomplete.
B05
ICT Systems
Specific IT systems, applications, and platforms delivered as part of the ICT services. Links to the service in B03 and carries information about the system type and hosting arrangement.
B06
Functions — Critical or Important
The internal business functions of your organisation that are supported by ICT services. Captures function name, criticality assessment, and classification. This is the "inside" anchor of the relational chain.
B07
Function — ICT Service Mapping
The junction table linking ICT services (B03) to the functions they support (B06). A many-to-many relationship — one service may support multiple functions, and one function may be supported by multiple services.
B08
Impact Assessment — ICT Services
Assessment of the impact of a disruption to each ICT service — particularly for services supporting critical or important functions. Captures recovery time and recovery point objectives.
B09
Exit Plans
Documentation of exit strategies for ICT arrangements supporting critical or important functions. Captures whether a documented exit plan exists and its status.
B10
Contractual Provisions (Article 30)
Tracks which of the 12 mandatory Article 30(2) contractual provisions are present in each relevant contract. One of the most commonly incomplete tables in first submissions.
B11
Internal Audit
Record of internal audit reviews performed on the ICT third-party arrangements, including audit dates, scope, and findings status.
B12
Data Storage Location
Where data associated with ICT services is stored, processed, and managed — including country, data centre type, and whether storage is within or outside the EU.
B13
Sensitive Functions Assessment
Assessment of whether any ICT services involve processing of sensitive data — particularly relevant for data protection and sovereignty considerations.
B14
Provider Performance
Monitoring and performance data for ICT providers — service availability metrics, incident counts, and performance against contractual SLAs for critical arrangements.
How the tables connect
The relational chain runs like this: your reporting entity (B00) has internal functions (B06). Those functions are supported by ICT services (B03), which are linked to functions through the B07 junction table. Each ICT service is delivered under a contract (B02) by a provider (B01). Some services are sub-contracted (B04). Each contract has associated systems (B05), impact assessments (B08), exit plans (B09), and contractual provision checks (B10). Providers are subject to audit (B11) and their data handling characteristics are documented (B12, B13), with performance tracked over time (B14).
Every foreign key relationship in this chain must be intact in your submission. A single broken link — a service referencing a contract that doesn't exist, a function mapping referencing a service with a mismatched ID — fails the entire submission at the validation stage.
Key Concepts: Criticality, Sub-Outsourcing, and Functions
Three concepts in the RoI data model deserve extra attention because they're the ones teams get wrong most often — and because getting them wrong affects not just your submission but your underlying compliance posture.
Critical or important functions (CIFs)
The concept of "critical or important functions" under DORA is defined in Article 3(22) and links directly to the EBA's guidelines on outsourcing. A function is critical or important when its disruption would materially impair the financial performance of the entity, or the soundness or continuity of its services or activities.
In practice, this means your organisation must make and document a formal assessment of each business function against these criteria. The RoI (Table B06) records the outcome of those assessments. Common mistakes include: applying the criticality label too narrowly (underestimating which functions qualify, thereby understating your ICT dependency), applying it too broadly (over-classifying functions, creating unnecessary reporting scope), or failing to document the assessment methodology behind each classification — which regulators will ask for.
Sub-outsourcing chains
Article 28(2) requires financial entities to identify and document sub-outsourcing arrangements — situations where your direct ICT provider sub-contracts part of the service to another party. Table B04 captures this. In practice, it means you need to know not just who your providers are, but who their providers are, at least for arrangements supporting critical or important functions.
This is one of the most under-populated tables in first RoI submissions, for an obvious reason: gathering sub-outsourcing data requires your direct providers to disclose information about their supply chains that they may be reluctant to share. You have a contractual right to this information under Article 30(2)(h), but exercising that right takes time and sometimes produces disputes. Starting this data collection exercise early — ideally 6 months before your first submission — is strongly advisable.
The provider-contract-service-function chain
The most important structural concept in the RoI is that every ICT arrangement must be traceable from provider all the way to internal function. This is not just a data model requirement — it reflects the regulator's actual analytical goal: to understand, for any given business function, exactly which external parties you depend on and through what contractual relationships. If that chain is broken anywhere in your data, the register fails its purpose even if it passes technical validation.
The Submission Process
Format
The RoI must be submitted in xBRL-CSV format — a structured, machine-readable format defined by the XBRL International standard and profiled for DORA by the ESAs. Your submission is a ZIP archive containing one CSV file for each table in the data model. Each CSV must conform to the XBRL taxonomy that the ESAs publish and update. The taxonomy defines field names, data types, controlled value lists, and the relationship constraints between tables.
There is no provision for submitting in Excel format, PDF, or any other format. NCA portals only accept the xBRL-CSV ZIP. This is one of the most impactful practical requirements of DORA — it means that organisations maintaining their register in Excel must go through a conversion and validation process that introduces significant risk of error at the export stage.
Timing and deadlines
The annual submission deadline varies by NCA. Most NCAs have set deadlines in the first quarter of each calendar year, with the reference date being 31 December of the prior year — meaning your register must reflect the state of your ICT arrangements as of 31 December. Check your specific NCA's technical guidance for the exact filing deadline applicable to your entity type and jurisdiction.
The key operational implication: you cannot start building the register in January for a March deadline if your data collection processes aren't already in motion. The sub-outsourcing data alone can take months to gather. Organisations that treat the RoI as a year-end exercise consistently find themselves either submitting incomplete data or requesting extensions.
The NCA portal
Each EU member state's NCA operates its own submission portal. The portal requires registration, and submissions are made by authorised users whose identity is tied to the reporting entity. When you submit, the portal runs its validation sequence — package check, taxonomy conformance, referential integrity, controlled values, and business rules — and returns either a receipt confirmation or a feedback file containing error codes for each failure.
Year-Round Maintenance Obligations
This is the aspect of the RoI that surprises compliance teams most — particularly those who are used to compliance being primarily a point-in-time activity tied to audit cycles. The RoI is not something you build once a year and then archive. It is a living register with continuous maintenance obligations.
Article 28(3) requires financial entities to notify their NCA when material changes occur to ICT arrangements. The ITS specifies timeframes for updating the register following material changes — and "material" is defined more broadly than many compliance teams initially assume. The following events all require register updates:
| Triggering event | Tables affected | Update timeframe |
|---|---|---|
| New ICT third-party contract signed | B01, B02, B03, potentially B04–B14 | As soon as reasonably practicable; before next annual submission at latest |
| Existing contract terminated or renegotiated | B02, plus all downstream tables linked to affected contract | As soon as practicable following effective date |
| ICT provider changes name or is acquired | B01 (and potentially LEI update) | Following notification from provider or public registry update |
| Sub-contractor changes for existing arrangement | B04 | Upon notification from primary provider |
| Internal function classification changes | B06, B07, B08 (and potentially impact on B02, B09) | Following internal assessment completion |
| Data storage location changes | B12 | Upon notification from provider |
The practical implication is that the RoI needs to be owned by someone — or some function — that is plugged into the contract lifecycle management and procurement processes of the organisation year-round. A compliance team that only touches the register once a year will consistently find that it no longer reflects reality by the time submission comes around, and that catching up in the weeks before the deadline is frantic, error-prone, and often incomplete.
Common First-Time Mistakes
Teams building their first Register of Information consistently encounter the same set of structural errors. Here are the most consequential ones, and how to avoid them.
❌
Starting with the ESA Excel template as your system of record
The ESA Excel template is a data collection aid, not a register management system. Its tabs are not linked, its identifiers are not enforced, and it provides no validation against the EBA's rules. Using it as your primary tool for a register of any significant size invites foreign key errors, inconsistent identifiers, and a painful manual conversion process at submission time.
❌
Conflating "vendor" with "ICT third-party service provider"
Your internal vendor list almost certainly contains providers who don't qualify as ICT third-party service providers under DORA's definition — and may be missing some who do. DORA focuses specifically on ICT services: IT infrastructure, software, data and analytics services, and similar. Office supplies, cleaning contractors, and professional advisory services are not ICT providers. Mapping from your vendor register without applying DORA's specific criteria leads to either over-scoping (unnecessary work) or under-scoping (incomplete submission).
❌
Leaving Table B04 (sub-outsourcing) nearly empty
The vast majority of cloud providers, software vendors, and managed service providers rely on sub-contractors for at least some of their delivery — data centres, network providers, sub-processors. An empty or near-empty B04 table will draw NCA scrutiny because it is implausible for any organisation with more than a handful of ICT providers. Start gathering sub-outsourcing information from providers early, and make your right to this data explicit in new and renegotiated contracts.
❌
Treating the criticality assessment as a binary tick-box exercise
Classifying functions as critical or non-critical without a documented, methodical assessment process is a governance gap in itself — separate from whatever you put in the register. Regulators will ask how you made the determination. If the answer is "we looked at the list and used our judgement," that is unlikely to satisfy a supervisory review. The assessment should be documented, consistent, and tied to a defined methodology that references DORA's criteria.
❌
Not checking the taxonomy version before exporting
The DORA xBRL taxonomy is versioned, and the ESAs have published updates since the initial release. Submitting a package built against an older taxonomy version causes validation failures that can be difficult to diagnose. Always confirm which taxonomy version your NCA portal is currently accepting — and check for updates in the weeks before your submission date.
Tools and Approaches
There are three broad approaches organisations take to building and maintaining the Register of Information. Each has a different risk profile, and the right choice depends on the size and complexity of your register.
| Approach | Best suited for | Key risks |
|---|---|---|
| ESA Excel template + manual xBRL-CSV conversion | Entities with <30 providers and simple structures | Foreign key errors, date format corruption, controlled value typos, no pre-submission validation |
| General GRC platform with DORA framework overlay | Entities with multi-framework compliance needs who can accept manual RoI export workarounds | No native xBRL-CSV export; RoI data model not enforced; ICT-specific structure requires manual recreation |
| Purpose-built DORA RoI platform | Any entity with 30+ providers, multi-entity structure, or prior submission rejections | Vendor selection and onboarding time; integration with existing vendor data sources |
The case for a purpose-built platform becomes compelling quickly once you move beyond a small, simple register. The specific features that matter most for the RoI are: enforced referential integrity between tables, automated GLEIF LEI validation, hard constraints on controlled value fields, xBRL-CSV export that runs the 117 EBA validation rules before packaging, and audit trail management for updates made throughout the year. These aren't nice-to-haves — they're the capabilities that distinguish a register built for submission from a register that looks complete until the NCA portal tells you otherwise.
Build your Register of Information on a data model that won't break.
Venvera's RoI module enforces the relational structure, validates against all 117 EBA rules before export, and produces a submission-ready xBRL-CSV package directly — no Excel, no manual conversion, no resubmission loops.
See Venvera in action → Venvera.comFrequently Asked Questions
How often does the DORA Register of Information need to be submitted?
The RoI is submitted annually, with the reference date being 31 December of the prior reporting year. NCAs may set specific submission deadlines — typically in Q1 of the following year — which can vary by jurisdiction and entity type. Check your NCA's published guidance for the exact deadline applicable to you.
Do all 15 tables need to be populated for every submission?
Not all tables apply to all entities in all circumstances. Some tables are only mandatory for specific entity types or where certain conditions are met (for example, B09 exit plans are required only where critical or important functions are involved). However, all required tables must be present in the ZIP even if they contain no data rows — an empty required table file is different from a missing table file, and the latter causes a packaging failure.
What is the difference between a "provider" and a "sub-contractor" in the RoI?
A provider (B01) is an ICT third-party service provider with whom your organisation has a direct contractual relationship. A sub-contractor (B04) is a party that your direct provider uses to deliver part of the service to you — without a direct contractual relationship with your organisation. Both must be documented in the RoI, but they appear in different tables and are captured through different data fields.
What happens if we discover an error in our submitted register after the deadline?
You should contact your NCA and submit a corrected version as soon as possible. DORA's requirement is for an accurate, up-to-date register — submitting an incorrect version and leaving it uncorrected is a worse outcome than submitting a correction after the fact. NCAs generally prefer entities that proactively identify and correct errors over those that allow inaccurate data to stand.
Does the DORA Register of Information replace any existing reporting obligations?
The RoI is specific to DORA and does not replace reporting obligations under other regulatory frameworks. However, the data gathered for the RoI often overlaps with data needed for other purposes — vendor risk assessments, GDPR data mapping, outsourcing notifications, and business continuity documentation. Organisations that build the RoI properly find that it becomes a valuable data asset for these adjacent obligations, not just a standalone submission exercise.
Written by the Venvera compliance team. Venvera is a purpose-built DORA compliance platform for European financial entities. Last updated: February 2026.
