The CSSF has not changed any DORA deadline. On 29 September 2026 it published a communication that does two things. It asks Luxembourg financial entities to take into account the operational instructions the three European Supervisory Authorities, the EBA, EIOPA and ESMA, issued jointly on 16 September 2026. And it adds seven instructions of its own, each tied to a field of the major incident report template where the CSSF has seen reports go wrong (CSSF, 29 September 2026). Neither document touches the classification thresholds or the reporting clocks. Both are about how the template is filled in, field by field. For the person carrying DORA, the practical question is whether whoever completes the template, often someone in IT security rather than compliance, now knows what the regulator expects in each box.
What the CSSF published on 29 September 2026
The communication is not a new circular. It draws attention to the ESAs' instructions and states that the CSSF "expects financial entities to consider these practical instructions to facilitate the harmonised implementation of their incident reporting processes". It then highlights supplementary instructions of its own, meant "to enhance the quality of information submitted in the DORA major ICT-related incident reports, improve the efficiency of the reporting process and reduce subsequent exchanges", and says financial entities "are expected to take due account" of them (CSSF, 29 September 2026). In practice, the CSSF now has a written benchmark against which it can read every report it receives.
The seven fields the CSSF singled out
The CSSF's own document is a three-page table. Each line names a field of the template defined in Implementing Regulation (EU) 2025/302, what the CSSF observed and what it expects (Additional CSSF operational instructions, 28 September 2026).
| Field | What the CSSF observed | What it expects |
|---|---|---|
| 2.4, description of the incident | Too high-level or generic | Possible causes, immediate impacts, systems affected, resolution status, third parties or other entities affected, and updates in later reports |
| 2.10, reclassification as non-major | The justification is omitted | Why the incident does not meet, and is not expected to meet, the major criteria |
| 3.23, incident type | Only one type selected | Every applicable type, including "External event" when the incident comes from a third party |
| 3.29, infrastructure affected | Too generic or incomplete | The hardware and software components impacted |
| 3.34, temporary actions | Sometimes left empty | The recovery actions taken or planned, or the reason there are none |
| 2.8, 3.23, 4.1 and 4.2 | Incoherent answers, especially for third-party incidents | Root cause fields aligned with the third-party origin and the incident type |
| 4.6, resolution and lessons learnt | Very high-level or incomplete | Resolution actions, lessons learnt, and for open actions an identifier, owner, status and deadline |
What the three supervisory authorities published on 16 September 2026
The ESAs' document lists fourteen instructions. The ESAs present them as best-efforts guidance from their staff, agreed with the competent authorities, that does "not represent any legal interpretation" and will be updated regularly (ESAs, 16 September 2026). Their purpose is consistency across the member states that pass these reports on to the ESAs. A few of them change daily practice:
- Monetary fields 3.11, 4.13 and 4.14 are reported in thousands, in the currency given in field 1.15.
- The incident identifiers in fields 1.3a, 1.3b and 2.1 stay unchanged from the initial notification to the final report, or the incident may be counted twice.
- "Critical services affected" is always listed among the classification criteria in field 2.5, and the entity's home country is left out of the geographical spread in field 2.6.
- A third-party origin in field 2.8 follows a fixed format: legal name; LEI or EUID; type of code; any other information, separated by semicolons.
- Free-text fields hold only relevant content. A field that is neither mandatory nor applicable is left blank rather than filled with "not applicable".
Close-ended values follow the English terminology of Regulation 2025/302, but free-text fields may still be written in the national language.
The reporting clocks have not moved
The clocks come from Article 5 of Delegated Regulation (EU) 2025/301, which Circular CSSF 25/893 refers to (point 9). They are unchanged (RTS 2025/301, Article 5):
- the initial notification within four hours of classifying the incident as major, and no later than 24 hours after becoming aware of it;
- the intermediate report within 72 hours of the initial notification, even where the status or handling of the incident has not changed, and an updated one when regular activities have been recovered;
- the final report no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.
The ESAs add an expectation: after the first intermediate report, at least one updated intermediate report per month until the final report is submitted. Luxembourg filings go through the "DORA Major ICT-related Incident Notification" procedure on the CSSF eDesk portal or through the CSSF API interface (S3). Since the update of 27 August 2026, an entity facing a technical impossibility informs the CSSF by email at ictrisksupervision@cssf.lu within the same time limits, and explains why it used that channel (CSSF 25/893, points 8 and 9).
What this means for the second line
Second-line officers rarely draft the incident report themselves, but they usually sign it off, or explain a late or incomplete one to the CSSF afterwards. Three things are worth doing before the next incident, not during it.
- Read both sets of instructions with whoever completes the template, and update your internal completion guide for the fields they name.
- Check that what you record against each incident, the classification criteria of Delegated Regulation 2024/1772, the third party and its LEI, the root cause, maps directly onto fields 2.5, 2.8, 3.23, 4.1 and 4.2, so the first draft of any report is already aligned.
- Keep a short record that this review happened. The CSSF expects entities to take due account of the instructions, and a second line that can show it did is in a stronger position than one that cannot.
None of this changes your DORA programme. It is a reminder that reporting quality, not just reporting speed, is something the CSSF is now measuring.
Where Klavius fits
Klavius drafts the major incident notification for you, and keeps the clock in front of you while you check it. In its DORA module, an incident is logged with the moment it was detected, and the reporting clock starts from there. When the assessment against the criteria of Delegated Regulation 2024/1772 classifies it as major, Klavius stamps the time of classification, and the incident page shows the initial notification deadline as a live countdown: four hours from classification, and never later than twenty-four hours from detection. Each filing then sets the next deadline, seventy-two hours after the initial notification for the intermediate report, and one month after the latest intermediate report for the final one. When regular activities recover, Klavius flags the updated intermediate report as due. Every submission is recorded against its deadline, so whether each report went in on time is on file rather than reconstructed afterwards.
The draft starts from what the platform already holds. The entity's identifiers and contacts, the detection and classification times, the criteria the incident met, whether critical services are affected and the third party involved are taken from the incident record, the assessment and the firm profile. Klavius then writes the narrative fields, such as the description of the incident, from the record and the assessment. Your officer reviews and edits every field, which is where the CSSF's seven instructions are applied, by someone who knows the incident. The report then exports in the CSSF template, ready to submit through eDesk. Klavius prepares; your officers validate and sign. See the DORA page.
Sources
- CSSF, Additional CSSF operational instructions on DORA major ICT-related incident reporting, communiqué, 29 September 2026, and the CSSF instructions document, last updated 28 September 2026.
- EBA, EIOPA, ESMA, DORA Incident Reporting, Operational Instructions, 16 September 2026.
- CSSF, Circular CSSF 25/893 on reporting of major ICT-related incidents and significant cyber threats under DORA, published 28 May 2025, as amended by Circular CSSF 26/915 of 27 August 2026, points 8 and 9.
- Commission Delegated Regulation (EU) 2025/301, Article 5.