Selon l'IBM X-Force Threat Intelligence Index 2025, le délai médian entre la compromission initiale et la détection atteint 194 jours pour les incidents de type data breach. Plus révélateur encore : 73 % des organisations mettent plus de 72 heures à contenir un incident une fois détecté — alors qu'elles disposent quasi toutes d'un plan de réponse aux incidents formalisé. Ce paradoxe n'est pas anecdotique. Il révèle une rupture structurelle entre la conformité IR documentaire et la capacité opérationnelle réelle. Ce que les CISO ayant traversé une compromission sérieuse en retiennent est rarement ce qui figure dans les frameworks standards.
Le contexte réglementaire qui transforme l'IR en obligation contraignante
Jusqu'en 2023, la gestion des incidents cyber était largement traitée comme une bonne pratique de sécurité. Les régulations européennes successives l'ont transformée en exigence légale aux conséquences chiffrées. NIS2 impose une notification aux autorités compétentes dans les 24 heures pour les incidents significatifs, avec un rapport complet sous 72 heures. DORA exige la déclaration des incidents ICT majeurs dans des délais similaires — et introduit une obligation de notification aux contreparties pour les entités financières. Le RGPD, quant à lui, encadre depuis 2018 la notification des violations de données personnelles sous 72 heures à la CNIL.
La conjonction de ces trois régimes crée une situation inédite : un incident cyber touchant une entité dans le scope NIS2 et DORA, impliquant des données personnelles, génère des obligations de notification simultanées vers l'ANSSI, le régulateur financier (BCE, ACPR), et la CNIL — avec des délais, des formats, et des destinataires distincts. Les sanctions pour notification tardive ou incomplète peuvent atteindre 2 % du chiffre d'affaires mondial sous RGPD et 1 % par jour sous DORA.
Cette réalité réglementaire change fondamentalement la nature de l'Incident Response. Ce n'est plus seulement un problème technique et organisationnel — c'est un problème de gouvernance et de communication qui engage la direction et le conseil d'administration dès les premières heures.
Première leçon : votre vrai problème est la détection, pas la réponse
La majorité des plans IR sont construits autour du MTTR — Mean Time to Respond — comme indicateur clé. Les CISO qui ont traversé des incidents réels pointent systématiquement vers un indicateur antérieur : le MTTD, Mean Time to Detect. Un plan IR parfaitement calibré qui s'active après 60 jours de présence attaquante ne peut pas compenser les dommages infligés pendant cette période.
Ce que révèlent les compromissions réelles : les incidents qui dépassent les 72 heures de confinement ne sont presque jamais des échecs de réponse. Ce sont des échecs de détection. L'attaquant a eu le temps de latéraliser, d'exfiltrer des credentials, de compromettre des sauvegardes. À ce stade, le plan IR réalise une opération de récupération, pas de confinement.
L'erreur de conception la plus courante : investir massivement dans les runbooks de réponse sans investir proportionnellement dans les capacités de détection précoce — EDR couvrant 100 % des endpoints, SIEM avec règles de corrélation testées, capacité de détecter les mouvements latéraux dans Active Directory. Un CISO d'une entité financière régulée EU formulait la chose ainsi : "Nous avions 47 procédures de réponse aux incidents. Nous n'avions pas de baseline comportementale de nos comptes de service." L'attaquant avait utilisé des comptes de service légitimes pendant 11 semaines.
Deuxième leçon : la communication tue plus vite que l'incident lui-même
Les décisions les plus critiques pendant un incident cyber ne sont pas techniques. Ce sont des décisions de communication — interne et externe — prises sous pression, avec une information incomplète, dans un délai réglementaire contraint.
Trois scénarios de communication récurrents dans les compromissions réelles que les plans IR standard ne préparent pas suffisamment :
La notification prématurée. Sous pression réglementaire (délai de 24h NIS2), une organisation notifie l'ANSSI sur la base d'une qualification initiale incorrecte. L'incident est recatégorisé 48 heures plus tard. Le rectificatif est plus coûteux en réputation que la notification initiale différée. La solution : distinguer la "notification d'alerte" préliminaire — qui peut être transmise avec des informations partielles si le seuil de signification est atteint — du "rapport complet" sous 72 heures. Les régulateurs acceptent l'incertitude initiale ; ils n'acceptent pas l'absence de communication.
La communication interne non-maîtrisée. Dans les premières heures d'un incident, les informations circulent sur des canaux non sécurisés (Teams, Slack, email) que l'attaquant peut encore surveiller s'il n'est pas contenu. Plusieurs compromissions documentées ont révélé que l'attaquant avait accès aux communications IR en temps réel. Un plan IR doit inclure un canal de communication hors-bande — lignes dédiées, messagerie chiffrée hors infrastructure compromise — activé dès que la compromission est suspectée, pas confirmée.
La communication vers le conseil d'administration. NIS2 et DORA engagent explicitement la responsabilité des dirigeants. Un conseil qui découvre l'ampleur d'un incident via la presse, ou qui reçoit des informations techniques sans contexte réglementaire et business, prend de mauvaises décisions. Préparer une "executive communication template" — une trame de message destiné au CA, formulée en termes de risque business et réglementaire, pas en termes techniques — est une des recommandations les plus systématiquement manquantes dans les plans IR audités.
Troisième leçon : les playbooks ne couvrent pas les incidents réels
Les plans IR sont construits autour de scénarios isolés : ransomware, phishing, violation de données, compromission d'un compte privilégié. Les incidents réels combinent rarement un vecteur unique. L'analyse des compromissions significatives en Europe en 2024–2025 fait apparaître une structure récurrente : accès initial via phishing ciblé (spear phishing sur un compte non-MFA) → mouvement latéral via comptes de service → exfiltration progressive sur plusieurs semaines → déclencheur visible (ransomware ou notification tierce) qui révèle une compromission bien plus ancienne.
Ce que cela implique pour vos playbooks : la question opérationnelle lors d'un incident n'est pas "quel playbook activer ?" mais "à quel stade de compromission sommes-nous ?" La réponse détermine si l'objectif prioritaire est le confinement, l'investigation forensique, ou la récupération — trois séquences d'actions différentes qui ne peuvent pas être menées simultanément avec les mêmes ressources.
Un exercice simple et systématiquement révélateur : prenez votre dernier playbook ransomware. Supprimez l'hypothèse que l'incident vient d'être déclenché. Posez la question : "Si l'attaquant est présent depuis 60 jours, quelles étapes de ce playbook ne fonctionnent plus ?" Les réponses identifient les lacunes réelles de votre capacité IR bien plus efficacement qu'un audit documentaire.
Évaluer votre maturité IR — trois questions décisives
Avant d'investir dans un nouveau SIEM ou de refondre vos runbooks, trois questions permettent de situer votre maturité IR réelle.
Avez-vous testé votre plan IR avec une compromission de sauvegarde ? Si vos sauvegardes sont sur le même Active Directory que votre production, un ransomware les chiffre aussi. Un plan IR qui suppose des sauvegardes disponibles et intègres n'a pas été testé dans les conditions d'un incident réel.
Votre délai de notification réglementaire est-il calculé à partir de la détection ou de la compromission initiale ? Sous NIS2, le délai de 24h court à partir du moment où l'entité "prend connaissance" de l'incident — pas de la compromission initiale. La distinction a des implications juridiques sur la qualification du point de départ.
Qui prend la décision de notification réglementaire dans votre organisation, et en combien de minutes ? Cette décision doit pouvoir être prise à 3h00 du matin, sans le CISO titulaire, en moins de 30 minutes. Si la réponse implique plus de deux niveaux d'approbation, votre délai de notification est structurellement à risque.
Le module Incident Response de Presidio centralise la qualification des incidents, les templates de notification réglementaire NIS2/DORA/RGPD, et la traçabilité des décisions IR pour l'audit trail — voir notre analyse DORA sur la résilience opérationnelle. Pour évaluer votre maturité IR en 30 minutes : contactez-nous.
Conclusion
Les CISO qui ont traversé une compromission sérieuse partagent trois convictions que les frameworks standards ne transmettent pas : la détection précoce est le seul levier qui change vraiment l'issue d'un incident. La communication — interne et réglementaire — est aussi critique que les actions techniques, et bien moins préparée. Et les playbooks sont des hypothèses de travail, pas des algorithmes — la valeur opérationnelle réelle vient de la capacité de jugement que les équipes développent par l'exercice, pas de la complétude documentaire.
Les organisations qui progresseront le plus vite sont celles qui traitent l'IR comme une capacité organisationnelle à exercer — pas comme un ensemble de procédures à archiver. La différence entre les deux se mesure en heures lors d'un incident réel.