ICT Incident Notification — CSSF & DORA Article 19 in practice
As at 25 July 2026, Article 19 of the Digital Operational Resilience Act (Regulation (EU) 2022/2554, applicable since 17 January 2025) requires financial entities to report major ICT-related incidents to their competent authority — in Luxembourg, the CSSF. The hard part isn't knowing that; it's turning a live incident into an accurate, on-time notification. This is the bridge from the article to the filing.
1 · The requirement
Two questions decide everything: is the incident "major"? and, if so, what must be sent, and by when? Classification follows the criteria in the Commission Delegated Regulation on incident classification (Delegated Reg (EU) 2024/1772) — clients/counterparts affected, data losses, reputational impact, duration and service downtime, geographical spread, economic impact, and the criticality of the services touched. Cross the thresholds and reporting obligations begin.
2 · The operational control — the clock
Reporting runs against a clock defined by the reporting RTS/ITS. The shape (confirm exact hours against the current text before relying on them):
| Stage | Indicative timing | Purpose |
|---|---|---|
| Initial notification | shortly after classifying as major (hours, not days) | "this happened, it's major" |
| Intermediate report | within ~72h of the initial notification | status, scope, containment |
| Final report | within ~1 month | root cause, impact, remediation |
The precise deadlines and templates live in the DORA reporting RTS/ITS. Treat the row above as the shape of the obligation, not the letter of it.
3 · The deliverable
Each stage needs the same spine: a defensible, timestamped sequence of events. Build that once, in the Incident Timeline tool, then assemble the notification itself with the Incident Report Generator — it structures the content the authority expects so the filing is complete rather than reconstructed under pressure. The regulator judges the report on accuracy; the timeline is what makes it accurate.