Most RoI failures only become visible after the register already looks complete.
The DORA Register of Information (RoI) is meant to be a structured, connected view of ICT third-party arrangements. It links providers, services, contracts, business functions, subcontractors, locations, and exit plans into one dataset that supervisors can actually analyse. The ambition is straightforward: make dependency visible across the market.
The requirement itself sits in Regulation (EU) 2022/2554 (DORA) and its implementing standards under Commission Implementing Regulation (EU) 2024/2956.
Who must maintain the RoI (and how it is used)
The register only becomes visible to supervisors once it is submitted, and that is where its real purpose starts to show.
Financial entities across the DORA scope—banks, insurers, investment firms and others—must maintain it, but the obligation is less about who is in scope and more about how the data is used once reported. Submission flows through national competent authorities into European Supervisory Authority (ESA) processes, where the data is analysed across institutions.
Registers can be maintained at entity level or at group level, but that flexibility comes with a constraint: each entity must still meet its own obligations. A shared register does not dilute accountability.
In practice, the operating cadence is straightforward but demanding: firms maintain the register continuously, submit it at least annually to support Critical ICT Third-Party Provider (CTPP) designation, and provide it on request where competent authorities ask for it. Reporting windows themselves are set by each National Competent Authorities (NCA).
Many firms underestimate the requirement at this point. The register is not collected for completeness. It is collected for comparison.
Copla Registry
DORA-ready Register of Information
Maintaining a complete RoI across providers, services, contracts, and subcontractors becomes difficult in spreadsheets.
Copla Registry provides a structured environment built for DORA supervision and RoI reporting.
- Maintain connected records across providers, services, contracts, and subcontractors
- Track ICT service supply chains and critical function dependencies in one place
- Generate regulator-ready RoI reporting outputs when requested
What must be included in the RoI
The pressure sits in how each contract is represented across the record.
Every arrangement needs to connect to the ICT service it delivers, the business function it supports (including critical and important function mapping), the locations where the service runs, and the subcontractors involved in delivery. The full structure is laid out in the detailed RoI field requirements by category.
Beyond that core chain, the record also extends into how the service is controlled and overseen—covering areas such as risk controls, continuity arrangements, auditability, and how changes are tracked over time.
RoI scope: the “critical vendor” filter mistake
A common starting point is to take the outsourcing register, filter for critical vendors, and expand from there.
That approach breaks almost immediately.
The implementing standards require coverage of all ICT services provided by direct ICT third-party providers—not just the critical ones. Subcontractor detail becomes mandatory where those providers support critical or important functions.
The March 2025 FAQ reinforces this further. In intra-group setups, firms must show how internal arrangements connect to external providers in the chain, including key subcontractors where relevant.
This is where the work shifts from mapping to restructuring. Translating outsourcing register logic into RoI relationships is rarely clean.
Many institutions end up rethinking their data setup entirely, which is why multi-register architecture across related datasets becomes the practical direction.
The supervisory point is dependency visibility
Supervisors are not interested in the register as a document. They use it to understand how firms depend on external technology.
That same structure has internal value if it is built properly. Incident response becomes faster because dependencies are already mapped. Contract reviews stop relying on scattered documents. Board-level discussions become more grounded in actual exposure.
There is also a second layer to this. Institutions that get the structure right can use the same data for concentration risk analysis, while supervisors use it to inform CTPP supervision at sector level.
Broken identifiers break traceability
The RoI only works if identifiers stay consistent.
Provider IDs, service IDs, contract references—these are what hold the dataset together. When they drift across systems, the links break. The record may still look complete, but it no longer reconciles.
That is usually when teams realise they need to understand how the RoI data model connects in practice.
Illustrative scenario
When an amendment breaks the dependency picture
A bank records a cloud-based document platform used in lending. The initial entry is clean: one provider, one contract, one service, one function.
Months later, the service changes. Part of the delivery is moved to another provider in a different jurisdiction.
Nothing disappears from the register. The contract is still there. The service is still there.
What has changed is the dependency chain.
If the update does not capture that change properly, the register continues to show the old structure. The error is not visible in any single field. It sits in the relationships.
Ownership decides whether the record survives change
RoI data is spread across procurement, IT, risk, legal, and vendor management, and each function controls a different part of the same record.
| Data element | Primary owner | Typical trigger |
|---|---|---|
| Contract reference and signer data | Procurement / Legal | New contract, amendment, renewal |
| Service description and service type | IT / Service management | Scope or architecture change |
| Function identifier and criticality mapping | Risk / Business continuity | Reassessment or operating model change |
| Subcontractor chain | Vendor management / Procurement | Notification or due diligence update |
| Location data | IT / Vendor management | Hosting move or new processing site |
| Exit and termination evidence | Legal / Risk / Procurement | Renewal, remediation, exit review |
If ownership and triggers are not clearly defined, updates stall. The register remains in place, but it no longer reflects the underlying arrangements.
Why manual control fails once the RoI becomes relational
Manual approaches tend to hold while the dataset is small. They start to struggle once multiple linked updates arrive across functions.
Reconciliation becomes the main workload, with repeated cross-checking across contracts, services, and subcontractors. This is where Excel-based RoI project failure under change pressure becomes visible.
At that point, the discussion usually shifts toward automation. Evaluating automation versus manual maintenance becomes unavoidable.
Move beyond spreadsheets for DORA RoI
Spreadsheets struggle with the RoI’s relational structure and validation rules. Copla Registry provides a structured environment for maintaining the register and generating ESA-ready outputs.
Subcontractors are not just a GDPR mapping issue
A lot of firms start with GDPR sub-processor lists.
That is not enough.
DORA focuses on service delivery dependency. The question is who delivers the service and how that delivery is structured, not just who processes data.
This is where tracking the full subcontractor chain becomes more complex than expected.
Maintain versus report (and what “submission-ready” means)
Maintaining the register is continuous. Reporting is periodic.
For the first reporting cycle in 2025, the EBA DORA RoI reporting FAQ (March 2025) confirms that RoI submissions use CSV format.
Annual submissions support the designation of critical providers, while competent authorities may also request the register on an ad hoc basis.
Templates show the record. The underlying data model defines how elements connect. The taxonomy governs how the data is structured for submission. Validation rules then check whether that submission meets technical and consistency requirements. The distinction is explained in the difference between the DORA taxonomy and the underlying data model.
Validation rules do not fix underlying issues. They only test what is submitted.
“Submission-ready” therefore means something more demanding. The dataset must pass validation, be reproducible, and survive corrections without breaking internally. That is the reason why real-world RoI implementation timelines often exceed expectations, and why preparing RoI data for xBRL-CSV submission is not just a formatting step.
Exit evidence becomes visible late
Exit planning tends to sit in the background until something forces attention.
A renewal, a remediation effort, or a supplier issue usually brings it forward. At that point, termination rights, substitutability, and exit feasibility are no longer theoretical.
They are tested, and this is where RoI exit strategy requirements start to matter in practical terms.
What supervisors tend to test first
Supervisors do not need to search long for weaknesses.
They typically focus on:
- identifier consistency
- completeness of relationships
- subcontractor and location accuracy
- evidence that updates are actually applied
Across institutions, what regulators tend to check first in the RoI converges quickly.
The ESAs DORA dry-run summary report highlights that only 6.5% of registers passed all checks.
RoI is also a governance test
A working register needs full scope, current data, connected records, consistent classification, clear ownership, and the ability to answer basic questions quickly under pressure—who provides the service, where it runs, what it supports, and what happens if it fails.
Each of those depends on how data is governed across the organisation.
Seen this way, understanding RoI as a data governance maturity test exposes whether ownership models and data standards hold up when the organisation changes.
What matters before the next reporting window
The main risk is not missing data at the start. It is data drift over time.
Firms that hold up under scrutiny tend to do three things consistently: define the scope correctly, design identifiers and relationships so the dataset stays coherent, and build change capture into day-to-day processes rather than treating the register as a periodic exercise.
Copla Registry
Maintain a living DORA Register of Information
Keeping the RoI accurate requires coordination across teams as contracts and services change. Copla Registry helps maintain a structured, continuously updated RoI dataset.
- Link providers, services, contracts, functions, subcontractors, and locations
- Maintain a continuously updated RoI dataset across teams
- Generate supervisory reporting outputs when required
FAQ
-
How do RoI records link together (provider, service, contract, function)?
-
What’s the difference between the data model and the reporting format?
-
What changes should trigger an RoI update?
