DORA Register of Information: Fill the 15 ITS 2024/2956 Templates in the Right Order, With the Column Codes the 2025 Corrigendum Changed

Fill the DORA register of information in dependency order. Start with the tables where the keys are first entered: the entities (B_01.02), the providers (B_05.01), the contracts (B_02.01) and, once you know which entity uses which contract, the functions (B_06.01). Then fill the templates that only point at those keys, and finish with the terminology template, B_99.01. Annex I of the ITS points from one template’s column to another’s with the words “as reported in” more than 20 times. Each one is a place where a value typed in one sheet must match a value typed in another, so filling in the wrong order means creating the same key twice and reconciling later.

This guide sets out that order, the identifier problems that featured most in the supervisors’ dry run, how to rank a supply chain, what the six data-quality principles mean in practice, and the nine changes made by the corrigendum of 19 September 2025. For DORA as a whole, start with our DORA compliance hub.

Who keeps the register, and at which level

Plain-language summary: every financial entity in DORA’s scope keeps one, including the smallest. Groups keep it at entity level and again at sub-consolidated and consolidated level.

The duty sits in Article 28(3) of Regulation (EU) 2022/2554 (DORA): “financial entities shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.” Article 28(2), the paragraph before it, exempts microenterprises and Article 16(1) entities from the third-party risk strategy. Article 28(3) has no such carve-out, so a five-person payment institution keeps the same 15 templates as a bank. If you are unsure whether DORA reaches your firm at all, our explainer on what DORA is and which 20 entity types it covers settles that first.

Your situation	What the ITS requires	Where it shows
Stand-alone financial entity	One register at entity level. B_01.02 lists only your entity and repeats B_01.01.	B_01.02 instructions
Group with a parent that is a financial entity	Registers at entity, sub-consolidated and consolidated level; the group register “shall include all financial entities and ICT intra-group service providers”	ITS Art. 6(2)
Parent is a holding company outside DORA	Where the parent keeps the group register, it reports itself as “Other financial entity”	B_01.01.0040
Entity that outsources all its activities	Still keeps a register; the providers of the entity acting on its behalf are recorded in it	Recital 7; B_01.02.0050 option 5
Firm outside DORA (for example a card scheme supplier)	No DORA register; NIS2 supplier rules may apply instead	See our finance supply-chain gap guide

Two readers need different things from this section. A compliance officer needs the other duties in the same paragraph: reporting “at least yearly” on new arrangements, handing over the full register “upon its request”, and informing the authority “in a timely manner” about any planned arrangement for a critical or important function. A small-firm owner needs the shorter message: being small reduces DORA’s governance load, but it never removes the register.

The fill order: 15 templates in nine steps

Plain-language summary: a few templates create keys and the rest reuse them. Fill the key templates first and every later step becomes copying, not inventing.

Commission Implementing Regulation (EU) 2024/2956 lists the 15 templates in Article 5(1), points (a) to (o). Recital 8 names four keys that link them: the contractual arrangement reference number, the identifier of entities and providers, the function identifier and the type of ICT services. Recital 8 is an explanation, not an obligation, but the column instructions make it binding in practice: B_02.02.0050, for example, says the function identifier is “As defined by the financial entity in B_06.01.0010”. We mapped every cross-reference in Annex I to the template it points at. The result is the order below.

Step	Template(s)	What goes in	Reads keys from	Effort
1	B_01.01, B_01.02, B_01.03	The entity keeping the register, every entity in scope, branches outside the home country	Only within the step (B_01.03 repeats LEIs from B_01.02)	Low
2	B_05.01	Every direct provider, intra-group provider, listed subcontractor and their ultimate parents	Nothing (creates provider codes)	High
3	B_02.01	One row per contract with a unique, stable reference number, type and annual cost	Nothing (creates contract numbers)	Medium
4	B_04.01	Which entity or branch uses the services under each contract	B_01.03, B_02.01	Low
5	B_06.01	One function identifier (F1, F2 …) per LEI, licensed activity and function, with criticality, RTO, RPO and impact	B_04.01 (the LEI of the entity using the service)	High
6	B_02.02	One row per contract, ICT service type and function: dates, notice periods, governing law, data location, reliance	B_02.01, B_04.01, B_05.01, B_06.01	High
7	B_03.01, B_03.02, B_03.03, B_02.03	Who signs on each side, and how intra-group contracts link to external ones	B_01.02, B_02.02, B_05.01	Medium
8	B_05.02, then B_07.01	The supply chain for each contract and service type, with ranks; then the assessment of each service supporting a critical or important function	B_02.01, B_05.01	High
9	B_99.01	Your own definitions of the closed-list options (what “High” means to you)	The six closed lists it names	Low

