Implementation GuideEU

EU DORA Register of Information (RoI)

Build the RoI as a relational dataset you can export on demand - not a spreadsheet nobody trusts.

Grounded in Article 28 and ITS 2024/2956 (standard templates for the register of information).

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA requires financial entities to maintain and update a register of information covering contractual arrangements for ICT services from ICT third-party providers, and to provide the full register or specified sections to competent authorities on request. The simplest way to comply (and stay consistent across entity/sub-consolidated/consolidated levels) is to treat the RoI as a data product: a relational model, governed identifiers, and an automated extraction + validation pipeline that can export ITS templates quickly and accurately.

Section 1

What the RoI is (and what it is not)

The RoI is a supervisory artifact and an internal risk management instrument: a structured view of ICT third-party dependencies, linked to contracts and services.

It's not a procurement vendor list. It's not a one-time spreadsheet. If you can't export it reliably and explain the joins, it won't survive supervision.

Scope: contractual arrangements on the use of ICT services provided by ICT third-party providers (Article 28).
Levels: maintain and update at entity level, and at sub-consolidated and consolidated levels where applicable (Article 28).
On request: be able to provide the full register or specified sections, plus supporting information for effective supervision (Article 28).

Section 2

RoI data model blueprint (contract -> service -> function -> provider -> supply chain)

Implement the RoI as a normalized relational model with stable identifiers and explicit links between contracting entities, ICT services, functions, providers, and subcontractors.

This aligns with the ITS approach: open tables linked by specific keys (contract reference numbers, function identifiers, LEIs/provider identifiers).

Contractual arrangement reference number: define one unique key per contract and never reuse it (your primary join key).
ICT service taxonomy: normalize service names and map each service to business functions and technical dependencies.
Function identifier catalog: define a stable function ID set for critical/important mapping and cross-template joins.
Provider identity normalization: use LEI/EUID where available; standardize naming, group relationships, and service ownership models.
Supply chain representation: model direct providers and relevant subcontractors that effectively underpin ICT services supporting critical/important functions.

Recommended next step

Keep EU DORA Register of Information (RoI) in one governed evidence system

SSOT can take EU DORA Register of Information (RoI) from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Evidence system

Open SSOT for EU DORA Register of Information (RoI)

Start from EU DORA Register of Information (RoI) and keep documents, evidence, and control records in one governed system.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Register of Information (RoI).

Explore next step

Section 3

Extraction pipeline (systems-of-record -> RoI dataset -> ITS export)

The RoI is an integration problem: procurement, vendor risk, CMDB/service catalog, IAM, cloud inventory, and contract repositories each contain part of the truth.

Your target state is export-ready data - not hand-assembled files.

Ingest: contract metadata (legal), vendor + spend (procurement), due diligence (security/vendor risk), service mapping (CMDB/service catalog), locations + hosting (cloud inventory).
Transform: resolve entity/provider identities, enforce stable identifiers, and create relational links (contract->provider, contract->users, service->function, service->subcontractors).
Validate: completeness, uniqueness, and referential integrity checks block exports when critical joins fail.
Export: generate the ITS annex templates (B_01-B_07) from the same dataset so entity vs consolidated views reconcile.

Section 4

Governance + operating cadence (how to keep the RoI accurate)

RoI compliance is a governance discipline: without clear ownership and change controls, it drifts immediately after launch.

Define an operating cadence that makes updates automatic whenever contracts or service dependencies change.

RACI: procurement (vendor onboarding), legal (contract metadata), security (due diligence + monitoring), engineering (service/function mapping), compliance (export readiness).
Change control: provider changes (subcontractors, hosting locations, scope expansions) are treated as material changes and trigger RoI updates.
Quarterly RoI QA: sample critical/important services and verify the full supply chain + exit dependencies are current.
Supervisor readiness drill: timebox an RoI export request and measure speed + consistency across entity and consolidated exports.

Section 5

Common pitfalls (use these as acceptance criteria)

Most RoI failures are predictable: missing keys, inconsistent naming, and invisible subcontracting chains for critical services.

Fix the root causes in your model and pipeline - not in the export file.

No global contract reference key -> joins break across templates and entities.
No service/function mapping -> you can't prove which ICT services support which critical/important functions.
Subcontractors ignored -> supply chain risk and concentration risk are invisible.
Manual exports -> every request becomes a fire drill and produces inconsistent outputs.
Weak validation -> supervisors get different answers depending on who exports the register.

Section 6

Build for actual supervisory use, not just annual maintenance

Supervisors use RoI data to understand concentration risk, critical-function support chains, and reliance on major providers across the sector.

That is why RoI engineering should be treated as production data management, not as a once-a-year compliance exercise.

The first critical ICT third-party provider designation list published on 18 November 2025 shows the RoI now feeds real oversight decisions.
Make provider identity normalization and subcontractor coverage mandatory controls, because those are the records that determine whether systemic dependency is visible.
Run export drills against the ITS structure so entity and consolidated views produce the same provider, contract, and function relationships.

Primary sources

References and citations

Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements RTS

eur-lex.europa.eu

Referenced sections

Due diligence, monitoring, audit/access, and exit planning expectations that should be reflected in RoI fields and evidence links.

Commission Implementing Regulation (EU) 2024/2956 - Standard templates for the register of information (ITS)

eur-lex.europa.eu

Referenced sections

Defines the RoI template structure (Annex templates B_01-B_07), relational keys, and data quality expectations for consistent reporting.

EBA press release - ESAs consult on first batch of DORA policy products

eba.europa.eu

Referenced sections

Regulatory activity context for DORA policy products, including register-of-information templates.

ESMA news - ESAs designate critical ICT third-party providers under DORA

esma.europa.eu

Referenced sections

Confirms that RoI submissions feed real criticality assessments at EU level.

Regulation (EU) 2022/2554 (DORA) - Official Journal

eur-lex.europa.eu

Referenced sections

Article 28 establishes the register of information obligation at entity/sub-consolidated/consolidated levels and requires making it available to competent authorities on request.

Related guides