Données à caractère personnel dans les journaux de sécurité : guide opérationnel GDPR, NIS2 et DORA
Un analyste de sécurité ouvre le SIEM à 02:17. L’alerte paraît d’abord classique : plusieurs échecs de connexion, une session réussie depuis une adresse IP inhabituelle, puis une rafale d’appels API vers un point de terminaison d’export client. En quelques minutes, le canal de gestion de l’incident est saturé. Le RSSI veut savoir s’il s’agit d’une compromission de compte. Le service juridique demande si les journaux contiennent des données à caractère personnel. Le DPO demande si l’identifiant utilisateur, l’adresse IP, l’identifiant d’appareil et les URL de requête présents dans le SIEM sont couverts par la notice d’information et par le registre des activités de traitement. Le responsable conformité demande si les journaux doivent être préservés aux fins de déclaration réglementaire. L’équipe relation client demande si un client pourra demander l’effacement de ces mêmes entrées de journal le lendemain.
C’est souvent à ce moment que les organisations découvrent que la journalisation de sécurité et la gouvernance de la protection des données ont été conçues comme deux univers séparés.
Les équipes de sécurité veulent des journaux détaillés, une conservation longue, un stockage immuable et un accès rapide. Les équipes protection des données exigent la minimisation, la limitation des finalités, un contrôle d’accès fondé sur les rôles, une discipline de conservation et la suppression lorsque les données ne sont plus nécessaires. Les intervenants en réponse aux incidents veulent préserver les éléments probants exactement dans leur état d’origine. La responsabilité au titre du GDPR impose à l’organisation d’expliquer pourquoi des données à caractère personnel sont présentes, qui y a accédé et combien de temps elles sont conservées. NIS2 et DORA ajoutent une exigence d’urgence : les entités essentielles, les entités importantes et les organisations financières doivent disposer d’éléments probants suffisants pour qualifier les incidents, les notifier dans les délais et démontrer une gestion efficace des risques liés aux TIC.
La réalité est simple et inconfortable : les journaux de sécurité sont souvent des référentiels de données à caractère personnel. Les journaux d’authentification peuvent contenir des noms d’utilisateur, adresses électroniques, adresses IP, empreintes d’appareil et données de géolocalisation. Les journaux applicatifs peuvent exposer des URL, chaînes de recherche, fragments de charge utile, numéros de dossier et contenus de messages. Les journaux EDR et cloud peuvent inclure des noms d’hôte associés à des employés, chemins de fichiers contenant des noms, identifiants de session et actions d’administration. Les journaux IAM peuvent révéler des changements de privilèges, des appartenances à des groupes et des tentatives d’accès échouées à des systèmes sensibles.
Si des journaux contiennent des données à caractère personnel, ils ne relèvent plus seulement de la journalisation ISO 27001. Ils deviennent un sujet de protection des données, de conservation, de preuve, de notification d’incident et de gouvernance des fournisseurs. Clarysec traite la gouvernance des données à caractère personnel dans les journaux de sécurité comme un enjeu transverse de conformité, et non comme un simple paramétrage d’outil.
Le véritable dilemme du RSSI : éléments probants de détection ou minimisation des données
Dans le scénario de 02:17, le RSSI fait face à un conflit opérationnel réel. Si les journaux sont trop pauvres, le SOC ne peut pas détecter la compromission, reconstruire les chronologies ni étayer les déclarations NIS2 et DORA. S’ils sont trop riches, l’organisation peut collecter plus de données à caractère personnel que nécessaire, les conserver trop longtemps, les exposer à trop d’administrateurs ou ne pas pouvoir répondre correctement aux droits GDPR et aux obligations de transparence.
GDPR définit largement les données à caractère personnel comme toute information se rapportant à une personne identifiée ou identifiable. Le traitement inclut la collecte, le stockage, l’utilisation, la divulgation, l’effacement et la destruction. En pratique, les journaux contenant des adresses IP, identifiants utilisateur, identifiants d’appareil ou enregistrements d’activité peuvent constituer des données à caractère personnel selon le contexte. Les principes GDPR imposent un traitement licite, loyal et transparent, la limitation des finalités, la minimisation des données, la limitation de la conservation, l’intégrité et la confidentialité, ainsi que la responsabilité.
La question de gouvernance n’est pas : « pouvons-nous journaliser des données à caractère personnel ? » La bonne question est : « quelles données à caractère personnel devons-nous journaliser pour la sécurité, la réponse aux incidents et la conformité, quelle base légale les justifie, quelles mesures de protection s’appliquent, et quand doivent-elles être supprimées, anonymisées ou placées sous gel de conservation approuvé ? »
La bibliothèque Clarysec de politiques d’entreprise relatives à la protection des données traite directement cette tension. La Politique de protection des données et de la vie privée, Exigences de mise en œuvre de la politique, clause 6.2.1, indique :
Seules les données nécessaires à une finalité métier spécifique et légitime peuvent être collectées et traitées.
Pour les PME, le même principe est énoncé dans la Data Protection and Privacy Policy-sme, Exigences de mise en œuvre de la politique, clause 6.2.1 :
Seules les données à caractère personnel minimales nécessaires doivent être collectées et conservées.
Cette phrase doit guider chaque décision de conception de la journalisation. Chaque champ de chaque source de journal est-il nécessaire à une finalité de sécurité, opérationnelle, légale ou contractuelle définie ?
Pourquoi ISO 27701 change la conversation sur la journalisation
ISO/IEC 27001:2022 fournit le système de management : périmètre, parties intéressées, appréciation des risques, traitement des risques, maîtrise opérationnelle, surveillance, audit interne et amélioration continue. ISO/IEC 27002:2022 fournit les lignes directrices de contrôle pour la journalisation, la surveillance, la protection des données à caractère personnel, la collecte des éléments probants, la protection des enregistrements, la suppression, le contrôle d’accès et la gestion des fournisseurs. ISO/IEC 27701 étend ce modèle au système de management des informations relatives à la vie privée, en se concentrant sur les responsables du traitement et sous-traitants, les rôles de protection des données, les registres de traitements, la protection de la vie privée dès la conception, la gestion des droits et les obligations des sous-traitants.
Pour les journaux de sécurité, ISO 27701 est importante parce qu’elle impose des questions propres à la protection des données que les équipes de sécurité omettent parfois :
- La source de journal traite-t-elle des données à caractère personnel en tant que responsable du traitement, sous-traitant, responsable conjoint du traitement ou sous-traitant ultérieur ?
- Les données de journal sont-elles incluses dans l’inventaire des traitements ?
- L’organisation sait-elle quels champs de journal contiennent des données à caractère personnel ?
- Les données à caractère personnel présentes dans les journaux sont-elles liées à des règles de conservation et de suppression ?
- Les clients responsables du traitement sont-ils informés de la journalisation des accès aux données à caractère personnel lorsque le contrat l’exige ?
- Les journaux sont-ils pris en compte lors de la réponse aux demandes d’accès, d’effacement ou de limitation ?
- Les incidents relatifs aux données à caractère personnel sont-ils évalués au regard des déclencheurs de notification liés à la protection des données, à la cybersécurité et au secteur financier ?
La PII Security and Access Control Policy de Clarysec traduit ces attentes en exigences opérationnelles. Dans Journalisation et surveillance, clause 4.6.1 :
[Both] Le propriétaire du système / propriétaire d’application DOIT définir dans REG12 le périmètre de journalisation des données à caractère personnel pour les événements d’authentification, les événements d’accès, les actions à privilèges, les activités d’export de données à caractère personnel et les modifications de configuration substantielles avant toute utilisation en production ou toute modification substantielle.
La clause 4.6.2 relie ensuite journalisation, contrôle d’accès et conservation :
[Both] Le responsable de la sécurité de l’information DOIT veiller à ce que les journaux contenant des données à caractère personnel soient soumis à des restrictions d’accès et rattachés à une règle approuvée de conservation ou de suppression dans REG02 ou REG12 avant le début de la surveillance des journaux.
Cela rend la gouvernance du PIMS opérationnelle. REG12 définit quelle journalisation des données à caractère personnel est autorisée et requise. REG02 identifie où les données à caractère personnel existent, y compris dans les journaux. Les règles de conservation et de suppression ne sont pas des documents ajoutés après coup : elles deviennent des prérequis à la journalisation en production.
Les journaux de sécurité sont des enregistrements, des éléments probants et une activité de traitement de données à caractère personnel
Une organisation mature ne traite pas les journaux comme de simples résidus techniques jetables. Les journaux sont des enregistrements. Pendant un incident, ils peuvent devenir des éléments probants juridiquement recevables. Lorsqu’ils contiennent des données à caractère personnel, ils constituent aussi des données de traitement soumises à la gouvernance de la protection des données.
La Politique de journalisation et de surveillance de Clarysec définit les attentes de normalisation des journaux. Dans Exigences de gouvernance, clause 5.1.4 :
Exigences relatives au format et à la normalisation des journaux (par exemple, horodatage, identifiant utilisateur, type d’événement, adresse IP source)
Ce sont précisément les champs qui rendent les journaux utiles pour la réponse aux incidents. Ce sont aussi les champs qui font souvent des journaux des données à caractère personnel. La même politique d’entreprise précise ce qui ne doit jamais se produire, dans Exigences de gouvernance, clause 5.3.3 :
Stockage de données sensibles en clair (par exemple, mots de passe, secrets cryptographiques)
L’enjeu n’est pas d’éviter tout identifiant dans les journaux. L’enjeu est que les identifiants soient intentionnels, protégés et justifiés. Les mots de passe, secrets, jetons complets et charges utiles inutiles ne doivent pas être journalisés. Les identifiants utilisateur, adresses IP et métadonnées d’événements peuvent être nécessaires, mais exigent des contrôles.
Pour les PME, la Logging and Monitoring Policy-sme de Clarysec intègre la revue protection des données dans la répartition des rôles. Dans Rôles et responsabilités, clause 4.3.1, elle impose de :
Vérifier que les données de journal relatives à des informations personnelles ou sensibles sont traitées conformément au GDPR et aux autres lois relatives à la protection des données.
La version PME établit également une exigence claire de conservation de référence. Dans Exigences de gouvernance, clause 5.2.1 :
Les journaux doivent être conservés pendant au moins 12 mois, sauf si une période de conservation plus longue est requise par la loi ou par contrat, ou justifiée dans le cadre d’un incident actif ou d’un litige.
Elle fixe aussi l’attente de protection, dans Exigences de gouvernance, clause 5.3.1 :
Les journaux doivent être stockés dans des emplacements protégés en écriture, et l’accès doit être limité au seul personnel autorisé.
Pour la réponse aux incidents en entreprise, la Evidence Collection and Forensics Policy, Exigences de mise en œuvre de la politique, clause 6.3.1, impose :
Les journaux des pare-feu, du SIEM, des agents terminaux, des plateformes de gestion des identités et des accès (IAM) et des plateformes cloud doivent être exportés et stockés dans des formats immuables.
La version PME ajoute un garde-fou de proportionnalité. La Evidence Collection and Forensics Policy-sme, Traitement des risques et exceptions, clause 7.2.1, indique :
Minimiser le périmètre de collecte ; ne recueillir que ce qui est nécessaire.
C’est le cœur d’une journalisation respectueuse de la protection des données : préserver ce qui est nécessaire, démontrer pourquoi c’est nécessaire, limiter les personnes pouvant y accéder et supprimer les données lorsque la finalité approuvée expire.
Le modèle de contrôle Clarysec pour des éléments probants respectueux de la protection des données
Dans Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec place la journalisation dans la phase de mise en œuvre des contrôles, étape 19 : contrôles technologiques I. Le guide explique l’exigence de contrôle ISO/IEC 27002:2022 :
A.8.15 – Journalisation : « Les journaux enregistrant les activités, exceptions, défauts et autres événements pertinents doivent être produits, stockés, protégés et analysés. »
La même étape demande aux organisations de générer des journaux pour les événements clés, de les stocker de manière sécurisée afin qu’ils ne puissent pas être altérés, de les conserver pendant une durée définie et de les analyser au moyen d’un SIEM ou d’un processus de revue. Elle relie aussi la journalisation à la notification des violations au titre du GDPR, aux enregistrements d’incidents DORA, à la gestion des risques NIS2 et à l’analyse des journaux de sécurité COBIT.
Mais la journalisation seule ne suffit pas. Dans la même phase, Zenith Blueprint traite la suppression. Il avertit que les données conservées au-delà de leur utilité opérationnelle augmentent l’exposition et le risque réglementaire, et vise explicitement les sauvegardes, instantanés et archives. C’est essentiel : une règle de conservation du SIEM n’a aucun effet si des archives de journaux répliquées ou des compartiments de stockage cloud conservent indéfiniment les mêmes données à caractère personnel.
À l’étape 23 : contrôles organisationnels, Zenith Blueprint couvre la collecte des éléments probants. Il indique que les éléments probants d’incident doivent être identifiés, collectés et préservés d’une manière juridiquement recevable, fiable et alignée sur les besoins d’investigation. Il souligne aussi une réalité opérationnelle : les éléments probants sont souvent perdus dans les premières minutes de réponse, lorsque les journaux sont écrasés par rotation, que les systèmes sont redémarrés ou que les administrateurs modifient des comptes compromis avant la prise d’instantanés.
L’étape 23 traite également la vie privée et la protection des données à caractère personnel. Le guide présente ces données comme un sujet de cycle de vie exigeant connaissance des données, classification, contrôle d’accès, masquage, suppression, chiffrement et obligations fournisseurs. Pour les journaux, cela signifie que le SIEM, l’EDR, la plateforme cloud de journalisation et le système de gestion des tickets doivent faire partie de l’inventaire des données à caractère personnel.
Cartographie croisée de conformité pour les données à caractère personnel dans les journaux
Zenith Controls: The Cross-Compliance Guide cartographie la mesure ISO/IEC 27002:2022 8.15, Journalisation, avec des contrôles associés essentiels à la gouvernance des données à caractère personnel. Ces relations montrent pourquoi la journalisation n’est pas seulement une préoccupation du SOC.
| Relation ISO/IEC 27002:2022 | Pourquoi c’est important pour les données à caractère personnel dans les journaux |
|---|---|
| 8.16 Activités de surveillance | La surveillance dépend des données de journal, mais les contrôles de protection des données doivent gouverner quelles données à caractère personnel sont surveillées et qui peut voir les alertes. |
| 5.25 Appréciation et décision relatives aux événements de sécurité de l’information | Les journaux soutiennent la qualification des événements, notamment pour déterminer si l’exposition de données à caractère personnel crée un incident notifiable. |
| 5.26 Réponse aux incidents de sécurité de l’information | Les équipes de réponse ont besoin des journaux pour le confinement et l’éradication, mais l’accès doit rester limité au besoin d’en connaître. |
| 5.27 Apprentissage à partir des incidents | Les journaux historiques soutiennent l’analyse de la cause racine et l’amélioration des contrôles, sous réserve des limites de conservation. |
| 8.17 Synchronisation des horloges | Des horodatages exacts sont essentiels pour les chronologies de violation, l’évaluation des DSAR et la reconstruction forensique. |
| 5.34 Vie privée et protection des données à caractère personnel | La journalisation des accès aux données à caractère personnel soutient la traçabilité et la responsabilité en matière de protection des données. |
| 5.28 Collecte des éléments de preuve | Les journaux protégés contre l’altération soutiennent l’investigation numérique et la recevabilité juridique. |
| 5.15 Contrôle d’accès | Les tentatives d’accès et les journaux d’accès aux données à caractère personnel valident l’efficacité des restrictions d’accès. |
| 5.33 Protection des enregistrements | Les journaux sont des enregistrements qui doivent être protégés contre l’altération, la perte et la divulgation non autorisée. |
Zenith Controls cartographie aussi la journalisation avec ISO/IEC 27002:2022 8.15, ISO/IEC 27035-1 et ISO/IEC 27035-2 pour la gestion des incidents, ISO/IEC 27701 pour la journalisation des activités de traitement de données à caractère personnel, ISO/IEC 27017 pour les journaux d’audit cloud, ISO/IEC 27018 pour la journalisation des accès aux données à caractère personnel dans le cloud, ISO/IEC 27005 pour les risques liés à une journalisation insuffisante, ISO/IEC 27033 pour la journalisation des activités réseau et ISO/IEC 15408-2 pour les fonctionnalités d’audit dans les produits évalués.
Pour la protection des données, Zenith Controls cartographie la mesure ISO/IEC 27002:2022 5.34, Vie privée et protection des données à caractère personnel, avec l’inventaire des actifs, le masquage des données, les services cloud, la classification, le transfert d’informations, le contrôle d’accès, la gestion des identités et la revue de sécurité des projets et changements. Pour un programme de gouvernance des journaux, ces liens deviennent des exigences de conception opérationnelles :
- Inventorier les référentiels de journaux comme emplacements de données à caractère personnel.
- Masquer ou tokeniser les données à caractère personnel lorsque les identifiants complets ne sont pas nécessaires.
- Revoir les services de journalisation cloud et les fournisseurs SIEM au titre des contrôles cloud et fournisseurs.
- Classifier les journaux contenant des données à caractère personnel comme des enregistrements sensibles.
- Gouverner les exports et transferts de journaux comme des transferts de données à caractère personnel.
- Restreindre l’accès aux journaux au moyen de contrôles d’identité et d’accès à privilèges.
- Revoir les changements de journalisation applicative avant la mise en production.
GDPR, NIS2 et DORA : un journal, trois prismes réglementaires
La même entrée de journal peut être analysée différemment au titre du GDPR, de NIS2 et de DORA.
Au titre du GDPR, l’organisation se demande si l’entrée contient des données à caractère personnel, quelle base légale justifie le traitement, si les données sont nécessaires, combien de temps elles sont conservées, qui peut y accéder, si elles sont divulguées à des sous-traitants ou à des clients, et si elles doivent être prises en compte dans une demande d’exercice des droits ou dans l’évaluation d’une violation de données à caractère personnel.
Au titre de NIS2, l’organisation se demande si les journaux soutiennent la gestion des risques de cybersécurité, la gestion des incidents, la continuité d’activité, le contrôle d’accès, la sécurité de la chaîne d’approvisionnement et l’évaluation de l’efficacité des contrôles. NIS2 Article 20 rend les organes de direction responsables de l’approbation et de la supervision des mesures de gestion des risques de cybersécurité. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. Article 23 instaure une notification par étapes pour les incidents significatifs : alerte précoce dans les 24 heures, notification dans les 72 heures et rapport final dans un délai d’un mois.
Au titre de DORA, les entités financières doivent exploiter un cadre documenté de gestion des risques liés aux TIC. DORA Article 5 attribue la responsabilité à l’organe de direction. Article 10 traite la détection. Article 17 exige un processus de gestion des incidents liés aux TIC. Article 18 couvre la classification des incidents liés aux TIC et des cybermenaces. Article 19 traite la notification des incidents majeurs liés aux TIC. Les journaux soutiennent la détection, la classification, l’analyse de la cause racine, l’évaluation d’impact, la réponse, le rétablissement et les éléments probants de remédiation.
| Prisme de conformité | Question clé pour les données à caractère personnel dans les journaux | Éléments probants attendus par Clarysec |
|---|---|---|
| GDPR | Les données à caractère personnel présentes dans les journaux sont-elles licites, nécessaires, transparentes, protégées et conservées uniquement aussi longtemps que nécessaire ? | Inventaire des données à caractère personnel, base légale, règle de conservation, contrôles d’accès, alignement avec la notice d’information, enregistrements d’évaluation des violations. |
| ISO 27701 | Les journaux de traitement de données à caractère personnel sont-ils gouvernés par les rôles PIMS et les obligations du responsable du traitement ou du sous-traitant ? | Inventaire REG02, périmètre de journalisation des données à caractère personnel REG12, procédures de gestion des droits, règles de divulgation par le sous-traitant, éléments probants de surveillance du PIMS. |
| NIS2 | Les journaux soutiennent-ils la détection, la réponse, la continuité d’activité et la notification des incidents significatifs ? | Chronologies d’incident, indicateurs de compromission, éléments probants de conservation des journaux, supervision par la direction, obligations de journalisation des fournisseurs. |
| DORA | Les journaux soutiennent-ils la classification des incidents TIC, la résilience, l’analyse de la cause racine et le reporting ? | Enregistrements d’incidents TIC, éléments probants immuables, couverture de journalisation des fonctions critiques, accès des tiers aux journaux et droits d’audit. |
| NIST CSF 2.0 | Les risques de cybersécurité, de protection des données et de chaîne d’approvisionnement sont-ils intégrés à la gouvernance des risques de l’entreprise ? | Profils actuel et cible, registre des risques, rôles fournisseurs, résultats de surveillance, éléments probants de réponse et de rétablissement. |
| COBIT 2019 | Les contrôles de journalisation, de protection des données et d’enregistrements sont-ils gouvernés, surveillés et améliorés ? | Revue de direction, surveillance de la conformité, suivi des actions, reporting de performance des contrôles. |
Une table de correspondance plus détaillée aide le RSSI à justifier la journalisation sans s’appuyer sur des déclarations vagues telles que « nous en avons besoin pour la sécurité ».
| Référentiel | Clauses ou articles pertinents | Comment la journalisation soutient l’exigence |
|---|---|---|
| GDPR | Articles 5(2), 30, 32, Recital 49 | Les journaux soutiennent la responsabilité, les registres des activités de traitement, la sécurité du traitement et les finalités de sécurité des réseaux et de l’information lorsqu’ils sont gouvernés et minimisés. |
| NIS2 Directive | Articles 20, 21, 23 | Les journaux soutiennent la supervision par la direction, la gestion des incidents, l’efficacité des contrôles et les délais de notification des incidents significatifs. |
| DORA | Articles 5, 10, 17, 18, 19 | Les journaux soutiennent la gestion des risques liés aux TIC, la détection, la gestion des incidents, la classification et la notification des incidents majeurs. |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Les journaux soutiennent la surveillance des systèmes et l’analyse des événements potentiellement défavorables. |
| COBIT 2019 | DSS05.07, DSS05.09, MEA03 | Les journaux soutiennent la surveillance des vulnérabilités, la surveillance et la journalisation de sécurité, la surveillance de la conformité et l’assurance. |
Construire un périmètre de journalisation des données à caractère personnel dans REG12
Un client Clarysec traiterait l’incident SIEM de 02:17 avant même qu’il ne survienne. L’organisation commence par une application orientée client qui traite des données de compte. Avant la production, le propriétaire d’application utilise REG12 pour définir le périmètre de journalisation des données à caractère personnel. L’objectif est de capturer suffisamment d’événements pour la sécurité et les éléments probants réglementaires sans journaliser de données à caractère personnel ni de contenu de charge utile inutiles.
| Source de journal | Événements à journaliser | Champs de données à caractère personnel autorisés | Champs de données à caractère personnel interdits | Règle de conservation | Rôle d’accès |
|---|---|---|---|---|---|
| Plateforme IAM | Connexion réussie, échec de connexion, échec d’authentification multifacteur, changement de privilège | Identifiant utilisateur, adresse IP source, identifiant d’appareil, horodatage | Mots de passe, codes de récupération, réponses de sécurité complètes | 12 mois, prolongation sous gel de conservation lié à un incident actif | Opérations de sécurité, responsable IAM |
| API applicative | Accès au point de terminaison d’export de données à caractère personnel, échec d’autorisation, volume élevé de requêtes à risque | Identifiant de compte, identifiant utilisateur, point de terminaison, adresse IP source | Corps de requête, contenu de message, détails complets de paiement | 12 mois, 24 mois pour un contrat client réglementé | Opérations de sécurité, propriétaire d’application |
| Plan de contrôle cloud | Connexion administrateur, changement de politique, changement d’accès à un compartiment de stockage, activité de clé | Identifiant administrateur, adresse IP source, identifiant de ressource | Secrets, jetons, clés privées | 12 mois, conservation pour litige si un incident est déclaré | Sécurité cloud, commandant d’incident |
| EDR | Alerte de logiciel malveillant, processus suspect, accès à un fichier dans un emplacement protégé | Nom d’hôte, identifiant utilisateur, métadonnées de processus | Contenu de fichier sauf si une collecte forensique est approuvée | 12 mois, conservation du dossier forensique en cas d’escalade | SOC, responsable forensique |
| Notes de dossier SIEM | Chronologie d’incident, décisions, références d’éléments probants | Noms du personnel, identifiants des utilisateurs affectés lorsque nécessaire | Charges utiles client non caviardées, captures d’écran inutiles | Calendrier de conservation des enregistrements d’incident | Équipe de réponse aux incidents, service juridique, responsable de la protection des données |
Ensuite, le responsable de la protection des données confirme si l’organisation agit comme responsable du traitement, sous-traitant ou les deux pour chaque source de journal. Si l’organisation est sous-traitante, les instructions contractuelles du client et les divulgations relatives aux sous-traitants ultérieurs peuvent encadrer l’accès aux journaux et leur partage. Si elle est responsable du traitement, les notices d’information, la base légale et la gestion des droits doivent être traitées.
Le propriétaire des données met ensuite à jour REG02 afin d’inclure les référentiels de journaux actifs, les index SIEM, les archives, les sauvegardes et les exports forensiques temporaires. Cela s’aligne avec la PII Retention, Deletion and Disposal Policy, Sauvegardes, archives, réplicas, journaux et fichiers temporaires, clause 4.4.1 :
[Both] Le propriétaire du système / propriétaire d’application DOIT identifier dans REG02 les magasins actifs, archives, copies de sauvegarde, réplicas, journaux, environnements de préproduction et fichiers temporaires contenant des données à caractère personnel avant la mise en production et lors de chaque revue annuelle de conservation.
La Politique de conservation et d’élimination des données doit ensuite aligner les règles de conservation métier avec les exigences légales, contractuelles et de préservation des éléments probants.
Enfin, l’équipe de sécurité configure le SIEM afin que les mots de passe, secrets et corps de charge utile soient supprimés ou caviardés avant ingestion. Les journaux contenant des données à caractère personnel sont affectés à des index restreints. La conservation est appliquée automatiquement, sauf gel lié à un incident ou gel légal approuvé. Les actions de suppression sont journalisées. Les exports forensiques exigent une approbation et un suivi de la chaîne de conservation. Les tableaux de bord affichent des identifiants pseudonymisés lorsque l’identité complète n’est pas nécessaire. La récupération historique des journaux est testée pendant les audits internes.
C’est la différence entre dire « nous journalisons pour la sécurité » et démontrer « nous ne journalisons que ce qui est nécessaire, nous le protégeons, nous le conservons selon des règles approuvées et nous pouvons l’utiliser comme élément probant sans violer les obligations de protection des données ».
DSAR, effacement et journaux : décider avant l’arrivée de la demande
L’une des questions les plus difficiles consiste à déterminer si les journaux doivent être recherchés, divulgués ou supprimés en réponse à des demandes d’accès ou d’effacement. La réponse dépend du rôle, de la finalité, de la base légale, de la faisabilité, des exemptions et des obligations de conservation. Mais le processus de gouvernance ne doit pas être improvisé demande par demande.
La PII Principal Rights Management Policy, Vérification de l’identité, champ d’application et évaluation, clause 4.2.3, indique :
[Controller] Le responsable de processus / propriétaire métier DOIT identifier les systèmes, enregistrements, finalités, catégories de données à caractère personnel, destinataires et contraintes de conservation pertinents à partir de REG02 avant d’évaluer l’exécution de la demande.
Cela signifie que les journaux doivent figurer dans REG02 avec des métadonnées claires : catégories de données à caractère personnel, finalité, contrainte de conservation et modalité de traitement d’une demande par divulgation directe, accès résumé, limitation, suppression à l’échéance ou refus fondé sur un motif juridique documenté.
Clarysec recommande une approche à trois niveaux :
- Journaux opérationnels à faible impact sur la protection des données, tels que les journaux d’événements système utilisant des identifiants utilisateur pseudonymes, qui peuvent être recherchés et divulgués lorsque cela est approprié.
- Journaux de sécurité à forte sensibilité, tels que les données de corrélation SIEM ou le contexte de renseignement sur les menaces, qui peuvent exiger un filtrage, une divulgation synthétique ou une limitation afin d’éviter d’exposer la logique de détection ou des données de tiers.
- Éléments probants forensiques sous gel de conservation lié à un incident actif ou conservation pour litige, qui ne doivent pas être modifiés de manière informelle. L’effacement peut être différé ou limité lorsqu’il est juridiquement justifié, la décision étant documentée par les parties prenantes protection des données et juridiques.
Si le DPO et le SOC débattent chaque DSAR depuis zéro, l’organisation sera incohérente et lente. Si REG02 et REG12 sont tenus à jour, la gestion des droits devient fondée sur des éléments probants.
Notification des violations et des incidents : un événement, plusieurs horloges
L’alerte de 02:17 peut déclencher plusieurs horloges. L’évaluation d’une violation de données à caractère personnel au titre du GDPR peut exiger une notification à l’autorité de contrôle lorsque les seuils de risque sont atteints. La notification d’un incident significatif au titre de NIS2 peut exiger une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final. DORA peut exiger la notification d’un incident majeur lié aux TIC selon des étapes initiale, intermédiaire et finale. Les contrats clients peuvent prévoir des délais encore plus courts.
La PII Incident and Breach Management Policy de Clarysec traite directement ce problème de déclencheurs croisés. Dans Classification et évaluation d’une violation de données à caractère personnel, clause 4.2.6 :
[Conditional] Le responsable protection des données / responsable du PIMS DOIT évaluer les déclencheurs de reporting légaux, sectoriels, propres au secteur financier, de cybersécurité, contractuels, clients et destinataires de services applicables à chaque incident à fort impact relatif aux données à caractère personnel, et consigner le résultat d’applicabilité dans REG01, REG08 et REG10.
Pendant le triage, l’organisation doit se demander :
- L’attaquant a-t-il accédé à des données à caractère personnel, ou seulement à des métadonnées ?
- Les journaux ont-ils exposé des données à caractère personnel supplémentaires à des utilisateurs non autorisés ?
- Les journaux sont-ils nécessaires pour déterminer les personnes, systèmes et périodes concernés ?
- Les journaux sont-ils stockés de manière immuable et soumis à des restrictions d’accès ?
- Un gel de conservation lié à un incident a-t-il suspendu la suppression des journaux pertinents ?
- Des clients responsables du traitement, des clients du secteur financier ou des destinataires de services sont-ils affectés ?
- Quelles horloges de notification s’appliquent, et qui est responsable de chaque notification ?
Des journaux bien gouvernés accélèrent le reporting parce qu’ils fournissent aux décideurs des faits fiables. Une journalisation insuffisante crée des retards. Une journalisation excessive crée un risque pour la protection des données. La bonne réponse est une journalisation ciblée, protégée et cartographiée.
Journalisation fournisseurs et cloud : le problème de sous-traitance caché dans votre SIEM
La plupart des organisations ne stockent pas tous les journaux sur une infrastructure entièrement maîtrisée. Les journaux alimentent des plateformes SIEM, portails EDR, services cloud natifs de journalisation, outils d’observabilité, systèmes de gestion des tickets et prestataires de détection et réponse managées. Au titre du GDPR, ces prestataires peuvent être des sous-traitants ou sous-traitants ultérieurs. Au titre de NIS2 et de DORA, ils peuvent aussi être des fournisseurs directs, prestataires tiers de services TIC, prestataires de services managés ou fournisseurs de services de sécurité managés.
NIS2 Article 21 inclut explicitement la sécurité de la chaîne d’approvisionnement, les vulnérabilités des fournisseurs et les pratiques globales de cybersécurité des fournisseurs. DORA ajoute des exigences détaillées de gestion des risques liés aux prestataires tiers de services TIC pour les entités financières : diligences précontractuelles, registres d’informations, droits d’audit et d’accès, assistance en cas d’incident, localisation des données, clauses de protection des données, stratégies de sortie et clauses contractuelles relatives aux fonctions critiques ou importantes.
Pour les données à caractère personnel dans les journaux de sécurité, les revues fournisseurs doivent inclure les questions suivantes :
| Question fournisseur | Pourquoi c’est important |
|---|---|
| Quels champs de données à caractère personnel sont ingérés, indexés, enrichis ou affichés ? | Détermine le périmètre GDPR, la minimisation et les exigences de transparence. |
| Où les journaux sont-ils stockés, répliqués et sauvegardés ? | Soutient l’analyse des transferts, la localisation des données, la conservation et la suppression. |
| Qui peut accéder aux données de journal client chez le fournisseur ? | Soutient le contrôle d’accès, la gouvernance du sous-traitant et les droits d’audit DORA. |
| Le fournisseur peut-il prendre en charge le stockage immuable et la conservation pour litige ? | Soutient la préservation des éléments probants et les investigations d’incident. |
| Le fournisseur peut-il supprimer ou restituer les journaux en fin de contrat ? | Soutient la limitation de la conservation au titre du GDPR et la planification de sortie DORA. |
| Les journaux d’accès du fournisseur sont-ils disponibles pour le client ? | Soutient la responsabilité ISO 27701 et les attentes de journalisation des accès aux données à caractère personnel dans le cloud. |
| Comment le fournisseur assiste-t-il en cas d’incident et de reporting réglementaire ? | Soutient les délais NIS2 et DORA. |
Un contrat SIEM n’est pas seulement un abonnement logiciel. C’est une dépendance de traitement de données à caractère personnel et d’éléments probants d’incident.
Point de vue audit : comment les évaluateurs testent les données à caractère personnel dans les journaux de sécurité
Un bon auditeur n’acceptera pas une simple affirmation selon laquelle « les journaux sont protégés ». Il testera la chaîne allant de la politique à la configuration, puis aux éléments probants et à la revue.
| Profil de l’auditeur | Approche d’audit probable | Demande typique d’éléments probants |
|---|---|---|
| Auditeur de système de management ISO | Retracer la politique, le traitement des risques, l’inclusion dans la SoA, la maîtrise opérationnelle et l’amélioration continue. | Politique de journalisation, inventaire des données à caractère personnel, périmètre REG12, calendrier de conservation, captures d’écran SIEM, enregistrements de revue d’accès, constats d’audit interne. |
| Auditeur ISO 27701 protection des données | Tester la cartographie des rôles PIMS, les registres de traitements de données à caractère personnel, la gestion des droits, les obligations des sous-traitants et les éléments probants d’incident relatif aux données à caractère personnel. | Entrées REG02 relatives aux journaux, base légale, cartographie responsable du traitement ou sous-traitant, enregistrements d’évaluation DSAR, évaluations de violation de données à caractère personnel. |
| Évaluateur NIST | Tester la couverture des événements d’audit, la revue des journaux, l’exactitude des horodatages, la protection des enregistrements d’audit et l’articulation avec la réponse aux incidents. | Configuration d’audit, tickets d’alerte, tests de protection AU-9, récupération historique des journaux, autorisations d’accès. |
| Auditeur COBIT 2019 | Évaluer la gouvernance, la surveillance, le reporting de conformité et la responsabilité de la direction. | Comptes rendus de revue de direction, rapports KPI, journaux d’actions, tableaux de bord de performance des contrôles, suivi de la remédiation. |
| Auditeur ISACA ITAF | Valider l’exhaustivité, la continuité, la fiabilité des éléments probants et les tests des contrôles. | Journaux de chaîne de conservation, exports immuables, analyse des écarts, exemples de journaux d’incident et actions de suivi. |
| Auditeur axé sur DORA | Évaluer le processus d’incident TIC, la couverture des fonctions critiques, les risques liés aux tiers et les tests de résilience. | Registre des incidents TIC, rapports d’analyse de la cause racine, contrats fournisseurs, résultats de tests, éléments probants du workflow de reporting. |
| Relecteur axé sur NIS2 | Évaluer les mesures de gestion des risques, la gestion des incidents, la continuité et la préparation à la notification des incidents significatifs. | Critères de classification des incidents, playbooks d’escalade, workflow de reporting à 24 heures et 72 heures, obligations de journalisation des fournisseurs. |
Un test d’audit pratique est simple mais révélateur : demander au SOC de récupérer une entrée de journal vieille de dix mois montrant un changement d’accès à privilèges dans une plateforme cloud, de prouver qui a accédé à ce journal, de prouver qu’il n’a pas été altéré, de présenter la règle de conservation qui autorisait son existence, de montrer les champs de données à caractère personnel qu’il contient et d’expliquer comment il serait traité dans une DSAR ou un rapport d’incident. Si l’équipe ne peut pas répondre sur les volets sécurité, protection des données et conformité, la gouvernance est incomplète.
Constats fréquents dans les audits de journaux contenant des données à caractère personnel
Clarysec observe souvent les mêmes schémas :
- Les équipes applicatives journalisent des charges utiles de requêtes complètes à des fins de débogage, y compris des noms, adresses électroniques, numéros de compte ou contenus de message.
- Les index SIEM sont ouverts à de larges groupes d’administrateurs informatiques au lieu d’être limités aux rôles SOC.
- La conservation des journaux est définie globalement sans tenir compte de la sensibilité des données à caractère personnel, des contrats clients ou des règles de gel de conservation lié à un incident.
- Les journaux de fournisseurs cloud sont activés, mais l’accès des administrateurs du fournisseur aux données de journal client n’est pas revu.
- Les procédures DSAR ne mentionnent pas les journaux, les dossiers SIEM ni les exports forensiques.
- Les playbooks de réponse aux incidents préservent les éléments probants, mais les équipes protection des données ne participent pas à la classification.
- Les sauvegardes et archives conservent les données à caractère personnel des journaux plus longtemps que le SIEM.
- Les développeurs peuvent modifier les niveaux de journalisation en production sans revue de protection des données ni revue de sécurité.
- Les environnements de test reçoivent des journaux de production contenant des données à caractère personnel.
- L’organisation a des obligations de reporting NIS2 ou DORA, mais ne peut pas récupérer rapidement des éléments probants fiables.
Ces constats résultent rarement d’une mauvaise intention. Ils découlent d’une propriété cloisonnée. Les journaux de sécurité se situent entre le SOC, l’ingénierie de plateforme, la protection des données, le service juridique, la conformité, l’audit et les fournisseurs. Si personne ne possède l’ensemble du cycle de vie, des lacunes apparaissent.
Checklist Clarysec pour une gouvernance des journaux prête pour l’audit
Utilisez cette checklist comme point de départ opérationnel pour votre prochaine revue de gouvernance :
- Définir quelles sources de journaux peuvent contenir des données à caractère personnel : IAM, application, passerelle API, SIEM, EDR, cloud, base de données, réseau, accès physique et gestion des tickets.
- Enregistrer chaque référentiel de journaux dans REG02, y compris les magasins actifs, archives, sauvegardes, réplicas et exports forensiques temporaires.
- Définir le périmètre de journalisation des données à caractère personnel dans REG12 avant toute utilisation en production ou modification substantielle.
- Identifier la finalité et la base légale du traitement des journaux de sécurité.
- Interdire les mots de passe, secrets, jetons complets et charges utiles inutiles dans les journaux.
- Utiliser le masquage, le hachage cryptographique ou la pseudonymisation lorsque les identifiants complets ne sont pas nécessaires.
- Restreindre l’accès aux journaux contenant des données à caractère personnel par rôle, avec revue des accès à privilèges.
- Stocker les journaux à forte valeur dans des formats immuables ou protégés en écriture.
- Définir la conservation par type de journal, obligation légale, contrat, besoin lié à l’incident et risque relatif à la protection des données.
- Mettre en œuvre des gels de conservation liés à un incident avec approbation, périmètre et échéance.
- Inclure les journaux dans la logique d’évaluation des DSAR et des demandes d’effacement.
- Revoir les fournisseurs SIEM, EDR, cloud et MDR comme sous-traitants ou tiers TIC.
- Tester la récupération historique et l’intégrité des éléments probants.
- Cartographier la journalisation avec les besoins de reporting GDPR, ISO 27701, NIS2, DORA, NIST CSF et COBIT.
- Former les équipes SOC, protection des données et applicatives à ce qui peut ou ne peut pas être journalisé.
Cette checklist transforme la journalisation respectueuse de la protection des données en un processus de contrôle répétable.
Du dilemme à la confiance au niveau de l’organe de direction
NIS2 fait de la cybersécurité une responsabilité de direction. DORA rend l’organe de direction responsable de la gestion des risques liés aux TIC, de la stratégie de résilience opérationnelle numérique, de la confidentialité des données, de la communication relative aux incidents et des politiques relatives aux prestataires tiers de services TIC. ISO/IEC 27001:2022 impose à la direction d’aligner le SMSI avec les objectifs métier, d’attribuer les responsabilités, de fournir les ressources et de piloter l’amélioration continue.
Les données à caractère personnel dans les journaux de sécurité ne sont donc pas un détail technique. C’est un enjeu de confiance au niveau de l’organe de direction. La capacité de l’organisation à détecter les incidents, protéger les données à caractère personnel, préserver les éléments probants, répondre aux clients, satisfaire les régulateurs et rétablir les opérations dépend de décisions de journalisation prises bien avant l’incident.
Les meilleurs programmes de gouvernance ne choisissent pas entre protection des données et sécurité. Ils définissent la journalisation minimale nécessaire à une sécurité robuste, protègent cette journalisation comme des données à caractère personnel sensibles lorsque nécessaire, et la relient à la conservation, aux éléments probants, à la gestion des droits et aux obligations des fournisseurs.
Prochaines étapes avec Clarysec
Si vos journaux SIEM, IAM, EDR ou cloud contiennent des données à caractère personnel, le moment est venu de les gouverner délibérément.
Clarysec peut vous aider à :
- Construire un périmètre de journalisation des données à caractère personnel avec REG12 et l’aligner avec la PII Security and Access Control Policy.
- Inventorier les référentiels de journaux, archives, sauvegardes et exports forensiques avec REG02 et la PII Retention, Deletion and Disposal Policy.
- Aligner les contrôles de journalisation, de surveillance, de preuve et de protection des données avec Zenith Blueprint.
- Cartographier vos contrôles au regard de GDPR, ISO 27701, NIS2, DORA, NIST CSF et COBIT avec Zenith Controls.
- Préparer des éléments probants exploitables en audit pour les revues d’assurance ISO, protection des données, NIST, COBIT, NIS2 et DORA.
Commencez par un système à haut risque : votre plateforme IAM, votre SIEM ou votre application orientée client. Identifiez quelles données à caractère personnel entrent dans les journaux, pourquoi elles sont nécessaires, qui peut y accéder, combien de temps elles sont conservées et comment elles seraient utilisées pendant un incident ou une demande d’exercice des droits. Ce seul exercice révélera si votre programme de journalisation actuel est simplement opérationnel, ou réellement prêt pour l’audit.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
