Journaux d’incidents de sécurité : comment créer des journaux conformes au RGPD et aux autorités de régulation

La partie la plus difficile d’un incident de sécurité survient généralement après la fin de l’incident : lorsque l’entreprise doit expliquer ce qui s’est passé, quand il a été découvert, quelles données ont été concernées, qui a été affecté et pourquoi certaines décisions ont été prises.

Pour de nombreuses PME, ces enregistrements n’existent pas sous une forme complète. Les informations peuvent être dispersées dans les messages de discussion, les boîtes de réception, les tickets d’assistance, les captures d’écran et la mémoire des membres de l’équipe. Les entreprises se maintiennent à flot pendant un incident grâce à ces enregistrements hétéroclites, mais ils posent problème lorsqu’une autorité de contrôle, un assureur, un client ou un membre du conseil d’administration demande une chronologie claire.

Les entreprises de toutes tailles ont besoin d’un journal d’incidents de sécurité complet. Il doit constituer une source unique de vérité pour consigner ce qui s’est passé, comment l’incident a été géré et quels éléments de preuve étayent les décisions prises tout au long du processus.

Ce registre est précieux même lorsque vous n’avez pas besoin de signaler un incident. Nous expliquerons pourquoi les journaux d’incidents de sécurité sont utiles pour votre entreprise et comment créer le vôtre.

Pourquoi les journaux d’incidents de sécurité sont importants

Journaux d’incidents ou plans de réponse aux incidents

Ce qu’un journal d’incidents de sécurité doit contenir

Un modèle simple de journal d’incidents pour les PME

Comment consigner les décisions de notification

Ce que les autorités de contrôle attendent des journaux d’incidents de sécurité

Le journal des accès aux identifiants

Pourquoi les journaux d’incidents de sécurité sont importants

Les journaux d’incidents de sécurité créent une responsabilité au moment où une entreprise risque le plus de perdre le fil des informations. Pendant un incident, les actions s’enchaînent rapidement : les mots de passe sont réinitialisés, les comptes sont désactivés, les prestataires informatiques sont contactés, les données clients sont vérifiées et la direction est informée. Ces étapes peuvent être exactement ce dont l’entreprise a besoin sur le moment, mais elles deviennent bien plus difficiles à expliquer par la suite si personne n’enregistre quand chaque action a eu lieu, qui l’a approuvée et quels éléments de preuve ont étayé la décision.

Pour les entreprises établies en Europe, il ne s’agit pas seulement d’une bonne pratique. En vertu du Règlement général sur la protection des données (RGPD), au Royaume-Uni comme dans l’UE, les fuites de données personnelles doivent être évaluées et certaines doivent être signalées à l’autorité de contrôle compétente.

Au Royaume-Uni, les conseils de l’ICO pour signaler une violation(nouvelle fenêtre)⁠ expliquent que les organisations doivent évaluer le risque probable pour les droits et libertés des personnes et notifier l’ICO lorsque ce risque est probable. L’article 33 exige également que les responsables du traitement documentent les fuites de données personnelles, y compris les faits de la violation, ses effets et les mesures correctives prises. Les mêmes exigences s’appliquent en vertu du RGPD de l’UE.

Par exemple, l’ICO ne s’attend pas à ce que chaque PME dispose de systèmes de niveau entreprise, mais elle attend des enregistrements appropriés. Son cadre de réponse et de surveillance des violations indique que les organisations doivent disposer de procédures pour garantir que les incidents et les fuites de données personnelles sont détectés, gérés et consignés de manière appropriée. Cela signifie qu’un journal d’incidents ne doit pas être créé uniquement lorsqu’une violation grave s’est déjà produite. Il doit faire partie du processus de réponse normal.

De bons enregistrements facilitent également les demandes d’indemnisation. Les assureurs cyber peuvent demander des preuves du moment où l’incident a été découvert, des mesures de confinement prises, des comptes touchés et de la manière dont l’entreprise a suivi son processus de réponse aux incidents. Un journal bien tenu peut montrer que l’entreprise a agi rapidement et de manière cohérente.

