Registre des Incidents de Sécurité NIS2/RGPD (Template PDF)

Le registre des incidents de sécurité est un document opérationnel et réglementaire indispensable pour toute organisation soumise à la directive européenne NIS 2 et au Règlement Général sur la Protection des Données (RGPD). Loin d'être un simple tableau de suivi administratif, le registre des incidents constitue la mémoire organisationnelle de votre cybersécurité : il documente chaque événement de sécurité survenu, les actions de réponse entreprises, les leçons tirées, et les améliorations mises en œuvre. L'article 23 de la directive NIS 2 impose aux entités essentielles et importantes de notifier les incidents significatifs et de maintenir une documentation exhaustive de leur gestion des incidents. L'article 33(5) du RGPD exige quant à lui la documentation de toute violation de données personnelles, qu'elle ait fait l'objet d'une notification à la CNIL ou non. Ce guide détaillé vous accompagne dans la conception, la mise en œuvre et l'exploitation d'un registre des incidents conforme aux exigences réglementaires les plus récentes, avec un modèle professionnel téléchargeable au format PDF prêt à l'emploi.

Obligations NIS 2 en matière de documentation des incidents (Article 23)

La directive NIS 2 (Network and Information Security Directive 2), adoptée en décembre 2022 et transposée en droit national des États membres, renforce considérablement les obligations de gestion des incidents de sécurité par rapport à la directive NIS 1. L'article 23 établit un cadre de notification et de documentation des incidents significatifs qui impose une rigueur documentaire inédite.

Un incident est considéré comme « significatif » au sens de NIS 2 s'il a causé ou est susceptible de causer une perturbation opérationnelle grave des services, des pertes financières importantes pour l'entité concernée, ou un préjudice pour d'autres personnes physiques ou morales en causant des dommages matériels, corporels ou moraux considérables. Les critères précis de significativité sont définis par les actes d'exécution de la Commission européenne et les transpositions nationales.

Le processus de notification NIS 2 est structuré en trois phases obligatoires. L'alerte précoce (early warning) doit être transmise au CSIRT national (CERT-FR en France) dans les 24 heures suivant la détection, indiquant si l'incident est susceptible d'avoir été causé par un acte malveillant et s'il peut avoir un impact transfrontalier. Le rapport d'incident, dû dans les 72 heures, fournit une évaluation initiale de l'incident, de sa gravité et de son impact, ainsi que des indicateurs de compromission. Le rapport final, dû dans le mois suivant la résolution, contient une description détaillée, l'analyse des causes racines, les mesures de remédiation et l'évaluation de l'impact transfrontalier.

Le registre des incidents est le support opérationnel qui alimente ces notifications. Chaque notification exige des informations précises, horodatées et documentées que seul un registre bien tenu peut fournir dans les délais imposés. Sans registre, la conformité aux délais de notification est virtuellement impossible.

Obligations RGPD en matière de documentation des violations (Article 33)

L'article 33(5) du RGPD impose une obligation spécifique et souvent méconnue : « Le responsable du traitement documente toute violation de données à caractère personnel, en indiquant les faits concernant la violation, ses effets et les mesures prises pour y remédier. Cette documentation permet à l'autorité de contrôle de vérifier le respect du présent article. »

Cette obligation s'applique à toutes les violations de données personnelles, y compris celles qui ne nécessitent pas de notification à la CNIL (parce qu'elles n'engendrent pas de risque pour les personnes concernées). La documentation doit être suffisamment détaillée pour permettre à la CNIL, lors d'un contrôle, de vérifier que l'évaluation du risque a été correctement effectuée et que la décision de notifier ou de ne pas notifier était justifiée.

Le registre des violations de données peut être intégré au registre général des incidents de sécurité, à condition d'inclure les champs spécifiques au RGPD : catégories de données personnelles affectées, catégories et nombre approximatif de personnes concernées, conséquences probables pour les droits et libertés des personnes, évaluation du niveau de risque (faible, modéré, élevé), décision de notification et justification, et pour les incidents notifiés à la CNIL, le numéro de dossier de notification et les échanges avec l'autorité.

Pourquoi le registre des incidents est stratégiquement vital

