DORA : préparer les premières heures d’un incident TIC majeur

Le premier rapport annuel des autorités européennes sur les incidents TIC majeurs sous DORA donne une leçon plus utile qu’un classement des causes : la préparation à l’incident dépend de la capacité à réunir rapidement des données fiables sur l’impact, le périmètre et les dépendances du SI. En 2025, 3 383 incidents majeurs ont été rapportés dans l’Union européenne ; environ un tiers ont eu un impact transfrontière et presque un tiers provenaient de défaillances attribuables à des tiers.1

Ces chiffres ne signifient pas que le secteur est structurellement fragile. Les ESAs précisent au contraire que le nombre d’incidents, pris isolément, n’est pas un indicateur de risque et que deux tiers des incidents ont entraîné une perturbation nulle ou mineure pour les clients et les transactions.1

Pour un RSSI, la question opérationnelle est donc moins « saurons-nous remplir le formulaire DORA ? » que « saurons-nous produire, sous contrainte de temps, les informations que ce formulaire exige sans reconstruire le SI au milieu de la crise ? ». DORA impose une chaîne de notification progressive : information initiale limitée, rapport intermédiaire plus détaillé, puis rapport final lorsque l’analyse de cause est suffisamment avancée.24

Quand un incident TIC devient-il majeur au sens de DORA ?

DORA distingue l’incident TIC de l’incident TIC majeur. Le règlement définit ce dernier par son impact élevé sur les réseaux et systèmes d’information qui soutiennent des fonctions critiques ou importantes.2 Le règlement délégué 2024/1772 précise ensuite les critères et les seuils utilisés pour la classification.3

Un incident est considéré comme majeur lorsqu’il touche des services critiques et qu’il remplit les conditions de matérialité définies par le règlement délégué : notamment le seuil spécifique prévu à l’article 9, paragraphe 5, point b), ou au moins deux des autres seuils d’importance significative.3

Les critères couvrent notamment les clients, contreparties financières et transactions, la durée et l’interruption de service, la répartition géographique, les pertes de données, la criticité des services et l’impact économique.3

Cette mécanique a une conséquence d’architecture de données : au début de l’incident, la classification ne dépend pas seulement d’un signal technique. Elle exige de relier l’événement à des services, des fonctions, des populations touchées et des effets opérationnels. Une alerte sur un composant n’est donc pas encore une qualification DORA.

Les quatre heures commencent après la classification, mais les 24 heures ont déjà commencé

Le règlement délégué 2025/301 fixe trois échéances.4

La notification initiale doit être envoyée le plus tôt possible, dans les quatre heures suivant la classification comme incident majeur et au plus tard 24 heures après le moment où l’entité a eu connaissance de l’incident. Le rapport intermédiaire est dû au plus tard 72 heures après la notification initiale, même si la situation ou son traitement n’ont pas changé. Le rapport final est dû au plus tard un mois après le rapport intermédiaire, ou après le dernier rapport intermédiaire actualisé lorsqu’il y en a un.4

Il faut donc suivre plusieurs horodatages distincts : détection technique, prise de connaissance au niveau de l’entité, classification comme majeur, soumission de la notification initiale et versions suivantes. Confondre « détecté » et « classifié » peut rendre le pilotage du délai ambigu.

Étape	Échéance réglementaire	Capacité interne nécessaire
Qualification	Dès que les critères peuvent être évalués	Relier incident, services, fonctions et impacts
Notification initiale	≤ 4 h après classification et ≤ 24 h après connaissance	Référence, horodatages, périmètre et informations disponibles
Rapport intermédiaire	≤ 72 h après la notification initiale	Impact enrichi, état du traitement, éléments consolidés
Rapport final	≤ 1 mois après le dernier intermédiaire	Cause, résolution, impacts et coûts consolidés

Le règlement d’exécution 2025/302 impose un modèle unique pour ces étapes et définit les champs à fournir selon le stade du reporting.5 La bonne réponse technique n’est pas nécessairement un nouvel outil : c’est d’abord une source de données identifiable pour chaque champ important.

Construire une colonne vertébrale de données incident avant la crise

Cybercoria recommande de définir un enregistrement interne minimal qui ne cherche pas à reproduire le formulaire réglementaire, mais à relier ses données aux référentiels opérationnels. Par exemple :

incident:
  id: INC-...
  detected_at: ...
  aware_at: ...
  classified_major_at: ...
  affected_services: [...]
  critical_functions: [...]
  affected_entities: [...]
  countries: [...]
  third_parties: [...]
  impact:
    clients: ...
    transactions: ...
    availability: ...
    integrity: ...
  containment_actions: [...]
  root_cause_status: ...
  report_versions: [...]
  evidence_refs: [...]

Cette structure est une proposition Cybercoria, pas une exigence de DORA. Sa valeur tient aux jointures : affected_services doit pouvoir retrouver le catalogue de services ; critical_functions, le référentiel métier ou de continuité ; third_parties, les contrats et services externalisés ; affected_entities, le périmètre juridique ; evidence_refs, les journaux, tickets et décisions conservés pendant la réponse à incident.