Cela aide aussi l’entreprise à apprendre. Les souvenirs et les témoignages oraux ne sont pas fiables, mais un enregistrement qui montre que l’incident a commencé par un mot de passe réutilisé, une authentification multifacteur (MFA) manquante, un accès fournisseur ou un départ tardif donne à l’entreprise un élément concret à corriger et une orientation plus claire pour renforcer la sécurité au fil du temps.

Journaux d’incidents ou plans de réponse aux incidents

Un journal d’incidents de sécurité et un plan de réponse aux incidents sont liés, mais ce ne sont pas les mêmes documents.

Un plan de réponse aux incidents explique ce que l’entreprise doit faire en cas de problème. Il attribue les rôles, les voies d’escalade, les mesures de confinement, les responsabilités de communication et les procédures de récupération. Le journal d’incidents consigne ce qui s’est réellement passé. Il constitue la chronologie, la piste de preuves, le registre des décisions et le dossier de suivi d’un événement spécifique.

Cette distinction est importante car même un bon plan peut échouer sans documentation. Une entreprise peut suivre les bonnes étapes mais avoir du mal à le prouver par la suite. Le journal doit permettre de répondre à des questions pratiques : quand l’avons-nous su, qui a agi, qu’avons-nous confiné, quelles données étaient à risque, qu’avons-nous décidé et qu’est-ce qui a changé ensuite ?

Ce qu’un journal d’incidents de sécurité doit contenir

Un journal d’incidents utile doit être suffisamment cohérent pour qu’une entreprise puisse reconstituer l’événement par la suite et expliquer les décisions prises pendant la réponse.

Date et heure de la découverte

Consignez le moment où l’entreprise a pris connaissance de l’incident pour la première fois, qui l’a remarqué et comment il a été découvert. Si l’heure est approximative, indiquez-le. L’heure de la découverte est importante car les délais de notification du RGPD et les exigences des assureurs dépendent souvent du moment où l’entreprise a pris connaissance du problème.

Nature de l’incident

Décrivez ce qui s’est passé en termes simples. Évitez les libellés vagues tels que « problème de sécurité » ou « fuite potentielle » sans contexte. Le journal doit expliquer quels systèmes ont été touchés et si l’incident impliquait des identifiants, des e-mails, des fichiers, des données clients, des systèmes de paiement, des points de terminaison ou des accès tiers.

Données concernées

Si des données personnelles ont pu être touchées, consignez le type de données concernées : noms, adresses e-mail, numéros de téléphone, adresses, informations de compte, informations financières, dossiers des employés, communications clients, identifiants de connexion ou toute autre catégorie pertinente. Estimez le nombre de personnes susceptibles d’être touchées et précisez si ce nombre est confirmé ou encore en cours d’investigation.

Cause probable

Consignez la cause connue ou suspectée, même si l’investigation est toujours en cours. À mesure que de nouvelles informations apparaissent, le journal peut être mis à jour de « cause inconnue » à « un e-mail d’hameçonnage a conduit à une compromission d’identifiants » ou « le compte d’un ancien prestataire est resté actif ». Le journal doit montrer comment la compréhension de l’entreprise a évolué au fil du temps.

Mesures de confinement immédiates

Documentez ce qui a été fait pour limiter les dommages. Cela peut inclure des réinitialisations de mots de passe, la révocation de sessions, l’application de l’authentification multifacteur (MFA), la suspension de comptes, la suppression de règles de messagerie, l’isolement d’appareils, la suppression d’accès fournisseur, des modifications de pare-feu ou des arrêts temporaires de service. Dans la mesure du possible, indiquez le responsable et l’horodatage de chaque action.

Décisions de notification

