Guide · DORA Register of Information
What goes in each DORA Register of Information template, and how the tables link
The DORA Register of Information is fifteen linked tables, B_01.01 to B_99.01, set by Annex I of Implementing Regulation (EU) 2024/2956. Four of them define identifiers: B_01.02 the entities, B_05.01 the providers, B_02.01 the contracts, B_06.01 the business functions. Nine others refer to those by key: an LEI, a provider code, a contract reference, a function identifier. B_01.01 and B_99.01 refer to nothing. The EBA data model marks 35 of the 120 columns as keys and declares 22 references between tables. A file is rejected when a key is empty (rule 805), repeated (806) or points at a row that does not exist (807). This page lists every column, every key and every link, generated from the EBA taxonomy, and walks through a one-contract example across all fifteen files.
Sources, each read on 18 October 2026: the ITS text on EUR-Lex (OJ L, 2 December 2024), the EBA taxonomy package 4.0 (errata 5, 20 March 2025, DORA module 1.1.0), the EBA validation rules workbook (28 April 2025), the ESAs reporting FAQ (28 March 2025) and the EBA observations from the 2025 testing (April 2025). The full list is at the end.
The fifteen templates, and what one row means
Article 4 of the ITS says each template is “a table with a predefined number of columns and an indefinite number of rows”. The columns are fixed by the taxonomy; what a row stands for is in the Annex I instructions. Both are condensed here.
| Template | One row is | Key columns | Refers to |
|---|---|---|---|
| B_01.01Entity maintaining the register of information | The entity submitting the register. One row. | c0010 | — |
| B_01.02List of entities within the scope of the register of information | Every entity the register covers: the reporting entity, each subsidiary and parent in scope, and any intra-group ICT provider. One row per entity. | c0010 | B_01.02 |
| B_01.03List of branches | Branches of those entities located outside their home country. One row per branch. Empty, but still filed, when there are none. | c0010, c0020 | B_01.02 |
| B_02.01Contractual arrangements – General Information | Each contractual arrangement once: its type, its overarching (master) arrangement if any, and the annual expense. One row per contract. | c0010 | B_02.01 |
| B_02.02Contractual arrangements – Specific information | The detail: which entity uses which ICT service, from which provider, for which function, under which contract, with dates, notice periods, governing law and data locations. One row per contract, entity, provider, function, service type and location combination. | c0010, c0020, c0030, c0050, c0060, c0130, c0150, c0160 | B_06.01, B_03.02 |
| B_02.03List of intra-group contractual arrangements | Pairs of linked intra-group arrangements. One row per link. | c0010, c0020 | B_02.01 |
| B_03.01Entities signing the Contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s) | Who signed each contract on the receiving side. One row per contract and signing entity. | c0010, c0020 | B_01.02, B_02.01 |
| B_03.02ICT third-party service providers signing the Contractual arrangements for providing ICT service(s) | Which provider signed each contract. One row per contract and signing provider. | c0010, c0020 | B_02.01, B_05.01 |
| B_03.03Entities signing the Contractual arrangements for providing ICT service(s) to other entity within the scope of consolidation | Entities in scope that provide ICT services to others in the group under a contract. One row per contract and providing entity. | c0010, c0020 | B_01.02, B_02.01 |
| B_04.01Entities making use of the ICT services | Every entity, and every branch, that makes use of each contract. One row per contract, entity and branch. | c0010, c0020, c0040 | B_01.02, B_02.01 |
| B_05.01ICT third-party service providers | Every ICT third-party provider the register mentions, including subcontractors and ultimate parents, with identifier, name, country and total annual expense. One row per provider. | c0010 | B_05.01 |
| B_05.02ICT service supply chains | The supply chain behind each service: the direct provider at rank 1, each subcontractor at rank 2 and below, and who subcontracted to whom. One row per contract, service type, provider, rank and recipient. | c0010, c0020, c0030, c0050, c0060 | B_02.01, B_05.01 |
| B_06.01Functions identification | The business functions ICT services support, per entity, with the criticality assessment, its date, recovery objectives and the impact of losing the function. One row per function and entity. | c0010, c0040 | B_01.02 |
| B_07.01Assessment of the ICT services | The assessment of each ICT service supporting a critical or important function: substitutability, exit plan, reintegration, last audit, alternatives. One row per contract, provider and service type. | c0010, c0020, c0040 | B_02.01, B_05.01 |
| B_99.01Definitions from Entities making use of the ICT Services | The entity’s own definitions of the scales used elsewhere (low, medium, high; substitutable, not substitutable; and so on). Free text, no key. | — | — |
How the tables link
The taxonomy declares 22 references. Each is a column, or a pair of columns, in one table that must match the key of another. The EBA engine enforces every one of them as rule 807, and the reference number in the message, R1 to R22, is the label on the arrow.
Read the graph in three layers
- Defining tables. B_01.02 defines every LEI, B_05.01 every provider code, B_02.01 every contract reference. Each also refers to itself: a parent LEI (R6), an ultimate parent code (R18) and an overarching contract (R13) must be rows in the same table.
- Link tables. B_03.01, B_03.02, B_03.03 and B_04.01 each pair a contract with an entity or provider, and B_06.01 pairs a function with an entity. They refer to the defining tables and nothing else.
- Detail tables. B_02.02 refers to B_03.02 (contract and provider, R17) and to B_06.01 (function and entity, R7). B_05.02 and B_07.01 refer to B_02.01 and B_05.01. B_02.03 refers to B_02.01 twice.
Two things the diagram shows that the Annex does not
- B_02.02 has no direct link to B_02.01 or B_05.01. The Annex says its contract reference is “as reported in B_02.01.0010”, but the check the engine runs is R17: the pair of contract and provider must exist in B_03.02. A contract that is in B_02.01 but has no signing-provider row fails on every B_02.02 row, and the error is reported against B_02.02, not against the table where the row is missing.
- B_04.01’s branch code has no foreign key. The Annex says to use the code from B_01.03.0010, but no reference is declared, so a mismatch passes the engine. The column is still a key, which is why the FAQ has filers type “Not Applicable” into it rather than leave it blank (FAQ Q64).
The order in which the keys resolve
Every table appears after the tables it refers to. Fill in this order and each row can be checked as it is written; fix in this order and each 807 is found once, at its cause.
B_01.01 → B_01.02 → B_01.03 → B_06.01 → B_05.01 → B_02.01 → B_02.03 → B_03.01 → B_03.02 → B_03.03 → B_04.01 → B_05.02 → B_07.01 → B_02.02 → B_99.01
Which fields are keys, and the three rules that check them
The EBA’s validation rules workbook (28 April 2025) describes the three key rules in one line each, all three in its “Additional Plain-csv” category. The EBA’s April 2025 observations mark 805 and 807 as leading to rejection. For 806 its summary table says no, while its own 806 slide says a repeated key “will be rejected with 806”; treat it as blocking.
- 805
- “For open tables, the key columns values cannot be empty”
- Every key column listed in the reference below must hold a value in every row. Where the ITS has nothing to put there, the FAQ supplies a value: “Not Applicable” typed into B_04.01.c0040 (Q64), eba_GA:qx2007 in the three B_02.02 country keys (Q59, Q61, Q63), the provider’s own code in B_05.02.c0060 at rank 1 (Q65), and “Not Applicable” in any other key field that cannot be filled (Q26). The EBA’s April 2025 observations illustrate 805 with missing c0010 values.
- 806
- “For open tables, you cannot have multiple rows with identical key values”
- The key is the whole tuple. B_02.02 has eight key columns, so two rows for the same contract, entity, provider, function and service type are duplicates only if the three country columns also match. One provider listed twice in B_05.01, or one contract twice in B_02.01, is the simple case.
- 807
- “The reported data must follow the key-foreign key contraints [sic] defined in the DPM”
- The 22 references on the diagram. The EBA’s worked example of a self-reference failure is a c0030 value “not in any row for C 0010”, which in the taxonomy is R13 in B_02.01. Its cross-table example is a contract reference in B_07.01 that is not found in B_02.01.
One rule sits in front of these. Rule 809, “CSV formatting problem detected”, was added in May 2025 because, in the EBA’s words, if a table cannot be integrated “many foreign keys will fail with 807”, and without the new rule “it is hard for the submitters to understand the reason for the 807” (workbook, observations). A row with an extra or missing comma in b_05.01.csv can therefore surface as 807 messages on every table that refers to B_05.01: B_03.02, B_05.02, B_07.01, and B_05.01 itself through R18. Read the 809 and UTF-8 (306) messages first.
The checks above run on your register, in your browser, and each 807 in the output names the reference (R1 to R22), the row and the table that should hold the missing key.
Check a register against these rulesField reference, template by template
All 120 columns from the EBA taxonomy, with their type, the closed list they draw from and its size, whether they are part of the key, and which table they refer to. The notes are the instructions from Annex I of the ITS and the ESAs FAQ that the column label does not already say. Types map to rules: dates must be yyyy-mm-dd (330), amounts plain numbers (305), closed-list values one of the listed codes with the eba_ prefix (503), link columns the word true.
B_01.01 · Entity maintaining the register of information
The entity submitting the register. One row.
file b_01.01.csv · key c0010 · no references
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | LEI of the entity maintaining the register of information20-character ISO 17442 LEI of the entity filing the register (ITS Annex I). | text | key |
| c0020 | Name of the entity | text | |
| c0030 | Country of the entity | closed listGA251 · 251 | |
| c0040 | Type of entity | closed listCT22 · 22 | |
| c0050 | Competent authority | text | |
| c0060 | Date of the reporting | date yyyy-mm-dd |
B_01.02 · List of entities within the scope of the register of information
Every entity the register covers: the reporting entity, each subsidiary and parent in scope, and any intra-group ICT provider. One row per entity.
file b_01.02.csv · key c0010 · refers to B_01.02
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | LEI of the entity | text | key |
| c0020 | Name of the entity | text | |
| c0030 | Country of the entity | closed listGA251 · 251 | |
| c0040 | Type of entityThe same 22 types as B_01.01 plus two non-financial options: ICT intra-group service provider, and other non-financial entity (taxonomy list CT24). | closed listCT24 · 24 | |
| c0050 | Hierarchy of the entity within the groupFive options; an entity that fits more than one takes the higher level, for example parent other than ultimate parent over subsidiary (FAQ Q100). | closed listRP5 · 5 | |
| c0060 | LEI of the direct parent undertakingRefers to c0010 of this table (R6): the parent must have its own row. An entity with no direct parent, such as the ultimate parent itself, repeats its own LEI from c0010 (FAQ Q58). | text | R6 → B_01.02 |
| c0070 | Date of last update | date yyyy-mm-dd | |
| c0080 | Date of integration in the register | date yyyy-mm-dd | |
| c0090 | Date of deletion in the register9999-12-31 when the entity has not been deleted (ITS Annex I). | date yyyy-mm-dd | |
| c0100 | Currency | closed listCU166 · 166 | |
| c0110 | Value of total assets | amount |
B_01.03 · List of branches
Branches of those entities located outside their home country. One row per branch. Empty, but still filed, when there are none.
file b_01.03.csv · key c0010 + c0020 · refers to B_01.02
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Identification code of the branchThe branch’s own LEI if it has one, otherwise the code the entity uses for it (ITS Annex I). | text | key |
| c0020 | LEI of the head office of the branchMust match an LEI in B_01.02 (R3). | text | keyR3 → B_01.02 |
| c0030 | Name of the branch | text | |
| c0040 | Country of the branch | closed listGA251 · 251 |
B_02.01 · Contractual arrangements – General Information
Each contractual arrangement once: its type, its overarching (master) arrangement if any, and the annual expense. One row per contract.
file b_02.01.csv · key c0010 · refers to B_02.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference numberAssigned by the entity. The ITS requires it to be unique and consistent over time at entity, sub-consolidated and consolidated level, and used identically in every template. | text | key |
| c0020 | Type of contractual arrangementStandalone, overarching (master or framework), or subsequent/associated to an overarching one. | closed listCO3 · 3 | |
| c0030 | Overarching contractual arrangement reference numberRefers to c0010 of this table (R13). When the contract is itself overarching or standalone the FAQ says to type “Not applicable”, because the field cannot be left blank and there is no list value for it (FAQ Q124). “Not applicable” is not a contract reference, so an engine applying R13 literally would not find it in c0010; neither the FAQ nor the rules workbook says how the EBA engine treats it. | text | R13 → B_02.01 |
| c0040 | Currency of the annual expense | closed listCU166 · 166 | |
| c0050 | Annual expense or estimated costIn units, not thousands (ITS); the currency goes in c0040. A plain number, not text (rule 305). | amount |
B_02.02 · Contractual arrangements – Specific information
The detail: which entity uses which ICT service, from which provider, for which function, under which contract, with dates, notice periods, governing law and data locations. One row per contract, entity, provider, function, service type and location combination.
file b_02.02.csv · key c0010 + c0020 + c0030 + c0050 + c0060 + c0130 + c0150 + c0160 · refers to B_06.01, B_03.02
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference number“As reported in B_02.01.0010” (ITS). The taxonomy checks it together with c0030 against B_03.02 (R17), not against B_02.01 directly. | text | keyR17 → B_03.02 |
| c0020 | LEI of the entity making use of the ICT service(s)“As reported in B_04.01.0020” (ITS). Checked together with c0050 against B_06.01 (R7). | text | keyR7 → B_06.01 |
| c0030 | Identification code of the ICT third-party service providerThe provider’s code as in B_05.01.0010. Checked with c0010 against B_03.02 (R17); the chain B_02.02 → B_03.02 → B_05.01 is what ties a service to its provider. | text | keyR17 → B_03.02 |
| c0040 | Type of code to identify the provider | closed listqCO6 · 6 | |
| c0050 | Function identifierLetter F followed by a natural number, as defined by the entity in B_06.01.0010 (ITS). Checked with c0020 against B_06.01 (R7). | text | keyR7 → B_06.01 |
| c0060 | Type of ICT services | closed listTA19 · 19 | key |
| c0070 | Start date of the contractual arrangement | date yyyy-mm-dd | |
| c0080 | End date of the contractual arrangementThe end date in the contract; 9999-12-31 where the arrangement is indefinite; the renewal date where it renews; the termination date where it was ended early (ITS). Expired or terminated contracts are not included in the register, so c0090 normally stays empty (FAQ Q52). The rule that end must follow start (v8816_m) was deactivated in March 2025. | date yyyy-mm-dd | |
| c0090 | Reason of the termination | closed listCO6 · 6 | |
| c0100 | Notice period for the financial entity (days)Mandatory if the service supports a critical or important function (ITS). | integer | |
| c0110 | Notice period for the provider (days)Mandatory if the service supports a critical or important function (ITS). | integer | |
| c0120 | Country of the governing lawMandatory if the service supports a critical or important function (ITS). | closed listGA251 · 251 | |
| c0130 | Country of provision of the ICT servicesKey column, so it cannot be blank. eba_GA:qx2007 (Not applicable) when the service does not support a critical or important function (FAQ Q59). | closed listGA252 · 252 | key |
| c0140 | Storage of data | closed listBT2 · 2 | |
| c0150 | Location of the data at restKey column. eba_GA:qx2007 when c0140 is No (FAQ Q61). | closed listGA252 · 252 | key |
| c0160 | Location of management of the dataKey column. eba_GA:qx2007 when the service involves no data processing (FAQ Q63). | closed listGA252 · 252 | key |
| c0170 | Sensitiveness of the data storedLow, medium or high; the most sensitive data present decides (ITS). | closed listZZ3 · 3 | |
| c0180 | Level of reliance on the ICT service | closed listZZ4 · 4 |
B_02.03 · List of intra-group contractual arrangements
Pairs of linked intra-group arrangements. One row per link.
file b_02.03.csv · key c0010 + c0020 · refers to B_02.01
B_03.01 · Entities signing the Contractual arrangements for receiving ICT service(s) or on behalf of the entities making use of the ICT service(s)
Who signed each contract on the receiving side. One row per contract and signing entity.
file b_03.01.csv · key c0010 + c0020 · refers to B_01.02, B_02.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference number | text | keyR10 → B_02.01 |
| c0020 | LEI of the entity signing the contractual arrangementLEI, or EUID for an EU entity. The signatory need not be a financial entity nor the one using the service (ITS). Must exist in B_01.02 (R2). | text | keyR2 → B_01.02 |
| c0030 | Link | true |
B_03.02 · ICT third-party service providers signing the Contractual arrangements for providing ICT service(s)
Which provider signed each contract. One row per contract and signing provider.
file b_03.02.csv · key c0010 + c0020 · refers to B_02.01, B_05.01
B_03.03 · Entities signing the Contractual arrangements for providing ICT service(s) to other entity within the scope of consolidation
Entities in scope that provide ICT services to others in the group under a contract. One row per contract and providing entity.
file b_03.03.csv · key c0010 + c0020 · refers to B_01.02, B_02.01
B_04.01 · Entities making use of the ICT services
Every entity, and every branch, that makes use of each contract. One row per contract, entity and branch.
file b_04.01.csv · key c0010 + c0020 + c0040 · refers to B_01.02, B_02.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference number | text | keyR16 → B_02.01 |
| c0020 | LEI of the entity making use of the ICT service(s)Must exist in B_01.02 (R4). | text | keyR4 → B_01.02 |
| c0030 | Nature of the entity making use of the ICT service(s) | closed listZZ2 · 2 | |
| c0040 | Identification code of the branchKey column. Type “Not Applicable” when the entity is not a branch (FAQ Q64); otherwise the branch code from B_01.03. The taxonomy declares no foreign key to B_01.03 for it. | text | key |
B_05.01 · ICT third-party service providers
Every ICT third-party provider the register mentions, including subcontractors and ultimate parents, with identifier, name, country and total annual expense. One row per provider.
file b_05.01.csv · key c0010 · refers to B_05.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Identification code of the ICT third-party service providerFor a legal person, a valid LEI or EUID, and both where available (ITS Article 3(5)); a provider established outside the EU is identified by LEI only (ITS recital 9). Where none exists for a third-country provider the FAQ says to fill the field with another identifier rather than leave it blank; it is flagged, not rejected (FAQ Q40). | text | key |
| c0020 | Type of code to identify the provider | closed listqCO6 · 6 | |
| c0030 | Additional identification code | text | |
| c0040 | Type of additional identification code | closed listqCO6 · 6 | |
| c0050 | Legal name of the provider | text | |
| c0060 | Name of the provider in Latin alphabet | text | |
| c0070 | Type of personLegal person, or individual acting in a business capacity. The rule tying legal persons to LEI or EUID (v8817_m) was deactivated in March 2025. | closed listCT2 · 2 | |
| c0080 | Country of the provider’s headquarters | closed listGA251 · 251 | |
| c0090 | Currency of the total annual expense | closed listCU166 · 166 | |
| c0100 | Total annual expense or estimated costMandatory only for direct providers, rank 1 in B_05.02 (ITS). | amount | |
| c0110 | Identification code of the ultimate parent undertakingRefers to c0010 of this table (R18), so the parent needs its own row. When the provider has no parent, repeat its own code here (ITS). Report the highest-level parent; the model cannot hold two (FAQ Q119). | text | R18 → B_05.01 |
| c0120 | Type of code to identify the ultimate parent | closed listqCO6 · 6 |
B_05.02 · ICT service supply chains
The supply chain behind each service: the direct provider at rank 1, each subcontractor at rank 2 and below, and who subcontracted to whom. One row per contract, service type, provider, rank and recipient.
file b_05.02.csv · key c0010 + c0020 + c0030 + c0050 + c0060 · refers to B_02.01, B_05.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference number | text | keyR14 → B_02.01 |
| c0020 | Type of ICT services | closed listTA19 · 19 | key |
| c0030 | Identification code of the ICT third-party service provider | text | keyR20 → B_05.01 |
| c0040 | Type of code to identify the provider | closed listqCO6 · 6 | |
| c0050 | RankThe direct provider is always rank 1 (ITS Article 2); rank 2 and above are subcontractors. | integer | key |
| c0060 | Identification code of the recipient of sub-contracted ICT servicesAt rank n, the rank n−1 provider that subcontracted the service. The ITS says to leave it blank at rank 1, but the column is a key, so the FAQ says to repeat the provider code from c0030 at rank 1 (FAQ Q65). Must exist in B_05.01 (R21), which the repeated code does. | text | keyR21 → B_05.01 |
| c0070 | Type of code to identify the recipient | closed listqCO6 · 6 |
B_06.01 · Functions identification
The business functions ICT services support, per entity, with the criticality assessment, its date, recovery objectives and the impact of losing the function. One row per function and entity.
file b_06.01.csv · key c0010 + c0040 · refers to B_01.02
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Function identifierLetter F followed by a natural number; one identifier per combination of LEI, licensed activity and function (ITS). | text | key |
| c0020 | Licenced activity | closed listTA131 · 131 | |
| c0030 | Function name | text | |
| c0040 | LEI of the financial entityMust exist in B_01.02 (R5). | text | keyR5 → B_01.02 |
| c0050 | Criticality or importance assessmentNumbered B_06.01.0060 in the ITS. The ITS has no 0050 in this template, so from here on each ITS field number is one higher than the taxonomy column: ITS 0060 is c0050, 0080 is c0070, 0090 (recovery time) is c0080, 0100 (recovery point) is c0090, 0110 is c0100. The FAQ uses the ITS numbers (Q59 refers to B_06.01.0060); the CSV header uses the taxonomy codes. | closed listBT3 · 3 | |
| c0060 | Reasons for criticality or importance | text | |
| c0070 | Date of the last assessment of criticality or importance9999-12-31 when the assessment has not been performed (ITS B_06.01.0080). | date yyyy-mm-dd | |
| c0080 | Recovery time objective (hours)Hours. “1” when under an hour; “0” when no objective is defined (ITS B_06.01.0090). | integer | |
| c0090 | Recovery point objective (hours)Hours. “1” when under an hour; “0” when no objective is defined (ITS B_06.01.0100). | integer | |
| c0100 | Impact of discontinuing the function | closed listZZ4_2 · 4 |
B_07.01 · Assessment of the ICT services
The assessment of each ICT service supporting a critical or important function: substitutability, exit plan, reintegration, last audit, alternatives. One row per contract, provider and service type.
file b_07.01.csv · key c0010 + c0020 + c0040 · refers to B_02.01, B_05.01
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Contractual arrangement reference numberOnly for arrangements supporting a critical or important function (ITS). Must exist in B_02.01 (R15). | text | keyR15 → B_02.01 |
| c0020 | Identification code of the ICT third-party service providerMust exist in B_05.01 (R22). | text | keyR22 → B_05.01 |
| c0030 | Type of code to identify the provider | closed listqCO6 · 6 | |
| c0040 | Type of ICT services | closed listTA19 · 19 | key |
| c0050 | Substitutability of the provider | closed listZZ4_3 · 4 | |
| c0060 | Reason if not substitutable or difficult to substitute | closed listZZ3_2 · 3 | |
| c0070 | Date of the last audit on the provider9999-12-31 where no audit has been performed (ITS). | date yyyy-mm-dd | |
| c0080 | Existence of an exit plan | closed listBT2 · 2 | |
| c0090 | Possibility of reintegration of the contracted ICT service | closed listZZ4_4 · 4 | |
| c0100 | Impact of discontinuing the ICT services | closed listZZ4_2 · 4 | |
| c0110 | Alternative ICT third-party service providers identified | closed listBT3 · 3 | |
| c0120 | Identification of alternative providers | text |
B_99.01 · Definitions from Entities making use of the ICT Services
The entity’s own definitions of the scales used elsewhere (low, medium, high; substitutable, not substitutable; and so on). Free text, no key.
file b_99.01.csv · key none · no references
| Column | Field | Type · list | Key · refers to |
|---|---|---|---|
| c0010 | Definition: standalone arrangement | text | |
| c0020 | Definition: overarching arrangement | text | |
| c0030 | Definition: subsequent or associated arrangement | text | |
| c0040 | Definition: data sensitiveness, low | text | |
| c0050 | Definition: data sensitiveness, medium | text | |
| c0060 | Definition: data sensitiveness, high | text | |
| c0070 | Definition: impact of discontinuing the function, low | text | |
| c0080 | Definition: impact of discontinuing the function, medium | text | |
| c0090 | Definition: impact of discontinuing the function, high | text | |
| c0100 | Definition: not substitutable | text | |
| c0110 | Definition: highly complex substitutability | text | |
| c0120 | Definition: medium complexity substitutability | text | |
| c0130 | Definition: easily substitutable | text | |
| c0140 | Definition: reintegration easy | text | |
| c0150 | Definition: reintegration difficult | text | |
| c0160 | Definition: reintegration highly complex | text | |
| c0170 | Definition: impact of discontinuing the ICT services, low | text | |
| c0180 | Definition: impact of discontinuing the ICT services, medium | text | |
| c0190 | Definition: impact of discontinuing the ICT services, high | text |
The closed lists
21 lists in the taxonomy. A cell drawn from one must contain the code exactly, prefix included: eba_TA:S19, not S19 and not “Cloud services: SaaS” (rule 503). The six large lists are summarised; the rest are printed in full.
- GA251 (251 values) ISO 3166 country codes, used for the country of an entity, a branch, a provider’s headquarters and the governing law.
- GA252 (252 values) The same 251 countries plus eba_GA:qx2007 “Not applicable”, used only for the three key columns in B_02.02: country of provision, data at rest, data management.
- CU166 (166 values) ISO 4217 currency codes.
- CT22 (22 values) The 22 types of financial entity for B_01.01.
- CT24 (24 values) The same 22 plus two non-financial types for B_01.02.
- TA131 (131 values) Licensed activities for B_06.01, across banking, insurance, investment, payments and market infrastructure.
CO3
- eba_CO:x1 Standalone arrangement
- eba_CO:x2 Overarching arrangement
- eba_CO:x3 Subsequent or associated arrangement
qCO6
- eba_qCO:qx2000 Legal Entity Identfier (LEI)
- eba_qCO:qx2001 National code
- eba_qCO:qx2002 European Unified ID (EUID)
- eba_qCO:qx2003 Company registration number (CRN)
- eba_qCO:qx2004 Value added tax identification number (VAT)
- eba_qCO:qx2005 Passport Number
TA19
- eba_TA:S01 ICT project management
- eba_TA:S02 ICT Development
- eba_TA:S03 ICT help desk and first level support
- eba_TA:S04 ICT security management services
- eba_TA:S05 Provision of data
- eba_TA:S06 Data analysis
- eba_TA:S07 ICT, facilities and hosting services (excluding Cloud services)
- eba_TA:S08 Computation
- eba_TA:S09 Non-Cloud Data storage
- eba_TA:S10 Telecom carrier
- eba_TA:S11 Network infrastructure
- eba_TA:S12 Hardware and physical devices
- eba_TA:S13 Software licencing (excluding SaaS)
- eba_TA:S14 ICT operation management (including maintenance)
- eba_TA:S15 ICT Consulting
- eba_TA:S16 ICT Risk management
- eba_TA:S17 Cloud services: IaaS
- eba_TA:S18 Cloud services: PaaS
- eba_TA:S19 Cloud services: SaaS
CO6
- eba_CO:x4 Termination not for cause: Expired and not renewd
- eba_CO:x5 Termination for cause: Provider in breach of applicable law, regulations or contractual provisions
- eba_CO:x6 Termination for cause: Identified impediments of the provider capable of altering the supported function
- eba_CO:x7 Termination for cause: provider's weaknesses regarding the management and security of sensitive data or information
- eba_CO:x8 Termination: as requested by the competent authority
- eba_CO:x9 Other reasons for termination
RP5
- eba_RP:x21 Entities other than entities of the group
- eba_RP:x210 Outsourcing
- eba_RP:x53 Ultimate parent
- eba_RP:x551 Parent other than ultimate parent
- eba_RP:x56 Subsidiary
CT2
- eba_CT:x212 Legal person, excluding individual acting in a business capacity
- eba_CT:x213 Individual acting in a business capacity
ZZ2
- eba_ZZ:x838 branch of a financial entity
- eba_ZZ:x839 not a branch
BT2
- eba_BT:x28 Yes
- eba_BT:x29 No
BT3
- eba_BT:x21 Assessment not performed
- eba_BT:x28 Yes
- eba_BT:x29 No
ZZ3
- eba_ZZ:x791 Low
- eba_ZZ:x792 Medium
- eba_ZZ:x793 High
ZZ4
- eba_ZZ:x794 Not significant
- eba_ZZ:x795 Low reliance
- eba_ZZ:x796 Material reliance
- eba_ZZ:x797 Full reliance
ZZ4_2
- eba_ZZ:x791 Low
- eba_ZZ:x792 Medium
- eba_ZZ:x793 High
- eba_ZZ:x799 Assessment not performed
ZZ4_3
- eba_ZZ:x959 Not substitutable
- eba_ZZ:x960 Highly complex substitutability
- eba_ZZ:x961 Medium complexity in terms of substitutability
- eba_ZZ:x962 Easily substitutable
ZZ3_2
- eba_ZZ:x963 Lack of real alternatives
- eba_ZZ:x964 Difficulties in migrating or reintegrating
- eba_ZZ:x965 Lack of real alternatives and difficulties in migrating or reintegrating
ZZ4_4
- eba_ZZ:x0 Not applicable
- eba_ZZ:x798 Easy
- eba_ZZ:x966 Difficult
- eba_ZZ:x967 Highly complex
Worked example: one contract, fifteen files
A credit institution in the Netherlands with one SaaS contract, supporting one critical function, from one provider that belongs to a group. Key and reference columns only; the other columns are filled as the field reference describes. The LEIs follow the DUMMYLEI pattern the ESAs use in their own file-naming example (FAQ Q24), so they are visibly placeholders.
B_01.01 · 1 row
| c0010 | c0030 | c0040 |
|---|---|---|
| DUMMYLEI123456789012 | eba_GA:NL | eba_CT:x12 |
B_01.02 · 1 row
| c0010 | c0050 | c0060 |
|---|---|---|
| DUMMYLEI123456789012 | eba_RP:x53 | DUMMYLEI123456789012 |
An ultimate parent has no direct parent, so c0060 repeats its own LEI (FAQ Q58), and R6 finds it in c0010 of the same row.
B_01.03 · 0 rows
No branches outside the home country. The file b_01.03.csv is still in the package with its header row (FAQ Q76).
B_06.01 · 1 row
| c0010 | c0040 | c0050 |
|---|---|---|
| F1 | DUMMYLEI123456789012 | eba_BT:x28 |
Key is (c0010, c0040): F1 is unique per entity, not per register. R5 needs the LEI in B_01.02.
B_05.01 · 2 rows
| c0010 | c0020 | c0110 | c0120 |
|---|---|---|---|
| DUMMYLEI0000000CLOUD | eba_qCO:qx2000 | DUMMYLEI00000000PRNT | eba_qCO:qx2000 |
| DUMMYLEI00000000PRNT | eba_qCO:qx2000 | DUMMYLEI00000000PRNT | eba_qCO:qx2000 |
Two rows for one contract: the provider, and its ultimate parent, which must exist as a row because c0110 refers to c0010 (R18). The parent repeats its own code in c0110.
B_02.01 · 1 row
| c0010 | c0020 | c0030 |
|---|---|---|
| CA-2025-017 | eba_CO:x1 | Not applicable |
Standalone, so there is no overarching arrangement; the FAQ says to type “Not applicable” into c0030 (Q124). This is the one cell in the example whose treatment by R13 the published sources do not settle; see the field reference.
B_03.01 · 1 row
| c0010 | c0020 | c0030 |
|---|---|---|
| CA-2025-017 | DUMMYLEI123456789012 | true |
R10 needs the contract in B_02.01; R2 needs the LEI in B_01.02.
B_03.02 · 1 row
| c0010 | c0020 | c0030 |
|---|---|---|
| CA-2025-017 | DUMMYLEI0000000CLOUD | eba_qCO:qx2000 |
R9 needs the contract in B_02.01; R19 needs the provider in B_05.01. This row is also what B_02.02 points at.
B_03.03 · 0 rows
No intra-group provider. Empty file, still in the package.
B_04.01 · 1 row
| c0010 | c0020 | c0030 | c0040 |
|---|---|---|---|
| CA-2025-017 | DUMMYLEI123456789012 | eba_ZZ:x839 | Not Applicable |
c0040 is a key column and the entity is not a branch, so the FAQ’s typed “Not Applicable” goes in (Q64).
B_02.02 · 1 row
| c0010 | c0020 | c0030 | c0050 | c0060 | c0130 | c0150 | c0160 |
|---|---|---|---|---|---|---|---|
| CA-2025-017 | DUMMYLEI123456789012 | DUMMYLEI0000000CLOUD | F1 | eba_TA:S19 | eba_GA:NL | eba_GA:IE | eba_GA:IE |
Eight key columns. R17 looks up (c0010, c0030) in B_03.02; R7 looks up (c0050, c0020) in B_06.01. Three country columns are keys, which is why the FAQ added “Not applicable” to their list.
B_05.02 · 1 row
| c0010 | c0020 | c0030 | c0050 | c0060 |
|---|---|---|---|---|
| CA-2025-017 | eba_TA:S19 | DUMMYLEI0000000CLOUD | 1 | DUMMYLEI0000000CLOUD |
Rank 1, so there is no recipient of subcontracted services. c0060 is a key and cannot be blank, so it repeats the provider code from c0030 (FAQ Q65), which also satisfies R21.
B_07.01 · 1 row
| c0010 | c0020 | c0030 | c0040 | c0050 |
|---|---|---|---|---|
| CA-2025-017 | DUMMYLEI0000000CLOUD | eba_qCO:qx2000 | eba_TA:S19 | eba_ZZ:x961 |
Present because F1 is critical. R15 needs the contract in B_02.01; R22 needs the provider in B_05.01.
B_99.01 · 1 row
| c0010 | c0040 |
|---|---|
| A contract with one provider that is not tied to a master agreement | Data whose loss would not harm clients or the entity |
One row of the entity’s own definitions; no key, so nothing checks it beyond type.
Three edits that each break it
- Delete the second B_05.01 row. The first row’s c0110 now points at nothing: 807 on R18, reported against B_05.01.
- Change F1 to F2 in B_02.02. No (F2, DUMMYLEI123456789012) pair exists in B_06.01: 807 on R7, reported against B_02.02.
- Delete the B_03.02 row. The contract still exists in B_02.01, but B_02.02 looks for (CA-2025-017, DUMMYLEI0000000CLOUD) in B_03.02: 807 on R17, reported against B_02.02, which is the wrong place to look for the cause.
What happens if you get it wrong
The ESAs’ FAQ describes three layers: technical checks, DPM validation and business checks. A submission that fails the technical layer is rejected and returned with feedback. The EBA’s April 2025 observations list which common errors lead to rejection: 807, 805, 808, 720, 714, 103 and 801 do; missing mandatory values (v88xx_m rules), wrong LEIs (VR_ rules), EUIDs not found in BRIS and the LEI mask rule do not. The DPM business rules, prefixed v88xx_m and e2xxxx_e, are listed with severity “warning”: the file is accepted and the gaps come back as data-quality findings. The workbook does not state a severity for the other DPM technical checks (305, 330, 503); it moved the UTF-8 rule 306 out of that group specifically to make it blocking. Several of those were deactivated in March 2025, among them the rules that a legal person must carry an LEI or EUID (v8817_m, v8818_m) and that an end date must follow the start date (v8816_m); the regulation still asks for both, the engine no longer enforces them (EBA workbook, 28 April 2025).
The scale of the problem is public. In the ESAs’ 2024 dry run, 947 registers were analysed and 93.5% failed at least one check; 86% of the failed checks were missing mandatory information and 60% of those sat in B_02.02 (ESA 2024 35, 17 December 2024). In its April 2025 observations from RoI reporting the EBA counted 58,170 reported EUIDs with an invalid format, against 2,717 found in BRIS (observations, April 2025).
For 2026 the CSSF warned that the April 2025 checks “have not changed but will be applied to more data fields”, so “a register of information which was accepted last year, may be rejected this year” (CSSF, February 2026). The ESAs’ decision also lets the EBA require revisions through the competent authority after acceptance (ESA 2024 22, Article 7).
Fixing a rejected register, step by step
- Open the feedback file and sort by rule code. Deal with 1xx, 3xx and 7xx package errors and with 809 before anything else; until every table parses, the 807 list is noise.
- Clear every 805. For each, decide whether the value is missing or whether the ITS has nothing to put there; in the second case use the FAQ literal for that column, never a blank.
- Clear every 806 by finding the duplicate tuple. In B_02.02 compare all eight key columns, not the first two.
- Clear the 807s in resolution order: B_01.02, then B_05.01, then B_02.01, then B_03.02 and B_06.01, then everything that refers to them. Fix the defining table, not the referring one; one added row in B_05.01 often clears dozens of messages.
- Clear 503 by replacing labels with codes and adding the eba_ prefix; rule 330 by reformatting dates to yyyy-mm-dd.
- Rebuild the zip with all fifteen table files (empty ones with their header row), lower-case table file names, UTF-8, every template declared true in FilingIndicators.csv (rule 808), and the zip name in the FAQ’s pattern (Q24). Run the checks again before resubmitting.
Dates and versions, as of 18 October 2026
- The obligation
- Article 28(3) of DORA: maintain and update a register of all contractual arrangements on the use of ICT services at entity, sub-consolidated and consolidated level; make it available to the competent authority on request; report at least yearly on new arrangements. DORA applies from 17 January 2025 (Regulation (EU) 2022/2554).
- The templates
- Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, published in the Official Journal on 2 December 2024 and in force on the twentieth day after (EUR-Lex). Annex I holds the fifteen templates and their instructions.
- The data model
- EBA reporting framework 4.0, taxonomy package 4.0 errata 5 of 20 March 2025, DORA module 1.1.0; the module code DORA010100 in the file name is this version (EBA, FAQ Q24). DNB confirmed on 3 February 2026 that the taxonomy for the 2026 round was “exactly the same as last year” (DNB).
- The rules
- Validation rules workbook last updated 28 April 2025, with the March 2025 deactivations marked (EBA). FAQ last updated 28 March 2025 (ESAs).
- Reference date and deadlines
- ESA 2024 22, Article 4: the reference date is 31 December of the year before the submission; Article 5: competent authorities send the registers to the ESAs by 31 March each year (first cycle: reference 31 March 2025, deadline 30 April 2025) (ESAs decision ESA 2024 22, 8 November 2024, FAQ Q11 and Q13). Each authority sets an earlier window for entities: in 2026 DNB asked for submissions between 2 and 20 March, the CSSF between 11 February and 31 March (DNB, CSSF).
- The next round
- Under the standing decision the register with reference date 31 December 2026 is due to the ESAs by 31 March 2027; the national windows for it had not been announced on the pages above when we checked on 18 October 2026. Check your own authority’s page, and the EBA’s DORA page for any taxonomy change, before building the file.
Sources
Every document below was fetched and read on 18 October 2026. The field reference and the diagram are generated from the taxonomy files, with acknowledgement of the EBA as source; nothing in them is retyped.
- Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 (ITS on the register of information), OJ L of 2 December 20242 December 2024
- Regulation (EU) 2022/2554 (DORA), Article 28(3)27 December 2022
- EBA reporting framework 4.0: taxonomy package 4.0 errata 5 (DORA module 1.1.0)20 March 2025
- EBA, Overview of the RoI reporting technical checks and validation rules (xlsx)28 April 2025
- ESAs, Frequently asked questions on reporting of the registers of information under DORA28 March 2025
- EBA, Observations from testing of RoI reporting to the ESAs: key common issues identified (slides)16 April 2025, updated 16 May 2025
- ESAs, Dry Run exercise summary report (ESA 2024 35)17 December 2024
- ESAs Decision ESA 2024 22 on the reporting by competent authorities of information necessary for the designation of critical ICT third-party service providers8 November 2024 (published 15 November 2024)
- EBA, Preparing plain csv reporting package for DORA (slides)January 2025
- De Nederlandsche Bank, DORA reporting: registers of information in March 20263 February 2026
- CSSF, DORA: submission timeframe for the register of information, eDesk open as of 11 February 2026February 2026
Questions people ask
- What are the fifteen DORA Register of Information templates?
- Annex I of Commission Implementing Regulation (EU) 2024/2956 defines fifteen templates. B_01.01 to B_01.03 describe the reporting entity, the entities in scope and their branches. B_02.01 to B_02.03 describe each contractual arrangement in general, in detail per service, and the links between intra-group arrangements. B_03.01 to B_03.03 record who signed each contract on the receiving and providing sides. B_04.01 lists the entities and branches using each contract. B_05.01 lists every ICT third-party provider with its ultimate parent, and B_05.02 the supply chain of subcontractors by rank. B_06.01 lists business functions with their criticality assessment, B_07.01 the assessment of each ICT service supporting a critical or important function, and B_99.01 the entity’s own definitions of the scales it used.
- Which fields in the register of information are primary keys?
- The EBA data model marks 35 of the 120 columns as keys. Single-column keys: the LEI in B_01.01 and B_01.02, the contract reference in B_02.01, the provider code in B_05.01. Composite keys: branch code plus head-office LEI in B_01.03; the two linked contract references in B_02.03; contract plus entity or provider in B_03.01, B_03.02 and B_03.03; contract, entity and branch in B_04.01; contract, service type, provider, rank and recipient in B_05.02; function identifier plus LEI in B_06.01; contract, provider and service type in B_07.01; and eight columns in B_02.02, including the three country-of-service and data-location columns. B_99.01 has no key. A key column cannot be empty (rule 805) and a key tuple cannot repeat (rule 806).
- What does DORA error 807 mean and how do I fix it?
- Rule 807 is the EBA’s foreign-key check: “The reported data must follow the key-foreign key contraints [sic] defined in the DPM”. A value in one template must exist as a key in the template it refers to. The taxonomy declares 22 such references. Typical cases are an ultimate parent code in B_05.01 column c0110 with no row of its own in B_05.01, a contract used in B_02.03, B_03.01 to B_03.03, B_04.01, B_05.02 or B_07.01 that is missing from B_02.01 (the EBA’s own example is a B_07.01 contract reference not found in B_02.01), a contract and provider pair in B_02.02 with no matching row in B_03.02, and a function identifier in B_02.02 that is not defined for the same entity in B_06.01. Fix the defining table first, in the order B_01.02, B_05.01, B_02.01, B_03.02 and B_06.01, then B_02.02, and check that every CSV parsed, because the EBA notes that when a table cannot be integrated many foreign keys referring to it fail with 807.
- How do B_02.02, B_03.02 and B_05.01 relate to each other?
- B_05.01 defines each provider once with its identification code. B_03.02 records which provider signed which contract, keyed on contract reference plus provider code, and refers to B_05.01 for the code. B_02.02 then describes each service under the contract and refers to B_03.02 for the pair of contract reference and provider code. So the taxonomy does not check B_02.02 against B_05.01 or B_02.01 directly: a service row is valid only if the same contract and provider pair appears in B_03.02, and that pair is valid only if the contract exists in B_02.01 and the provider in B_05.01.
- Do empty templates have to be included in the register of information file?
- They have to be declared. The ESAs’ FAQ says that an entity with no branches does not fill B_01.03 but the empty template still needs to be reported (Q76). The EBA’s April 2025 observations say all DORA templates must be reported, every template must be declared as true in FilingIndicators.csv (rule 808 rejects a missing or false declaration), and a template can be reported empty when there is nothing to report. Since the May 2025 rule changes a missing or empty table file is accepted, but a package in which every table is empty fails rule 724. The simplest safe package declares all fifteen and includes all fifteen CSV files, empty ones with just their header row.
- Is there an official Excel template for the DORA register of information?
- The ESAs provided an Excel template and a CSV conversion tool for the 2024 dry run only. Their FAQ of 28 March 2025 says those tools were based on the draft ITS and the draft data model, and that the ESAs did not plan to update and maintain the conversion tool for official reporting (Q2); it adds that, given the referential integrity the data model imposes, the ESAs are not in a position to create an Excel solution that would pass the validation rules (Q21). The format reported to the ESAs is the plain-CSV package defined by the EBA taxonomy. Some national authorities accept a workbook of their own and convert it: DNB says it converts its Excel template to the xBRL-CSV standard. The ESAs’ checks then run on the converted package, so the keys and closed lists described here apply either way.
Try it on your own file first
Every tool here runs in your browser and uploads nothing, so you can see what we would see before telling us anything at all. When it is worth a conversation, send the real extract and the question you actually need answered.