A practical field guide for building the DORA register of information around the Commission's standard templates for ICT third-party contractual arrangements.
Use it to check entity, provider, service, function, contract, subcontracting, criticality, date, data-quality, and submission-evidence fields before a supervisory request or register export.
Structured answer sets in this page tree.
Cited legal and guidance references.
The DORA register of information is not a free-form outsourcing inventory. Implementing Regulation (EU) 2024/2956 sets standard templates that financial entities use to maintain and update information about contractual arrangements for ICT services provided by ICT third-party service providers. The data model works only when contract references, entity identifiers, provider identifiers, function identifiers, ICT service types, and subcontractor ranks reconcile across the templates.
Build the register as linked tables, not as one flat supplier list. The standard templates separate the entity scope, contractual arrangements, contract signatories, entities using the ICT services, ICT third-party providers, ICT service supply chains, functions, and assessments for ICT services that support critical or important functions.
The four practical join keys are the contractual arrangement reference number, the entity and provider identifiers, the function identifier, and the type of ICT services. If those keys are not stable and reused consistently, the register will not reconcile at entity, sub-consolidated, or consolidated level.
The register should distinguish the entity maintaining the register, the financial entity or branch making use of the ICT service, the undertaking that signs the contract, the direct ICT third-party provider, any intra-group ICT provider, and subcontractors in the same ICT service supply chain. Those are different roles and can be different legal entities in a group.
Provider records should not rely on informal supplier names. Legal-person ICT third-party providers use a valid and active LEI or EUID where allowed by the ITS, with LEI required for legal persons established outside the Union. Natural persons acting in a business capacity can use the alternative identifier options described in the template instructions.
The register needs more than a yes/no label for critical or important functions. Template B_06.01 captures whether the function is critical or important, the reason where provided, the date of the last assessment, recovery time objective, recovery point objective, and impact of discontinuing the function.
Template B_07.01 then connects the relevant ICT service and provider to substitutability, audit, exit, reintegration, discontinuation-impact, and alternative-provider fields. This is where the register becomes evidence for concentration risk, exit planning, and supervisory review.
Contract records should be granular enough to separate a master arrangement from subsequent or associated arrangements and to avoid double-counting costs. B_02.02 then repeats the contract reference at service/function level, so one contract covering multiple ICT services and functions produces multiple rows.
For subcontracting, B_05.02 models the ICT service supply chain with rank. The direct ICT third-party provider is rank 1; subcontractors have ranks higher than 1. For every subcontractor row, the register identifies the provider that receives the subcontracted ICT service at the previous rank.
The ITS requires the register information to be accurate and consistent, and it lists data-quality principles including validity. Treat validation as part of register maintenance, not as a clean-up step immediately before submission.
Useful export evidence shows that the register can be reproduced from source systems and that each exported row traces back to a contract, provider identifier, function owner, service owner, criticality assessment, subcontractor record, and approval or correction history.
At minimum, model the DORA register as linked template tables for entities, branches, contractual arrangements, signatories, entities using ICT services, ICT third-party providers, ICT service supply chains, functions, and critical-function service assessments. The join keys are the contractual arrangement reference number, entity and provider identifiers, function identifier, and ICT service type.
For legal-person ICT third-party providers, the ITS points to LEI and EUID where available and requires LEI for legal persons established outside the Union. Alternative code types are reserved for individuals acting in a business capacity under the template instructions.
The register needs subcontractor rows for ICT services supporting critical or important functions or material parts where those subcontractors effectively underpin the service, including subcontractors whose disruption would impair service security or continuity. The supply-chain template records rank 1 for the direct provider and higher ranks for subcontractors.
Sorena can help map DORA register templates to contract, procurement, risk, and service-owner data so exports preserve identifiers, subcontracting chains, critical-function assessments, and evidence history.
Ask source-linked questions about DORA register fields, template joins, identifiers, subcontracting chains, and export evidence using the cited sources on this page.
Walk through register template coverage, data-quality checks, provider identifiers, and critical-function evidence before a supervisory request.
"material changes to subcontracting arrangements"
"accurate and consistent"
"Key contractual provisions"