Gérer un incident de sécurité : plan de réponse, BIA, exercice tabletop

La gestion des incidents est le moment où une organisation découvre la vraie maturité de sa sécurité. Un programme bien financé peut s’effondrer en quelques heures si la première crise révèle un plan papier jamais répété. À l’inverse, une équipe modeste avec un plan testé tient un incident majeur sans casse durable. Ce tutoriel déroule la construction du plan de réponse à incidents, la conduite d’un BIA (Business Impact Analysis), et la préparation d’un exercice tabletop crédible — les trois livrables qui couvrent l’essentiel du domaine 4 de l’examen CISM (30 % des questions).

Prérequis

• Charte sécurité signée, matrice RACI en place, registre des risques à jour
• Cartographie des actifs critiques et inventaire des applications
• Outil de ticketing en place (ITSM, ServiceNow, Jira Service Management ou équivalent)
• Connaissance des référentiels NIST SP 800-61 r2 et ISO/IEC 27035-1:2023
• Temps estimé pour boucler la première version : 6 à 8 semaines
• Niveau attendu : manager sécurité, candidat CISM en révision domaine 4

Étape 1 — Distinguer événement, incident et crise

Le vocabulaire fait la qualité du plan. Trois notions doivent être nettement séparées dans la politique avant tout autre travail. Un événement est tout fait observable dans le système d’information (échec de connexion, alerte antivirus, redémarrage inattendu). Un incident est un événement ou une série d’événements qui menace la confidentialité, l’intégrité ou la disponibilité d’un actif. Une crise est un incident dont l’impact dépasse les capacités de l’équipe d’astreinte et nécessite l’activation d’un dispositif exceptionnel (cellule de crise, communication externe, escalade COMEX).

Niveau	Définition	Décideur	Délai d’action attendu
N1 — Événement	Anomalie sans impact démontré	Analyste SOC	Heure ouvrée suivante
N2 — Incident mineur	Impact local, contrôle existant a tenu	Responsable SOC	4 heures
N3 — Incident majeur	Plusieurs services touchés, contrôles à renforcer	Manager sécurité	1 heure
N4 — Crise	Activité métier compromise, impact externe	COMEX, cellule de crise	Immédiat

Cette échelle de classification s’écrit dans la politique de gestion des incidents et se communique à toutes les équipes. Sans elle, chaque alerte devient un incident, chaque incident devient une crise, et l’organisation s’épuise. Avec elle, l’escalade est mécanique et les bons décideurs sont impliqués au bon moment. L’examen CISM teste régulièrement la capacité à classer correctement un scénario : un phishing isolé bloqué par le filtre n’est pas un incident majeur, une exfiltration de 50 000 enregistrements clients en est un.

Étape 2 — Constituer la CSIRT et définir les rôles

La CSIRT (Computer Security Incident Response Team) est l’équipe qui pilote la réponse aux incidents N2 et au-dessus. Sa composition se fixe dans le plan, avec un titulaire et un suppléant par rôle pour couvrir absences et congés. Une CSIRT à un seul niveau de profondeur est une CSIRT qui s’effondre dès qu’une personne clé est en vacances.

• Incident Commander — pilote unique de la réponse, coordonne toutes les actions, parle au COMEX. Souvent le manager sécurité lui-même pour les N3.
• Analyste technique (lead) — investigation, conteneurisation, collecte de preuves. C’est l’ingénieur sécurité senior ou un consultant externe en cas de besoin.
• Communication interne et externe — relations média, communication clients, notification régulateurs. Rôle tenu par le Directeur Communication ou son représentant.
• Juridique et conformité — analyse des obligations de notification (RGPD, sectorielles), préparation des dépôts de plainte. Souvent un avocat externe identifié à l’avance.
• RH — si l’incident implique un collaborateur, ou si la gestion impose des mesures conservatoires (suspension d’accès, mise à pied).
• Représentants métier — directeurs des lignes d’activité touchées par l’incident, pour arbitrer continuité vs investigation.

