Learn
📋 What this article covers: What the Register of Information actually is and isn't, who has to build and submit one, a table-by-table breakdown of the data model and how the tables connect to each other, what the submission process looks like from start to finish, and the maintenance obligations that start the day after your first submission goes in.
There is no single document from the EBA, ESMA, or EIOPA that explains everything you need to know about the DORA Register of Information in one place. The requirements are spread across the regulation text, the Joint Technical Standards, the ITS on registers of information, the xBRL taxonomy documentation, NCA-specific portal guidance, and a series of published Q&As that have clarified things the original texts left ambiguous.
This article pulls it together. By the end you will understand what the Register of Information is, why each of its 15 tables exists, how they relate to each other, what you need to do to submit it, and what ongoing obligations kick in once your first submission is behind you. Not just enough to fill in a template — enough to understand why each field exists and where the structural traps are for teams building it 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 annually to your NCA in xBRL-CSV format. It is not a vendor list, not a risk register, and not a compliance 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 the Register of Information Actually Is
The Register of Information (RoI) is defined under Article 28(3) of DORA, with detailed technical specifications set out in the Implementing Technical Standards on registers of information published jointly by the EBA, ESMA, and EIOPA. At its core, it 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 purposes: to understand systemic concentration risk across the financial sector (if one cloud provider fails, which institutions are exposed and how severely?), and to assess whether individual institutions have adequate visibility and governance over their ICT dependencies.
Understanding what it is not matters just as much. The RoI is not a vendor risk register — it does not capture risk scores or mitigation measures for each provider. It is not a contract management system — it captures structured fields about contracts, not the contract documents themselves. It is not a compliance control framework — it does not track whether you have implemented ICT security controls. And it is not a one-time artifact — it is a live register that must be maintained continuously and updated within defined timeframes whenever something material changes.
⚠️ The most common misconception
Many compliance teams approach the RoI as an extension of their existing vendor management programme — essentially a structured export of their vendor register. This causes problems. The RoI has a specific relational data model with mandatory fields and inter-table dependencies that do not map neatly onto vendor lists built for internal risk management. Building it correctly requires starting from the DORA data model, not from your existing vendor data.
Who Must Build and Submit One
Article 28(3) of DORA requires all financial entities within scope of the regulation to maintain and submit a Register of Information. The in-scope entity types defined in Article 2(1) include credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, statutory auditors, and 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, but the RoI obligation is not an area where micro-enterprise status provides full exemption. Check the ESA's proportionality guidance for your entity type.
Individual, sub-consolidated, and consolidated submissions
For financial groups, the ITS specifies three submission levels. Determining which applies to your structure is essential before you start building — it determines the scope of data you need to collect and how entities within the group relate to each other in the data model.
| Level | Who submits | What it covers | Key consideration |
|---|---|---|---|
| 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 all entities in the sub-group | Data must be aggregated across all subsidiaries in scope; requires shared ID conventions across entities |
| Consolidated | Ultimate EU parent undertaking | All in-scope entities across the group | Most complex; each entity's B00 record must identify its role in the group structure; group-wide data harmonisation required |
The 15 Tables and How They Connect
The RoI data model is the part most guides explain least well. Understanding not just what each table contains but how the tables relate to each other is what separates teams who build it correctly the first time from teams who spend months in a resubmission loop.
Think of the model as a set of concentric rings. At the centre is your organisation and its critical internal functions. Moving outward, you document the ICT services that support those functions, the contracts governing those services, the providers who deliver them, and the sub-contractors those providers rely on in turn.
The 15 RoI tables
B00
Reporting entity — The financial entity or group submitting the register. Establishes the identity anchor for all other tables.
B01
ICT third-party service providers — Master list of all external ICT providers including legal entity name, LEI, and country of establishment. Every provider referenced anywhere in the register must have a record here.
B02
Contractual arrangements — One record per contract. 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. One contract can cover multiple services. Each service links to its contract (B02), its provider (B01), and the internal functions it supports (B06).
B04
Sub-contracted ICT services — ICT services your primary provider sub-contracts to third parties. Captures sub-contractor identity and the services affected. The most commonly incomplete table in first submissions.
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 system type and hosting arrangement.
B06
Functions — critical or important — Internal business functions of your organisation 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 depend on multiple services.
B08
Impact assessment — ICT services — Assessment of the impact of a disruption to each ICT service, including recovery time and recovery point objectives. Particularly important for services supporting critical or important functions.
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 of ICT third-party arrangements, including audit dates, scope, and findings status.
B12
Data storage location — Where data associated with ICT services is stored and processed — including country, data centre type, and whether storage is within or outside the EU.
B13
Sensitive functions assessment — Assessment of whether 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
Your reporting entity (B00) has internal functions (B06). Those functions are supported by ICT services (B03), 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), their data handling is documented (B12, B13), and performance is tracked over time (B14).
Every foreign key relationship in this chain must be intact. 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. This is the most common cause of rejection and the one Excel hides most effectively.
Critical Functions, Sub-Outsourcing, and the Provider Chain
Three concepts in the RoI data model deserve extra attention because they are 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
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 — as defined in Article 3(22) and the EBA guidelines on outsourcing. Your organisation must make and document a formal assessment of each business function against these criteria. Table B06 records the outcome.
Common errors include applying the label too narrowly (understating your ICT dependency, which regulators will question), applying it too broadly (over-classifying and creating unnecessary scope), or failing to document the assessment methodology — which supervisors will ask to see. The criticality designation also drives obligations in B08 (impact assessment), B09 (exit plans), B10 (Article 30 contract provisions), and determines which providers may be subject to the oversight framework for critical ICT third-party providers.
Sub-outsourcing chains
Article 28(2) requires financial entities to identify and document sub-outsourcing arrangements — 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.
B04 is almost universally the most incomplete table in first submissions, for an obvious reason: gathering sub-outsourcing data requires your direct providers to disclose information about their supply chains. You have a contractual right to this information under Article 30(2)(h), but exercising that right takes time and sometimes produces friction. Starting this data collection six months before your first submission is strongly advisable.
The provider-to-function traceability requirement
The most important structural concept in the RoI is that every ICT arrangement must be traceable from provider all the way through 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. A chain that is broken anywhere in your data fails the register's purpose even if it passes technical validation.
The Submission Process
Format requirements
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. There is no provision for submitting in Excel, PDF, or any other format. NCA portals only accept the xBRL-CSV ZIP.
This is one of the most impactful practical requirements of DORA. Organisations maintaining their register in Excel must go through a conversion and validation process that introduces significant risk of error at the export stage — date format corruption, character encoding issues, controlled value failures, and broken identifier links that were invisible in the spreadsheet but fatal in the submitted file.
Deadlines
The annual submission deadline varies by NCA. Most 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 deadline applicable to your entity type.
The operational implication is that you cannot start building the register in January for a March deadline if your data collection processes are not already running. 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 scrambling for extensions.
What happens at the NCA portal
When you submit, the portal runs a multi-stage validation sequence: package structure check, taxonomy conformance check, referential integrity check, controlled value validation, and 117 EBA business rules. Failure at any stage produces a rejection and a feedback file containing cryptic rule codes for each error. The portal returns either a receipt confirmation or errors — there is no partial acceptance.
Ongoing Maintenance Obligations
This is the aspect that surprises compliance teams most. The RoI is not something you build once a year and archive. Article 28(3) requires financial entities to notify their NCA when material changes occur to ICT arrangements, and the ITS specifies timeframes for updating the register following those changes. The following events all require register updates.
| Triggering event | Tables affected | Timing |
|---|---|---|
| New ICT third-party contract signed | B01, B02, B03 — potentially B04–B14 | As soon as reasonably practicable |
| Existing contract terminated or renegotiated | B02 plus all downstream tables | Following the effective date |
| Provider changes name or is acquired | B01 and potentially LEI update | On notification or public registry update |
| Sub-contractor changes for existing arrangement | B04 | On notification from primary provider |
| Internal function classification changes | B06, B07, B08, B09 | Following internal assessment completion |
| Data storage location changes | B12 | On notification from provider |
The practical implication: the RoI needs to be owned by someone who is plugged into the contract lifecycle and procurement processes year-round, not just at submission time. A compliance team that only touches the register once a year will consistently find it no longer reflects reality by the time the filing deadline arrives.
First-Time Mistakes to Avoid
❌
Using 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 has no validation against EBA rules. For any register of meaningful size, it is a reliable source of the exact errors that cause submission rejections.
❌
Treating your existing vendor list as the starting point
Your internal vendor register almost certainly contains providers who don't qualify as ICT third-party service providers under DORA and may be missing some who do. DORA focuses on ICT services specifically. Mapping from a vendor list without applying DORA's criteria leads to over-scoping or under-scoping — both of which create problems.
❌
Leaving Table B04 nearly empty
Almost every cloud provider, software vendor, and managed service provider relies on sub-contractors for at least some of their delivery. An empty B04 table draws NCA scrutiny because it is implausible for any organisation with more than a handful of ICT providers.
❌
Treating criticality assessment as a tick-box exercise
Classifying functions without a documented, methodical assessment tied to DORA's criteria is a governance gap in itself. Regulators will ask how you made each determination. "We reviewed the list and used our judgment" is not a sufficient answer during supervisory review.
❌
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 version causes validation failures that are difficult to diagnose. Always confirm which taxonomy version your NCA portal is accepting before you export — and check for updates in the weeks before your submission date.
Build your Register of Information on a data model that won't break.
Venvera 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 of 31 December of the prior reporting year. NCAs 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 in all circumstances — some are only mandatory where specific conditions are met, such as B09 exit plans which apply 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. A missing required table file causes a packaging failure distinct from an empty data file.
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 — without a direct contractual relationship with your organisation. Both must be documented, but they appear in different tables and are captured through different fields.
What happens if we find an error in our submitted register after the deadline?
Contact your NCA and submit a corrected version as soon as possible. Submitting an incorrect version and leaving it uncorrected is a worse outcome than proactively correcting it after the fact. NCAs generally respond better to entities that identify and correct errors than 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 obligations under other frameworks. However, data gathered for the RoI often overlaps with what is needed for vendor risk assessments, GDPR data mapping, outsourcing notifications, and business continuity documentation. Organisations that build the RoI properly find it becomes a useful data asset for these adjacent purposes rather than a purely 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.
