EU DORA Register of Information Data Model

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. Each data element accepts one value; repeat the row when more than one value is valid instead of storing a list in one cell.

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.