Je dois mettre mon organisation luxembourgeoise en conformité au considérant 22 du DORA (UE 2022/2554). Quelles sont les exigences concretes a respecter, les sanctions encourues, et comment Luxgap peut-il m'accompagner ?

Le piège classiqueCe considérant 22 acte un constat brutal : avant DORA, chaque autorité financiere européenne avait ses propres seuils et taxinomies de notification d'incident TIC. Pour une entité financiere luxembourgeoise active en France, Allemagne et Irlande, cela signifiait jusqu'à quatre formats de notification differents pour le même incident. La CSSF sanctionné aujourd'hui non pas la divergence de format (DORA harmonise cela via les RTS), mais l'incapacite a produire la classification harmonisee dans les délais : initial notification sous 4 heures après classification comme majeur, intermediate report et final report. Le piège n'est plus réglementaire, il est opérationnel.Pourquoi ce considérant change votre architecture de détectionL'intention du legislateur est claire : un incident TIC doit être classifie selon une grille UE unique (critères de l'article 18 et RTS associes : clients impactes, durée, perte de données, criticite des services, impact economique, reputation, geographie). Concretement, cela impose :Une taxonomie interne alignee sur la taxonomie ESA (root cause catégories, incident types, impact dimensions), pas votre taxonomie SIEM historique.Un moteur de scoring automatique qui evalue chaque incident en temps reel contre les 7 critères de classification DORA, parce que 4 heures ne laissent pas le temps a un comite de crise de deliberer.Une traçabilite cryptographique de la décision de classification : pourquoi cet incident a ete jugé majeur (ou non), avec horodatage opposable a la CSSF.Un format de sortie pret a injecter dans le futur hub unique de notification que les ESA construisent, evitant la double saisie.Comment Luxgap automatise ce risqueNotre Luxgap Incident Severity Classifier transforme la classification d'incident TIC d'un exercice subjectif de comite de crise en un verdict automatique horodate, produit en moins de 60 secondes après la détection d'un événement. L'outil ingere les alertes de votre SIEM (Microsoft Sentinel, Splunk, Wazuh, CrowdStrike Falcon), les croise avec votre cartographie de criticite metier issue de l'Information Register DORA et applique en temps reel les 7 critères de classification des RTS ESA pour rendre un score major / non-major opposable a la CSSF.Detecte chaque incident TIC via connecteurs natifs vers Sentinel, Defender XDR, Splunk, CrowdStrike, Wazuh et les flux syslog de vos prestataires TIC critiques.Classifie automatiquement selon les 7 dimensions des RTS DORA (clients affectes, durée, perte de données, criticite, impact economique, reputation, geographie) avec une grille alignee sur la taxonomie ENISA et ESA.Déclenche le compteur des 4 heures des qu'un incident bascule en major et alerte le RSSI, le DPO et le management board via Teams, email et SMS simultanement.Genere automatiquement les trois rapports DORA (initial, intermediate, final) preremplis au format XBRL/JSON attendu par la CSSF, avec champs obligatoires vérifiés.Produit une preuve cryptographique horodatee de la ...

Considérant 22 DORA — Considérant 22

Cadre européenRGPD NIS 2DORAAI Act Lanceurs d'alerte

Circulaires CSSFCSSF 22/806 CSSF 25/883 CSSF 25/880 CSSF 25/881 CSSF 25/882 CSSF 20/750 CSSF 12/552 CSSF 11/504 (abrogée)CSSF 24/847

Considérant 22

Règlement sur la résilience opérationnelle numérique du secteur financier · UE 2022/2554

(22)

Les seuils et les taxinomies de notification des incidents liés aux TIC varient considérablement au niveau national. Bien que des bases communes puissent être dégagées grâce aux travaux pertinents menés par l’Agence de l’Union européenne pour la cybersécurité (ENISA) instituée par le règlement (UE) 2019/881 du Parlement européen et du Conseil (11) et le groupe de coopération relevant de la directive (UE) 2022/2555, des approches divergentes sur la fixation des seuils et l’utilisation des taxinomies existent toujours ou peuvent apparaître pour les autres entités financières. En raison de ces divergences, il existe de multiples exigences auxquelles les entités financières doivent se conformer, notamment lorsqu’elles sont actives dans plusieurs États membres et lorsqu’elles font partie d’un groupe financier. En outre, ces divergences sont susceptibles d’entraver la création de nouveaux mécanismes uniformes ou centralisés au niveau de l’Union, qui accéléreraient le processus de notification et favoriseraient un échange rapide et sans entrave d’informations entre les autorités compétentes, ce qui est essentiel pour faire face au risque lié aux TIC en cas d’attaques à grande échelle susceptibles d’avoir des conséquences systémiques.

Spécificité Luxembourg

Circulaire CSSF 24/847 du 5 aout 2024 relative au cadre de notification des incidents TIC

Au Luxembourg, la CSSF est l'autorité competente pour recevoir les notifications d'incidents TIC majeurs au titre de DORA. La Circulaire CSSF 24/847 précisé le canal de transmission (portail eDesk) et impose un alignement avec les déclarations existantes au titre de la Circulaire CSSF 20/750 sur les exigences en matière de gestion des risques TIC pour le secteur financier. Les entités doivent démontrer que la notification DORA ne fait pas doublon mais remplace les anciens canaux fragmentes.

Pratique Luxgap : configurez le connecteur eDesk CSSF dans l'Incident Severity Classifier des le go-live DORA et testez le flux complet sur un incident fictif en pre-production avant le premier incident reel.

Conseil Luxgap · DPO & CISO

Comment se conformer

Le piège classique

Ce considérant 22 acte un constat brutal : avant DORA, chaque autorité financiere européenne avait ses propres seuils et taxinomies de notification d'incident TIC. Pour une entité financiere luxembourgeoise active en France, Allemagne et Irlande, cela signifiait jusqu'à quatre formats de notification differents pour le même incident. La CSSF sanctionné aujourd'hui non pas la divergence de format (DORA harmonise cela via les RTS), mais l'incapacite a produire la classification harmonisee dans les délais : initial notification sous 4 heures après classification comme majeur, intermediate report et final report. Le piège n'est plus réglementaire, il est opérationnel.

Pourquoi ce considérant change votre architecture de détection

L'intention du legislateur est claire : un incident TIC doit être classifie selon une grille UE unique (critères de l'article 18 et RTS associes : clients impactes, durée, perte de données, criticite des services, impact economique, reputation, geographie). Concretement, cela impose :

