DORA register of information in Luxembourg: reporting to the CSSF and CAA, and the data behind it

Every financial entity in Luxembourg that falls under DORA must keep a register of all its contracts for ICT services from third-party providers and file it with its supervisor once a year: the CSSF for banks, investment firms, fund managers and payment institutions, the Commissariat aux Assurances (CAA) for insurers. In 2026, CSSF-supervised entities filed between 11 February and 31 March, with data as at 31 December 2025. The template is fixed by EU law; the real difficulty is getting complete, consistent and identifiable data into it.

What the law requires

The obligation sits in Article 28(3) of Regulation (EU) 2022/2554 (DORA), which applies since 17 January 2025. Financial entities must “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”.

The same paragraph adds four duties:

• distinguish arrangements that support critical or important functions from those that do not;
• report at least yearly on new arrangements, provider categories, contract types and the services and functions provided;
• make the full register, or parts of it, available to the supervisor on request;
• inform the supervisor in a timely manner of planned arrangements for critical or important functions.

The register covers all ICT arrangements, not only outsourcing and not only critical ones. Intra-group ICT services are in scope as well.

The templates

The structure is set by Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024, published on 2 December 2024 and in force since 22 December 2024. It defines 15 linked templates:

The templates are relational: a contract reference in B_02.01 must match the same reference in B_03 and B_05, and a function in B_06.01 must match the services that support it. EU providers may be identified by a Legal Entity Identifier (LEI) or a European Unique Identifier (EUID), a choice the European Commission imposed when it rejected the ESAs’ first draft in 2024.

How and when Luxembourg entities report

Three points from the CSSF communiqué of 11 February 2026 matter in practice. The entity’s LEI must be known to the CSSF before it can file. Registers are expected at individual, sub-consolidated and consolidated level as applicable. And the CSSF applies its validation checks to more data fields than in 2025, so “a register that was accepted last year may be rejected this year”.

Entities under direct ECB supervision do not file with the CSSF; according to its annual report for 2025, the ECB ran its first collection of registers for significant institutions in 2025. Third-country branches of credit institutions had until 30 June 2026 on a best-effort basis, and Circular CSSF 26/915 of 27 August 2026 formally brought third-country branches into the scope of Circular 25/882.

On 17 March 2026 the CSSF reported that only 40% of the entities concerned had filed. It also warned that the ESAs would run further quality checks throughout April 2026 and that rejected registers had to be corrected before the end of that month. As of 6 October 2026, the CSSF had not published the timeframe for the 2027 submission.

Why it is a data problem

The register is not a compliance form that can be filled in once. It is a small relational database drawn from procurement, legal, IT, vendor management and risk, and each of those sources usually holds a different version of the truth.

The CAA’s information note 26/3 of 15 April 2026 shows where it goes wrong. After the 2025 data collection, the ESAs found inconsistencies, notably in provider data in template B_05.01, and added a one-off set of checks. Among them:

• provider names filled with placeholders or legal suffixes only (“N/A”, “LTD”, “GMBH”);
• identification codes such as “DUMMY”, “12345” or “NONE”;
• code type and code concatenated in one field (“CRN123456”, “VAT#12345”);
• codes shorter than five characters;
• an LEI whose name in the GLEIF database does not match the reported provider name, or an EUID that does not match the business register (BRIS).

The note explains why this matters: generic names such as “LLC” or “N/A” caused unrelated companies to be grouped together during the ESAs’ analysis. That analysis is not academic. On 18 November 2025 the ESAs designated 19 critical ICT third-party providers for direct EU oversight, using data from the registers. The ECB has used the same data to confirm a growing reliance on a small number of providers, particularly cloud providers.

Behind these errors lie ownership questions. Who owns the provider master record and its LEI? Who decides whether a function is critical or important? Who keeps the contract reference stable when a contract is renewed? Without named owners, every annual cycle becomes a reconciliation exercise. Examples of how such ownership models are set up can be found in case studies of data-quality work in financial services.

What to do now

1. Name owners for the three core data sets: ICT providers (including LEI or EUID), contracts, and functions with their criticality assessment.
2. Build a provider master list and validate every LEI against GLEIF before the next cycle; remove placeholders and concatenated codes.
3. Fix contract keys: one stable contractual reference per arrangement, used identically across templates B_02, B_03 and B_05.
4. Run the published ESA and CSSF validation rules on the register internally before filing, not after a rejection.
5. Keep the register live: update it when contracts are signed, changed or terminated, since Article 28(3) allows the supervisor to request it at any time.
6. Plan resources for the filing window and the month after it, when the ESAs run their own checks.