CSSF — Circulaire 25/893 : alerte et reporting TIC durcis sous DORA

Le 17 mars 2026, la CSSF a rappelé la collecte du registre DORA et l’entrée en application de la circulaire 25/893 sur la classification et la notification des incidents TIC et cybermenaces significatives. Voici comment une pile EDR/XDR permet de s’y conformer sans délai.

Les faits

Le 17 mars 2026, la CSSF a publié une mise à jour de la « collecte du registre d’information » DORA et réitéré les obligations de notification des incidents TIC via son portail eDesk, dans le prolongement de la circulaire CSSF 25/893 entrée en vigueur fin 2025. Cette circulaire impose aux entités financières soumises à DORA de classifier et notifier les incidents majeurs liés aux TIC ainsi que, sur base volontaire, les cybermenaces significatives, selon des formulaires et délais harmonisés par les normes techniques européennes (ITS/RTS). Les prestataires de services de paiement non couverts par DORA sont explicitement visés par des exigences de classification et de notification alignées. La CSSF précise en outre l’organisation pratique (rôle « DORA Reporting », soumissions via eDesk et mises à jour régulières du registre des dépendances TIC) et resserre les attentes opérationnelles en matière de détection et de remontée d’incident.

Sources CSSF : mise à jour « DORA – Collecte du registre d’information » du 17/03/2026 (cssf.lu) et circulaire CSSF 25/893 (PDF) (cssf.lu), complétées par l’avis d’ouverture eDesk au 11/02/2026 (cssf.lu).

Pourquoi cela compte maintenant ? Les attaques progressent en intensité et en vitesse : en mai 2026, GitHub a confirmé qu’environ 3 800 dépôts internes ont été compromis via une extension VS Code piégée — un exemple supplémentaire de compromissions rapides qui exigent une détection et une notification quasi temps réel. (BleepingComputer)

Le cadre légal qui s’applique

Le règlement (UE) 2022/2554 (DORA) encadre la gestion des incidents TIC :

• Art. 17–18 : processus de gestion et critères de classification (incidents majeurs, cybermenaces).
• Art. 19 : notification des incidents majeurs et notification volontaire des cybermenaces significatives (gabarits et délais harmonisés par ITS/RTS). Voir EUR‑Lex et un rappel synthétique de l’art. 19 (Better Regulation).
• Art. 20–21 : contenu standardisé et centralisation du reporting.

La circulaire CSSF 25/893 durcit l’opérationnalisation au Luxembourg : elle précise la classification et le reporting pour les entités DORA et aligne des exigences pour certains PSP non‑DORA (cadre de notification, canaux eDesk, périmètre et définitions). Elle rappelle aussi l’articulation avec la collecte du registre d’informations (art. 28 DORA) via eDesk, dont la fenêtre 2026 a été formalisée par la CSSF. Pour un rappel pédagogique du cadre DORA côté Luxgap, voir les éléments clés de DORA. Références : Circulaire 25/893 (PDF), communiqué eDesk du 11/02/2026, et page thématique « TIC et cyber‑risque – entités DORA » (cssf.lu).

La solution technique à déployer

EDR/XDR — détection et réponse sur les terminaux et l’infrastructure — est la brique technique qui rend praticable la conformité CSSF/DORA :

• À quoi ça sert : identifier tôt les comportements anormaux (exfiltration, exécution malveillante, mouvements latéraux), contenir automatiquement (isolation réseau, blocage d’exécutables), et conserver des artefacts forensiques pour classer l’incident et documenter le rapport initial/intermédiaire/final.
• Comment ça marche : agents EDR sur postes/serveurs, capteurs sur workloads cloud, agrégation télémétrie réseau/identité/SaaS dans une plateforme XDR corrélée. Intégrations SIEM/SOAR pour remontées eDesk dans les délais.
• Contrôles concrets :
  • Détection (DORA art. 10 et ISO/IEC 27001:2022 Annexe A.5.28, A.8.16) : règles comportementales, détection d’exploit/certutil/PowerShell, marquage d’exfiltration.
  • Réponse et reprise (DORA art. 11) : containment automatique, playbooks d’éradication, vérification de remédiation.
  • Journalisation et preuves (ISO 27001 A.5.10, A.8.15; NIST CSF 2.0 DE.AE, RS.AN) : horodatage fiable, conservation, hash, chaîne de possession pour les rapports CSSF.
  • Classification/Reporting (DORA art. 18–20) : tableaux de bord mappés aux seuils ITS/RTS (impacts, indisponibilité, clients touchés), export des métadonnées structurées vers eDesk.