L’annuaire de crise — noms, téléphones personnels, mails personnels, suppléants — se conserve sous deux formes : version numérique chiffrée sur un coffre-fort accessible hors SI principal, version papier dans une enveloppe scellée chez le manager sécurité et chez un membre du COMEX. Lors d’un ransomware, l’annuaire interne est souvent inaccessible — c’est précisément la situation pour laquelle on prépare une copie hors ligne.

Étape 3 — Rédiger le plan de réponse à incidents (IRP)

Le plan de réponse à incidents s’appuie historiquement sur les six phases NIST SP 800-61 Rev. 2 résumées par l’acronyme PICERL (Preparation, Identification, Containment, Eradication, Recovery, Lessons learned). NIST a publié la Rev. 3 le 3 avril 2025, qui aligne désormais les recommandations sur les six fonctions du CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) ; PICERL reste la grille mentale dominante dans la pratique et dans les supports CISM. Chaque phase fait l’objet d’une section avec actions, rôles et critères de sortie pour passer à la phase suivante.

Phase	Objectif	Sortie
Préparation	Plan, équipe, outils, formation	Plan signé, équipe formée, outils déployés
Identification	Détecter et qualifier l’incident	Incident classé N2/N3/N4 avec ticket
Confinement	Arrêter la propagation	Périmètre stabilisé, preuves préservées
Éradication	Supprimer la cause racine	Vulnérabilité corrigée, accès malveillants révoqués
Récupération	Restaurer les services	Service revenu en production avec monitoring renforcé
Leçons apprises	Capitaliser sur l’incident	Rapport post-mortem, plan d’action signé

Une règle structurante : la phase de confinement précède toujours l’éradication. Beaucoup d’équipes débutantes veulent supprimer la menace dès qu’elles la détectent — c’est exactement ce qui détruit les preuves nécessaires à l’investigation forensique et qui permet à l’attaquant de revenir par un canal non détecté. L’examen CISM pose souvent une question piège sur ce point : la première action après identification d’une compromission de compte privilégié est l’isolation du compte et la préservation des journaux, pas la réinitialisation immédiate du mot de passe.

Étape 4 — Conduire un BIA (Business Impact Analysis)

Le BIA mesure l’impact d’une indisponibilité par processus métier. Il fournit les deux paramètres clés du plan de continuité : RTO (Recovery Time Objective, temps maximal acceptable avant retour en service) et RPO (Recovery Point Objective, perte maximale de données acceptable). Sans BIA, l’investissement en sauvegardes, en redondance et en site de secours est aveugle. Avec un BIA, chaque ligne de budget continuité se rattache à un processus métier précis et à une durée acceptable validée par le métier lui-même.

Processus métier      : Encaissement clients en ligne
Propriétaire          : Directeur Commercial
Applications de support : APP-001 (paiement), DATA-001 (commandes)
Personnel critique    : 3 ETP centre relation clients

Impact si indisponible :
  1 heure   : retard non bloquant, traitement après reprise (faible)
  4 heures  : perte CA estimée 25 k€, plaintes clients (modéré)
  24 heures : perte CA 150 k€, communication clients obligatoire (élevé)
  72 heures : perte CA 450 k€, risque réputationnel majeur, perte de contrats (critique)
  1 semaine : impossibilité d'exploitation, mise en péril activité (catastrophique)

RTO (temps de reprise visé) : 4 heures
RPO (perte de données max)  : 15 minutes
MAO (durée max acceptable)  : 24 heures
Niveau de priorité          : 1 (critique)

Le BIA se construit par atelier avec chaque propriétaire métier. La discipline qui rend l’exercice utile : forcer un chiffrage des impacts par tranche de durée — c’est seulement à ce moment que les responsables réalisent ce qu’une indisponibilité représente en euros et en confiance client. Les arbitrages d’investissement deviennent ensuite simples : un processus avec RTO 4 h justifie une bascule automatique vers un site de secours ; un processus avec RTO 24 h se contente d’une restauration depuis sauvegarde testée.

Étape 5 — Préparer le scénario tabletop

L’exercice tabletop est la simulation à table d’un incident réaliste, sans toucher au système réel. C’est l’outil de répétition le plus rentable du domaine 4 : 4 heures de préparation, 2 à 3 heures de jeu, des leçons apprises immédiatement exploitables. La règle d’or pour qu’il serve à quelque chose : choisir un scénario crédible, à mi-chemin entre l’incident vraisemblable et la crise majeure. Un scénario d’invasion extraterrestre amuse mais n’apprend rien ; un scénario de panne réseau anecdotique non plus.

