Community post

Depuis DORA, subir un incident informatique n’est pas nécessairement un échec réglementaire. En revanche, être incapable de démontrer quand l’incident a été détecté, comment il a été évalué, pourquoi il a été classé comme majeur, ou non, et dans quels délais il a été notifié peut rapidement le devenir.

Un serveur tombe.

Une application devient indisponible.

Un prestataire informatique informe l’entreprise d’un incident de cybersécurité.

Des données deviennent temporairement inaccessibles.

Une activité critique est perturbée pendant plusieurs heures.

Dans les premières minutes, les équipes cherchent naturellement à résoudre le problème.

C’est indispensable.

Mais depuis l’entrée en application de DORA, le 17 janvier 2025, une deuxième horloge tourne en parallèle.

Une horloge réglementaire.

Elle ne mesure pas seulement le temps nécessaire pour restaurer les systèmes.

Elle mesure le temps nécessaire pour :

• détecter ;
• documenter ;
• classifier ;
• escalader ;
• notifier ;
• mettre à jour ;
• et expliquer.

C’est précisément là que se situe probablement l’un des risques DORA les plus sous-estimés.

Le risque n’est plus simplement :

« Avons-nous subi un incident informatique ? »

La question devient :

« Pourrions-nous démontrer, six mois plus tard devant la CSSF, exactement ce que nous savions à chaque moment critique et pourquoi nous avons pris la décision de notifier — ou de ne pas notifier ? »

La distinction est fondamentale.

1. DORA n’exige pas l’absence d’incidents. Il exige leur maîtrise.

Aucune infrastructure informatique sérieuse ne peut raisonnablement garantir qu’aucun incident ne surviendra jamais.

DORA ne repose d’ailleurs pas sur cette fiction.

Le règlement européen organise au contraire un cadre permettant aux entités financières d’identifier, gérer, enregistrer, classifier et, lorsque les critères sont atteints, notifier les incidents majeurs liés aux technologies de l’information et de la communication.

Pour les entités relevant de DORA, l’incident devient donc un objet réglementaire.

À partir du moment où un événement survient, plusieurs questions commencent immédiatement à produire des conséquences :

Quand l’entité en a-t-elle eu connaissance ?

Quand a-t-elle disposé d’informations suffisantes pour l’évaluer ?

Quels critères de classification ont été examinés ?

Quand l’incident a-t-il été considéré comme majeur ?

Qui a pris cette décision ?

Sur quelles informations ?

Quand l’autorité compétente a-t-elle été informée ?

Ces questions ne sont pas théoriques.

Elles déterminent directement le respect des délais de notification.

2. Le détail qui change tout : le délai ne commence pas uniquement avec la notification

Le règlement délégué (UE) 2025/301 fixe désormais très précisément les délais applicables.

La notification initiale d’un incident majeur doit être effectuée le plus tôt possible, et en tout état de cause dans les quatre heures suivant sa classification comme incident majeur, sans dépasser 24 heures à compter du moment où l’entité financière a pris connaissance de l’incident.

Le rapport intermédiaire doit ensuite être transmis au plus tard 72 heures après la notification initiale, même lorsque la situation n’a pas évolué.

Le rapport final doit, en principe, être soumis au plus tard un mois après le rapport intermédiaire ou, le cas échéant, après sa dernière mise à jour.

Cette mécanique réglementaire crée une difficulté particulièrement intéressante.

Il existe au moins deux moments différents à documenter :

T0 : awareness of the incident

et

T1 : classification as major.

Entre les deux se déroule tout le processus d’analyse.

Et c’est précisément cette période qui peut devenir extrêmement sensible lors d’une inspection.

Car une question évidente peut apparaître :

Pourquoi l’incident n’a-t-il été classé comme majeur qu’à 17h42 alors que vos équipes en avaient connaissance depuis 09h15 ?

Pour répondre correctement, une entreprise doit disposer de beaucoup plus qu’un formulaire de notification.

Elle doit disposer de la preuve de son raisonnement.

3. Le véritable risque DORA pourrait donc être le “decision gap”

Prenons un cas volontairement simple.

À 08h47, un prestataire ICT informe l’entreprise qu’un service utilisé par plusieurs fonctions est indisponible.

À 09h05, IT ouvre un ticket.

À 09h30, le problème est considéré comme technique et temporaire.

À 11h15, l’indisponibilité continue.

À 13h40, les équipes réalisent que certaines opérations critiques ne peuvent plus être exécutées.

À 15h10, Compliance et Risk sont informés.

À 16h00, une première évaluation DORA est réalisée.

À 18h00, l’incident est classé comme majeur.

La question du superviseur pourrait ne pas porter uniquement sur la notification effectuée après 18h00.

Elle pourrait porter sur les neuf heures précédentes.

Pourquoi Compliance n’a-t-elle été informée qu’à 15h10 ?

Quels critères de matérialité étaient disponibles à 11h15 ?

Existe-t-il une règle claire permettant à IT de savoir quand déclencher l’analyse réglementaire ?

