Registre des Incidents ISO 27001 : Template Excel [A.5.24]

Le registre des incidents de sécurité de l'information est un document obligatoire pour toute organisation engagée dans une démarche ISO 27001:2022. Les contrôles A.5.24 à A.5.28 de l'Annexe A forment un ensemble cohérent qui encadre la gestion complète du cycle de vie d'un incident : planification et préparation de la réponse (A.5.24), signalement des événements (A.5.25), évaluation et décision (A.5.26), réponse aux incidents (A.5.27), et capitalisation par les leçons apprises (A.5.28). Sans registre structuré, il est impossible de démontrer à un auditeur de certification que votre organisation gère les incidents de manière systématique, traçable et améliorable. Ce template Excel, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, répond à l'ensemble de ces exigences en un seul fichier. Il intègre les délais de notification légaux et réglementaires : 24 heures pour les opérateurs de services essentiels (OSE) soumis à la directive NIS 2 qui doivent notifier l'ANSSI des incidents significatifs, et 72 heures pour la notification à la CNIL en cas de violation de données personnelles (Article 33 du RGPD). Le registre est conçu pour être utilisable immédiatement par les RSSI, les SOC analysts, les responsables conformité et les auditeurs internes. Il permet de tracer chaque incident depuis sa détection jusqu'à sa clôture formelle, d'analyser les tendances mensuelles grâce aux KPI automatisés, de préparer les rapports de revue de direction, et de constituer le dossier de preuves pour l'audit de certification. La gestion rigoureuse des incidents n'est pas seulement une exigence normative : c'est un levier concret de réduction du risque cyber et d'amélioration continue du SMSI, au cœur de la clause 10 d'ISO 27001.

Contexte réglementaire et normatif

La gestion des incidents de sécurité est encadrée par un ensemble de référentiels et réglementations qui se superposent et se renforcent mutuellement :

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

La version 2022 d'ISO 27001 a restructuré et renforcé les exigences en matière de gestion des incidents par rapport à la version 2013. Les cinq contrôles A.5.24-28 forment désormais un processus intégré :

• A.5.24 — Planification et préparation : l'organisation doit planifier et se préparer à la gestion des incidents en définissant les rôles, responsabilités et procédures avant qu'un incident ne survienne. Ce contrôle exige une procédure de gestion des incidents documentée et testée.
• A.5.25 — Évaluation et décision sur les événements de sécurité : tous les événements suspects doivent être évalués pour déterminer s'ils constituent des incidents de sécurité. Cette qualification est critique : elle détermine le niveau d'escalade et les délais de notification applicables.
• A.5.26 — Réponse aux incidents : les incidents qualifiés doivent faire l'objet d'une réponse structurée et documentée (confinement, éradication, récupération).
• A.5.27 — Leçons apprises des incidents : chaque incident clôturé doit donner lieu à une analyse des causes racines et à l'identification de mesures préventives pour éviter la récurrence.
• A.5.28 — Collecte de preuves : les preuves numériques liées aux incidents doivent être collectées, préservées et documentées selon des procédures qui garantissent leur intégrité (chaîne de custody).

Directive NIS 2 — Obligations de notification

La directive NIS 2 (transposée en droit français en 2024) impose aux entités essentielles et importantes des obligations strictes de notification des incidents significatifs à l'ANSSI. Le calendrier de notification est le suivant : alerte préliminaire dans les 24 heures après détection, rapport d'incident complet dans les 72 heures, et rapport final dans le mois suivant la résolution. Un incident est considéré "significatif" s'il a causé ou est susceptible de causer une perturbation grave des services. Le registre ISO 27001 doit documenter ces notifications pour démontrer la conformité NIS 2. Pour en savoir plus sur les obligations NIS 2, consultez notre article sur la conformité NIS 2.

RGPD — Notification des violations de données

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 susceptible d'engendrer un risque pour les droits et libertés des personnes. L'Article 34 impose d'informer directement les personnes concernées en cas de risque élevé. Le registre incidents ISO 27001 doit inclure une colonne "Données personnelles concernées" et le référencement des notifications CNIL effectuées, pour démontrer la cohérence entre la gestion des incidents cyber et la conformité RGPD.

Structure détaillée du template Excel

Onglet 1 — Registre des incidents (log principal)