En pratique, une pile EDR/XDR bien raccordée au SIEM et à un moteur SOAR permet de produire les éléments exigés par la circulaire 25/893 en heures plutôt qu’en jours : chronologie, indicateurs d’impact, étendue des systèmes concernés, et mesures correctrices appliquées.

Comment Luxgap déploie cela

• Notre SOC managed 24/7 : onboarding des logs et de la télémétrie EDR/XDR, corrélation en temps réel, hunt proactif, et playbooks d’escalade alignés sur les jalons DORA (notification initiale, rapports intermédiaires et final). Nous préparons les exports eDesk et validons la classification avec votre CISO/DPO avant soumission. Découvrez notre approche SOC managé pour l’EDR/XDR.
• Notre gouvernance ISO 27001 : cadrage des politiques de journalisation, des durées de conservation, du modèle de preuve (hash/horodatage) et des procédures d’incident handling documentées — indispensables pour répondre aux demandes CSSF post‑incident.
• Nos consultants DPO et CISO externalisés : animation des cellules de crise, qualification DORA art. 18/19, cohérence RGPD (art. 33 CNPD si données personnelles touchées) et coordination des notifications multiples (CSSF/CSIRT/CNPD si nécessaire). Pour le pilotage, nous proposons un CISO externalisé aux côtés de votre équipe.

Cas concret au Luxembourg ou en UE

Exemple réaliste : une société de gestion soumise à DORA, avec prestataires TIC multiples, subit un début d’exfiltration via une extension IDE compromise. Grâce à l’EDR, l’exécutant malveillant est détecté par règle comportementale (lancement anormal de curl et empaquetage d’artefacts). Notre SOC isole les hôtes, rassemble la télémétrie (process tree, connexions sortantes), évalue l’impact (aucune fonction critique indisponible, données clients non atteintes), et qualifie l’événement. Résultat :

• Notification initiale structurée via eDesk dans les délais prévus par l’ITS,
• Rapport intermédiaire 24–72 h avec IOCs/mesures,
• Rapport final avec analyse de cause racine, durcissement des contrôles, et mise à jour du registre d’informations (art. 28)

— le tout piloté par des éléments probants issus de l’EDR/XDR et conservés selon ISO 27001.

Premiers pas concrets

1. Cartographiez vos fonctions critiques DORA et reliez‑les à des use cases de détection XDR (indisponibilité, dégradation, atteinte aux données) pour accélérer la classification art. 18.
2. Activez l’EDR sur 100 % des actifs critiques (postes, serveurs, workloads cloud) et validez les intégrations SIEM/SOAR. Testez l’isolation automatique sur un périmètre pilote.
3. Établissez les modèles eDesk (templates ITS/RTS) avec votre CISO/Compliance : qui rédige quoi, dans quel délai, et comment extraire les métriques d’impact depuis XDR.
4. Mettez à jour le registre d’informations (art. 28) et nommez un titulaire du rôle « DORA Reporting » dans eDesk (CSSF) avec relais de secours.
5. Faites un exercice table‑top « compromission développeur/extension IDE » pour roder la chaîne détection‑>classification‑>notification‑>remédiation en 48 h.

Sources officielles

• CSSF — Circulaire 25/893 (PDF)
• CSSF — DORA, collecte du registre d’information (17 mars 2026)
• CSSF — eDesk « DORA Reporting » ouvert dès le 11 février 2026
• EUR‑Lex — Règlement (UE) 2022/2554 (DORA) et Art. 19 — notification d’incidents TIC
• BleepingComputer — GitHub confirme une compromission (~3 800 dépôts), 20 mai 2026