Procédure Gestion des Incidents ISO 27001 : Modèle Word [A.5.24-28]

La procédure de gestion des incidents de sécurité de l'information est un document fondateur de tout SMSI conforme à la norme ISO/IEC 27001:2022. Elle matérialise le contrôle A.5.24 — Planification et préparation à la réponse aux incidents et constitue le cadre de référence opérationnel pour les contrôles A.5.25 (évaluation des événements), A.5.26 (réponse aux incidents), A.5.27 (leçons apprises) et A.5.28 (collecte de preuves). Sans procédure documentée, testée et connue des équipes, la gestion des incidents reste improvisée — avec les conséquences prévisibles sur le temps de réponse, la qualité de la documentation, et le respect des délais de notification réglementaires. Ce modèle Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, couvre l'intégralité du cycle de vie d'un incident : de la détection initiale d'un événement suspect jusqu'à la clôture formelle de l'incident et la capitalisation par les leçons apprises. Il intègre un diagramme de flux d'escalade clair, les délais de notification légaux (ANSSI sous 24h pour les OSE NIS 2, CNIL sous 72h pour les violations RGPD), des fiches réflexe par type d'incident (phishing, ransomware, fuite de données, accès non autorisé), et les modèles de communication de crise interne et externe. Cette procédure est indispensable pour les RSSI qui préparent une certification ISO 27001, pour les équipes SOC qui gèrent les alertes au quotidien, pour les directions qui doivent valider la robustesse du dispositif de réponse à incident, et pour les organisations soumises à NIS 2 qui doivent démontrer une capacité de réponse opérationnelle aux incidents significatifs. Elle doit être revue au moins annuellement et testée par un exercice de simulation (tabletop ou full-scale) pour rester pertinente face à l'évolution des menaces.

Contexte réglementaire et normatif

La gestion des incidents est à l'intersection de plusieurs référentiels qui imposent des exigences cumulatives et complémentaires :

ISO/IEC 27001:2022 — Contrôles A.5.24 à A.5.28

La version 2022 de la norme a significativement renforcé les exigences de gestion des incidents par rapport à 2013. Le bloc A.5.24-28 forme désormais un processus intégré dont chaque contrôle est vérifié en audit de certification Stage 2. Le contrôle A.5.24 (Planification et préparation) est le plus structurant : il exige que l'organisation définisse et documente sa procédure avant qu'un incident ne survienne, avec des rôles et responsabilités clairs, des canaux de communication définis, et des ressources pré-identifiées. Les auditeurs vérifient que la procédure est connue des équipes concernées et qu'elle a été testée — une procédure non testée est considérée comme théorique et insuffisante.

Directive NIS 2 — Capacité de réponse aux incidents

La directive NIS 2, transposée en France avec l'ordonnance de juillet 2024, impose aux entités essentielles et importantes de disposer d'une capacité de réponse aux incidents documentée et opérationnelle. Les délais de notification sont stricts : alerte préliminaire à l'ANSSI dans les 24 heures, rapport d'incident dans les 72 heures, et rapport de synthèse finale dans le mois suivant. Ces délais commencent à courir dès la détection, pas dès la qualification complète. La procédure de gestion des incidents doit donc intégrer explicitement ces seuils et les mécanismes permettant de les respecter même en situation de crise. Pour plus de détails sur NIS 2, consultez notre guide sur la conformité NIS 2.

RGPD — Articles 33 et 34

L'Article 33 du RGPD impose de notifier la CNIL dans les 72 heures après avoir pris connaissance d'une violation de données personnelles. L'Article 34 impose une notification directe aux personnes concernées si le risque est élevé. La procédure de gestion des incidents doit inclure un arbre de décision permettant de qualifier rapidement si un incident constitue une violation de données personnelles au sens RGPD, et d'impliquer le DPO dans la chaîne d'escalade dès cette qualification.

ISO 22301 — Lien avec la continuité d'activité