C'est le cœur du document. Chaque ligne représente un incident avec les informations suivantes : identifiant unique (format INC-AAAA-NNN), date et heure de détection, date et heure de déclaration formelle, source de détection (SOC, utilisateur, outil automatique, prestataire), catégorie d'incident (intrusion, malware, phishing, fuite de données, déni de service, accès non autorisé, défaillance système, etc.), description courte et description détaillée, systèmes et actifs impactés (avec référence à l'inventaire des actifs), criticité initiale (P1/P2/P3/P4), classification finale après évaluation, données personnelles concernées (O/N), notification CNIL effectuée (O/N/NA) avec date, notification ANSSI effectuée (O/N/NA) avec date, responsable de la gestion (incident manager), statut (Ouvert/En cours/Résolu/Clôturé), date de résolution, date de clôture formelle, durée totale de traitement, mesures de confinement prises, causes racines identifiées, mesures correctives décidées, et référence aux leçons apprises.

Onglet 2 — Tableau de bord KPI mensuel

Un dashboard automatisé calcule les indicateurs clés sur la période sélectionnée : nombre total d'incidents par mois et par trimestre, répartition par catégorie et par criticité, temps moyen de détection (MTTD — Mean Time To Detect), temps moyen de résolution (MTTR — Mean Time To Resolve), taux d'incidents avec données personnelles, taux de notification CNIL dans les 72h, taux de récurrence (incidents similaires au cours des 12 derniers mois), et évolution mensuelle du nombre d'incidents (tendance). Ces KPI sont directement exploitables pour la revue de direction (clause 9.3 ISO 27001) et pour les rapports adressés à la Direction.

Onglet 3 — Catalogue des catégories d'incidents

Un référentiel standardisé des catégories d'incidents avec leur description, leur criticité par défaut, et les seuils de notification applicables. Ce référentiel garantit la cohérence de la qualification entre différents opérateurs du registre et facilite l'analyse statistique.

Onglet 4 — Matrice d'escalade

La matrice d'escalade définit qui doit être notifié selon la criticité de l'incident (P1 : RSSI + DG + équipe d'intervention dans l'heure ; P2 : RSSI + responsables métier dans les 4h ; P3 : RSSI dans le jour ouvré ; P4 : traitement normal). Elle inclut les coordonnées des interlocuteurs clés (astreinte, hotline cyber, ANSSI, CNIL, assureur cyber).

Onglet 5 — Historique des révisions

Trace toutes les modifications du registre avec date, auteur et nature de la modification. Indispensable pour maintenir la traçabilité et démontrer à l'auditeur que le document est activement maintenu.

Guide d'utilisation étape par étape

1. Paramétrer le registre avant le premier incident : complétez l'onglet "Catalogue des catégories" avec les types d'incidents pertinents pour votre organisation, définissez votre matrice de criticité (P1 à P4) en cohérence avec votre procédure de gestion des incidents, et renseignez la matrice d'escalade avec les coordonnées actuelles. Ce travail préparatoire est crucial : en situation de crise, on n'a pas le temps de définir les procédures.
2. Déclarer tout événement suspect comme événement potentiel : la norme A.5.25 exige que tout événement suspect soit évalué. La pratique recommandée est d'enregistrer d'abord comme "événement" (non qualifié) puis de qualifier en "incident" après évaluation. Cela évite de passer à côté d'incidents réels par manque de signalement.
3. Qualifier la criticité dans les premières heures : la criticité initiale (P1 à P4) doit être évaluée rapidement car elle déclenche le niveau d'escalade. La qualification définitive peut être revue après investigation mais l'escalade initiale doit être faite sans délai pour les incidents critiques.
4. Vérifier les obligations de notification : pour chaque incident, vérifiez dans les premières heures si des données personnelles sont concernées (délai CNIL 72h) et si l'incident est significatif au sens NIS 2 (délai ANSSI 24h). Ces délais courent dès la détection, pas dès la qualification complète. Documentez les décisions de notification ou de non-notification dans le registre.
5. Documenter les actions en temps réel : pendant la gestion de l'incident, le registre doit être mis à jour au fil de l'eau : actions de confinement, analyses forensiques, systèmes restaurés, communications effectuées. Cette documentation en temps réel est essentielle pour les preuves (A.5.28) et pour la reconstruction de la timeline en post-incident.
6. Conduire le post-mortem et documenter les leçons apprises : dans les 5 à 10 jours ouvrés suivant la clôture de l'incident, organisez une réunion de post-mortem avec toutes les parties prenantes. Documentez les causes racines réelles (5 pourquoi, ishikawa, ou analyse RCCA selon votre maturité), les mesures correctives décidées avec responsables et délais, et les indicateurs qui auraient pu permettre une détection plus précoce.
7. Clôturer formellement chaque incident : un incident n'est clôturé que lorsque les mesures correctives immédiates ont été mises en œuvre et vérifiées. La clôture formelle doit être validée par le RSSI ou un manager désigné. Les incidents à fort impact peuvent nécessiter une validation par la Direction avant clôture.
8. Exploiter le registre pour la revue de direction : le registre incidents est l'un des inputs obligatoires de la revue de direction (clause 9.3 ISO 27001). Préparez un rapport synthétique basé sur l'onglet KPI : tendances, incidents significatifs de la période, taux de résolution dans les SLA, mesures préventives mises en œuvre suite aux leçons apprises.

Tableau des contrôles — Checklist gestion des incidents complète

Points de vigilance pour l'audit de certification

1. Registre vide ou avec très peu d'incidents : un registre vierge ou avec seulement 2-3 incidents en 12 mois est suspect pour un auditeur. Soit votre organisation n'a vraiment aucun incident (peu probable), soit les événements ne sont pas signalés ou enregistrés. Remédiation : sensibilisez les utilisateurs au signalement, abaissez le seuil d'enregistrement, et documentez les quasi-incidents et les signalements de sécurité même mineurs.
2. Post-mortem manquants pour les incidents P1/P2 : les auditeurs demandent systématiquement les rapports post-mortem pour les incidents critiques. L'absence de post-mortem est une non-conformité majeure sur A.5.27. Remédiation : systématisez le post-mortem pour tout incident P1/P2 et planifiez-les dans les 10 jours ouvrés suivant la clôture.
3. Délais de notification CNIL/ANSSI non respectés : les auditeurs vérifient les dates de détection et de notification pour les incidents impliquant des données personnelles ou qualifiés de significatifs au sens NIS 2. Un retard de notification peut constituer une violation réglementaire grave. Remédiation : formez l'équipe aux seuils de notification et intégrez une vérification automatique dans le registre (alerte si données perso et pas de notification après 48h).
4. Mesures correctives décidées mais jamais mises en œuvre : les auditeurs font le suivi des mesures correctives des années précédentes et vérifient leur mise en œuvre effective. Des plans d'action qui ne sont jamais réalisés indiquent un problème systémique. Remédiation : intégrez le suivi des mesures correctives dans l'audit interne et dans la revue de direction.
5. Confusion entre incident et non-conformité : certains incidents de sécurité doivent être tracés à la fois dans le registre incidents (A.5.24) et dans le registre des non-conformités (Clause 10). L'absence de lien entre ces deux registres est un manquement fréquemment noté. Remédiation : définissez des critères clairs de double-enregistrement et ajoutez une colonne "Réf. NC" dans le registre incidents.
6. Preuves numériques non conservées ou altérées : A.5.28 exige la collecte et préservation des preuves selon des procédures garantissant leur intégrité. Des logs purgés, des screenshots non horodatés, ou des preuves sans chaîne de custody sont insuffisants. Remédiation : documentez une procédure de collecte de preuves avec hachage des fichiers et stockage dans un espace immuable.
7. Exercices de simulation inexistants : la norme exige que la réponse aux incidents soit testée. Un plan sur papier non testé n'est pas crédible en audit. Remédiation : organisez au minimum un exercice de table-top par an, documentez-le dans le registre, et tracez les améliorations identifiées lors de l'exercice.
8. Registre incidents non sécurisé (accès trop large) : le registre incidents contient des informations très sensibles sur les vulnérabilités de votre organisation. S'il est accessible à tous les collaborateurs, c'est une faille. Remédiation : restreignez l'accès au RSSI, aux analystes sécurité et aux auditeurs mandatés, et documentez cette restriction.

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

REGISTRE DES INCIDENTS (A.5.24-28) ← Document opérationnel
│
├── ALIMENTE →
│   ├── Registre des non-conformités (Clause 10) — incidents → NC si récurrents
│   ├── Plan d'amélioration continue — leçons apprises → actions SMSI
│   ├── Revue de direction (Clause 9.3) — KPI incidents comme input obligatoire
│   ├── Tableau de bord ISMS — indicateurs de performance (A.5.24 / ISO 27004)
│   └── Rapport annuel RSSI — synthèse pour la Direction
│
├── EST ALIMENTÉ PAR →
│   ├── Signalements utilisateurs (canal de signalement défini)
│   ├── Alertes SOC / SIEM / outils de détection
│   ├── Prestataires et fournisseurs (notification d'incident selon contrats)
│   └── Surveillance de sécurité (A.8.16 — monitoring)
│
├── COHÉRENCE REQUISE AVEC →
│   ├── Procédure gestion incidents (A.5.24) — processus de référence
│   ├── Inventaire des actifs (A.5.9) — actifs impactés par les incidents
│   ├── Registre des risques — incidents réels vs risques anticipés
│   ├── PCA/BCP (ISO 22301) — activation si incident P1 avec impact continuité
│   └── Registre RGPD (Art.30) — violations de données personnelles
│
└── EST VÉRIFIÉ PAR →
    ├── Audit interne (Clause 9.2) — revue du registre et des post-mortems
    ├── Revue de direction (Clause 9.3) — KPI et tendances
    └── Audit de certification — A.5.24 à A.5.28 vérifiés en Stage 2

Bonnes pratiques terrain

• Créez une culture du signalement sans punition : le plus grand frein au bon fonctionnement du registre incidents est la peur des utilisateurs d'être sanctionnés s'ils signalent une erreur qu'ils ont commise (clic sur un lien de phishing, clé USB trouvée branchée). Communiquez clairement que le signalement est valorisé, pas pénalisé.
• Automatisez l'alimentation du registre depuis votre SIEM : si vous disposez d'un SIEM (Splunk, Elastic, Microsoft Sentinel), configurez des alertes qui créent automatiquement une entrée dans le registre lors de dépassement de seuil. Cela réduit la charge manuelle et améliore la complétude.
• Intégrez le registre dans votre ITSM : si votre organisation utilise un outil ITSM (ServiceNow, Jira, GLPI), l'idéal est que les incidents de sécurité soient tracés dans l'ITSM avec les attributs ISO 27001 enrichis. Le template Excel est un excellent point de départ en l'absence d'ITSM.
• Publiez des statistiques anonymisées en interne : partager régulièrement avec les collaborateurs des statistiques agrégées (nombre d'incidents ce trimestre, top 3 des vecteurs d'attaque) crée de la conscience sécurité et valorise l'utilité du signalement.
• Préparez des fiches réflexe par type d'incident : pour les types d'incidents les plus fréquents (phishing, ransomware, fuite de données), préparez des fiches réflexe qui guident les équipes dans les premières heures critiques. Ces fiches doivent être annexées à la procédure de gestion des incidents.

Questions fréquentes sur le registre des incidents ISO 27001

Quelle est la différence entre un événement de sécurité et un incident de sécurité selon ISO 27001 ?

La distinction est fondamentale et souvent mal comprise. Un événement de sécurité (security event) est tout occurrence identifiée sur un système, un service ou un réseau qui indique une possible violation de la politique de sécurité, un échec de contrôle, ou une situation inconnue pouvant être pertinente pour la sécurité. Un incident de sécurité (security incident) est un événement ou une série d'événements indésirables ou inattendus qui présentent une probabilité significative de compromettre les opérations métier et de menacer la sécurité de l'information. En pratique : une tentative de connexion avec un mauvais mot de passe est un événement ; une série de 1000 tentatives de connexion suivies d'une connexion réussie depuis un pays inhabituel est un incident. Selon A.5.25, tous les événements de sécurité doivent être évalués pour déterminer s'ils doivent être classifiés comme incidents. Le registre peut inclure une colonne "Type" pour distinguer événements et incidents, avec un workflow de qualification formelle entre les deux statuts. Cette distinction impacte directement les délais de notification : les obligations NIS 2 et RGPD s'appliquent aux incidents qualifiés, pas nécessairement aux événements bruts.

Combien de temps doit-on conserver le registre des incidents ?

ISO 27001 n'impose pas de durée de conservation spécifique mais exige que les informations documentées soient conservées comme preuves de conformité. La pratique communément recommandée est de conserver le registre incidents pendant au minimum 3 ans, et 5 ans pour les incidents impliquant des données personnelles (afin de couvrir les délais de prescription RGPD). Pour les organisations soumises à des réglementations sectorielles spécifiques (santé, finance, défense), des durées plus longues peuvent s'appliquer. Techniquement, la conservation à long terme doit préserver l'intégrité du document : un fichier Excel modifiable n'est pas suffisant comme archive légale. Pour les incidents significatifs, archivez une version PDF signée et horodatée dans un espace immuable. Le registre doit également être sauvegardé régulièrement et les sauvegardes testées — un registre incidents perdu dans un ransomware serait particulièrement problématique et gênant pour la relation avec les autorités.

Doit-on déclarer un incident interne (erreur d'un collaborateur) à l'ANSSI ou la CNIL ?

La nature interne ou externe de l'incident n'est pas le critère déterminant pour les obligations de notification. Ce qui compte est l'impact de l'incident. Pour la CNIL (RGPD Article 33) : si l'incident — quelle qu'en soit la cause, humaine, technique ou malveillante — a conduit à une destruction, perte, altération, divulgation ou accès non autorisé à des données personnelles, et si cela est susceptible d'engendrer un risque pour les droits et libertés des personnes, la notification est obligatoire dans les 72h. Exemple : un collaborateur qui envoie par erreur un fichier contenant des données clients à la mauvaise adresse email doit donner lieu à une évaluation RGPD et probablement une notification CNIL. Pour l'ANSSI (NIS 2) : si l'incident — même interne — a causé une perturbation significative des services essentiels de votre organisation (pour les entités NIS 2), il doit être notifié. Exemple : une erreur de configuration par un administrateur qui a rendu le service indisponible pendant 8 heures peut constituer un incident significatif NIS 2. En cas de doute, il vaut mieux notifier et en discuter avec l'autorité que de ne pas notifier et risquer une sanction pour non-déclaration. L'ANSSI et la CNIL apprécient la transparence proactive.

Comment gérer les incidents impliquant un sous-traitant ?

Les incidents de sécurité chez vos sous-traitants qui impactent vos données ou vos systèmes doivent être tracés dans votre registre incidents, même si c'est le sous-traitant qui gère la réponse technique. Vos contrats de sous-traitance doivent imposer des obligations de notification (délai, format, canal) pour tout incident de sécurité chez le prestataire impactant vos données ou vos services. Ces clauses sont exigées par A.5.19-23 d'ISO 27001 et par l'Article 28 du RGPD pour les sous-traitants traitant des données personnelles. En pratique : lorsqu'un sous-traitant vous notifie d'un incident, ouvrez immédiatement une fiche dans votre registre avec le statut "Incident sous-traitant", qualifiez l'impact sur votre organisation, et évaluez si des obligations de notification CNIL ou ANSSI vous incombent en tant que responsable de traitement. Ne laissez pas le sous-traitant décider seul si vous devez notifier — c'est votre responsabilité légale en tant que responsable de traitement RGPD. Le registre des sous-traitants doit référencer les obligations contractuelles de notification pour chaque prestataire.

Comment mesurer l'efficacité de notre gestion des incidents ?

L'efficacité de la gestion des incidents se mesure avec des indicateurs clés (KPI) que votre registre doit permettre de calculer automatiquement. Les principaux KPI recommandés sont : le MTTD (Mean Time To Detect) — temps moyen entre l'occurrence réelle d'un incident et sa détection, indicateur de la qualité de votre surveillance ; le MTTC (Mean Time To Contain) — temps moyen entre la détection et le confinement de l'incident, indicateur de la réactivité de votre équipe de réponse ; le MTTR (Mean Time To Resolve) — temps moyen entre la détection et la résolution complète, indicateur de l'efficacité globale de votre processus ; le taux de récurrence — pourcentage d'incidents du même type dans les 12 mois, indicateur de l'efficacité de vos mesures correctives ; et le taux de respect des SLA de notification (CNIL 72h, ANSSI 24h). Ces KPI doivent être mesurés mensuellement, présentés en revue de direction, et leur évolution dans le temps démontre la dynamique d'amélioration continue de votre SMSI — un argument fort pour l'auditeur de certification lors du renouvellement.

Que faire si notre organisation n'a enregistré aucun incident depuis 12 mois ?

L'absence d'incidents enregistrés sur une longue période n'est généralement pas une bonne nouvelle : elle indique presque toujours que les événements de sécurité ne sont pas signalés ou pas détectés, plutôt qu'une absence réelle de problèmes. Un auditeur ISO 27001 expérimenté sera très sceptique face à un registre vide sur 12 mois pour une organisation de taille significative. Les recommandations sont les suivantes : menez une campagne de sensibilisation au signalement pour rappeler aux collaborateurs l'importance de tout signaler ; vérifiez que votre canal de signalement est fonctionnel et connu ; analysez vos logs système — des anomalies non signalées sont-elles présentes ? ; enregistrez rétroactivement les quasi-incidents et les signalements informels qui n'avaient pas été formalisés dans le registre ; et considérez la réalisation d'un test de phishing interne pour mesurer le taux de clic et le taux de signalement. En audit de certification, un registre vide génère systématiquement des questions sur l'efficacité de la détection et du signalement. Il vaut mieux avoir un registre avec 50 incidents mineurs bien documentés que 0 incident — cela démontre que le processus fonctionne.

Pour aller plus loin

• Procédure de gestion des incidents ISO 27001 [A.5.24-28] — Modèle Word
• Registre des non-conformités ISO 27001 [Clause 10]
• Tableau de bord KPI ISMS ISO 27004 [25 indicateurs]
• Plan d'audit interne ISO 27001 — Template Excel
• Notre service d'accompagnement ISO 27001 complet