Au-delà de la conformité réglementaire, le registre des incidents remplit plusieurs fonctions stratégiques qui en font un outil de pilotage essentiel de la cybersécurité.

La détection de patterns est l'une des valeurs ajoutées les plus importantes du registre. L'analyse historique des incidents révèle des tendances que les événements isolés ne permettent pas de percevoir : augmentation des tentatives de phishing ciblant un département spécifique, recrudescence des infections par malware après les périodes de congés, vulnérabilités récurrentes sur un type d'équipement, erreurs humaines répétitives dans un processus métier. Ces patterns orientent les investissements de sécurité et les programmes de sensibilisation vers les risques les plus concrets.

L'audit trail (piste d'audit) constitue une preuve de diligence en cas de contrôle réglementaire, de litige ou de sinistre. Un registre bien tenu démontre que l'organisation prend la sécurité au sérieux, qu'elle détecte et traite les incidents de manière structurée, et qu'elle tire les leçons de chaque événement. À l'inverse, l'absence de registre ou un registre lacunaire est un signal négatif fort pour les auditeurs, les régulateurs et les assureurs.

Les réclamations d'assurance cyber nécessitent une documentation précise des incidents : date et heure de détection, nature et étendue des dommages, actions de remédiation entreprises, coûts associés. Le registre fournit cette documentation de manière structurée et horodatée, facilitant le traitement des sinistres et réduisant les délais d'indemnisation. Consultez notre article sur les exigences des cyber-assureurs en 2026.

Les 13 colonnes essentielles du registre des incidents

Un registre complet et conforme doit contenir au minimum 13 colonnes couvrant l'intégralité du cycle de vie de l'incident. Voici chaque colonne expliquée en détail avec des exemples et des bonnes pratiques de remplissage.

Colonne 1 : Date et heure de détection