Les incidents de sécurité de criticité P1 (impact critique sur les activités) peuvent déclencher les plans de continuité d'activité (PCA). La procédure ISO 27001 doit définir clairement le point de bascule entre "gestion d'incident sécurité" et "activation PCA", avec une communication fluide entre le responsable de la réponse à incident et le gestionnaire de crise PCA. Notre modèle de PCA ISO 22301 est le document complémentaire pour ce point de bascule.

Structure détaillée de la procédure

Chapitre 1 — Objet, domaine d'application et définitions

Ce chapitre définit l'objet de la procédure (cadrer la gestion des incidents de sécurité conformément à ISO 27001 A.5.24-28), son domaine d'application (tous les systèmes, données et processus dans le périmètre du SMSI), les définitions clés (événement vs incident, criticité P1-P4, violation de données, incident significatif NIS 2), et les références normatives et réglementaires applicables.

Chapitre 2 — Rôles et responsabilités

Ce chapitre définit le RACI complet de la gestion des incidents : l'incident manager (coordonne la réponse, prend les décisions), le RSSI (valide la qualification, décide des notifications réglementaires, informe la Direction), les analystes sécurité (investigation technique, confinement, éradication), les propriétaires des systèmes impactés (autorisent les actions sur leurs systèmes), le DPO (impliqué si données personnelles concernées), la Direction générale (informée pour P1/P2, décide des communications externes), la communication (gère les communications de crise), et les prestataires spécialisés (forensique, CERT, assureur cyber) à contacter si nécessaire.

Chapitre 3 — Détection et signalement

Ce chapitre décrit les sources de détection (SOC/SIEM, alertes outils, signalements utilisateurs, prestataires, partenaires, CERT), les canaux de signalement (email dédié, portail ticketing, hotline), les délais de signalement attendus (immédiat pour tout événement suspect), et les critères de qualification événement → incident. Il inclut un formulaire de signalement simple et accessible à tous les collaborateurs, avec les questions essentielles : quoi, quand, qui a découvert, quels systèmes semblent impactés.

Chapitre 4 — Qualification et classification

Ce chapitre définit la matrice de criticité (P1 : impact critique sur les activités ou données très sensibles ; P2 : impact significatif sur un périmètre limité ; P3 : impact modéré, activités non interrompues ; P4 : impact faible, quasi-incident) avec des exemples concrets pour chaque niveau. Il inclut également la matrice de décision de notification CNIL (violation de données personnelles ?) et ANSSI (incident significatif NIS 2 ?), avec des exemples de chaque cas.

Chapitre 5 — Workflow de réponse selon la criticité

Le cœur opérationnel de la procédure. Pour chaque niveau de criticité, le workflow détaille : les délais d'escalade (P1 : incident manager notifié en moins de 15 minutes, RSSI en moins de 30 minutes, DG en moins de 1 heure), les actions de confinement prioritaires par type d'incident, les ressources à mobiliser, et les décisions à prendre dans les premières heures critiques.

Chapitre 6 — Fiches réflexe par type d'incident

Des fiches d'aide à la décision pour les types d'incidents les plus fréquents : phishing avec clic utilisateur, infection ransomware, fuite ou exfiltration de données, accès non autorisé à des systèmes sensibles, compromission de compte privilégié, attaque DDoS, défaillance d'un service cloud critique. Chaque fiche indique les 5 premières actions à prendre, les systèmes à isoler en priorité, les personnes à contacter, et les preuves à sécuriser immédiatement.

Chapitre 7 — Collecte de preuves et forensique

Ce chapitre documente les procédures de collecte et préservation des preuves numériques (A.5.28) : capture des logs système avec horodatage, hash des fichiers collectés pour garantir l'intégrité, chaîne de custody (qui a collecté quoi, quand, comment), stockage sécurisé des preuves dans un espace immuable, et précautions pour ne pas contaminer les preuves lors des actions de confinement.

Chapitre 8 — Communication de crise

