Building your DORA Register of Information
The build sequence these templates are populated in.
Read the guide →
Resource center · Operational Resilience
Register of Information template overview.
Fifteen templates in eight groups, joined by keys. This is the reference sheet: what each template holds, and which other templates depend on it.
The eight groups
The templates cluster into eight subject groups: entity information; contractual arrangements; the entities and providers signing them; the entities using the services; ICT third-party providers and their supply chains; functions; assessments of services supporting critical or important functions; and definitions. Reading them as groups rather than as fifteen separate forms is the shift that makes the register tractable.
The fifteen templates
| Reference | Carries |
|---|---|
| B_01.01 | The entity maintaining the register, and the level at which it is maintained. |
| B_01.02 | The entities within the scope of consolidation covered by the register. |
| B_01.03 | Branches of the entities listed in the consolidation template. |
| B_02.01 | Contractual arrangements, general information — each arrangement and its reference number. The central template most others point at. |
| B_02.02 | Contractual arrangements, specific information — the ICT services under each arrangement, the functions they support, terms, notice and applicable law. |
| B_02.03 | Intra-group contractual arrangements, linking arrangements in the same supply chain where intra-group providers are involved. |
| B_03.01 | Financial entities signing the contractual arrangements to receive ICT services. |
| B_03.02 | ICT third-party service providers signing the contractual arrangements to provide the services. |
| B_03.03 | Entities signing on behalf of the entities that make use of the services. |
| B_04.01 | The entities and branches actually making use of the ICT services. |
| B_05.01 | ICT third-party service providers and their identification codes. |
| B_05.02 | ICT service supply chains, including the rank of each participant. |
| B_06.01 | Functions, with their criticality determination. |
| B_07.01 | Assessments of the ICT services supporting critical or important functions. |
| B_99.01 | Definitions used across the register. |
How they reference each other
The relationships are what make this a model rather than a workbook. Three carry most of the weight:
- The arrangement reference allocated in the general arrangement template is quoted by the specific-information, intra-group, signatory and usage templates. It is the closest thing the register has to a spine.
- The provider identification code allocated in the provider template is quoted wherever a provider appears, including in the supply chain.
- The function identifier allocated in the function template is quoted by the specific-information template and by the assessment template.
One value, one place. Where more than one value is valid for a data element, the completion instructions require an additional row rather than a combined value — and the added rows must not duplicate key values. That rule generates more validation findings than any other.
Reading this as a build order
The Annex sequence is not the efficient population order, because later templates define keys that earlier ones need. Working outwards from the stable data instead: entities and perimeter, then functions and criticality, then arrangements, then providers, then services, then the supply chain, then assessments and the mapping rows that join services to functions.
Using this reference safely
This sheet is an orientation aid. Three cautions apply to any use of it.
- Field-level detail lives in the Annex. Column references, data types and closed lists are specified there, and they are what the validator applies.
- Naming varies by package. The B_ references are the Annex I convention; supervisory taxonomy and submission packages may present the same templates under a different prefix. Match on content, not on the label.
- Framework versions move. Confirm the template set and the data model against the release your competent authority is collecting for the reference date in question.
Official sources
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
- Commission Implementing Regulation (EU) 2024/2956 laying down implementing technical standards with regard to standard templates for the register of information, Annexes I to IVEUR-Lex · Implementing Regulation · the templates and completion instructions
- Regulation (EU) 2022/2554 (DORA), Article 28(3)EUR-Lex · Regulation · the register obligation
- European Banking Authority — data model for registers of information and the reporting technical packageEBA · column references, data types and closed lists · consult the current release
REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.
Keep reading
More on this framework, and the module that produces the filing.
Mapping entities, contracts and providers to the templates
Turning source systems into linked template rows.
Read the guide →DORA Register of Information module
Assemble, validate and export the report package.
See the module →Fifteen templates, one dataset.
Load entities, contracts and providers once and let the module hold the references between them.