Consignez si l’entreprise a notifié l’autorité de contrôle compétente (l’ICO au Royaume-Uni, ou l’autorité nationale de protection des données ailleurs dans l’UE), les personnes concernées, les clients, les fournisseurs, les assureurs, les conseillers juridiques ou les forces de l’ordre. Si la décision a été de ne pas notifier, documentez le raisonnement. Cette explication est souvent aussi importante que la notification elle-même.

Étapes de remédiation et chronologie

Le confinement traite l’incident immédiat. La remédiation réduit le risque que le même problème se reproduise. Consignez les actions de suivi telles que l’application de l’authentification multifacteur (MFA), la suppression des identifiants partagés, la mise à jour des politiques d’accès, l’amélioration des processus de départ, la correction d’une mauvaise configuration ou la modification de la protection des sauvegardes.

Enseignements tirés

Terminez par ce que l’entreprise a appris et ce qui va changer. Cela ne doit pas être rédigé sous forme de reproche. Il convient d’identifier la faiblesse, l’amélioration nécessaire et la personne responsable du suivi.

Un modèle simple de journal d’incidents pour les PME

Un logiciel spécialisé n’est pas nécessaire pour documenter les incidents. Une feuille de calcul, un formulaire interne sécurisé, un système de tickets ou un registre partagé peuvent faire l’affaire si les accès sont contrôlés et les entrées maintenues de manière cohérente.

Un journal d’incidents efficace doit inclure les champs suivants :

• ID de l’incident : Un numéro de référence unique.
• Date et heure de la découverte : Moment où l’entreprise a pris connaissance de l’incident.
• Signalé par : un employé, un prestataire, un client, un fournisseur, une alerte de surveillance ou un tiers externe.
• Type d’incident : hameçonnage, logiciel malveillant, compromission d’identifiants, perte de données, accès non autorisé, rançongiciel, incident chez un fournisseur, perte d’appareil, message mal adressé ou autre.
• Résumé : ce qui s’est passé, rédigé en langage clair.
• Systèmes concernés : applications, comptes, appareils, bases de données, boîtes de réception ou services tiers concernés.
• Données concernées : si des données à caractère personnel ont été affectées, de quel type, et combien de personnes peuvent être touchées.
• Cause probable : connue, suspectée ou en cours d’investigation.
• Mesures de confinement : ce qui a été fait immédiatement.
• Décision de notification : autorité de contrôle, personnes concernées, clients, assureur ou absence de notification avec justification.
• Liens vers les preuves : captures d’écran, tickets, journaux, messages, enregistrements d’accès, fichiers exportés ou rapports de prestataires.
• Mesures de remédiation : étapes entreprises après le confinement.
• Responsable : personne chargée du suivi.
• Statut : ouvert, sous surveillance, contenu, résolu, fermé.
• Enseignements tirés : ce qui doit changer.

Comment consigner les décisions de notification

Les décisions de notification méritent une place à part dans un journal d’incidents de sécurité, car elles sont souvent examinées après l’incident.

En vertu du GDPR britannique et du GDPR de l’UE, les organisations doivent évaluer le risque probable pour les droits et libertés des personnes lorsqu’une fuite de données à caractère personnel se produit. Si le risque est probable, l’autorité de contrôle doit être notifiée dès que possible et, si possible, dans les 72 heures, l’ICO(nouvelle fenêtre) au Royaume-Uni, l’autorité nationale de protection des données dans chaque État membre de l’UE. Si le risque est élevé, les personnes concernées doivent également être notifiées sans retard injustifié. Les seuils et le délai sont les mêmes des deux côtés ; seule l’autorité change.

Un bon journal d’incidents doit montrer que l’entreprise a réalisé cette évaluation. Il doit consigner si des données à caractère personnel étaient concernées, quel type de préjudice pouvait en résulter, quelles protections étaient en place et pourquoi l’entreprise a décidé de signaler ou non l’incident.

Par exemple, un incident impliquant un mot de passe administrateur exposé peut ne pas révéler immédiatement si des données à caractère personnel ont été consultées. Le journal doit refléter cette incertitude. Il peut consigner la préoccupation initiale, les étapes de l’investigation, l’examen de l’activité du compte et la conclusion finale une fois les preuves disponibles.