L'horodatage précis de la détection est la première information à consigner. Utilisez le format ISO 8601 (AAAA-MM-JJ HH:MM:SS) avec indication du fuseau horaire (UTC+1 ou UTC+2 pour la France selon la saison). La précision est essentielle car le délai de 24 heures (NIS 2) et de 72 heures (RGPD) court à partir de ce moment. Distinguez la date de détection (quand l'organisation a pris connaissance de l'incident) de la date estimée de début de l'incident (quand la compromission a réellement commencé, déterminée ultérieurement par l'investigation). Exemple : « Détection : 2026-05-05 14:32:00 UTC+2 | Début estimé : 2026-05-03 03:15:00 UTC+2 ».

Colonne 2 : Temps de détection (dwell time)

Le dwell time mesure le délai entre le début réel de l'incident et sa détection. Cet indicateur est crucial pour évaluer l'efficacité des capacités de détection de l'organisation. Un dwell time élevé (semaines, mois) indique une faiblesse dans les mécanismes de surveillance. Le temps médian de détection est de 10 jours au niveau mondial (Mandiant M-Trends 2025), mais les organisations matures avec SOC/SIEM visent un dwell time inférieur à 24 heures. Cette colonne n'est pas toujours remplissable au moment de l'enregistrement initial et peut être complétée à l'issue de l'investigation.

Colonne 3 : Type d'incident (taxonomie)

La classification de l'incident par type est indispensable pour l'analyse statistique et la détection de patterns. Nous recommandons une taxonomie à 10 catégories détaillée plus loin dans ce guide. Exemples : « Ransomware — LockBit 3.0 », « Phishing — compromission de compte », « Violation de données — accès non autorisé », « DDoS — volumétrique L4 ». Utilisez une liste déroulante dans votre outil de registre pour garantir la cohérence du vocabulaire entre les différents enregistreurs.

Colonne 4 : Sévérité (matrice avec exemples)

La sévérité évalue l'impact de l'incident sur l'organisation. Utilisez une échelle à 4 niveaux cohérente avec votre plan de réponse à incident : Critique (S1) — continuité d'activité menacée, données massivement compromises ; Élevée (S2) — impact significatif sur un service ou une population de données ; Modérée (S3) — impact limité et contenu rapidement ; Faible (S4) — impact négligeable, incident mineur. La sévérité initiale peut être réévaluée au fil de l'investigation.

Colonne 5 : Description détaillée de l'incident

La description doit être factuelle, chronologique et précise. Évitez le jargon inutile mais soyez techniquement précis. Incluez : comment l'incident a été découvert, les premiers symptômes observés, les hypothèses initiales et leur validation/invalidation, et l'évolution de la compréhension de l'incident au fil du temps. Exemple : « À 14h32, alerte SIEM : détection de 500 échecs d'authentification en 10 minutes sur le portail VPN depuis l'IP 185.220.xxx.xxx (Tor exit node). Investigation : password spraying ciblant les comptes du domaine. 3 comptes compromis identifiés (mots de passe faibles). Pas de mouvement latéral détecté. »

Colonne 6 : Systèmes impactés (cartographie)

Listez précisément les systèmes, applications, réseaux et données affectés par l'incident. Utilisez les identifiants de votre CMDB (Configuration Management Database) si vous en disposez. Incluez le nombre d'utilisateurs impactés, les données affectées (nature, volume, sensibilité), et l'impact sur les processus métier. Exemple : « Serveur SRV-ERP-01 (ERP Sage X3), base de données MySQL clients (45 000 enregistrements), réseau VLAN 10 (production). Impact métier : facturation impossible pendant 6 heures. »

Processus documentaire

Colonne 7 : Actions immédiates (playbook)

Documentez les premières actions de confinement entreprises dans les minutes et heures suivant la détection : isolation réseau, verrouillage de comptes, blocage d'IP/domaines, déconnexion de systèmes, activation du plan de réponse à incident. Pour chaque action, notez l'heure de réalisation et la personne responsable. Cette colonne est essentielle pour évaluer la réactivité de l'organisation et pour la reconstitution chronologique lors du retour d'expérience.

Colonne 8 : Responsable assigné (matrice RACI)

Identifiez clairement le responsable principal de l'incident (Incident Manager) et les personnes impliquées dans la réponse. Utilisez la matrice RACI : Responsible (qui fait le travail), Accountable (qui prend les décisions), Consulted (qui est consulté), Informed (qui est informé). Exemple : « R : Jean Dupont (analyste SOC), A : Marie Martin (RSSI), C : Paul Durand (DPO), I : Direction générale ».

Colonne 9 : Statut et workflow

Le statut suit un workflow prédéfini reflétant les phases du cycle de vie de l'incident : Nouveau → En cours d'investigation → En cours de confinement → En cours d'éradication → En cours de récupération → En cours de REX → Clos. Chaque changement de statut est horodaté. Un incident ne peut être clos qu'après validation par le responsable que toutes les actions de remédiation ont été réalisées et que le retour d'expérience a été effectué.

Colonne 10 : Critères de clôture

Définissez les critères objectifs qui doivent être remplis pour clôturer l'incident : la menace a été éradiquée (confirmation par scan de sécurité), les systèmes affectés ont été restaurés et validés, les causes racines ont été identifiées, les mesures correctives ont été mises en œuvre ou planifiées, le retour d'expérience a été réalisé, et les notifications réglementaires ont été effectuées si nécessaire (CNIL, CERT-FR). La clôture est formalisée par la signature du responsable d'incident et du RSSI.

Colonne 11 : Leçons apprises (template de REX)

Pour chaque incident de sévérité S1 à S3, documentez les leçons tirées : ce qui a bien fonctionné (détection rapide, réponse efficace, communication claire), ce qui a mal fonctionné (fausse alerte initiale, retard de confinement, manque de documentation), ce qui était improvisé (procédure non prévue, outil manquant), et les recommandations d'amélioration. Chaque recommandation doit être transformée en action avec un responsable et une date cible.

Colonne 12 : Suivi des notifications réglementaires

Tracez les notifications réglementaires liées à l'incident : notification CNIL (date, numéro de dossier, statut : initiale/complétée/clôturée), notification NIS 2 au CERT-FR (alerte précoce, rapport d'incident, rapport final), communication aux personnes concernées (article 34 RGPD), et notification à l'assureur cyber. Pour chaque notification, conservez une copie du formulaire soumis et des échanges avec l'autorité.

Colonne 13 : Coûts et impact financier