Quelqu’un a-t-il documenté à 13h40 le fait qu’une fonction critique était impactée ?

Qui disposait de l’autorité permettant de classifier l’incident ?

Pourquoi la classification a-t-elle nécessité près de deux heures supplémentaires ?

Toutes ces questions examinent la même chose :

la qualité du processus de décision.

4. Un incident bien géré mais mal documenté peut devenir un mauvais dossier réglementaire

Imaginons maintenant que les équipes aient réagi de manière excellente.

Le système est isolé.

Les utilisateurs sont informés.

Le fournisseur est challengé.

Le business continuity plan est activé.

Le service est restauré.

Aucune donnée n’est perdue.

Aucun investisseur ne subit de préjudice.

Opérationnellement, l’incident a été remarquablement géré.

Mais six mois plus tard, lors d’une inspection, personne n’est capable de déterminer avec certitude :

quand l’incident a été détecté ;

quand le management en a eu connaissance ;

quand il a été considéré comme potentiellement majeur ;

quels critères réglementaires ont été testés ;

qui a validé la classification ;

pourquoi certains seuils ont été considérés comme atteints ou non atteints.

L’entreprise dispose de centaines d’e-mails.

De messages Teams.

De tickets IT.

De rapports du prestataire.

De captures d’écran.

Mais pas d’une chronologie réglementaire consolidée.

C’est là que le problème apparaît.

L’organisation possède de l’information.

Mais elle ne possède pas nécessairement de preuve.

5. Sous DORA, l’horodatage devient presque aussi important que le contenu

Dans beaucoup de processus de compliance traditionnels, il est essentiel de démontrer ce qui a été décidé.

Dans la gestion des incidents DORA, il devient tout aussi important de démontrer quand cette décision a été prise.

Prenons une phrase apparemment anodine :

« The incident was assessed as major. »

Elle est insuffisante.

Il faut potentiellement être capable de démontrer :

18:02 — les derniers éléments nécessaires à la classification sont reçus ;

18:07 — l’évaluation des critères DORA est complétée ;

18:14 — Risk confirme que les seuils sont atteints ;

18:19 — Compliance confirme l’obligation de reporting ;

18:24 — le responsable autorisé valide la classification ;

18:37 — préparation de la notification ;

19:03 — transmission à l’autorité compétente.

Cette chronologie transforme une affirmation en preuve.

Elle permet surtout de répondre à la question réglementaire la plus importante :

L’organisation a-t-elle agi sans retard injustifié dès qu’elle disposait de l’information pertinente ?

6. Le 29 septembre 2026, la CSSF a envoyé un signal particulièrement clair

Le sujet est devenu encore plus actuel au Luxembourg.

Le 29 septembre 2026, soit moins d’une semaine avant la rédaction du présent article, la CSSF a publié des instructions opérationnelles complémentaires concernant la notification des incidents majeurs liés aux TIC dans le cadre de DORA.

La CSSF rappelle notamment les instructions opérationnelles publiées par les autorités européennes de supervision et précise que ces orientations doivent permettre d’améliorer la qualité des informations communiquées, d’harmoniser les pratiques de notification et de réduire les échanges ultérieurs avec les autorités.

Le message mérite d’être lu au-delà de sa dimension technique.

Le superviseur ne s’intéresse pas seulement au fait qu’un rapport ait été transmis.

Il s’intéresse à la qualité de ce qui est transmis.

Autrement dit :

reporting effectué ne signifie pas nécessairement reporting maîtrisé.

La notification devient elle-même un processus de contrôle réglementaire.

Toute la mécanique repose sur une étape particulièrement délicate :

la qualification de l’incident.

Tous les incidents ICT ne sont évidemment pas des incidents majeurs au sens de DORA.

Le processus de classification doit donc être suffisamment robuste pour distinguer :

un événement technique mineur ;

un incident ICT ;

un incident présentant un impact matériel ;

et un incident répondant aux critères réglementaires de major incident.

Mais cette analyse doit également être reproductible.

Une organisation mature ne devrait jamais se trouver dans une situation où la conclusion dépend essentiellement de la personne présente ce jour-là.

Deux personnes différentes confrontées au même événement devraient parvenir à une conclusion réglementaire raisonnablement comparable.

Cela suppose :

des critères clairement documentés ;

des sources de données identifiées ;

des responsabilités définies ;

une méthodologie commune ;

et une gouvernance d’escalade.

Sinon, le risque apparaît immédiatement :

le même incident pourrait être “major” le lundi et “non-major” le vendredi selon la personne réalisant l’analyse.

Ce n’est pas un problème informatique.

C’est un problème de gouvernance.

8. La décision de ne pas reporter doit être aussi documentée que celle de reporter

Voici probablement l’un des points les plus importants.

Les organisations ont naturellement tendance à documenter soigneusement les incidents ayant fait l’objet d’une notification.

Mais qu’en est-il des incidents analysés puis considérés comme non reportables ?

Ce sont parfois eux qui présentent le risque réglementaire le plus important.

Pourquoi ?

Parce qu’un superviseur peut parfaitement sélectionner a posteriori un incident figurant dans le registre interne et demander :