Ce chapitre définit les templates de communication interne (message d'alerte collaborateurs, compte-rendu à la Direction) et externe (notification ANSSI, notification CNIL, communication clients/partenaires si nécessaire), avec les canaux à utiliser et les personnes autorisées à communiquer officiellement en cas d'incident.

Chapitre 9 — Clôture et leçons apprises

Ce chapitre structure le post-mortem (participants, délai, questions clés à traiter), les méthodes d'analyse des causes racines (5 pourquoi, diagramme d'Ishikawa, analyse RCCA), le plan d'action correctif avec responsables et délais, la mise à jour du registre des incidents, et la capitalisation des leçons apprises dans la procédure elle-même (amélioration continue).

Guide d'utilisation étape par étape

1. Adapter le template à votre contexte : complétez les sections avec vos noms, postes, coordonnées réelles. Une procédure avec des noms génériques ("le RSSI", "la Direction") est moins opérationnelle qu'une procédure avec des noms et numéros de téléphone réels. Mettez à jour les coordonnées à chaque changement de poste.
2. Valider avec toutes les parties prenantes : soumettez la procédure à validation formelle auprès du RSSI, du DPO, de la Direction générale, de la DSI, du DRH, et des principaux propriétaires de systèmes. Leurs retours améliorent la procédure et leur signature renforce son autorité.
3. Former les équipes : une procédure non connue ne sera pas appliquée. Organisez des sessions de formation pour l'équipe sécurité et les équipes techniques (30 minutes suffisent), et une communication de sensibilisation pour tous les collaborateurs sur le canal de signalement et l'importance du signalement.
4. Tester par un exercice tabletop : simulez un scénario d'incident (ex: ransomware sur 3 serveurs) avec les parties prenantes clés. Vérifiez que chacun connaît son rôle, que les délais d'escalade sont respectables, et que les fiches réflexe sont claires. Documentez les lacunes identifiées et améliorez la procédure en conséquence.
5. Intégrer dans l'ITSM et les outils sécurité : configurez votre SIEM, votre EDR, ou votre outil ITSM pour déclencher automatiquement une alerte suivant le workflow de cette procédure lors de la détection d'événements qualifiés. Réduire la friction de la première étape (signalement) augmente la complétude du registre incidents.
6. Maintenir les coordonnées d'urgence à jour : vérifiez trimestriellement que les coordonnées de l'équipe d'astreinte, du CERT externe, de l'assureur cyber, de l'ANSSI et de la CNIL sont correctes. Une liste de contacts erronée en situation de crise peut faire perdre des heures critiques.
7. Réviser après chaque incident significatif : chaque incident P1 ou P2 est une opportunité d'améliorer la procédure. Le post-mortem doit systématiquement poser la question : "Qu'est-ce qui aurait pu être fait différemment si nous avions eu cette procédure ?"
8. Revoir annuellement et après chaque changement majeur : la procédure doit être revue au minimum une fois par an, et à chaque changement significatif du périmètre IT, de l'organisation, ou des exigences réglementaires applicables. Maintenez l'historique des révisions dans le document.

Tableau des contrôles — Checklist procédure gestion des incidents

Points de vigilance pour l'audit de certification