Documentez les coûts associés à l'incident : coûts directs (heures de travail de remédiation, intervention de prestataires externes, remplacement de matériel), coûts indirects (perte de productivité, interruption d'activité, pénalités contractuelles), et coûts de notification et de communication (frais de notification aux personnes concernées, communication de crise). Cette information est essentielle pour les réclamations d'assurance, la justification des investissements de sécurité, et le calcul du ROI de la cybersécurité.

Taxonomie des incidents : 10 types avec exemples concrets

Une classification cohérente des incidents est essentielle pour l'analyse statistique et la comparaison dans le temps. Voici une taxonomie en 10 catégories couvrant l'ensemble des incidents de sécurité courants.

Type 1 — Malware : infection par un logiciel malveillant (virus, trojan, worm, ransomware, cryptominer, adware). Exemple : « Infection par le ransomware Akira via pièce jointe Excel malveillante, 3 postes et 1 serveur de fichiers chiffrés. »

Type 2 — Phishing/Ingénierie sociale : tentative ou succès de manipulation d'un utilisateur pour obtenir des informations ou un accès. Exemple : « Spear phishing ciblant le directeur financier, fausse facture d'un fournisseur, virement de 45 000 € vers un compte frauduleux. »

Type 3 — Compromission de compte : accès non autorisé à un compte utilisateur par credential stuffing, password spraying, ou vol de session. Exemple : « Compromission du compte O365 de 5 utilisateurs par password spraying, exfiltration de 200 e-mails confidentiels. »

Type 4 — Déni de service (DDoS) : attaque visant à rendre un service indisponible par saturation. Exemple : « Attaque DDoS volumétrique (15 Gbps) sur le site web commercial pendant 4 heures, perte estimée de 30 000 € de CA. »

Type 5 — Intrusion système : accès non autorisé à un système via exploitation de vulnérabilité, mouvement latéral, élévation de privilèges. Exemple : « Exploitation de CVE-2024-XXXX sur le serveur Apache exposé, accès root obtenu, mouvement latéral vers le contrôleur Active Directory. »

Type 6 — Violation de données : accès, divulgation ou perte de données à caractère personnel ou confidentiel. Exemple : « E-mail contenant la liste des salaires envoyé par erreur à l'ensemble du personnel (700 personnes). »

Type 7 — Menace interne : action malveillante ou négligente d'un collaborateur, prestataire ou ex-employé. Exemple : « Ancien employé ayant conservé ses accès VPN télécharge la base clients avant son départ effectif. »

Type 8 — Vulnérabilité exploitée : exploitation active d'une faille de sécurité sur un système exposé. Exemple : « Exploitation de la vulnérabilité Log4Shell sur un serveur Elasticsearch non patché, exécution de code à distance. »

Type 9 — Attaque supply chain : compromission via un fournisseur, prestataire ou composant logiciel tiers. Exemple : « Mise à jour malveillante du plugin WordPress utilisé sur le site vitrine, injection de code JavaScript cryptominer. »

Type 10 — Incident physique : vol de matériel, accès physique non autorisé, destruction de supports. Exemple : « Vol d'un laptop non chiffré contenant des dossiers patients dans le train Paris-Lyon. »

Matrice de sévérité avec temps de réponse SLA

La matrice de sévérité doit être associée à des temps de réponse engagés (SLA — Service Level Agreement) pour chaque niveau, garantissant une mobilisation proportionnée à l'urgence.

Sévérité Critique (S1) : temps de réponse initial ≤ 15 minutes, mobilisation complète du CSIRT ≤ 1 heure, première communication à la direction ≤ 2 heures, notification NIS 2 (alerte précoce) ≤ 24 heures. Le CSIRT est en mobilisation continue (24/7) jusqu'à la résolution.

Sévérité Élevée (S2) : temps de réponse initial ≤ 1 heure, mobilisation de l'équipe de sécurité ≤ 4 heures, escalade au management si nécessaire ≤ 8 heures. Résolution cible : 48-72 heures.

Sévérité Modérée (S3) : temps de réponse initial ≤ 4 heures, prise en charge par l'équipe de sécurité pendant les heures ouvrées, résolution cible : 5 jours ouvrés.

Sévérité Faible (S4) : temps de réponse initial ≤ 24 heures, traitement dans le cadre des opérations courantes, résolution cible : 10 jours ouvrés.

