La CSSF n'a modifié aucun délai DORA. Le 29 septembre 2026, elle a publié une communication qui fait deux choses. Elle demande aux entités financières luxembourgeoises de tenir compte des instructions opérationnelles publiées conjointement le 16 septembre 2026 par les trois autorités européennes de surveillance (AES), l'ABE, l'AEAPP et l'AEMF. Et elle y ajoute sept instructions propres, chacune liée à un champ du modèle de rapport d'incident majeur où la CSSF a constaté des rapports défaillants (CSSF, 29 septembre 2026). Aucun des deux documents ne touche aux seuils de classification ni aux délais de notification. Les deux portent sur la manière de remplir le modèle, champ par champ. Pour la personne qui porte le dossier DORA, la question pratique est de savoir si celui qui remplit le modèle, souvent en sécurité informatique plutôt qu'en compliance, sait désormais ce que le régulateur attend dans chaque champ.
Ce que la CSSF a publié le 29 septembre 2026
La communication, publiée en anglais uniquement, n'est pas une nouvelle circulaire. Elle attire l'attention sur les instructions des AES et indique que la CSSF attend des entités financières qu'elles en tiennent compte pour harmoniser leurs processus de notification des incidents. Elle met ensuite en avant des instructions complémentaires qui lui sont propres, destinées à améliorer la qualité des informations transmises dans les rapports d'incidents majeurs, à rendre le processus plus efficace et à réduire les échanges ultérieurs, et précise que les entités financières sont tenues d'en tenir dûment compte. En pratique, la CSSF dispose désormais d'un repère écrit à l'aune duquel elle peut lire chaque rapport reçu.
Les sept champs relevés par la CSSF
Le document propre de la CSSF est un tableau de trois pages. Chaque ligne désigne un champ du modèle défini par le règlement d'exécution (UE) 2025/302, ce que la CSSF a constaté et ce qu'elle attend (instructions additionnelles de la CSSF, 28 septembre 2026).
| Champ | Ce que la CSSF a constaté | Ce qu'elle attend |
|---|---|---|
| 2.4, description de l'incident | Trop général ou générique | Causes possibles, impacts immédiats, systèmes touchés, état de la résolution, tiers ou autres entités touchés, et mises à jour dans les rapports suivants |
| 2.10, reclassement en incident non majeur | Justification omise | Pourquoi l'incident ne remplit pas, et ne devrait pas remplir, les critères d'un incident majeur |
| 3.23, type d'incident | Un seul type sélectionné | Tous les types applicables, dont « External event » lorsque l'incident provient d'un tiers |
| 3.29, infrastructure touchée | Trop générique ou incomplet | Les composants matériels et logiciels touchés |
| 3.34, actions temporaires | Parfois laissé vide | Les actions de rétablissement menées ou prévues, ou la raison de leur absence |
| 2.8, 3.23, 4.1 et 4.2 | Réponses incohérentes, surtout pour les incidents provenant de tiers | Des champs de cause profonde alignés sur l'origine tierce et le type d'incident |
| 4.6, résolution et enseignements | Très général ou incomplet | Actions de résolution, enseignements tirés et, pour les actions ouvertes, un identifiant, un responsable, un statut et une échéance |
Ce que les trois autorités de surveillance ont publié le 16 septembre 2026
Le document des AES compte quatorze instructions. Les AES les présentent comme des indications fournies au mieux par leurs services, convenues avec les autorités compétentes, qui ne constituent pas une interprétation juridique et seront mises à jour régulièrement (AES, 16 septembre 2026). Elles visent la cohérence entre les États membres qui transmettent ces rapports aux AES. Quelques-unes changent la pratique quotidienne :
- les champs monétaires 3.11, 4.13 et 4.14 sont déclarés en milliers, dans la devise indiquée au champ 1.15 ;
- les identifiants de l'incident aux champs 1.3a, 1.3b et 2.1 restent inchangés de la notification initiale au rapport final, faute de quoi l'incident risque d'être compté deux fois ;
- « services critiques affectés » figure toujours parmi les critères de classification au champ 2.5, et le pays d'origine de l'entité est exclu de l'étendue géographique au champ 2.6 ;
- l'origine tierce au champ 2.8 suit un format fixe : dénomination légale ; LEI ou EUID ; type de code ; toute autre information, séparés par des points-virgules ;
- les champs de texte libre ne contiennent que des informations pertinentes, et un champ ni obligatoire ni applicable est laissé vide plutôt que rempli de « sans objet ».
Les valeurs à choix fermés suivent la terminologie anglaise du règlement 2025/302, mais les champs de texte libre peuvent rester rédigés dans la langue nationale.
Les délais de notification n'ont pas bougé
Les délais viennent de l'article 5 du règlement délégué (UE) 2025/301, auquel renvoie la circulaire CSSF 25/893 (point 9). Ils sont inchangés (règlement 2025/301, article 5) :
- la notification initiale dans les quatre heures suivant la classification de l'incident comme majeur, et au plus tard vingt-quatre heures après en avoir eu connaissance ;
- le rapport intermédiaire dans les soixante-douze heures suivant la notification initiale, même si le statut ou le traitement de l'incident n'a pas changé, puis un rapport intermédiaire mis à jour lorsque les activités normales ont été rétablies ;
- le rapport final au plus tard un mois après le rapport intermédiaire ou, le cas échéant, après le dernier rapport intermédiaire mis à jour.
Les AES ajoutent une attente : après le premier rapport intermédiaire, au moins un rapport intermédiaire mis à jour par mois jusqu'au rapport final. Les déclarations luxembourgeoises passent par la procédure « DORA Major ICT-related Incident Notification » du portail eDesk de la CSSF ou par l'interface API (S3) de la CSSF. Depuis la mise à jour du 27 août 2026, une entité confrontée à une impossibilité technique informe la CSSF par e-mail à ictrisksupervision@cssf.lu dans les mêmes délais, et explique pourquoi elle a utilisé ce canal (CSSF 25/893, points 8 et 9).
Ce que cela signifie pour la deuxième ligne
Les responsables de la deuxième ligne rédigent rarement eux-mêmes le rapport d'incident, mais ce sont généralement eux qui le valident, ou qui expliquent ensuite à la CSSF un rapport tardif ou incomplet. Trois actions valent la peine d'être menées avant le prochain incident, et non pendant celui-ci.
- Lire les deux séries d'instructions avec la personne qui remplit le modèle, et mettre à jour votre guide interne de complétion pour les champs qu'elles désignent.
- Vérifier que ce que vous consignez pour chaque incident, les critères de classification du règlement délégué 2024/1772, le tiers et son LEI, la cause profonde, se reporte directement dans les champs 2.5, 2.8, 3.23, 4.1 et 4.2, afin que la première version de tout rapport soit déjà alignée.
- Conserver une trace courte de cette revue. La CSSF attend des entités qu'elles tiennent dûment compte des instructions, et une deuxième ligne capable de montrer qu'elle l'a fait est mieux placée que celle qui ne le peut pas.
Rien de tout cela ne modifie votre dispositif DORA. C'est un rappel que la qualité de la notification, et pas seulement sa rapidité, est désormais un point que la CSSF mesure.
Où se place Klavius
Klavius rédige pour vous la notification d'incident majeur, et garde l'horloge sous vos yeux pendant que vous la vérifiez. Dans son module DORA, un incident est enregistré avec le moment de sa détection, et l'horloge de notification démarre à partir de là. Lorsque l'évaluation au regard des critères du règlement délégué 2024/1772 le classe comme majeur, Klavius horodate la classification, et la fiche de l'incident affiche l'échéance de la notification initiale sous forme de compte à rebours : quatre heures après la classification, et jamais plus de vingt-quatre heures après la détection. Chaque envoi fixe ensuite l'échéance suivante, soixante-douze heures après la notification initiale pour le rapport intermédiaire, et un mois après le dernier rapport intermédiaire pour le rapport final. Lorsque les activités reprennent normalement, Klavius signale que le rapport intermédiaire mis à jour est attendu. Chaque envoi est enregistré face à son échéance : le respect des délais est au dossier, et non reconstitué après coup.
Le brouillon part de ce que la plateforme connaît déjà. Les identifiants et contacts de l'entité, les heures de détection et de classification, les critères remplis par l'incident, l'atteinte éventuelle aux services critiques et le tiers concerné sont repris de la fiche de l'incident, de l'évaluation et du profil de l'entité. Klavius rédige ensuite les champs narratifs, comme la description de l'incident, à partir du dossier et de l'évaluation. Votre responsable relit et corrige chaque champ : c'est là que les sept instructions de la CSSF s'appliquent, par quelqu'un qui connaît l'incident. Le rapport s'exporte ensuite au format du modèle CSSF, prêt à être déposé via eDesk. Klavius prépare ; vos responsables valident et signent. Voir la page DORA.
Sources
- CSSF, Instructions opérationnelles additionnelles de la CSSF relatives à la notification des incidents majeurs liés aux TIC dans le cadre DORA, communiqué en anglais, 29 septembre 2026, et le document d'instructions de la CSSF, mis à jour le 28 septembre 2026.
- ABE, AEAPP, AEMF, DORA Incident Reporting, Operational Instructions, 16 septembre 2026.
- CSSF, circulaire CSSF 25/893 relative à la notification des incidents majeurs liés aux TIC et des cybermenaces importantes dans le cadre DORA, publiée le 28 mai 2025, telle que modifiée par la circulaire CSSF 26/915 du 27 août 2026, points 8 et 9.
- Règlement délégué (UE) 2025/301, article 5.