1. Procédure non testée : c'est le piège numéro un. Une procédure non testée par un exercice est théorique. Les auditeurs demandent systématiquement le compte-rendu de l'exercice de simulation le plus récent. Remédiation : organisez un tabletop exercise (2h avec les parties prenantes clés) au moins une fois par an et conservez le compte-rendu avec les actions d'amélioration identifiées.
2. Procédure inaccessible lors d'un incident de type ransomware : si votre procédure est stockée uniquement sur le réseau interne et qu'un ransomware chiffre vos systèmes, vous perdez l'accès à la procédure au moment où vous en avez le plus besoin. Remédiation : imprimez et stockez physiquement (coffre-fort) une version à jour de la procédure, et maintenez-en une copie sur un cloud indépendant du SI principal.
3. Délais d'escalade irréalistes : si votre procédure indique que le RSSI doit être notifié en 5 minutes mais qu'il n'est pas d'astreinte le week-end, ce délai est intenable. Remédiation : ajustez les délais selon les contraintes réelles d'organisation (astreinte, disponibilité), documentez une solution pour les horaires hors bureau, et mettez en place une vraie astreinte si votre criticité l'exige.
4. Pas de mécanisme de décision pour les notifications réglementaires : la procédure doit inclure un arbre de décision clair pour qualifier si l'incident nécessite une notification CNIL et/ou ANSSI. Une procédure qui dit seulement "notifier si nécessaire" est insuffisante. Remédiation : intégrez un flowchart de qualification avec des questions fermées (oui/non) et des seuils clairs.
5. DPO absent de la chaîne d'escalade : si votre procédure ne cite pas le DPO dans la chaîne d'escalade, c'est un gap notable. Le DPO doit être impliqué dès la qualification de tout incident pouvant impliquer des données personnelles. Remédiation : ajoutez le DPO dans le RACI avec un délai d'implication (dès qualification si données personnelles suspectées).
6. Fiches réflexe absentes ou obsolètes : en situation de crise, les équipes techniques n'ont pas le temps de lire une procédure de 30 pages. Les fiches réflexe sont les outils pratiques utilisés dans les premières heures. Remédiation : créez des fiches d'une page par type d'incident, avec les 5 premières actions à prendre, affichées physiquement dans la salle technique et accessibles depuis le téléphone mobile.
7. Procédure non mise à jour après les incidents : le post-mortem doit conduire à une mise à jour de la procédure si des lacunes ont été identifiées. Une procédure jamais révisée après incident est un signal de non-amélioration continue. Remédiation : incluez explicitement dans le template post-mortem la question "La procédure de gestion des incidents doit-elle être mise à jour ?"
8. Absence de coordination avec les prestataires clés : si votre hébergeur cloud, votre infogérant ou votre prestataire EDR n'est pas intégré dans la procédure avec ses propres obligations de notification, vous avez une lacune. Remédiation : documentez dans la procédure les SLA de notification de chaque prestataire critique et vérifiez la cohérence avec les contrats en vigueur.

Intégration dans le SMSI : liens avec les autres documents

PROCÉDURE GESTION DES INCIDENTS (A.5.24) ← Référence opérationnelle
│
├── ALIMENTE →
│   ├── Registre incidents (A.5.24) — chaque incident traçé
│   ├── Registre NC (Clause 10) — incidents récurrents → NC formelle
│   ├── Plan de formation (A.6.3) — formation procédure incident
│   └── Plan d'amélioration SMSI — leçons apprises → actions
│
├── EST COHÉRENT AVEC →
│   ├── PCA/BCP (ISO 22301) — bascule incident P1 → activation crise
│   ├── Politique de classification (A.5.12) — criticité données impactées
│   ├── Politique accès logiques (A.5.15) — isolation accès en cas d'incident
│   ├── Procédure gestion changements (A.8.32) — patch d'urgence post-incident
│   └── Contrats fournisseurs (A.5.19) — obligations notification sous-traitants
│
├── EST DÉCLENCHÉ PAR →
│   ├── Signalements utilisateurs
│   ├── Alertes SIEM/SOC/EDR
│   ├── Notifications prestataires
│   └── Veille cyber (CVE critiques exploités activement)
│
└── EST VÉRIFIÉ PAR →
    ├── Exercice de simulation annuel (CR exercice)
    ├── Audit interne (Clause 9.2)
    ├── Revue de direction (Clause 9.3)
    └── Audit de certification Stage 2 (A.5.24-28)

Bonnes pratiques terrain

