---
name: "DORA Register of Information Starter"
version: "1.0"
updated: "2026-07-16"
source: "https://www.orbiqhq.com/templates/dora-register-of-information-starter"
license: "Free to use and adapt within your organisation. Attribution appreciated. Not legal advice."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Regulation (EU) 2022/2554 (Art. 28(3))
  - "https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj"     # ITS — Register of Information standard templates
---

# DORA Register of Information Starter (machine-readable template)

Purpose: maintain a human-readable working Register of Information under DORA Article 28(3),
structured to map onto the ESAs' official Register of Information templates (Commission
Implementing Regulation (EU) 2024/2956 — 15 templates in 8 groups, linked by relational keys).
This file is self-contained: an agent can construct and maintain a complete working register
from the definitions below, then hand structured records to an xBRL-CSV conversion step at
reporting time.

CRITICAL SCOPE NOTE — working layer, not submission file: the ESAs state they cannot provide
an Excel that would pass submission validation ("not the least due to the limitations of
Excel" — EBA DORA RoI reporting FAQ, updated 2025-03-28). Official submission is a plain-CSV /
xBRL-CSV (OIM-CSV) ZIP package built on the ESA taxonomy and data point model, filed through
the national competent authority's portal. Everything below is the layer you maintain BETWEEN
submissions.

Reporting calendar (from 2026): reference date = 31 December of the preceding year; entities
file to their NCA in a nationally-set Q1 window (2026 examples: DNB by 20 March; Central Bank
of Ireland 1–31 March; CSSF eDesk open from 11 February); NCAs forward consolidated registers
to the ESAs by 31 March each calendar year. There is no single universal EU deadline for firms.

EEA note: DORA applies in Norway via the EEA Agreement; the Norwegian DORA Act has been in
force since 2025-07-01 with Finanstilsynet as competent authority. The UK has no register
regime (FCA/PRA operational resilience: internal mapping, no RoI submission).

---

## 1. Entity & Group — maps to template group B_01

One record per legal entity or branch in scope of the register.

| # | Field | Type | Definition / rule | RoI anchor |
|---|---|---|---|---|
| 1 | `entity_legal_name` | text | Registered legal name | B_01.01–B_01.03 |
| 2 | `entity_lei` | text (LEI-20) | Mandatory for financial entities; branches are identified via their head office | B_01.01 |
| 3 | `register_role` | enum: `register_maintainer` / `group_entity_in_scope` / `branch` | The register is maintained at entity, sub-consolidated and consolidated level (Art. 28(3)) | B_01.01–B_01.03 |
| 4 | `country` | ISO 3166-1 alpha-2 | Country of establishment | B_01 |
| 5 | `entity_type` | text | Type of financial entity per DORA Art. 2 (credit institution, payment institution, etc.) | B_01.02 |
| 6 | `parent_lei` | text (LEI-20) | Direct or ultimate parent within the scope of consolidation | B_01.02 |
| 7 | `competent_authority` | text | NCA supervising the entity (BaFin, DNB, CBI, Finanstilsynet, …) | B_01.01 |
| 8 | `last_updated` | date (ISO 8601) | Register-record maintenance date | Art. 28(3) |

## 2. Contractual Arrangements — maps to template group B_02

One record per contractual arrangement on the use of ICT services — ALL arrangements,
not only cloud and not only critical (Art. 28(3)).

| # | Field | Type | Definition / rule | RoI anchor |
|---|---|---|---|---|
| 1 | `contract_ref` | text, unique | Contractual arrangement reference number — the PRIMARY RELATIONAL KEY joining every other section | B_02.01 |
| 2 | `arrangement_type` | enum: `standalone` / `overarching_master` / `subsequent_under_master` / `intra_group` | Nature of the arrangement | B_02.01 |
| 3 | `master_ref` | text | Reference of the overarching arrangement, if subsequent | B_02.01 |
| 4 | `provider_legal_name` | text | Must exist in section 3 (ICT Providers) | B_02 → B_05.01 |
| 5 | `ict_service_type` | enum `S01`–`S19` (closed list, see section 7) | Only the S-code identifiers are valid — no free text | B_02.02, Annex III |
| 6 | `service_description` | text | Complete description of the ICT service | Art. 30(2)(a) |
| 7 | `contract_start` | date (ISO 8601) | Start date | B_02.02 |
| 8 | `contract_end` | date or `indefinite` | End date | B_02.02 |
| 9 | `notice_period_entity` | integer (days) | Entity's termination notice period | B_02.02 |
| 10 | `notice_period_provider` | integer (days) | Provider's termination notice period | B_02.02 |
| 11 | `governing_law` | ISO 3166-1 alpha-2 | Country of the governing law | B_02.02 |
| 12 | `annual_expense_eur` | number, plain | Annual expense/estimated cost; no separators or symbols | B_02.01 |
| 13 | `supports_cif` | enum: `yes` / `no` / `under_assessment` | Whether the service supports a critical or important function (Art. 28(2), Art. 3(22)) | B_02.02 |
| 14 | `function_ids` | list of `function_id` | Functions supported; must exist in section 6 | B_02 → B_06.01 |
| 15 | `data_storage` | boolean | Whether the service involves storage of data | B_02.02 |
| 16 | `data_locations_storage` | list of ISO country codes | Where data is stored | B_02.02 |
| 17 | `data_locations_processing` | list of ISO country codes | Where data is processed / service managed from | B_02.02 |
| 18 | `data_sensitiveness` | enum: `low` / `medium` / `high` | Sensitiveness of the data held | B_02.02 |
| 19 | `last_reviewed` | date (ISO 8601) | Record review date | Art. 28(3) |

## 3. ICT Third-Party Providers — maps to template B_05.01

One record per provider (deduplicated across arrangements).

| # | Field | Type | Definition / rule | RoI anchor |
|---|---|---|---|---|
| 1 | `provider_legal_name` | text | Registered legal name | B_05.01 |
| 2 | `provider_id_type` | enum: `LEI` / `EUID` / `CC_CRN` / `CC_VAT` / `CC_PNR` / `CC_NIN` | ID-type rules: EU legal persons → LEI or EUID; third-country legal persons → LEI only; natural persons in business capacity → country code + CRN/VAT/PNR/NIN | B_05.01 |
| 3 | `provider_id` | text | The identifier itself; LEIs must be 20 uppercase alphanumeric characters and not lapsed (validate against GLEIF) | B_05.01 |
| 4 | `provider_country` | ISO 3166-1 alpha-2 | Country of establishment | B_05.01 |
| 5 | `person_type` | enum: `legal_person` / `natural_person` | — | B_05.01 |
| 6 | `ultimate_parent` | text | Ultimate parent undertaking | B_05.01 |
| 7 | `intra_group` | boolean | Provider belongs to the same group | B_05.01 |
| 8 | `ctpp_designated` | boolean | On the ESAs' designated critical ICT third-party provider list (first designations 2025-11-18) | ESAs CTPP list |
| 9 | `total_annual_expense_eur` | number | Aggregate across arrangements | B_05.01 |

## 4. ICT Service Supply Chains — maps to template B_05.02

One record per link in the chain behind each arrangement.

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `contract_ref` | key → section 2 | Arrangement this chain belongs to |
| 2 | `rank` | integer ≥ 1 | 1 = direct provider; 2+ = subcontractors that effectively underpin the service (Art. 29; CDR (EU) 2025/532) |
| 3 | `provider_legal_name` | text | Provider or subcontractor at this rank |
| 4 | `provider_id` | text | LEI/EUID per section 3 rules |
| 5 | `country` | ISO 3166-1 alpha-2 | Establishment of this chain member |
| 6 | `ict_service_type` | enum `S01`–`S19` | Service provided at this rank |
| 7 | `service_underpinned` | text | What this link underpins / who receives the subcontracted service |

## 5. Signing & Using Entities — maps to templates B_03.01–B_03.03 and B_04.01

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `contract_ref` | key → section 2 | — |
| 2 | `signing_entity` | text + LEI | Entity signing the arrangement (possibly on behalf of others in the group) |
| 3 | `provider_signatory` | text | ICT provider signing the arrangement |
| 4 | `using_entity` | text + LEI | Financial entity actually making use of the ICT service |
| 5 | `using_branch` | text | Branch using the service, if any |

## 6. Functions — maps to template B_06.01

One record per business function supported by ICT services.

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `function_id` | text, unique | RELATIONAL KEY referenced from section 2 |
| 2 | `function_name` | text | — |
| 3 | `licensed_activity` | text | Licensed activity the function belongs to |
| 4 | `performing_entity_lei` | text (LEI-20) | Entity performing the function |
| 5 | `criticality` | enum: `cif` / `not_cif` / `under_assessment` | Art. 3(22) test: would disruption materially impair financial performance, soundness or continuity of services, or authorisation compliance? |
| 6 | `criticality_reasons` | text | Documented reasons for the assessment |
| 7 | `assessment_date` | date (ISO 8601) | At least annually and on material change |
| 8 | `discontinuation_impact` | enum: `low` / `medium` / `high` | Impact of discontinuing the function |

## 7. CIF Assessments — maps to template B_07.01

One record per arrangement whose `supports_cif = yes`.

| # | Field | Type | Definition / rule |
|---|---|---|---|
| 1 | `contract_ref` | key → section 2 | — |
| 2 | `substitutability` | enum: `easy` / `difficult` / `highly_complex` / `not_substitutable` | — |
| 3 | `substitutability_reason` | text | Required if not `easy` |
| 4 | `last_audit_date` | date (ISO 8601) | Last audit or assurance review of the provider |
| 5 | `exit_plan_documented` | boolean | Art. 28(8): documented, comprehensive, sufficiently tested, periodically reviewed |
| 6 | `exit_plan_last_tested` | date (ISO 8601) | An untested exit plan does not meet Art. 28(8) |
| 7 | `reintegration_possibility` | enum: `easy` / `difficult` / `highly_complex` / `not_possible` | Bringing the service back in-house |
| 8 | `discontinuation_impact` | enum: `low` / `medium` / `high` | — |
| 9 | `alternative_providers` | text | Identified alternatives (Art. 28(8)) |

### Closed list — types of ICT services (ITS Annex III; only these identifiers are valid)

`S01` ICT project management · `S02` ICT development · `S03` Helpdesk and first-level support ·
`S04` ICT security management services · `S05` Data provider services · `S06` Data analysis services ·
`S07` ICT infrastructure, facilities and hosting (non-cloud) · `S08` Digital processing capabilities (non-cloud) ·
`S09` Data storage platform (non-cloud) · `S10` Telecommunication systems and flow management ·
`S11` Network infrastructure · `S12` Hardware and physical devices as a service ·
`S13` Licensing software run on premises (non-SaaS) · `S14` ICT operation management ·
`S15` ICT consulting · `S16` ICT risk management under DORA · `S17` Infrastructure-as-a-service (IaaS) ·
`S18` Platform-as-a-service (PaaS) · `S19` Software-as-a-service (SaaS)

## 8. Pre-submission checks (derived from the ESAs' 2024 dry run and 2025 collection)

In the ESAs' 2024 dry run (~1,000 entities), only 6.5% of registers passed all 116 data-quality
checks; 86% of failures were missing mandatory information. Run these before converting:

1. No mandatory field blank in any section.
2. Every LEI is 20 uppercase alphanumeric characters, matches the right legal entity, and is
   not lapsed (GLEIF check).
3. Provider ID types follow section 3 rules (EU legal persons: LEI or EUID; third-country: LEI only).
4. `ict_service_type` values are S-codes only — no free text.
5. All dates ISO 8601 and logically consistent (start ≤ end; nothing after the reference date).
6. `contract_ref` values unique; every cross-section reference resolves (contracts ↔ providers ↔
   functions ↔ assessments ↔ supply chains).
7. Country codes ISO 3166-1 alpha-2; currency ISO 4217; monetary values plain numbers.
8. Convert to the xBRL-CSV package per the ESA taxonomy; run the EBA validation rules; fix and re-run.
9. Confirm your NCA's submission window — they differ by country.

---

Maintained by Orbiq (orbiqhq.com). Human-readable page with context, sources and the XLSX/PDF
variants: https://www.orbiqhq.com/templates/dora-register-of-information-starter