À lire aussi
DORA : construire le registre des prestataires TIC à partir du SI réel →

Le registre des prestataires et le reporting d’incident répondent à deux questions différentes mais se rejoignent au moment critique : le registre décrit les dépendances contractuelles et les services TIC ; l’incident doit permettre d’identifier lesquelles sont effectivement touchées. Le premier ne prouve pas que le second sera rapide.

Cas construit : une panne d’identité partagée fait courir deux chronomètres

Prenons un cas construit, sans référence à une organisation réelle. À 08 h 10, la supervision détecte des échecs d’authentification massifs sur un fournisseur d’identité utilisé par plusieurs applications. À 08 h 20, l’équipe d’astreinte confirme que l’incident affecte le service en production et l’organisation en a connaissance. À 09 h 05, l’inventaire des dépendances montre que deux fonctions importantes sont touchées et que des clients de deux pays ne peuvent plus accéder à leurs services. À 10 h 05, l’incident est classifié comme majeur selon les critères applicables.

Dans cet exemple, le plafond lié à la classification place la notification initiale au plus tard à 14 h 05. Le plafond de 24 heures depuis la prise de connaissance arriverait le lendemain à 08 h 20 ; c’est donc l’échéance de 14 h 05 qui contraint ici la notification.4

La différence entre une organisation préparée et une organisation qui improvise se voit dans ce qui se passe entre 08 h 20 et 10 h 05. Si la criticité des fonctions, les applications dépendantes, les entités utilisatrices et le fournisseur sont déjà reliés, l’équipe peut concentrer son temps sur l’impact réel et le rétablissement.

Si ces relations n’existent que dans des fichiers séparés, des mails et la mémoire de quelques personnes, la classification devient elle-même une enquête.

Ce cas ne couvre pas toutes les situations. Un incident de confidentialité, une perte d’intégrité ou un événement touchant des transactions exigera d’autres données et d’autres expertises. Il illustre seulement la valeur d’un modèle de dépendances maintenu avant la crise.

Le premier rapport DORA montre surtout l’interconnexion du risque

Le rapport 2025 apporte trois signaux utiles. D’abord, environ un tiers des incidents majeurs ont eu un impact transfrontière.1 Ensuite, les défaillances de systèmes et les événements externes sont les principaux moteurs observés.1 Enfin, presque un tiers des incidents provenaient de défaillances attribuables à des tiers, catégorie qui inclut prestataires TIC, autres entités financières et fournisseurs d’infrastructure.1

Ces résultats renforcent une exigence opérationnelle déjà visible dans DORA : pendant un incident, il faut pouvoir passer d’un composant touché à la fonction soutenue, au prestataire impliqué, aux entités affectées et au périmètre géographique. La valeur n’est pas dans une carte statique, mais dans la capacité à traverser ces relations sous pression.

Ils ne permettent toutefois pas de conclure qu’un tiers des incidents seraient « causés par le cloud », ni que la cybersécurité représenterait seulement une faible part du risque total. Les ESAs indiquent que 10 % des incidents ont été catégorisés comme liés à la cybersécurité, mais cette statistique appartient à un cadre de classification précis et à une première année de reporting.1

Ce que les 3 383 incidents ne prouvent pas

Le rapport lui-même appelle à la prudence. Environ 15 % des incidents majeurs notifiés en 2025 n’étaient pas inclus dans l’analyse parce qu’aucun rapport final n’avait été reçu avant la date de coupure du 5 février 2026.1

Les ESAs indiquent aussi qu’il s’agissait de la première année du dispositif et que les rapports ne bénéficiaient pas encore de l’ensemble des contrôles automatisés de qualité de données qui pourraient être dérivés des exigences de reporting.1

Le nombre d’incidents ne doit donc ni devenir un benchmark simpliste entre établissements, ni servir à démontrer qu’une organisation est plus résiliente qu’une autre. La donnée agrégée indique des tendances ; elle ne remplace ni l’analyse du contexte ni les tests internes.

Le prochain test utile : produire le dossier initial sans chercher l’information

Un exercice DORA utile peut être beaucoup plus simple qu’une simulation de crise complète. Choisir un service critique, construire un incident plausible, déclencher le chronomètre, puis demander à l’équipe de retrouver les informations nécessaires à la qualification et à la notification initiale.

Mesurer alors quatre choses : le temps pour identifier les fonctions touchées ; le temps pour déterminer les entités et pays concernés ; le temps pour retrouver les tiers impliqués ; le temps pour établir une version traçable des faits et des horodatages.

Ces mesures sont des indicateurs internes proposés par Cybercoria, pas des seuils réglementaires.

Si l’essentiel du temps est passé à demander « qui sait où se trouve cette information ? », la priorité n’est probablement pas d’améliorer le formulaire de notification. Elle est de réduire le coût de reconstruction du contexte avant le prochain incident.