• Scénario type 1 — Rançongiciel : chiffrement détecté à 4 h du matin sur le contrôleur de domaine principal, propagation observée sur 12 serveurs en 2 heures. Cas exploré dans 80 % des organisations en 2026.
• Scénario type 2 — Compromission de compte privilégié : exfiltration silencieuse détectée tardivement par un fournisseur tiers (banque, partenaire) qui appelle pour signaler des transactions anormales.
• Scénario type 3 — Fuite de données via prestataire : alerte publique d’un fournisseur SaaS critique annonçant une intrusion, doute sur les données concernées.
• Scénario type 4 — DDoS prolongé : indisponibilité du site marchand pendant les heures de forte activité commerciale, accompagnée d’une demande de rançon par message anonyme.

Le déroulement type comporte une chronologie injectée toutes les 15 à 30 minutes par un animateur (souvent le manager sécurité avec l’aide d’un consultant externe). À chaque injection, les participants doivent décider et justifier leur décision. L’animateur prend note de chaque hésitation, de chaque divergence d’interprétation, de chaque téléphone qu’on ne sait pas appeler. Le compte rendu post-exercice transforme ces observations en plan d’action concret.

Étape 6 — Définir la procédure de notification

En 2026, les obligations de notification se sont multipliées. Pour une organisation francophone, plusieurs cadres se cumulent souvent. La règle est de cartographier les obligations en amont — pas pendant la crise. Une notification ratée ou tardive constitue souvent une faute aussi grave que l’incident lui-même.

Cadre	Champ	Délai	Destinataire
RGPD article 33 (UE)	Violation données personnelles	72 heures	Autorité de protection nationale
Directive NIS 2 (UE)	Incident significatif sur services essentiels	Alerte 24 h, rapport 72 h	CSIRT national
Loi 2008-12 Sénégal	Violation données personnelles	Délai raisonnable	CDP — Commission de Protection des Données
Régulateur bancaire (BCEAO)	Incident bancaire majeur	Selon cadre prudentiel	Banque centrale + ministère
Contractuel client	Selon clauses négociées	Souvent 24 à 72 heures	Clients concernés

Le manager sécurité tient une fiche par cadre applicable : déclencheur, délai, modèle de communication, signataire habilité. Ces fiches sont annexées au plan de réponse et révisées chaque année par le juridique. Une chose à savoir : la décision de notifier reste politique et doit être tracée par écrit, même quand le délai légal est respecté à la lettre.

Étape 7 — Tester et améliorer en continu

Un plan non testé est une fiction. La fréquence minimale recommandée : un tabletop par semestre sur un scénario différent, un exercice technique annuel (test de restauration complète d’un serveur critique, basculement vers le site de secours, test des sauvegardes hors ligne), une revue annuelle complète du plan en comité. Chaque test produit un compte rendu signé, un plan d’action, et une mise à jour de la version du plan.

Le suivi des actions issues des exercices se traite avec la même rigueur que le suivi de la feuille de route programme : pilote nommé, échéance datée, statut mensuel. Sans ce suivi, les leçons apprises se perdent et le tabletop suivant révèle les mêmes failles. L’examen CISM teste cette boucle de retour d’expérience : la phase « Lessons Learned » n’est pas une formalité, c’est ce qui transforme un incident subi en capacité durable.

Étape 8 — Vérifier que le dispositif tient

Trois questions concrètes pour valider la version 1 du plan avant de le considérer comme opérationnel.

1. Si le manager sécurité est en vacances à l’étranger sans accès au SI, l’organisation peut-elle gérer un N3 en moins de 30 minutes ? Si non, c’est que la suppléance est insuffisante.
2. L’annuaire de crise est-il disponible hors du SI principal, sous forme papier ou hors-bande ? Sinon, un ransomware le rendra inaccessible.
3. Le dernier exercice tabletop a-t-il produit moins de cinq actions correctives ? S’il en a produit vingt, c’est que le plan est encore loin d’être abouti — ce qui n’est pas un échec, mais doit être affiché clairement en comité.

