Template GuideEU

EU DORA RoI Template Guide

Implement the ITS annex templates as a relational schema with stable identifiers and fast exports.

Grounded in Implementing Regulation (EU) 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

Implementing Regulation (EU) 2024/2956 defines standard templates for the DORA register of information and describes a relational structure that links open tables via specific keys (contract reference numbers, function identifiers, LEIs, provider identifiers). The fastest path to compliance is to treat the annex templates as a schema contract: define your identifiers, enforce referential integrity, and generate exports automatically - so you can produce supervisor-ready templates on demand.

Section 1

What the ITS templates are for (and why they're relational)

The ITS templates enable consistent understanding of ICT dependencies across firms and groups, and they support effective supervision and oversight of critical ICT third-party providers.

The ITS uses open tables (fixed columns, unlimited rows) and explicit relational keys to avoid ambiguous, non-comparable narrative registers.

Build once, export many: a governed dataset + exporter beats manual spreadsheet updates.
Identifier discipline is non-negotiable: contract reference numbers and function IDs must be stable and consistent.
Data quality is part of compliance: accuracy, consistency, regular review, and prompt error correction are explicit expectations.

Recommended next step

Keep EU DORA RoI Template Guide in one governed evidence system

SSOT can take EU DORA RoI Template Guide 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 RoI Template Guide

Start from EU DORA RoI Template Guide 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 RoI Template Guide.

Explore next step

Section 2

Template map (B_01-B_07) - a workable mental model

The annex templates cover: reporting perimeter, contractual arrangements, signatories, providers, usage, supply chain, functions, and criticality assessment.

Treat templates as views over one normalized model; avoid duplicating the same facts across multiple tables.

B_01.*: reporting perimeter (entity, consolidation, branches outside home country).
B_02.*: contractual arrangements (general + specific details + intra-group reconciliation where applicable).
B_03.*: parties who sign (contracting entities, direct ICT provider signatories, intra-group signatories).
B_04.*: entities using ICT services (consumption mapping).
B_05.*: providers + subcontractors and ICT service supply chain links.
B_06.*: function identification catalog (function IDs and descriptions).
B_07.*: assessment of ICT services supporting critical/important functions (or material parts thereof).

Section 3

Relational keys (define these first or exports will never reconcile)

The ITS stresses identifier consistency (contract reference numbers, function identifiers, LEIs/provider identifiers) to ensure operability and comparability.

Define these centrally, make them immutable, and validate them before every export.

Contractual arrangement reference number: immutable primary key for contractual arrangements (join backbone).
Function identifier: stable function catalog used for critical/important mapping and cross-template joins.
LEI/EUID: use valid and active LEIs where required; capture EUID where applicable and normalize provider identities.
Supply chain linkage keys: represent direct providers, intra-group providers, and external subcontractors consistently.

Section 4

Data quality rules (make "export-ready" a measurable state)

Export readiness is not a feeling - it's a set of checks. Build a validation layer that blocks exports when joins or required fields fail.

This turns RoI maintenance into a continuous-control process rather than a yearly scramble.

Completeness: required fields present for all contracts supporting critical/important functions and their underpinning supply chain.
Referential integrity: every foreign key resolves (contract->provider, contract->users, service->function, service->subcontractors).
Uniqueness: no duplicated/reused contract reference numbers, function IDs, or provider IDs across the reporting perimeter.
Consistency across levels: entity vs consolidated exports reconcile without conflicting identifiers.
Review cadence: evidence of regular review and prompt correction of discrepancies (audit trail).

Section 5

Why RoI data quality now has direct supervisory consequences

The register of information is not just an internal inventory. The ESAs used RoI data from financial entities as part of the process that led to the first DORA critical ICT third-party provider designations.

That means inconsistent identifiers, missing subcontractors, or weak critical-function mapping do not just create an internal cleanup problem. They affect how supervisors understand concentration and systemic dependency.

The first designated critical ICT third-party provider list was published on 18 November 2025.
Use that milestone as a quality threshold: your RoI should support provider concentration analysis, critical-function mapping, and group-level consistency without manual repair.
If a key provider becomes designated as critical, make sure your RoI, contract posture, monitoring, and exit planning all reconcile to the same provider and contract identifiers.

Section 6

Implementation checklist (fast path)

Use this to implement quickly without building a brittle solution.

Aim for a minimal viable RoI in 2-6 weeks, then iterate for coverage and automation.

Define identifier policy (contract reference numbers, function IDs, provider identity normalization).
Map service catalog -> functions and tag critical/important services (with approvals).
Integrate contract repository + procurement + vendor risk + CMDB/cloud inventory into one model.
Generate B_01-B_07 exports and run validation checks; fix root causes, not export outputs.
Run quarterly RoI drills: produce exports and answer supervisor-style questions from the dataset.

Primary sources

References and citations

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

eur-lex.europa.eu

Referenced sections

Defines Annex templates (B_01-B_07), relational keys, and data quality expectations for maintaining and updating the register.

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

esma.europa.eu

Referenced sections

Shows that RoI data feeds real supervisory decisions on critical ICT third-party provider designations.

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

eur-lex.europa.eu

Referenced sections

Article 28 establishes the register of information obligation and the ability for competent authorities to request the full register or specific sections.

Related guides