Une taxonomie interne alignee sur la taxonomie ESA (root cause catégories, incident types, impact dimensions), pas votre taxonomie SIEM historique.
Un moteur de scoring automatique qui evalue chaque incident en temps reel contre les 7 critères de classification DORA, parce que 4 heures ne laissent pas le temps a un comite de crise de deliberer.
Une traçabilite cryptographique de la décision de classification : pourquoi cet incident a ete jugé majeur (ou non), avec horodatage opposable a la CSSF.
Un format de sortie pret a injecter dans le futur hub unique de notification que les ESA construisent, evitant la double saisie.

Comment Luxgap automatise ce risque

Notre Luxgap Incident Severity Classifier transforme la classification d'incident TIC d'un exercice subjectif de comite de crise en un verdict automatique horodate, produit en moins de 60 secondes après la détection d'un événement. L'outil ingere les alertes de votre SIEM (Microsoft Sentinel, Splunk, Wazuh, CrowdStrike Falcon), les croise avec votre cartographie de criticite metier issue de l'Information Register DORA et applique en temps reel les 7 critères de classification des RTS ESA pour rendre un score major / non-major opposable a la CSSF.

Detecte chaque incident TIC via connecteurs natifs vers Sentinel, Defender XDR, Splunk, CrowdStrike, Wazuh et les flux syslog de vos prestataires TIC critiques.
Classifie automatiquement selon les 7 dimensions des RTS DORA (clients affectes, durée, perte de données, criticite, impact economique, reputation, geographie) avec une grille alignee sur la taxonomie ENISA et ESA.
Déclenche le compteur des 4 heures des qu'un incident bascule en major et alerte le RSSI, le DPO et le management board via Teams, email et SMS simultanement.
Genere automatiquement les trois rapports DORA (initial, intermediate, final) preremplis au format XBRL/JSON attendu par la CSSF, avec champs obligatoires vérifiés.
Produit une preuve cryptographique horodatee de la chaîne de décision (qui a classifie, quand, sur quels critères, avec quel score) opposable lors d'une revue CSSF.
Suit le délai réglementaire en temps reel et alerte 30 minutes avant chaque echeance pour eviter le non-respect des fenetres de notification.

Disponible en complement d'un mandat CISO Luxgap ou en brique SaaS dediee selon votre périmètre. Demandez un devis personnalise et nos équipes preparent une demonstration sur un incident reel rejoue depuis vos logs, avec un audit blanc gratuit sous 48h pour mesurer votre capacite actuelle a tenir les 4 heures réglementaires.

Besoin d'aide ?

Notre équipe (juristes + ingénieurs cyber + devs) vous accompagne. Devis gratuit sous 48h.

Nous contacter →

Considérant 22

Ils nous font confiance

Avant de discuter