• Créez une cellule de crise cyber permanente : identifiez les membres de la cellule de crise cyber (RSSI, DSI, DG, Communication, DPO, Juridique), maintenez un annuaire d'astreinte à jour, et testez la capacité à se rejoindre rapidement. En situation de crise, la coordination est le facteur limitant le plus fréquent.
• Anticipez les canaux de communication alternatifs : si votre messagerie interne est compromise lors d'un incident, par quel canal communiquez-vous ? Préparez un canal de communication de secours (Signal, WhatsApp groupe, numéros personnels) documenté dans la procédure.
• Documentez les leçons apprises publiquement (en interne) : partager une version anonymisée des leçons apprises avec les équipes informatiques renforce la culture sécurité et aide à prévenir des incidents similaires. Organisez un "retex" mensuel ou trimestriel sur les incidents passés.
• Intégrez la gestion d'incident dans le processus d'achat : tout nouveau prestataire ou solution SaaS doit avoir ses obligations de notification d'incident documentées dans le contrat avant signature. Ce point est vérifié lors des audits ISO 27001 dans le cadre des contrôles A.5.19-23 (chaîne d'approvisionnement).
• Préparez un "go-bag" digital pour les incidents ransomware : une clé USB chiffrée (ou un cloud indépendant) contenant la procédure, les contacts d'urgence, les licences de récupération, les accès de secours aux systèmes critiques, et les templates de communication peut faire la différence lors d'un ransomware qui chiffre tout le SI.

Questions fréquentes sur la procédure de gestion des incidents ISO 27001

Quelle est la différence entre un plan de réponse à incident et une procédure de gestion des incidents ?

Ces deux documents sont souvent confondus mais ont des portées différentes. La procédure de gestion des incidents ISO 27001 est un document de gouvernance qui définit le processus global, les rôles, les responsabilités, les critères de qualification, les délais d'escalade et les obligations de notification. Elle couvre l'ensemble du cycle de vie d'un incident, de la détection à la clôture, et est applicable à tous les types d'incidents. Le plan de réponse à incident (Incident Response Plan ou IRP) est un document plus opérationnel et spécifique, souvent décliné par type d'incident (IRP ransomware, IRP phishing, IRP fuite de données). Il détaille les étapes techniques spécifiques à exécuter, les commandes à lancer, les systèmes à isoler, les preuves à collecter. En pratique, la procédure ISO 27001 est le cadre général dont les fiches réflexe constituent des éléments du plan de réponse. Pour une PME, ces documents peuvent être fusionnés. Pour une grande organisation, ils sont distincts mais doivent être cohérents. ISO 27001 impose la procédure (A.5.24) ; le plan de réponse détaillé est une bonne pratique qui en facilite la mise en œuvre opérationnelle et est fortement recommandé par l'ANSSI dans ses guides sur la gestion de crise cyber.

Comment gérer un incident en dehors des heures ouvrées ?