Why functions come before the contract details: B_02.02 needs a function identifier on every row, and B_06.01 is the only place the identifier is created. Teams that start from the contract list end up inventing function names per contract and merging them afterwards. Effort ratings are our own estimate for a firm with a few dozen ICT contracts, not a figure from the ITS.

For B_06.01 itself, the example in Annex I shows the granularity: one entity with two licensed activities gets two identifiers, F1 and F2, for the same function. Recovery time and recovery point objectives go in whole hours; under one hour is reported as “1”, and an objective that is not defined is reported as “0”. Where the criticality assessment has not been performed, the date column is filled with “9999-12-31”.

Identifiers: the LEI and EUID rule

Plain-language summary: every provider that is a company needs a valid, active LEI or an EUID, and both where both exist. A provider established outside the EU needs an LEI. National codes such as VAT numbers are only for individuals.

Article 3(5) of the ITS requires financial entities to “use a valid and active legal entity identifier (LEI) or the European Unique Identifier … (‘EUID’), and where available both of these identifiers, to identify all of their ICT third-party service providers that are legal persons, except for individuals acting in a business capacity.” The column instruction for B_05.01.0020 adds the third-country rule: “Only LEI shall be used for legal persons that are not established in the Union.” Article 3(6) pushes the rule one level down. For a service supporting a critical or important function, you must ensure, through the direct provider, that the subcontractors you record also use a valid and active LEI or provide their EUID.

Identifiers were among the main failure points. The ESAs’ summary names missing mandatory information as the most common failed check, with identification codes for providers and their parent undertakings as the most problematic field. Invalid LEI codes came second, and the ESAs called one result “unexpected”: more invalid LEIs were reported for the financial entities themselves than for their providers. The dry run used the January 2024 draft templates, not the final ITS, so treat the figures as a warning about where errors cluster, not as a forecast.

Three rules catch most of these errors:

• Entities in scope use LEI only. B_01.01, B_01.02 and B_04.01 ask for the LEI as a 20-character code under ISO 17442. B_03.01.0020, the entity signing for receiving the services, expressly accepts the EUID as well. The B_03.01 instructions add that the signing entity “is not necessarily a financial entity”.
• Ultimate parents are providers too. B_05.01 must list the ultimate parent undertaking of each provider. Where a provider is not part of a group, B_05.01.0110 repeats the provider’s own code.
• Check status, not just format. In our reading, “valid and active” in Article 3(5) rules out a lapsed LEI, and the ESAs checked every LEI in the dry run against the GLEIF database. A code with the right 20 characters can still fail.

Supply chains: how to assign the rank

Plain-language summary: the provider you signed with is rank 1. Its subcontractor is rank 2, that subcontractor’s subcontractor is rank 3, and so on. You record subcontractors only where the service supports a critical or important function, with one intra-group exception.

Article 2 of the ITS sets the rule: the rank “shall be any natural number higher or equal to ‘1’”, the direct provider “shall always be ‘1’”, and a subcontractor’s rank “shall always be higher than ‘1’”. Which subcontractors go in depends on the service. Article 3(2)(b) limits the list to those “that effectively underpin ICT services supporting critical or important functions or material parts thereof”. The B_05.02 instructions describe them as subcontractors “whose disruption would impair the security or the continuity of the service provision”. For services that support no critical or important function, B_05.02 holds only the direct provider (which may be an intra-group provider), with one exception. Where an intra-group provider uses subcontractors, you record “at least the first extra-group subcontractor” whatever the function.

A worked example (illustrative, not taken from the ITS). A payment institution signs contract C-014 with a core-banking software vendor delivered as software-as-a-service (Annex III type S19, “Cloud services: SaaS”). The vendor hosts it on two cloud infrastructure providers, and one of those rents space from a colocation data centre. The payment-processing function is critical.

B_05.02 row	Provider	Rank (0050)	Recipient of the subcontracted service (0060)
1	Core-banking vendor	1	Left blank (rank 1)
2	Cloud provider A	2	Vendor’s code
3	Cloud provider B	2	Vendor’s code
4	Colocation data centre	3	Cloud provider A’s code

