The European Supervisory Authorities, EBA, EIOPA and ESMA, have published operational instructions on the reporting of major ICT-related incidents under Regulation (EU) 2022/2554, DORA. The document is dated 16 September 2026. The CSSF has since issued a communiqué pointing financial entities to it, together with a table of its own supplementary instructions, and states that financial entities are expected to take due account of them. In our reading, each numbered item in the two tables records a mistake that competent authorities have been seeing in live reports, which makes the documents a useful diagnostic for any firm’s reporting playbook.
What the instructions are, and are not
The ESAs say the instructions are provided on a best efforts basis by ESAs staff and do not represent a legal interpretation or the official stance of the ESAs. They have been agreed with the relevant competent authorities and will be updated regularly. Their stated purpose is to support supervisory engagement, enhance data quality and promote greater consistency across jurisdictions. Competent authorities notify the ESAs using pre-defined templates in English, so values in closed questions follow the English-language ITS terminology, though free-text fields may still be provided in the applicable national language.
The label matters. A best efforts staff document is not, in our reading, a rule, and departing from it for good reason should not itself be a breach. But the same document tells you what the people reading your report expect to see, and where they have been sending reports back. Treat it accordingly.
The ESA list, field by field
Identity first. The values in fields 1.3a/1.3b and 2.1 must remain unchanged from the initial notification through to the final report, because they identify the incident and a change can produce double counting.
Then cadence. RTS 2025/301 requires the final report “no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report”, as the ESAs quote it. The ESAs therefore expect at least one intermediate report per month until the final report is produced and submitted. Corrections are to be filed as a new version of the latest report submitted, carrying all the information from that report, not as a stand-alone fragment.
Classification. Under RTS 2024/1772 the criterion of affected critical services must always be fulfilled alongside at least one other criterion, and the ESAs expect every report to name it explicitly in field 2.5. Field 2.6, geographical spread, concerns impact in other Member States, so the home country of the affected entity should not be listed there. Where an incident originates with a third-party provider or another financial entity, field 2.8 is to be completed in a standardised order separated by semicolons: full legal name, identification code, whether the code is an LEI or EUID, then any further information.
Numbers and blanks. Monetary fields are reported in thousands of units, so EUR 2 500 382 is entered as 2 500. Free-text fields should carry only information relevant to the field, and where a field is not mandatory and not applicable the ESAs recommend leaving it blank.
What the CSSF added
The CSSF’s table is about narrative quality. Field 2.4, the incident description, is described as frequently too high-level; the CSSF expects an overview of possible causes, immediate impacts, systems affected and the status of resolution, plus known third-party impacts and, in later reports, the internal severity rating. Where an incident is reclassified from major to non-major, field 2.10 must explain why the incident does not fulfil, and is not expected to fulfil, the major incident criteria. Field 3.23 is multiple-choice: a payment-related incident should carry that type in addition to any other, and an external event should be selected whenever the incident originates with a third party or another financial entity. Field 3.34, temporary recovery measures, is sometimes submitted empty; if no action was taken, the CSSF expects the reason to be documented in the field. The root cause fields 4.1 and 4.2 are expected to align with what was said about origin and incident type earlier in the report. And field 4.6 is expected to go beyond high-level resolution: permanent fixes, whether procedures were adapted, added controls with timelines, and lessons learnt with an action plan giving an identifier, description, owner, status and deadline for each open item.
Read together, the two tables are less a set of new rules than a supervisor’s marked-up copy of the reports firms have been filing.
What it signals
In our reading the pattern is consistent. Almost every item concerns a report that was technically submitted but could not be used: identifiers that drifted, incidents that went quiet after the first intermediate report, descriptions that told an analyst nothing actionable. The move suggests competent authorities are now reading these reports for content rather than receipt, and that follow-up questions are likely where fields are generic. That the CSSF chose to publish its own additions suggests it expects to hold firms to the narrative fields in particular. We expect the list to grow over time; a firm that builds the check into its runbook once will absorb later additions cheaply.
What still applies
The obligations themselves sit in DORA and its technical standards: RTS 2025/301 on the content and timing of initial, intermediate and final reports, ITS 2025/302 on the templates, and RTS 2024/1772 on classification criteria and materiality thresholds. Financial entities in scope must still report a major incident to their competent authority using the reporting channels, templates and format established at national level. In our reading the instructions add no fields, move no deadlines and change no thresholds; they describe how to complete what the standards already require. Whether a specific incident meets the classification thresholds remains a legal and factual question, and where it is contested a firm should take legal advice.
What firms should do
Lock the identifier. The incident reference should be set once at initial notification and be read-only thereafter, in the reporting tool and in the runbook.
Put the cadence in the diary. Every open major incident should generate an intermediate report at least monthly until the final report goes out, and any correction should be filed as a complete new version of the most recent report.
Fix the classification defaults. Pre-select the critical services criterion, strip the home country from the geographical spread list, and hold third-party names and identifiers in the semicolon order so they are pasted, not typed under pressure.
Rebuild the narrative templates. The description and lessons-learnt fields should force causes, systems, impact, status, severity and an owner-dated action plan, and reject placeholder text. A blank optional field is better than a filler word.
Add a pre-submission consistency check. Origin, incident type and root cause should tell one story, and monetary values should be in thousands in the reporting currency.
Then test it. Take the last incident, or a tabletop scenario, and re-run it against both tables before a supervisor does; the discipline is the same one described in our guide to audit readiness for financial firms. Where the compliance function is thin, Taft’s fractional compliance team can review the runbook against these instructions, redraft the templates and rehearse the reporting cycle with the people who will file the next report.
Sources
- Additional CSSF operational instructions on DORA major ICT-related incident reporting, CSSF
- 16 September 2026, EBA
- Additional CSSF Operational Instructions on DORA Major ICT-Related Incident, Primary document
Taft does not provide legal advice. Content is for informational purposes only and subject to regulatory guidance.