Maintenance et exploitation du registre

Un registre n'a de valeur que s'il est maintenu de manière rigoureuse et exploité régulièrement. La mise à jour doit être effectuée en temps réel pendant les incidents actifs (le « scribe » de l'équipe de réponse est chargé de cette tâche) et dans les 24 heures pour les incidents mineurs. Chaque mois, le RSSI doit effectuer une revue mensuelle du registre : vérification de la complétude (toutes les colonnes renseignées pour chaque incident), relance des incidents ouverts dont le statut n'a pas évolué, et suivi de la mise en œuvre des actions correctives issues des REX.

Chaque trimestre, une analyse trimestrielle approfondie doit être réalisée : statistiques par type, sévérité et département, tendances par rapport aux trimestres précédents, identification des risques émergents, évaluation des KPIs de réponse (temps de détection, temps de confinement, temps de résolution), et présentation au comité de direction ou au comité de sécurité. Cette analyse alimente la mise à jour de l'analyse de risques et du plan de sécurité.

Intégration avec les outils SIEM et SOAR

Pour les organisations disposant d'un SIEM (Security Information and Event Management) ou d'un SOAR (Security Orchestration, Automation and Response), l'intégration du registre avec ces outils automatise une partie du processus de documentation et améliore la réactivité.

L'intégration SIEM→Registre permet de créer automatiquement une entrée dans le registre lorsqu'une alerte SIEM est qualifiée comme incident réel (vrai positif). Les informations techniques (source, type, horodatage, systèmes concernés) sont pré-rempliées à partir des données du SIEM, réduisant le travail manuel de documentation et garantissant la précision de l'horodatage.

L'intégration SOAR→Registre automatise les mises à jour de statut lorsque les playbooks de réponse sont exécutés : le passage du statut « En cours d'investigation » à « En cours de confinement » est déclenché automatiquement par l'exécution de l'action de confinement dans le SOAR, avec horodatage et traçabilité complète.

Les solutions de ticketing IT (ServiceNow, Jira Service Management, GLPI) peuvent également être utilisées comme support du registre, en configurant un projet ou une catégorie dédiée aux incidents de sécurité avec les 13 champs obligatoires. L'avantage est l'intégration avec le workflow existant de l'IT et la familiarité des équipes avec l'outil.

KPIs de sécurité à extraire du registre

Le registre est une mine de données pour le pilotage de la cybersécurité. Voici les KPIs (Key Performance Indicators) essentiels à calculer et suivre trimestriellement.

MTTD (Mean Time To Detect) : temps moyen entre le début de l'incident et sa détection. Cet indicateur mesure l'efficacité des capacités de détection. Objectif : MTTD < 24 heures pour les incidents de sévérité S1-S2.

MTTC (Mean Time To Contain) : temps moyen entre la détection et le confinement complet de la menace. Mesure la réactivité de l'équipe de réponse. Objectif : MTTC < 4 heures pour les S1, < 24 heures pour les S2.

MTTR (Mean Time To Resolve) : temps moyen entre la détection et la résolution complète (systèmes restaurés, incident clos). Mesure l'efficacité globale du processus de réponse.

Nombre d'incidents par type et tendance : évolution du nombre d'incidents par catégorie, permettant d'identifier les menaces croissantes et l'efficacité des mesures de prévention.

Taux de récurrence : pourcentage d'incidents du même type se reproduisant après la mise en œuvre des actions correctives. Un taux élevé indique que les leçons ne sont pas correctement tirées ou que les actions correctives sont insuffisantes.

Coût moyen par incident : permet de quantifier l'impact financier de la cybersécurité et de justifier les investissements de prévention.

Durée de conservation du registre

La question de la durée de conservation du registre des incidents est encadrée par plusieurs textes. Le RGPD impose la conservation de la documentation des violations aussi longtemps que le responsable de traitement est susceptible de faire l'objet d'un contrôle de la CNIL (pas de durée maximale explicite, mais la CNIL recommande 5 ans comme durée raisonnable). NIS 2 ne fixe pas de durée explicite mais les obligations de reporting et d'audit impliquent une conservation d'au moins 3 ans. Les exigences des cyber-assureurs imposent généralement la conservation des registres pendant la durée du contrat et 2 ans après son terme. L'ISO 27001 recommande la conservation des enregistrements de sécurité pendant au moins 3 ans.

Notre recommandation est une conservation de 5 ans minimum, avec archivage sécurisé au-delà (les données anciennes restent accessibles pour l'analyse de tendances à long terme mais sont déplacées vers un stockage d'archivage). Les registres contenant des données personnelles (noms des personnes impliquées, données des personnes concernées par une violation) doivent respecter le principe de minimisation du RGPD : anonymisez les données personnelles non nécessaires après la clôture de l'incident et la fin des éventuelles procédures judiciaires.

Classification des incidents par impact métier

Au-delà de la classification technique par type de menace, il est essentiel d'évaluer chaque incident selon son impact sur les activités métier de l'organisation. Cette double classification (technique et métier) permet une communication plus efficace avec la direction générale, qui raisonne en termes d'impact opérationnel plutôt qu'en termes de vecteur d'attaque.

L'impact sur la disponibilité des services mesure la durée et l'étendue de l'interruption des services métier critiques. Un ransomware chiffrant le serveur ERP a un impact maximal sur la disponibilité si aucun PCA n'est activé. Un DDoS sur le site web commercial a un impact limité si les ventes en ligne ne représentent qu'une fraction du chiffre d'affaires. Quantifiez l'impact en heures d'indisponibilité multipliées par le coût horaire estimé de l'interruption.

L'impact sur la confidentialité des données mesure le volume et la sensibilité des données exposées. Utilisez la classification des données de votre organisation (public, interne, confidentiel, secret) et le nombre de personnes potentiellement affectées. Un accès non autorisé à 10 documents internes de faible sensibilité a un impact différent d'une exfiltration de 100 000 dossiers clients contenant des données financières.

L'impact réputationnel est souvent le plus difficile à quantifier mais peut être le plus dévastateur à long terme. Une violation de données médiatisée, un défacement de site web visible publiquement, ou une arnaque utilisant le nom de l'entreprise affectent la confiance des clients, des partenaires et des investisseurs. Évaluez l'impact réputationnel selon l'exposition médiatique (locale, nationale, internationale), le profil des personnes affectées (clients, partenaires, grand public), et la durée de l'exposition.

L'impact réglementaire mesure les obligations de notification déclenchées par l'incident et les sanctions potentielles. Un incident impliquant des données personnelles déclenche les obligations RGPD (notification CNIL 72h, communication aux personnes). Un incident significatif chez une entité NIS 2 déclenche les obligations de l'article 23. Un incident dans le secteur financier peut déclencher les obligations DORA. Documentez précisément les obligations réglementaires applicables à chaque incident pour garantir le respect des délais.

Modèles de registre et formats recommandés

Le choix du format et de l'outil de registre dépend de la taille et de la maturité de l'organisation. Pour les TPE et PME (jusqu'à 100 salariés), un tableur structuré (Excel avec macro de validation, ou Google Sheets avec formulaire de saisie) est un point de départ pragmatique. Le modèle PDF que nous proposons en téléchargement peut être directement transposé dans un tableur avec les 13 colonnes. Protégez le fichier par mot de passe, limitez les droits d'édition aux personnes habilitées, et effectuez une sauvegarde hebdomadaire automatique. L'utilisation de Google Forms comme interface de saisie connectée à un Google Sheets offre une ergonomie améliorée et un horodatage automatique.

Pour les ETI (100 à 5000 salariés), un outil de ticketing (Jira Service Management, ServiceNow, GLPI) offre un workflow structuré, une traçabilité complète des modifications, des permissions granulaires, et des capacités de reporting intégrées. Configurez un type de ticket « Incident de sécurité » avec les 13 champs obligatoires comme champs personnalisés. Les transitions de workflow (Nouveau → Investigation → Confinement → Éradication → Récupération → REX → Clos) automatisent le suivi du statut.

Pour les grands groupes et organisations matures, l'intégration native avec le SIEM (Splunk, IBM QRadar, Microsoft Sentinel), le SOAR (Palo Alto XSOAR, Splunk SOAR, IBM Resilient) et la plateforme GRC (ServiceNow GRC, Archer, OneTrust) offre une automatisation maximale : création automatique d'incidents à partir des alertes qualifiées, pré-remplissage des champs techniques, orchestration des actions de réponse, et reporting consolidé multi-sources. Cette intégration nécessite un investissement initial significatif mais réduit considérablement le travail manuel de documentation et améliore la qualité des données.

Exercice pratique : documenter un incident fictif

Pour vous familiariser avec le registre, voici un exercice de documentation basé sur un scénario réaliste. Scénario : le lundi 5 mai 2026 à 09h15, un collaborateur du service commercial signale au service informatique qu'il reçoit des appels de clients lui demandant pourquoi il a envoyé un e-mail avec un lien suspect. L'investigation révèle que son compte de messagerie a été compromis par du password spraying, que l'attaquant a envoyé un e-mail de phishing à l'ensemble de ses contacts (450 adresses, dont 320 clients), et qu'un transfert automatique de tous ses e-mails vers une adresse Gmail externe avait été configuré.

Documentation dans le registre : Date de détection : 2026-05-05 09:15 UTC+2. Dwell time estimé : 48h (l'attaquant a accédé au compte le samedi 3 mai). Type : Compromission de compte — password spraying + phishing sortant. Sévérité initiale : S2 (élevée) → réévaluée S1 (critique) après découverte du transfert d'e-mails. Description : « Compromission du compte O365 de J. Martin (commercial) par password spraying (mot de passe 'Commercial2026!'). L'attaquant a configuré un transfert vers attaquant@gmail.com à 03h20 le 03/05 et envoyé un e-mail de phishing à 450 contacts le 04/05 à 22h45. » Systèmes impactés : compte O365 j.martin@entreprise.fr, messagerie, contacts CRM exportés. Actions immédiates : réinitialisation du mot de passe (09h20), suppression du transfert (09h22), révocation des sessions actives (09h25), activation MFA (09h30), blocage de l'IP source au pare-feu (09h35), communication aux clients (e-mail d'alerte à 10h00). Responsable : RSSI (A), Admin O365 (R), DPO (C), Direction commerciale (I). Notifications : CNIL notifiée le 05/05 (données clients — noms, e-mails, historique de correspondance — potentiellement exfiltrés via le transfert). Leçons apprises : absence de MFA sur les comptes commerciaux, mot de passe conforme à la politique mais prévisible, pas de surveillance des règles de transfert e-mail.

Bonnes pratiques de rédaction des entrées du registre

La qualité des entrées du registre conditionne son utilité opérationnelle et réglementaire. Voici les bonnes pratiques de rédaction à respecter pour chaque incident. Utilisez un langage factuel et objectif : décrivez les faits observés sans interprétation ni jugement de valeur. Préférez « Le compte de J. Martin a été compromis via password spraying » à « J. Martin a utilisé un mot de passe trop simple et s'est fait pirater ». Horodatez chaque action au format ISO 8601 avec fuseau horaire. Distinguez clairement les faits confirmés des hypothèses en cours de vérification (utilisez des formulations comme « confirmé par l'analyse des logs » versus « hypothèse à vérifier »). Maintenez un niveau de détail proportionné à la sévérité : un incident S4 nécessite quelques lignes, un incident S1 peut nécessiter plusieurs pages. Utilisez des identifiants techniques précis (noms de serveurs, adresses IP, CVE, hash de fichiers) qui facilitent la corrélation avec les données SIEM et la traçabilité forensique.

Questions fréquentes sur le registre des incidents de sécurité

Le registre des incidents est-il obligatoire pour toutes les entreprises ?

Le registre des violations de données personnelles est obligatoire pour tout responsable de traitement au titre de l'article 33(5) du RGPD, c'est-à-dire pour toute organisation qui traite des données personnelles (soit la quasi-totalité des entreprises). Le registre des incidents de sécurité au sens large est obligatoire pour les entités soumises à NIS 2. Pour les autres, il constitue une bonne pratique fortement recommandée par l'ANSSI et un prérequis pour la certification ISO 27001.

Quel outil utiliser pour tenir le registre ?

Pour les petites structures, un tableur (Excel, Google Sheets) avec les 13 colonnes peut suffire, à condition qu'il soit protégé par mot de passe et sauvegardé régulièrement. Pour les structures moyennes, un outil de ticketing (Jira, GLPI, ServiceNow) avec un projet dédié offre un meilleur workflow et une traçabilité plus robuste. Pour les grandes organisations, l'intégration avec le SIEM/SOAR et un outil GRC (Governance, Risk, Compliance) comme Archer, OneTrust ou ServiceNow GRC est recommandée.

Qui doit avoir accès au registre des incidents ?

L'accès au registre doit être strictement contrôlé car il contient des informations sensibles (vulnérabilités exploitées, systèmes compromis, données personnelles affectées). L'accès en écriture doit être limité à l'équipe de sécurité (RSSI, analystes SOC, incident managers). L'accès en lecture doit être accordé au DPO, à la direction juridique, à la direction générale, et aux auditeurs internes/externes sur demande motivée. Les informations techniques détaillées (IOC, vulnérabilités) ne doivent pas être accessibles aux personnes non habilitées.

Comment intégrer le registre dans une démarche ISO 27001 ?

L'ISO 27001 (Annexe A, contrôle A.5.24 « Information security incident management planning and preparation » et A.5.25 « Assessment and decision on information security events ») exige la tenue d'enregistrements des incidents de sécurité. Le registre des incidents est directement utilisable comme preuve de conformité lors de l'audit de certification. Veillez à ce que le registre soit cohérent avec la procédure de gestion des incidents documentée dans votre SMSI (Système de Management de la Sécurité de l'Information). Pour en savoir plus, consultez notre offre d'accompagnement ISO 27001.

Faut-il distinguer le registre des incidents du registre des violations RGPD ?

Vous pouvez maintenir un registre unique couvrant à la fois les incidents de sécurité et les violations de données RGPD, à condition d'inclure les champs spécifiques au RGPD (catégories de données, nombre de personnes, évaluation du risque, notifications). Un champ « Type réglementaire » (NIS 2, RGPD, les deux, aucun) permet de filtrer rapidement les événements selon le cadre réglementaire applicable. Cette approche unifiée est plus efficace et évite les doublons entre deux registres distincts.

Comment former les équipes à l'utilisation du registre ?

La formation doit être pratique et contextuelle. Intégrez la documentation dans les exercices de simulation (tabletop exercises) : pendant l'exercice, un participant est désigné comme « scribe » et doit renseigner le registre en temps réel. Après l'exercice, analysez la qualité de la documentation. Créez un guide de saisie avec des exemples concrets pour chaque colonne, des erreurs courantes à éviter (descriptions trop vagues, horodatage imprécis, statut non mis à jour), et les niveaux de détail attendus selon la sévérité de l'incident.

Quel est le lien entre le registre des incidents et le plan de réponse à incident ?

Le plan de réponse à incident définit le processus (qui fait quoi, dans quel ordre, avec quels outils), tandis que le registre documente l'exécution de ce processus pour chaque incident réel. Le plan prescrit, le registre enregistre. Les leçons tirées du registre alimentent la mise à jour du plan : si le registre révèle que le temps de confinement est systématiquement supérieur au SLA, le plan doit être révisé pour identifier et lever les obstacles.

Comment utiliser le registre pour améliorer la cybersécurité ?

L'exploitation proactive du registre passe par l'analyse trimestrielle des tendances : quels types d'incidents sont en augmentation (nécessité de renforcer les défenses correspondantes), quels départements sont les plus touchés (cibler les programmes de sensibilisation), quelles vulnérabilités sont le plus fréquemment exploitées (prioriser les patches), et quel est le ratio entre incidents détectés en interne et incidents signalés par des tiers (mesure de la maturité de détection). Chaque analyse doit déboucher sur des actions concrètes intégrées au plan d'amélioration de la sécurité.

Inspiré des recommandations de cybermalveillance.gouv.fr (licence Etalab 2.0), de l'ANSSI et de la CNIL.

Conclusion

La prévention et la préparation restent les meilleures armes face aux cybermenaces. Téléchargez cette ressource, diffusez-la dans votre organisation et n'hésitez pas à nous contacter pour un accompagnement personnalisé.