Three rules from the B_05.02 instructions show in that table. Both cloud providers get rank 2, because “Where multiple ICT third-party service providers have the same position within the same ICT service supply chain, those providers shall be assigned with the same ‘rank'”. Every row repeats the same contract reference number and the same service type, because a supply chain is defined by that pair. And every provider in the table, including the data centre, also needs its own row in B_05.01 with its identifier and ultimate parent. Do not create contract reference numbers for the vendor’s own contracts with its subcontractors: the B_02.01 instructions say financial entities “shall not include in the register of information a ‘contractual arrangement reference number’ for arrangements between the external ICT third-party service providers and their subcontractors”.

For the CISO, this is where the register stops being a contract list. The rank-2 and rank-3 rows are your concentration map: if two critical services from different vendors both end at the same cloud provider, B_05.02 is where that shows. Intra-group chains add one more template. EIOPA’s answer to Q&A 3302 puts the intra-group contract in B_02.03.0010 and the intra-group provider’s contract with its external provider in B_02.03.0020, with both contracts also reported in B_02.01.

Assessments and definitions: B_07.01 and B_99.01

Plain-language summary: B_07.01 records what you concluded about each critical service; B_99.01 records what your rating words mean.

B_07.01 applies “When supporting a critical or important function or material parts thereof”. It records substitutability on a four-step scale, the date of the last audit, whether an exit plan exists, how hard reintegration would be, the impact of discontinuing the service, and whether alternative providers have been identified. Two instructions are often misread. The audit date covers audits by your own internal audit, a pooled audit with other clients, or a third party you appointed. It “does not relate to the reception or reference date of third-party certifications”, so receiving the provider’s ISO certificate or assurance report does not count as an audit date. Where no audit has been performed, the column takes “9999-12-31”. On alternatives, the instruction is unconditional: “the assessment to identify an alternative service provider shall be performed” for each provider supporting a critical or important function.

B_99.01 has 19 rows covering six closed lists: the type of contractual arrangement, data sensitivity, the impact of discontinuing a function, substitutability, reintegration and the impact of discontinuing a service. Column C0040 is where you write what each option means inside your firm. The Annex I example is plain: if B_07.01 rates the impact of discontinuation as low, medium or high, B_99.01 must say what low, medium and high mean. Write definitions a supervisor can test, such as “High: function unavailable for more than its RTO, or more than [X] clients affected”, rather than restating the label.

The six data-quality principles, applied

Plain-language summary: the ITS names six principles but does not define them. The table shows how each one translates into a check you can run before sending the register.

Article 3(3) requires the information to be “accurate and consistent” and requires you to “review the information contained in the templates regularly and … promptly correct any errors or discrepancies detected”. Article 3(4) then lists the six principles: accuracy, completeness, consistency, integrity, uniformity and validity. The right-hand column is our reading, built from the column rules in Annex I and the check areas the ESAs used in the dry run. It is not text from the ITS.

Principle (Art. 3(4))	Check you can run
Accuracy	Each LEI is active in the GLEIF record; legal names match the business register; costs match the ledger for the past year
Completeness	No blank mandatory column (Art. 4(3): “complete all data elements”); every provider in B_05.02 also exists in B_05.01
Consistency	The same contract number, LEI, function identifier and provider code mean the same thing in every template and at every consolidation level
Integrity	Every reference resolves: no B_02.02 row with a function identifier missing from B_06.01, no B_05.02 recipient missing from B_05.01
Uniformity	Dates in ISO 8601, countries in ISO 3166-1 alpha-2, currencies in ISO 4217, amounts “in units”
Validity	Only closed-list values, service types S01 to S19 from Annex III, and the sentinel date 9999-12-31 where the instructions require it

One structural rule underlies the integrity checks. Article 4(2) allows one value per data element, so “where more than one value is valid for a specific data element, financial entities shall add an additional row”. A service whose data sits in two countries needs two B_02.02 rows, not “DE, NL” in one cell.

The 19 September 2025 corrigendum: what changed

Plain-language summary: nine corrections, most of them column codes. If your register was built from the December 2024 text, B_06.01 is the template to check first.

The corrigendum published in OJ L 2025/90725 on 19 September 2025 corrects the English text of the ITS in nine places, counting each of the six renumbered B_06.01 codes separately:

Column	Published text (December 2024)	Corrected text
B_05.01.0020	Options LEI, EUID, or “Country Code+Underscore+Type of Code” (CRN, VAT, PNR, NIN)	A flat list of six options: 1 LEI, 2 EUID, 3 CRN, 4 VAT, 5 PNR, 6 NIN (the last four still only for individuals acting in a business capacity)
B_05.01.0090	“Currency of the amount reported in B_05.01.0070”	“Currency of the amount reported in B_05.01.0100”
B_06.01.0060 to 0110	Six column codes, starting at 0060 (no 0050)	Renumbered 0050 to 0100: criticality 0050, reasons 0060, date of assessment 0070, RTO 0080, RPO 0090, impact of discontinuing 0100
B_07.01.0110	Option “7. Assessment not performed”	“3. Assessment not performed”

