DORA in Luxembourg: what the CSSF and CAA actually expect

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) sets a single ICT risk framework for the EU financial sector. It covers ICT risk management and governance, incident management and reporting, digital operational resilience testing, ICT third-party risk, and information sharing.

Most Luxembourg entities are past the question of whether DORA applies to them. The harder question is the one supervisors are now asking: can you evidence it, contract by contract, provider by provider, in the format the regulator will accept.

This page covers who is in scope in Luxembourg, which national texts sit on top of the Regulation, what the annual Register of Information cycle looks like in practice, and the failure patterns we see most often in Luxembourg filings.

Who is in scope in Luxembourg

Luxembourg has two competent authorities for DORA, split by entity type.

The CSSF supervises:

• Credit institutions
• Investment firms
• Professionals of the Financial Sector (PFS), including support PFS
• Investment fund managers, both UCITS management companies and AIFMs
• Payment institutions and electronic money institutions
• Crypto-asset service providers authorised under MiCA
• Central securities depositories, data reporting service providers, and other entity types listed in Article 2 of DORA

The Commissariat aux Assurances (CAA) supervises:

• Insurance and reinsurance undertakings
• Insurance intermediaries and ancillary insurance intermediaries, within the limits set by DORA

Following ESAs Q&A 102, third country branches of in-scope entity types supervised by the CSSF are also now in the reporting population. For third country branches of credit institutions, the CSSF treated the 2026 cycle as a first, best-effort run with a later deadline, and expects full quality from the next cycle onward.

If you are an ICT provider rather than a financial entity, DORA reaches you through your clients' contracts and through their register entries. Every Luxembourg bank, fund manager, or insurer you serve has to describe your service, your location, your subcontracting chain, and whether you support a critical or important function. Providers who cannot answer those questions quickly become the friction point in their clients' filings.

The Luxembourg layer on top of DORA

DORA is directly applicable, so there was no transposition of its substance. What Luxembourg added is the enforcement and supervisory scaffolding around it. Four texts matter most.

Law of 1 August 2024. Implements DORA in national law and gives the CSSF its DORA supervisory and sanctioning powers, on top of the existing regimes.

Circular CSSF 25/882. Sets the requirements for the use of ICT third-party services by DORA entities. This is the circular that carries the annual Register of Information submission obligation, prior notification for outsourcing of critical or important ICT functions, daily backup of accounting positions, and the retained cloud provisions. It also clarifies that where cloud resource operation is carried out by a provider in Luxembourg, that provider in principle needs authorisation as a support PFS under Article 29-3 of the 1993 Law on the financial sector.

Circular CSSF 22/806, as amended. The outsourcing circular was rewritten so that, for DORA entities, it now applies only to business process outsourcing. ICT outsourcing for those entities is governed by DORA and 25/882. For non-DORA entities it continues to apply to both. In practice this means every outsourcing contract has to be classified on two axes: ICT or not, and DORA entity or not. Get that matrix wrong and you apply the wrong rulebook to the wrong contract.

CAA Circular Letter 25/1. The insurance equivalent, setting the CAA's expectations on incident reporting and on the register, with submission through SOFiE and E-File rather than eDesk.

Circular CSSF 24/847 on ICT-related incident reporting and Circular 20/750 on ICT and security risk management remain part of the picture and have been aligned to reduce overlap with DORA.

The Register of Information: the obligation with a hard date

Article 28(3) of DORA requires you to maintain and update a register of all contractual arrangements for the use of ICT services, at entity level and at sub-consolidated and consolidated level where relevant. Circular CSSF 25/882 turns that into an annual submission to the supervisor.

How the cycle works:

• The reference date is 31 December of the preceding year. The register must contain every contractual arrangement in place at that date.
• Competent authorities must forward consolidated registers to the ESAs by 31 March each year, which is why national windows close before that.
• The CSSF collects through eDesk. In the 2026 cycle the window ran from 11 February to 31 March, with a later best-effort date for third country branches of credit institutions.
• The CAA collects through SOFiE and E-File. Its 2026 deadline for insurers was 1 March.
• The file is submitted as xBRL-CSV across the prescribed templates, and is run through the ESAs' validation checks before it is accepted.

Expect the same shape for the next cycle, with a 31 December 2026 reference date and a window opening early in 2027. Confirm the exact dates on the CSSF and CAA sites when they publish the 2027 calendar.

Two points from the CSSF are worth repeating, because they change how you should resource this. First, the register is meant to be maintained on an ongoing basis throughout the year, not assembled once in February. Second, the validation checks are being applied to more data fields each cycle, so a register that was accepted last year can be rejected this year without anything changing on your side.

Where Luxembourg filings actually fail

The scale of the data quality problem is not a secret. In the ESAs' dry run, fewer than 7% of nearly a thousand participating firms passed all 116 data quality checks. In Luxembourg, only 40% of the entities required to file had submitted with two weeks left in the 2026 window.

The failures cluster in predictable places.

Administrative blockers on day one. The entity's LEI has to be synchronised with the CSSF database, and at least one person needs the DORA Reporting role in eDesk. Synchronisation runs overnight, so an LEI mismatch discovered on the deadline cannot be fixed the same day. Filename and timestamp conventions are enforced, and reusing a timestamp from a previous or rejected submission causes a conflict.

Incomplete subcontracting chains. For contracts supporting critical or important functions, you have to trace the chain of subcontractors, not just name your direct counterparty. This is the single most common gap we see, because the answer usually is not in your contract at all. It is in an annex, a service description, or a provider response you never asked for.

Contract data that does not match the templates. Governing law, start and end dates, notice periods, termination rights, data location, processing location, and the function the service supports all have to be extracted per contract and expressed in controlled values. A master agreement with twelve schedules is not one register row.

Inconsistency across filers. Regulators now cross-reference submissions. If three Luxembourg entities describe the same provider differently, that surfaces immediately.

No single owner. The data sits with procurement, legal, IT, and compliance, and the register is usually assembled in a spreadsheet by whoever has the most time in February. That works once. It does not survive an inspection question about a contract signed in July.

What good preparation looks like

• Build the qualification matrix first. Classify every arrangement as ICT or business process, and check whether the entity is in DORA scope. That determines whether DORA and 25/882 apply, or the amended 22/806, or both.
• Inventory contracts before you inventory providers. The register is contract-level. Starting from a vendor list guarantees you miss schedules, renewals, and intragroup arrangements.
• Identify critical or important functions explicitly. Everything heavier in the register, including the subcontracting chain, keys off this determination. Document the reasoning, not just the outcome.
• Close the subcontracting gap with your providers now. Requesting chain information in February is too late. Build it into onboarding and renewal.
• Run the ESAs validation checks against your own file before you submit. Failing them at your desk in January is cheap. Failing them at the supervisor in March is not.
• Treat the register as a living record. Update it when contracts are signed, amended, or terminated, which is also what the CSSF has publicly asked for.

How Letzscale helps

Letzscale maps ICT contracts to the DORA register fields and produces the register data behind them, then tells you exactly where the gaps are before the supervisor does.

• Contract extraction, not data entry. Letzscale pulls the register fields from your signed agreements, schedules, and amendments, including scanned documents.
• Deterministic validation. Every extracted field is checked against the template rules and the ESAs' validation logic, so what you see is what the regulator will accept.
• Gap reporting per contract. You get a list of what is missing, which provider you need to chase, and what to ask them for.
• Built for Luxembourg. CSSF eDesk and CAA SOFiE submission paths, and the local circular framework, not a generic EU template.
• Processed in the EU. Your contracts are stored and processed in EU data centres, are never used to train AI models, and are isolated per tenant.