À ce stade du processus, de nombreuses entreprises se concentrent sur l’organisation de la correction technique et oublient de consigner le raisonnement de conformité. Les mots de passe sont réinitialisés, les comptes sont sécurisés et les opérations se poursuivent. Quelques semaines plus tard, l’entreprise ne peut plus expliquer pourquoi elle a jugé que l’incident n’était pas à signaler.

Ce que les autorités de contrôle attendent des enregistrements

Les autorités de contrôle ne se contentent pas de vérifier si une fuite de données a été signalée. Elles peuvent également demander comment l’entreprise :

• a identifié l’incident
• a évalué le risque
• a décidé si une notification était nécessaire
• a documenté les mesures prises

Un bon enregistrement doit rendre l’histoire de l’incident claire du début à la fin. Il doit montrer ce qui s’est passé, quelles données à caractère personnel étaient concernées, quel préjudice pouvait en résulter, ce que l’entreprise a fait pour contenir le problème et pourquoi elle a signalé ou non la fuite de données.

Le niveau de détail doit correspondre à la gravité de l’incident. Un message mal adressé n’aura pas besoin du même enregistrement qu’une attaque par rançongiciel, mais il doit tout de même être documenté pour montrer que l’entreprise l’a correctement évalué.

Ces enregistrements doivent également être stockés de manière sécurisée. Les journaux d’incidents peuvent contenir des informations sensibles sur les personnes concernées, les systèmes exposés, les actions des employés, des captures d’écran, des journaux d’accès ou des étapes de remédiation. L’accès doit être limité aux personnes qui en ont besoin, et la conservation doit être alignée sur la politique de conservation des données plus large de l’entreprise.

Le journal d’accès aux identifiants

De nombreux incidents impliquent des identifiants : ils peuvent être déclenchés par un mot de passe réutilisé, un compte partagé, une boîte de réception compromise, un identifiant administrateur exposé, une invite MFA suspecte ou un employé qui n’a pas été correctement retiré des accès.

Pour cette raison, les enregistrements d’accès aux identifiants peuvent devenir une source directe pour la documentation des incidents de cybersécurité. Lorsqu’un incident implique un identifiant partagé ou un compte sensible, l’entreprise doit savoir qui avait accès, comment l’accès a été partagé, si les autorisations ont changé et si l’identifiant a été renouvelé après l’incident.

Un gestionnaire de mots de passe d’entreprise⁠ comme Proton Pass for Business aide les équipes à gérer les identifiants dans des coffres-forts chiffrés, à générer des mots de passe uniques, à utiliser le remplissage automatique, à partager des identifiants en toute sécurité, à gérer les clés d’accès et à utiliser l’authentification à deux facteurs intégrée. Pour la documentation des incidents, la valeur la plus forte réside dans la piste d’accès autour des identifiants : qui avait accès aux coffres-forts/comptes partagés, comment l’accès était géré et qui l’utilisait, et ce qui a changé après l’incident.

Un gestionnaire de mots de passe pour les équipes informatiques ajoute des fonctionnalités d’administration telles que des politiques, des rapports, des journaux, un contrôle d’accès basé sur les rôles, le provisionnement SCIM et une intégration SSO. Ces fonctionnalités peuvent aider les entreprises à montrer comment l’accès aux identifiants est contrôlé et à fournir des preuves lorsqu’un incident lié aux identifiants fait l’objet d’une investigation.

Un gestionnaire de mots de passe ne peut pas remplacer un journal d’incidents, une évaluation juridique, un processus de notification réglementaire ou un plan de réponse aux incidents. Mais il fournit des preuves liées aux identifiants qui peuvent alimenter ces processus.

Conservez une piste d’audit complète des accès aux identifiants avec un gestionnaire de mots de passe d’entreprise⁠.