Erreurs fréquentes

Erreur	Cause	Solution
Éradiquer avant de confiner	Réflexe technique de « tuer la menace »	Politique stricte : isoler d’abord, préserver les preuves, puis éradiquer
Annuaire de crise uniquement dans Outlook	Confort de l’accès quotidien	Double copie hors ligne, papier + clé chiffrée hors SI
Plan jamais testé	Manque de temps perçu	Tabletop semestriel obligatoire, ajouté au calendrier comité
BIA réservé à l’IT	Vision technicienne	BIA piloté par chaque propriétaire métier, validé en comité
Notification décidée pendant la crise	Absence de cartographie préalable	Fiche notification par cadre applicable, révisée annuellement
Pas de communication interne pendant crise	Focus 100 % technique	Rôle communication interne dans la CSIRT avec messages préparés

Tutoriels frères

• Piloter un programme de sécurité : feuille de route, KPI, budget défendable
• Évaluer et traiter les risques informationnels : méthode pas-à-pas avec registre exploitable
• Vue technique complémentaire : CISSP Domaine 7 — Security Operations : SOC, DFIR et continuité déroule SOC, forensique et continuité avec le vocabulaire CBK.

Pour aller plus loin

• Retour au panorama : CISM (ISACA) : devenir Manager sécurité de l’information en 2026
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management (avril 2025, supersede Rev. 2) — référence anglophone gratuite.
• ISO/IEC 27035-1:2023 — Information security incident management — principes et phases.
• ENISA — Guidelines on assessment of DPA notification under GDPR (utile pour notification 72 h).
• CISM Review Manual 2026 — chapitre 4 sur la gestion des incidents.

FAQ

CSIRT interne ou prestataire externe ?

Mixte recommandé pour la plupart des organisations. Une équipe interne pour le N1 et N2 (analyse quotidienne, premières investigations), un contrat avec un prestataire CERT pour le N3 et N4 (forensique avancée, négociation rançon, communication aux régulateurs). Le contrat doit prévoir une activation en moins de 4 heures et inclure un tarif horaire pré-négocié — l’urgence n’est pas le bon moment pour négocier.

Faut-il payer la rançon en cas de ransomware ?

La position dominante des autorités (ANSSI, FBI, Europol) est de ne pas payer. Les raisons sont solides : aucune garantie de récupération, financement direct du crime organisé, augmentation de la cible perçue par d’autres groupes, et complications juridiques selon les sanctions internationales applicables. Cela dit, la décision finale appartient au COMEX et doit être documentée. Un plan mature prépare cette décision à froid plutôt que de la subir à chaud.

Quel ITSM utiliser pour les tickets d’incident sécurité ?

Ceux déjà en place pour l’IT couvrent l’essentiel : ServiceNow, Jira Service Management, GLPI, OTRS. Le choix prioritaire est d’avoir des champs spécifiques à la sécurité (classification N1-N4, données personnelles oui/non, base légale notification) et une séparation des droits — un incident sécurité confidentiel n’est pas visible par tous les opérateurs. Un outil dédié sécurité (SOAR, plateforme CSIRT) se justifie au-dessus de 100 incidents traités par mois.

Comment l’examen CISM teste-t-il ce domaine ?

Par des scénarios qui demandent de choisir la première action à prendre, ou de placer plusieurs actions dans le bon ordre. Les pièges classiques : choisir « notifier le régulateur » avant « confirmer l’étendue de la violation », ou « réinitialiser les mots de passe » avant « préserver les preuves ». La bonne séquence respecte toujours PICERL — préparation acquise, identification confirmée, confinement, éradication, récupération, leçons apprises.

BIA et analyse de risques sont-ils redondants ?

Non, ils sont complémentaires et l’examen attend que vous le sachiez. L’analyse de risques part de la menace et calcule un risque résiduel sur un actif. Le BIA part du processus métier et calcule l’impact d’une indisponibilité dans le temps. L’analyse de risques alimente le plan de traitement (atténuation, transfert, acceptation). Le BIA alimente le plan de continuité (RTO, RPO, priorités de reprise). Les deux sont nécessaires.