CSSF issues extra DORA incident-reporting instructions: what Luxembourg financial entities must fill in
On 29 September 2026 the CSSF added seven field-level instructions to the ESAs' guidance on DORA major ICT incident reports, aimed at better data quality.
Key takeaways
- On 29 September 2026 the CSSF published additional operational instructions on reporting major ICT-related incidents under DORA (Regulation (EU) 2022/2554).
- The CSSF document contains seven instructions, dated 28 September 2026, on fields such as the incident description (2.4), incident type (3.23), affected infrastructure (3.29) and lessons learnt (4.6).
- It supplements 14 operational instructions that the European Supervisory Authorities' staff dated 16 September 2026, which the CSSF also points to.
- The communiqué is addressed to CSSF-supervised entities, from credit institutions and investment fund managers to payment institutions and crypto-asset service providers.
On 29 September 2026 the Commission de Surveillance du Secteur Financier (CSSF) published additional operational instructions for financial entities in Luxembourg that report major ICT-related incidents under DORA. The seven instructions, dated 28 September 2026, tell entities what the CSSF expects in specific fields of the EU incident templates. They come on top of 14 instructions published by the staff of the European Supervisory Authorities (ESAs), dated 16 September 2026.
What the CSSF published
The CSSF communiqué says the instructions aim to support supervisory engagement, enhance data quality and promote consistency across jurisdictions, and that financial entities are expected to consider them. It is addressed to central securities depositories, credit institutions, credit servicers, crypto-asset service providers, data reporting service providers, investment firms, investment fund managers, and payment institutions, e-money institutions and account information service providers.
Each instruction in the CSSF document names a template field from Implementing Regulation (EU) 2025/302, the problem the CSSF observed, and what it expects instead:
| Field | CSSF observation | What is expected |
|---|---|---|
| 2.4 Incident description | Often too high-level or generic | An overview of causes, impacts, affected systems and resolution status; impacted third parties; updates in later reports |
| 2.10 Reclassification as non-major | Justification omitted | The reasons why the incident does not, and is not expected to, meet the major criteria |
| 3.23 Incident type | Only one type selected | All applicable types, e.g. “Payment-related” plus “System failure”; “External event” when a third party is the origin |
| 3.29 Affected infrastructure | Too generic or incomplete | The hardware and software components affected |
| 3.34 Temporary actions | Sometimes left empty | Recovery actions taken or planned, or the reason there are none |
| 2.8, 3.23, 4.1, 4.2 | Incoherent answers | Root causes consistent with the third-party origin and incident type |
| 4.6 Resolution and lessons learnt | Very high-level or incomplete | Resolution actions, controls added, and an action plan with identifier, owner, status and deadline |
The ESAs’ baseline
The ESAs’ operational instructions are given on a best-efforts basis, are not a legal interpretation, and were agreed with the national competent authorities. Among other points, they ask entities to:
- report the monetary fields 3.11, 4.13 and 4.14 in thousands of units, in the currency given in field 1.15;
- leave non-mandatory free-text fields blank rather than writing “not applicable” or “none”;
- keep the identifiers in fields 1.3a, 1.3b and 2.1 unchanged from initial notification to final report, to avoid double counting;
- always list “critical services affected” among the classification criteria in field 2.5, and leave the home country out of the geographical spread in field 2.6;
- report a third-party origin in field 2.8 as legal name, LEI or EUID, and code type, separated by semicolons;
- submit at least one intermediate report per month until the final report.
Why it matters
Both documents address weaknesses observed in the content of incident reports; they do not create new obligations. For Luxembourg entities, this means incident reporting is also a data-quality task: stable identifiers, clean third-party data and consistent classifications across fields.
What to do now
- Check recent incident reports against the seven CSSF and 14 ESA instructions.
- Update internal reporting templates and guidance for fields 2.4, 3.23, 3.29 and 4.6.
- Make sure third-party providers are recorded with a valid LEI or EUID, so field 2.8 can be filled correctly.
- Assign an owner for keeping incident identifiers stable across the reporting cycle.
Questions & answers
Are the new CSSF instructions legally binding?
They are operational instructions, not a new legal act. The CSSF says financial entities are expected to consider them; the ESAs state that their own instructions are given on a best-efforts basis and are not a legal interpretation.
Which templates do the instructions refer to?
The field numbers refer to the templates in Commission Implementing Regulation (EU) 2025/302 of 23 October 2024 on the forms and procedures for reporting major ICT-related incidents.
How often must a major incident be updated?
The ESAs' instructions recall that the final report is due no later than one month after the latest intermediate report, and therefore expect at least one intermediate report per month until the final report.
Sources
- Additional CSSF operational instructions on DORA major ICT-related incident reporting (29 September 2026) · CSSF
- Additional CSSF Operational Instructions on DORA Major ICT-Related Incident Reporting (PDF) · CSSF
- DORA Incident Reporting – Operational Instructions (16 September 2026) · EBA
- ICT and cyber risk for DORA entities · CSSF
Written and fact-checked against primary sources.