« Pourquoi cet incident n’a-t-il pas été notifié ? »

Une réponse telle que :

« Nous avions considéré qu’il n’était pas suffisamment important »

est extrêmement fragile.

Une réponse robuste serait plutôt :

« Nous avons appliqué les critères de classification DORA le 14 avril à 10h35. Les critères A et B étaient satisfaits, mais les seuils X, Y et Z ne l’étaient pas sur la base des données disponibles à cette date. L’évaluation a été revue à 15h00 après réception d’informations complémentaires et la conclusion est restée inchangée. Voici l’analyse, les données sources et les validations. »

La différence entre les deux est immense.

La première est une opinion.

La seconde est une position réglementaire démontrable.

C’est probablement ici que les organisations financières peuvent faire évoluer leur dispositif.

Chaque incident présentant une matérialité suffisante devrait pouvoir être reconstitué à travers un dossier standardisé que l’on pourrait appeler :

DORA Incident Evidence Pack

Il ne s’agirait pas d’ajouter de la bureaucratie.

Il s’agirait de transformer des informations dispersées en chaîne de preuve cohérente.

Le dossier devrait notamment permettre de retrouver immédiatement :

1. Detection

Quand l’incident est-il apparu ?

Quand a-t-il été détecté ?

Par quel système ou quelle personne ?

2. Awareness

Quand l’organisation en a-t-elle eu connaissance ?

Quelle fonction était informée ?

Existe-t-il une preuve horodatée ?

3. Initial assessment

Quelle était l’information disponible au départ ?

Quelles hypothèses ont été formulées ?

4. DORA classification

Quels critères réglementaires ont été évalués ?

Quels seuils étaient atteints ?

Lesquels ne l’étaient pas ?

5. Decision

Qui a décidé de classer l’incident comme majeur ou non majeur ?

À quelle heure ?

6. Escalation

Quand IT, Risk, Compliance, le senior management ou les organes de gouvernance concernés ont-ils été informés ?

7. Regulatory reporting

Quand la notification initiale a-t-elle été envoyée ?

Quand les rapports intermédiaires ont-ils été transmis ?

Le rapport final ?

8. Remediation

Quelles mesures ont été prises ?

Quelles actions restent ouvertes ?

9. Root cause

Quelle était la cause profonde ?

Interne ?

Prestataire ?

Configuration ?

Erreur humaine ?

Cyberattaque ?

10. Lessons learned

Qu’a changé l’organisation à la suite de l’incident ?

Sans cette dernière étape, l’organisation gère des événements.

Elle ne construit pas nécessairement de résilience.

De nombreuses organisations disposent aujourd’hui d’un incident register.

Date.

Description.

Impact.

Owner.

Status.

Cela constitue un bon point de départ.

Mais le simple enregistrement des incidents ne suffit pas.

Un véritable framework doit permettre de reconstruire la dynamique de décision.

Le registre devrait donc intégrer des informations beaucoup plus significatives :

Detection timestamp

Awareness timestamp

Classification started

Classification completed

Major / non-major

Rationale

Decision maker

Regulatory notification required

Initial notification timestamp

Intermediate report timestamp

Final report timestamp

Critical function impacted

ICT third party involved

Root cause

Financial impact

Remediation

Closure validation

Le changement semble subtil.

Il est en réalité majeur.

On passe d’un incident log à un regulatory decision log.

11. Le rôle des prestataires ICT crée un autre risque : “nous attendions leur analyse”

Imaginons qu’un incident survienne chez un prestataire critique.

L’entité financière demande des informations.

Le prestataire répond :

« Investigation ongoing. »

Deux heures plus tard :

« No further information available. »

Six heures plus tard :

« Root cause still under investigation. »

Le danger serait de considérer que l’horloge réglementaire est suspendue jusqu’à ce que le prestataire ait terminé son analyse.

Ce raisonnement peut être problématique.

L’entité financière reste responsable de ses propres obligations DORA.

Elle doit donc disposer d’un mécanisme permettant d’évaluer l’incident sur la base des informations disponibles à chaque moment, quitte à mettre à jour ensuite son appréciation.

Le principe devrait être simple :

L’incertitude du fournisseur ne doit jamais devenir l’absence de décision de l’entité financière.

C’est précisément pour cette raison que les contrats, mécanismes d’escalade, SLA, obligations de notification et accès aux informations des prestataires ICT deviennent stratégiques.

La gouvernance mérite également d’évoluer.

Un Board ou un senior management ne gagne pas nécessairement beaucoup à recevoir :

« 14 incidents ICT ce trimestre. »

Ce chiffre ne dit presque rien.

Un reporting DORA beaucoup plus mature présenterait par exemple :

14 incidents ICT identifiés

dont

3 incidents ayant déclenché une analyse formelle DORA

dont

1 classifié comme majeur

avec

100 % des notifications effectuées dans les délais réglementaires

temps médian entre detection et awareness : X

temps médian entre awareness et classification : Y

2 incidents impliquant un ICT third-party provider