The B_06.01 change matters most for anyone who built a spreadsheet or mapping from the December 2024 text. Every code from criticality onwards drops by ten, so a file built on the December 2024 codes puts the date of the last assessment in column 0080, which the corrected text assigns to the recovery time objective. The B_05.01.0020 change removes the country prefix from national codes, which affects any validation rule that expected a value like “DE_VAT”.

We also found three cross-references in the published text that the corrigendum did not touch. We read them as drafting slips, but the ITS has not corrected them, so confirm the treatment with your competent authority before relying on our reading:

• B_07.01.0060 is mandatory “in case ‘not substitutable’ or ‘highly complex substitutability’ is selected in B_07.01.0041”. No column 0041 exists; substitutability is B_07.01.0050.
• B_02.01.0050 says the annual cost “shall be expressed in the currency reported in B_01.02.0040”. B_01.02.0040 is the type of financial entity; the currency column of the same template is B_02.01.0040.
• B_99.01 row R0070 points to “B_06.01.0110”, impact of discontinuing the function. After the corrigendum that column is B_06.01.0100.

Sending the register: formats and dates

Plain-language summary: the ITS defines the templates and columns, but neither DORA nor the ITS sets a file format or a submission date. Your competent authority does.

Article 4(1) of the ITS defines each template as “a table with a predefined number of columns and an indefinite number of rows” and stops there. National practice in the 2026 cycle differed on both format and dates. The CSSF in Luxembourg took registers through its eDesk portal between 11 February and 31 March 2026, as “plain-csv files” in a .zip, with a reference date of 31 December 2025. De Nederlandsche Bank opened its request in MyDNB on 2 March 2026, asked for the register by 20 March 2026 in xBRL-CSV, and also accepted a standardised Excel template that it converts itself. DNB also used 31 December 2025 as the reference date.

Those dates are past. For the next cycle, check your own authority’s notice rather than assuming last year’s window repeats. The yearly reporting duty and the duty to hand over the register “upon its request” both come from DORA Article 28(3). So does the duty to inform the authority “in a timely manner” about planned arrangements for critical or important functions, and that duty runs all year, not once a year.

Frequently asked questions

Do microenterprises need a DORA register of information?

Yes. Article 28(2) exempts microenterprises and Article 16(1) entities from the third-party risk strategy, but Article 28(3), the register duty, applies to all financial entities with no such exception.

Do I have to list every subcontractor of every provider?

No. ITS Article 3(2)(b) requires subcontractors only where they “effectively underpin ICT services supporting critical or important functions or material parts thereof”. The exception is an intra-group provider that uses subcontractors: record at least the first subcontractor outside the group, whatever the function.

Can I identify a supplier by its VAT number?

Only if the supplier is an individual acting in a business capacity. Legal persons need an LEI or EUID, both where available, and legal persons established outside the EU need an LEI.

Is B_99.01 optional?

No. ITS Article 5(1)(o) lists terminology information as part of the register’s required content, and B_99.01 is the template for it.

What file format does the register have to be in?

The ITS does not say. In the 2026 cycle, Luxembourg’s CSSF required plain-csv files in a .zip, and DNB asked for xBRL-CSV and also accepted a standardised Excel template. Use whatever your competent authority specifies.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), Article 28(2) and (3). Official Journal of the European Union, EUR-Lex (linked above).
2. Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 laying down implementing technical standards with regard to standard templates for the register of information, Articles 1 to 6, Annex I and Annex III. Official Journal of the European Union, EUR-Lex (linked above).
3. Corrigendum to Commission Implementing Regulation (EU) 2024/2956, OJ L 2025/90725, 19 September 2025. EUR-Lex (linked above).
4. European Banking Authority (for the ESAs). DORA dry run exercise: summary workshop, 18 December 2024 (linked above).
5. Commission de Surveillance du Secteur Financier (CSSF). DORA – Submission timeframe for register of information – eDesk Portal open as of 11 February 2026 (linked above).
6. De Nederlandsche Bank (DNB). DORA reporting: DORA registers of information in March 2026, dnb.nl, supervision news 2026.
7. EIOPA. Questions and answers database, Q&A DORA 217 – 3302, 24 March 2025 (linked above).