Les nouvelles instructions de la CSSF sont-elles contraignantes ?

Il s'agit d'instructions opérationnelles, pas d'un nouvel acte juridique. La CSSF indique que les entités financières sont censées en tenir compte ; les AES précisent que leurs propres instructions sont fournies au mieux et ne constituent pas une interprétation juridique.

À quels modèles renvoient les numéros de champs ?

Aux modèles du règlement d'exécution (UE) 2025/302 de la Commission du 23 octobre 2024 relatif aux formulaires et procédures de déclaration des incidents majeurs liés aux TIC.

À quelle fréquence faut-il mettre à jour un incident majeur ?

Les instructions des AES rappellent que le rapport final est dû au plus tard un mois après le dernier rapport intermédiaire ; elles attendent donc au moins un rapport intermédiaire par mois jusqu'au rapport final.

DORA : la CSSF précise comment remplir les déclarations d'incidents TIC majeurs au Luxembourg

Le 29 septembre 2026, la CSSF a publié sept instructions champ par champ pour les déclarations d'incidents TIC majeurs sous DORA, afin d'en améliorer la qualité.

Le 29 septembre 2026, la Commission de Surveillance du Secteur Financier (CSSF) a publié des instructions opérationnelles complémentaires à l’intention des entités financières luxembourgeoises qui déclarent des incidents majeurs liés aux TIC au titre de DORA. Ces sept instructions, datées du 28 septembre 2026, précisent ce que la CSSF attend dans certains champs des modèles européens de déclaration. Elles s’ajoutent aux 14 instructions publiées par le personnel des autorités européennes de surveillance (AES), datées du 16 septembre 2026.

Ce que la CSSF a publié

Selon le communiqué de la CSSF, ces instructions visent à soutenir le dialogue prudentiel, à améliorer la qualité des données et à favoriser la cohérence entre juridictions ; les entités financières sont censées en tenir compte. Le communiqué s’adresse aux dépositaires centraux de titres, établissements de crédit, gestionnaires de crédits, prestataires de services sur crypto-actifs, prestataires de services de communication de données, entreprises d’investissement, gestionnaires de fonds d’investissement, ainsi qu’aux établissements de paiement, établissements de monnaie électronique et prestataires de services d’information sur les comptes.

Chaque instruction du document de la CSSF cite un champ des modèles du règlement d’exécution (UE) 2025/302, le problème constaté et ce qui est attendu :

Champ	Constat de la CSSF	Attente
2.4 Description de l’incident	Souvent trop générale	Aperçu des causes, impacts, systèmes touchés et état de résolution ; tiers concernés ; mises à jour dans les rapports suivants
2.10 Reclassement en non majeur	Justification absente	Les raisons pour lesquelles 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 coché	Tous les types applicables, p. ex. « Payment-related » et « System failure » ; « External event » si l’origine est un tiers
3.29 Infrastructure touchée	Trop générale ou incomplète	Les composants matériels et logiciels touchés
3.34 Mesures temporaires	Parfois laissé vide	Les mesures de rétablissement prises ou prévues, ou la raison de leur absence
2.8, 3.23, 4.1, 4.2	Réponses incohérentes	Des causes profondes cohérentes avec l’origine tierce et le type d’incident
4.6 Résolution et enseignements	Très générale ou incomplète	Actions de résolution, contrôles ajoutés et plan d’action avec identifiant, responsable, statut et échéance

La base fixée par les AES

Les instructions opérationnelles des AES sont fournies au mieux, ne constituent pas une interprétation juridique et ont été convenues avec les autorités nationales compétentes. Elles demandent notamment :

de déclarer les champs monétaires 3.11, 4.13 et 4.14 en milliers d’unités, dans la devise indiquée au champ 1.15 ;
de laisser vides les champs de texte libre non obligatoires plutôt que d’écrire « non applicable » ou « néant » ;
de conserver inchangés les identifiants des champs 1.3a, 1.3b et 2.1 de la notification initiale au rapport final, pour éviter les doubles comptages ;
de toujours mentionner « services critiques affectés » parmi les critères du champ 2.5, et de ne pas inclure le pays d’origine dans l’étendue géographique du champ 2.6 ;
d’indiquer une origine tierce au champ 2.8 sous la forme dénomination légale, LEI ou EUID et type de code, séparés par des points-virgules ;
de transmettre au moins un rapport intermédiaire par mois jusqu’au rapport final.

Pourquoi c’est important

Les deux documents ciblent des faiblesses constatées dans le contenu des déclarations ; ils ne créent pas de nouvelles obligations. Pour les entités luxembourgeoises, la déclaration d’incidents devient aussi un sujet de qualité des données : identifiants stables, données fiables sur les tiers et classifications cohérentes d’un champ à l’autre.

Que faire maintenant

Relire les dernières déclarations d’incidents à la lumière des sept instructions de la CSSF et des 14 instructions des AES.
Mettre à jour les modèles et consignes internes pour les champs 2.4, 3.23, 3.29 et 4.6.
Vérifier que les prestataires tiers sont enregistrés avec un LEI ou un EUID valide, afin de remplir correctement le champ 2.8.
Désigner un responsable de la stabilité des identifiants d’incident tout au long du cycle de déclaration.

DORA : la CSSF précise comment remplir les déclarations d'incidents TIC majeurs au Luxembourg

L'essentiel

Ce que la CSSF a publié

La base fixée par les AES

Pourquoi c’est important

Que faire maintenant

Questions & réponses

Sources