La question des incidents en dehors des heures ouvrées (nuit, week-end, jours fériés) est l'un des points les plus souvent défaillants dans les procédures de gestion des incidents. Un ransomware déclenché à 3h du matin un dimanche ne va pas attendre lundi matin pour progresser. La procédure doit explicitement traiter ce cas avec plusieurs options selon votre taille et votre niveau de risque : la mise en place d'une astreinte formelle (numéro d'astreinte rotatif, avec au minimum RSSI et un administrateur système), le recours à un CERT ou SOC externe disponible 24/7 (prestataire contractualisé), la définition d'actions autonomes que les utilisateurs ou le helpdesk peuvent prendre en attendant (isoler un poste du réseau, couper un accès), et des seuils d'alerte automatique (votre SIEM ou EDR peut envoyer des SMS ou des appels automatiques pour les alertes critiques). Documentez ces mécanismes dans votre procédure et testez-les lors de l'exercice de simulation — organisez un exercice surprise en dehors des heures ouvrées au moins une fois pour valider leur efficacité réelle. Les auditeurs ISO 27001 posent systématiquement la question "Que se passe-t-il si un incident P1 survient un samedi à 2h du matin ?"

Faut-il impliquer les forces de l'ordre lors d'un incident cyber ?

La décision d'impliquer les forces de l'ordre (Police, Gendarmerie, ANSSI) lors d'un incident cyber dépend de plusieurs facteurs. Elle est généralement recommandée dans les cas suivants : lorsque l'incident constitue une infraction pénale (accès frauduleux, extorsion, vol de données), lorsque vous souhaitez engager des poursuites judiciaires et avez besoin de preuves recevables, lorsque l'ANSSI doit être notifiée (NIS 2), ou lorsque votre assurance cyber l'exige comme condition de prise en charge. La décision implique des considérations pratiques : dépôt de plainte au commissariat ou à la gendarmerie, signalement sur la plateforme Cybermalveillance.gouv.fr pour les PME, ou contact direct avec le CERT-FR ou l'ANSSI pour les incidents critiques sur des systèmes d'importance. Votre procédure doit définir qui prend cette décision (généralement DG sur recommandation RSSI et Juridique), dans quel délai, et documentez les contacts utiles. Important : impliquer les forces de l'ordre ne signifie pas perdre le contrôle de la communication. Votre service communication reste maître des messages externes.

Comment adapter la procédure pour une PME sans RSSI à temps plein ?

De nombreuses PME n'ont pas de RSSI dédié à temps plein, mais elles sont tout autant soumises à ISO 27001 si elles souhaitent la certification. Dans ce cas, la procédure doit être adaptée à la réalité organisationnelle. Quelques adaptations clés : le RSSI peut être un responsable informatique, un DSI, ou un consultant externe mandaté — documentez clairement qui assure ce rôle ; la cellule de crise peut être réduite (DG + DSI/RSSI + DPO si applicable) ; les fiches réflexe sont d'autant plus importantes que les équipes sont moins spécialisées, car elles permettent d'agir rapidement sans expertise approfondie ; un abonnement à un CERT ou à un service de réponse à incident externalisé (disponible 24/7) compense l'absence d'équipe interne ; et le recours à Cybermalveillance.gouv.fr est gratuit et efficace pour les PME face à des incidents courants comme le phishing ou les rançongiciels. La procédure doit être réaliste : une PME de 50 personnes ne peut pas avoir le même niveau d'organisation qu'une banque, et les auditeurs ISO 27001 adaptent leurs attendus à la taille et la maturité de l'organisation.

Comment intégrer la gestion des incidents dans une démarche DevSecOps ?

La gestion des incidents cyber doit être intégrée dès la conception dans les pratiques DevSecOps, pas ajoutée en couche après coup. Plusieurs pratiques permettent cette intégration : les runbooks d'incident doivent être versionés dans le même dépôt de code que les configurations d'infrastructure (GitOps) ; les pipelines CI/CD doivent intégrer des seuils d'alerte automatiques qui alimentent le système de gestion d'incident (PagerDuty, OpsGenie) ; les environnements cloud doivent être instrumentés pour générer des alertes normalisées (CloudTrail AWS, Azure Monitor, GCP Cloud Logging) ; les équipes de développement doivent être formées à la réponse à incident pour les systèmes dont elles sont responsables (propriétaire technique = premier répondant pour les incidents liés à l'application) ; et les post-mortems doivent être partagés entre l'équipe sécurité et les équipes de développement pour améliorer la résilience des applications. Dans un contexte ISO 27001, le processus de gestion des changements (A.8.32) doit être coordonné avec la gestion d'incident : un patch d'urgence appliqué en réponse à un incident doit suivre un processus de changement d'urgence documenté, même simplifié.

Pour aller plus loin

• Registre des incidents ISO 27001 [A.5.24] — Template Excel
• Plan de Continuité d'Activité (PCA) [ISO 22301/27001]
• Registre des non-conformités ISO 27001 [Clause 10]
• Checklist audit de certification ISO 27001 Stage 1 + Stage 2
• Notre service d'accompagnement ISO 27001 complet