DORA Register of Information: Build Methodology

The Register of Information (RoI) is the most data-intensive deliverable of DORA’s third-party chapter. Article 28(3) of Regulation (EU) 2022/2554 requires it at entity, sub-consolidated and consolidated level, and Commission Implementing Regulation (EU) 2024/2956 (the ITS) fixes its 15 templates. This guide is the build method: what each template holds, how the keys tie them together, the order that avoids rework, and what the checks will reject.

The Register in 30 Seconds

The register records every contractual arrangement on the use of ICT services provided by ICT third-party service providers, and the arrangements behind them. It is not a vendor inventory and not a risk register: it is a relational dataset, collected by competent authorities in xBRL-CSV and read by machines before anyone reads it.

The 15 Templates of ITS 2024/2956

Each template holds one kind of fact, and the templates point to each other. The names below are those of Annex I to the ITS.

Recital 8 of the ITS names the four keys that link them: the reference number of the contractual arrangement, an identifier of financial entities and providers (LEI, or EUID for providers), the function identifier, and the type of ICT services (Annex III, S01 to S19). What the ITS does not contain matters as much: there is no template for costs on their own, none for services that do not support critical or important functions, none for Article 30 clause coverage and none for concentration. Criticality is recorded per function in B_06.01, costs sit in B_02.01 and B_05.01, and concentration is analysed from the data rather than reported as a template.

The xBRL-CSV Format: What Validation Checks

Competent authorities collect the register as an xBRL-CSV report package, laid out by the EBA Filing Rules: a ZIP holding META-INF/reportPackage.json, a reports/report.json that points at the DORA module of the taxonomy, a parameters.csv (entity, reference period, base currency, decimals), a FilingIndicators.csv, and one CSV per template named after it (b_02.02.csv). What gets a package sent back:

• Column codes, not column names. Each CSV is headed by the taxonomy column codes (c0010, c0020...). They do not always follow the ITS numbering: in B_06.01 the ITS skips 0050 and the taxonomy does not.
• Member codes, not labels. A country is eba_GA:DE, a service type eba_TA:S17, a Yes eba_BT:x28. A label where a code is expected fails.
• The EBA validation rules. Release 4.3 carries 49 active rules for the DORA module: groups of columns that become mandatory together, conditional requirements (an overarching reference for every subsequent arrangement, rule v8805_m), the LEI pattern, non-negative amounts.
• Keys that do not resolve. An arrangement in B_02.02 that is not in B_02.01, a function that is not in B_06.01 for the same entity, a provider or an ultimate parent that is not in B_05.01.
• Identifiers. A valid and active LEI or the EUID, and both where available, for every provider that is a legal person (ITS Article 3(5)).
• Amounts without their currency. Each amount has its own currency column; the currency of total assets is that of the entity’s financial statements (ITS instruction for B_01.02.0100).

The 6-Step Methodology to Build the Register

Step 1: Fix the scope and the entities

Start with B_01.02 and B_01.03. At sub-consolidated and consolidated level the register includes all financial entities and ICT intra-group service providers of the group (ITS Article 6(2)); outside a group, one entity, identical to B_01.01. Every other template points back to these LEIs.

Step 2: Identify the functions and their criticality

B_06.01 gives each combination of entity, licenced activity and function a unique identifier, F1, F2 and so on, with its criticality, the date of the last assessment and its recovery objectives in hours. These are outputs of your business impact analysis and your critical or important function assessment, not of the register: do them first, because the criticality of a function decides which columns of B_02.02 become mandatory.

Step 3: Inventory arrangements and providers

Pull every arrangement from procurement, legal and finance, and filter by the functional definition of ICT services in Article 3(21) of DORA rather than by accounting category. Each arrangement with a direct provider gets a reference number that stays stable over time and across levels (B_02.01). Each provider goes in B_05.01, with its ultimate parent undertaking, which also goes in B_05.01. Service level agreements under an arrangement do not get their own number.

Step 4: Decompose each arrangement

B_02.02 is the most granular template: one row per arrangement, entity using the service, provider, function, type of ICT service and country of provision, and one more row per additional country of data storage or processing. Then record who signed on each side (B_03.01, B_03.02), intra-group provision (B_03.03) and who uses the service, branches included (B_04.01).

Step 5: Map the supply chains and assess the critical services

In B_05.02 the direct provider is rank 1 and each subcontractor ranks one above the provider it serves. For services supporting critical or important functions, include every subcontractor that effectively underpins the service; where an intra-group provider uses subcontractors, include at least the first extra-group one. Link intra-group arrangements to the arrangements behind them in B_02.03, then assess the critical services in B_07.01: substitutability, exit plan, possibility of reintegration, date of the last audit, alternatives.

Step 6: Define, validate, package, maintain

Write your definitions of the ratings in B_99.01, run the EBA rules and the cross-template references, check that entity and group levels agree (ITS Article 3(3)), then build the package with your reporting tool. Keep the register current as arrangements change: a register updated once a year is rebuilt once a year.

The Common Pitfalls

1. Building it from a procurement export. Procurement tracks spend and suppliers; the register tracks arrangements, the functions they support and the chains behind them.
2. Asserting criticality without a BIA. Criticality belongs to the function, not to the contract or the provider. Without the analysis behind B_06.01, the ratings cannot be defended.
3. Stopping at the direct provider. Ultimate parents in B_05.01 and underpinning subcontractors in B_05.02 are the rows most often missing (ITS Article 3(2)(b)).
4. Keys that drift. The same arrangement spelled two ways, or a function identifier used without the LEI of its entity, breaks the joins the supervisor relies on.
5. Labels, and the wrong column codes. Values must be EBA member codes and headers taxonomy column codes. A spreadsheet that reads well can still file every value under the wrong data point.

Penalties for Register Failures

A register failure is a breach of Article 28(3), and it is sanctioned under your national regime, not at EU level. DORA sets no EU-wide maximum fine for financial entities: Article 50 leaves administrative penalties to national law, so the amount depends on the Member State. What the Regulation does fix is the minimum set of powers every competent authority must hold (Article 50(4)):

• Cease-and-desist orders: an order to stop the conduct in breach and not to repeat it (Article 50(4)(a) and (b)).
• Measures to restore compliance, including of a pecuniary nature (Article 50(4)(c)). Any amount comes from national law.
• Public notices naming the financial entity and the nature of the breach (Article 50(4)(e)).
• Reach to individuals: Member States must allow these penalties and measures to be applied to members of the management body and to other individuals responsible for the breach under national law (Article 50(5)).

Where a given failure lands on that scale is governed by Article 51(2): the competent authority weighs the materiality, gravity and duration of the breach, whether it was intentional or negligent, and the level of cooperation shown. A late submission corrected promptly and a register knowingly misstated sit at opposite ends of those criteria.

Article 35 does not apply to your register. Its periodic penalty payments (the “1% of average daily worldwide turnover” figure) are imposed by the Lead Overseer on designated critical ICT third-party providers (CTPPs) only, for failing to comply with its information requests, investigations, inspections or reporting requests (Article 35(6) to (8)). They are never imposed on a financial entity for the content of its Register of Information (RoI).