Register of Information
Mandatory fields of the DORA register of information
Mandatory vs conditional fields across the 13 DORA register templates: LEI, arrangements, functions, location, supply chains and assessments (2024/2956).
In the DORA register of information, “mandatory” does not mean “fill every cell everywhere”. Implementing Regulation (EU) 2024/2956 distinguishes:
- Mandatory — required whenever the template applies
- Conditional — required only if a condition is true (critical function, arrangement type, data storage, etc.)
- Optional — not required
Misreading that logic creates two symmetrical failures: incomplete files, or teams blocked on fields that do not yet apply.
This article focuses on the field families that most often go wrong. Overview of the 13 templates: complete guide.
1. Reporting entity (B_01.01)
One row. Structural fields: LEI (20 characters), name, country, financial-entity type (closed EBA list — 22 values in B_01.01), and competent authority + communication date when filing.
Without a valid LEI and correct entity type, licensed-activity lists in B_06.01 cannot be filtered consistently.
2. Arrangements — general (B_02.01)
Each arrangement gets a unique, stable reference number assigned by the entity — the universal join key.
Typical mandatory fields: arrangement type (standalone / overarching / subsequent or associated), currency, and annual expense or estimated cost for the past year (in units, not thousands).
Critical conditional: if the type is subsequent/associated, the reference to the overarching arrangement is mandatory. For a framework plus follow-ons, subsequent expenses should reconcile to the overarching total without double counting.
3. Arrangements — specific (B_02.02)
One row per arrangement × using entity × provider × function × ICT service type.
Always structural: arrangement reference, using-entity LEI, provider code + code type, function ID (F1…), ICT service type (19 values S01–S19), start/end dates (9999-12-31 if open-ended), termination reason when terminated.
Conditional if the function is critical or important: notice periods, governing-law country, service-provision country, data storage flag and location at rest, processing location, data sensitivity, dependency level.
Practical implication: until B_06.01 (functions) is clear, you do not know which B_02.02 fields are actually due.
4. Providers (B_05.01)
Identity code + code type, legal name + Latin-script name, person type, seat country, annual spend/currency when applicable, ultimate parent when the provider is not itself the ultimate parent.
Identifier rule: EU legal persons → LEI or EUID only; non-EU legal persons → LEI only; alternative codes (CRN, VAT, passport…) → natural persons acting in a business capacity only. Every subcontractor in B_05.02 must also exist in B_05.01.
5. Supply chains (B_05.02)
Per ICT service on an arrangement: service type, provider code, rank (≥ 1; 1 = direct); if rank > 1, recipient at the previous rank. Same arrangement number and service type across the chain. In practice, declare subcontractors that underpin critical/important functions (with specific intra-group rules).
6. Functions (B_06.01)
Function ID unique for (using-entity LEI + licensed activity + internal function name). Mandatory highlights: criticality assessment, last assessment date, RTO/RPO in whole hours (< 1h → report 1; 0 if undefined), disruption impact. Without this module, B_02.02 cannot reference functions correctly.
7. Assessments (B_07.01) — critical scope
Substitutability; reason if not substitutable / highly complex; date of last audit by the entity or a mandated third party (not a vendor certificate passively received); exit plan; reintegration feasibility; impact of cessation; whether alternatives were identified.
8. EBA validation families to prioritize
Roughly 71 EBA validation rules, often warning severity: existence, conditionals (framework ↔ subsequent; amount ↔ currency; weak substitutability ↔ reason), row completeness, LEI format. Some LEI checks on other templates were temporarily deactivated by the EBA — monitor reactivations.
Prioritization checklist (individual entity)
- LEI + entity type (B_01.01)
- Functions + criticality + RTO/RPO (B_06.01)
- Providers with LEI/EUID and ultimate parent (B_05.01)
- Arrangements: framework/standalone/subsequent + costs (B_02.01)
- Specific rows B_02.02 (including critical conditionals)
- Chains B_05.02 and assessments B_07.01 on the critical perimeter
Go further
Axenia’s role. Axenia helps structure these fields from existing contracts and referentials, distinguish mandatory from conditional based on function criticality, and flag gaps before export.
Based on Implementing Regulation (EU) 2024/2956. Not legal advice.