Appréciation des risques pour la vie privée pour ISO 27701 et GDPR

La réunion du lundi matin avait un air familier pour Maria, RSSI d’une entreprise de health-tech en forte croissance.
Le directeur général voulait un tableau de bord simple présentant l’exposition au risque GDPR avant le lancement de la plateforme d’analyse patient fondée sur l’IA. David, le nouveau responsable de la protection des données, disposait d’un registre des activités de traitement, ou RoPA, composé de 50 onglets. L’ingénierie avait sécurisé l’environnement cloud. L’équipe produit était prête à publier. Le fournisseur décrivait sa chaîne de sous-traitants ultérieurs comme « enterprise grade ».
Mais une question a interrompu la réunion.
« Quel est notre risque réel, et pouvons-nous prouver à nos clients grands comptes qu’il est maîtrisé ? »
Le RoPA montrait ce que l’entreprise traitait. Le registre des risques de sécurité montrait les risques d’infrastructure. Quelques AIPD étaient conservées dans des documents séparés. Les revues fournisseurs étaient rangées dans des dossiers Achats. Personne ne pouvait présenter une chaîne de décision traçable allant de l’activité de traitement au risque pour la vie privée, à la décision d’AIPD, au plan de traitement des risques, à la cartographie des contrôles, à l’approbation du risque résiduel et à la date de revue.
C’est l’écart auquel de nombreuses organisations sont confrontées lorsqu’elles progressent vers ISO/IEC 27701:2025 et la responsabilité au titre du GDPR. Elles disposent de mentions d’information, de questionnaires fournisseurs, d’entrées RoPA, de cartographies de données, de modèles d’AIPD et de contrôles ISO/IEC 27001:2022. Ce qui leur manque souvent, c’est la couche opérationnelle qui relie ces éléments.
Un système de management des informations relatives à la vie privée mature, ou PIMS, ne traite pas l’appréciation des risques pour la vie privée comme un document juridique parallèle. Il la traite comme un processus décisionnel reproductible : identifier le traitement, effectuer l’examen préalable du risque, décider si une AIPD est requise, sélectionner les contrôles, attribuer des responsables, approuver le risque résiduel, surveiller les déclencheurs et conserver les éléments probants.
C’est là que les packs de politiques Clarysec, Zenith Blueprint et Zenith Controls aident les équipes à passer de feuilles de calcul dispersées à un dispositif défendable de gestion des risques pour la vie privée.
L’appréciation des risques pour la vie privée est la couche opérationnelle manquante
La responsabilité au titre du GDPR est souvent réduite au fait de « disposer d’une documentation ». La documentation compte, mais l’Article 5(2) va plus loin. Le responsable du traitement est responsable du respect des principes de l’Article 5(1), notamment la licéité, la loyauté, la transparence, la limitation des finalités, la minimisation des données, l’exactitude, la limitation de la conservation, l’intégrité et la confidentialité, et doit être en mesure de le démontrer.
Cela exige davantage qu’un RoPA. L’organisation doit être capable d’expliquer pourquoi une activité de traitement est acceptable, quels risques elle crée pour les personnes, quels contrôles réduisent ces risques, qui est responsable de la décision et quand celle-ci doit être revue.
ISO/IEC 27701:2025 renforce cette exigence en intégrant la gouvernance de la protection des données dans un PIMS piloté. En pratique, l’appréciation des risques pour la vie privée doit relier six objets opérationnels :
- L’inventaire des traitements de données à caractère personnel ou RoPA.
- La documentation relative à la base juridique et aux finalités.
- L’examen préalable des risques pour la vie privée et la décision d’AIPD.
- Le traitement des risques et la sélection des contrôles.
- La gouvernance des fournisseurs, sous-traitants et sous-traitants ultérieurs.
- Les éléments probants conservés dans le SMSI et le PIMS.
Clarysec rend ce lien explicite. Dans la politique pour grandes organisations Privacy Risk Assessment and DPIA Policy, le déclencheur intervient avant le début du traitement :
[Responsable du traitement et sous-traitant] Le responsable de processus / propriétaire métier DOIT initier l’examen préalable des risques pour la vie privée dans REG04 avant le démarrage de tout traitement de données à caractère personnel nouveau ou faisant l’objet d’une modification substantielle enregistré dans REG02.
La même discipline amont apparaît dans la politique pour grandes organisations PII Processing Inventory and Lawful Basis Policy :
[Responsable du traitement et sous-traitant] Le responsable de processus / propriétaire métier DOIT initier l’examen préalable des risques pour la vie privée et de l’AIPD dans REG04 avant qu’un traitement de données à caractère personnel nouveau ou faisant l’objet d’une modification substantielle ne se poursuive.
Cela évite un schéma de défaillance courant : le produit est lancé, le RoPA est mis à jour ultérieurement, la question de l’AIPD arrive trop tard et le registre des risques ne reçoit jamais le scénario relatif à la vie privée.
Pour les responsables du traitement, cela soutient la discipline de la base juridique au titre de l’Article 6 du GDPR, la protection des données dès la conception et par défaut de l’Article 25, la sécurité du traitement de l’Article 32 et la responsabilité prévue à l’Article 5. Pour les sous-traitants, cela soutient les instructions documentées, les programmes d’assurance demandés par les clients, les limites contractuelles et la transparence des sous-traitants ultérieurs.
Commencer par la réalité du traitement, pas par un modèle vide
Une appréciation des risques pour la vie privée échoue lorsqu’elle commence par un formulaire vide et sans contexte opérationnel. La première question ne devrait pas être « Avons-nous besoin d’une AIPD ? ». Elle devrait être « Quel traitement change réellement ? »
Pour une organisation SaaS, fintech ou health-tech, le changement peut concerner :
- Une nouvelle catégorie de données, par exemple des données comportementales d’usage, des données de santé, des signaux biométriques ou des métadonnées de paiement.
- Une nouvelle finalité, par exemple la notation de fraude, l’analyse patient, l’assistance appuyée par l’IA, la prédiction de désabonnement ou la personnalisation.
- Un nouveau destinataire, sous-traitant ou sous-traitant ultérieur.
- Un nouveau processus de support ou un nouveau circuit d’accès transfrontalier.
- Une nouvelle durée de conservation.
- Un nouveau modèle, algorithme ou mécanisme de recommandation automatisée.
- Un nouveau groupe de personnes concernées, par exemple des mineurs, des employés, des patients ou des personnes financièrement vulnérables.
Les définitions du GDPR sont larges. Les données à caractère personnel incluent les identifiants, les identifiants en ligne, les données de localisation et les facteurs liés à l’identité. Le traitement inclut la collecte, le stockage, l’extraction, l’utilisation, la divulgation, la limitation, l’effacement et la destruction. Une violation de données à caractère personnel inclut la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé, de manière accidentelle ou illicite.
Cela signifie qu’un processus de gestion des risques pour la vie privée doit capturer davantage que le fait que la base de données soit chiffrée ou non. Il doit capturer la raison d’être du traitement, la compatibilité de la finalité, la validité de la base juridique, l’éventuelle implication de données de catégories particulières, la capacité des personnes à comprendre le traitement et la proportionnalité des garanties.
Pour les petites équipes, la politique PME Data Protection and Privacy Policy fournit le point de départ à la clause 5.2.1 :
Le coordinateur de la protection des données doit tenir un registre de toutes les activités de traitement de données à caractère personnel, comprenant les catégories de données, la finalité, la base juridique et les durées de conservation.
Ce registre n’est pas de la paperasse. C’est le modèle d’entrée de l’appréciation des risques pour la vie privée. Sans catégories de données, finalité, base juridique et durées de conservation, l’appréciation ne peut pas évaluer de manière fiable la limitation des finalités, la minimisation des données, la limitation de la conservation, la transparence ou la loyauté.
La même politique PME fait également de la revue des risques une obligation récurrente à la clause 7.1.1 :
Le coordinateur de la protection des données doit apprécier les risques pour la vie privée chaque année et lors de changements majeurs des systèmes.
Pour les grandes organisations, la cadence de gouvernance est plus soutenue. La politique pour grandes organisations Data Protection and Privacy Policy indique :
Les registres des risques pour la vie privée doivent être tenus dans le SMSI et revus au moins une fois par trimestre par le délégué à la protection des données (DPO) et le RSSI.
C’est là que l’intégration d’ISO/IEC 27701:2025 et d’ISO/IEC 27001:2022 devient opérationnelle. Les risques pour la vie privée ne sont pas enfouis dans des dossiers juridiques. Ils sont revus avec les risques de sécurité, les risques fournisseurs, les incidents, les constats d’audit, les plans de traitement des risques et le reporting de gestion.
Le processus Clarysec de REG02 à REG04
Le processus d’appréciation des risques pour la vie privée le plus efficace est suffisamment simple pour les responsables métier et suffisamment rigoureux pour les auditeurs. Le modèle Clarysec utilise REG02 comme inventaire des traitements de données à caractère personnel et REG04 comme enregistrement de l’appréciation des risques pour la vie privée et de l’AIPD.
| Point du processus | Question pratique | Élément probant créé | Responsable |
|---|---|---|---|
| Entrée de traitement REG02 | Quelles données à caractère personnel sont traitées, pour quelle finalité, par qui et sur quelle base juridique ? | Enregistrement de l’inventaire des traitements, base juridique, catégories de données, durée de conservation | Responsable de processus |
| Examen préalable REG04 | L’activité crée-t-elle un risque élevé pour les personnes ou déclenche-t-elle des critères d’AIPD ? | Décision d’examen préalable relatif à la vie privée, justification, date de revue | Responsable de la protection des données ou responsable du PIMS |
| Décision d’AIPD | Une AIPD complète est-elle requise avant le démarrage ou la modification du traitement ? | Enregistrement d’AIPD ou justification documentée de non-réalisation d’une AIPD | DPO ou responsable de la protection des données |
| Traitement des risques | Quels contrôles réduisent le risque à un niveau acceptable ? | Plan de traitement des risques, cartographie des contrôles, dates d’échéance | Propriétaire du risque |
| Approbation du risque résiduel | Qui accepte le risque élevé restant, et sous quelles conditions ? | Enregistrement d’approbation, justification de l’acceptation | Direction générale lorsque requis |
| Déclencheur de revue | Quels changements rouvrent l’appréciation ? | Date de revue, déclencheurs de changement, éléments probants de surveillance | Responsable de processus et responsable de la protection des données |
La Privacy Risk Assessment and DPIA Policy définit les éléments probants minimaux nécessaires avant la clôture de REG04 :
[Responsable du traitement et sous-traitant] Le responsable de la protection des données / responsable du PIMS DOIT s’assurer que chaque appréciation REG04 enregistre la cotation du risque, la décision de traitement, le propriétaire, la date d’échéance, le risque résiduel, le statut d’approbation et la date de revue avant clôture.
Cette phrase est l’ossature opérationnelle. Une appréciation des risques pour la vie privée n’est pas clôturée parce qu’une personne a écrit « risque faible » dans un champ de commentaire. Elle est clôturée lorsque l’enregistrement comprend la cotation, la décision de traitement, le propriétaire, la date d’échéance, le risque résiduel, le statut d’approbation et la date de revue.
Pour les PME, la même discipline est adaptée. La politique PME Risk Management Policy indique :
Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques.
Le principe est celui de la proportionnalité, non de l’informalité. Les petites organisations peuvent utiliser un registre plus simple, mais chaque risque doit toujours disposer d’une description, d’un score, d’un propriétaire et d’un plan de traitement des risques.
Utiliser le moteur de gestion des risques ISO/IEC 27001:2022 pour la vie privée
Les risques pour la vie privée ne doivent pas vivre en dehors de la méthode de gestion des risques de l’organisation. ISO/IEC 27001:2022 fournit déjà le moteur du système de management : contexte, parties intéressées, domaine d’application, leadership, appréciation des risques, traitement, maîtrise opérationnelle, informations documentées, évaluation des performances et amélioration continue.
Les clauses 4.1 à 4.4 exigent que l’organisation comprenne les enjeux internes et externes, les exigences des parties intéressées, le domaine d’application du SMSI et les processus du SMSI. Pour la vie privée, les parties intéressées incluent les clients, les personnes concernées, les employés, les régulateurs, les sous-traitants, les sous-traitants ultérieurs, les autorités de contrôle, les superviseurs du secteur financier le cas échéant et les clients contractuels.
La clause 6.1.2 exige un processus d’appréciation des risques de sécurité de l’information. La clause 6.1.3 exige le traitement des risques de sécurité de l’information, notamment la sélection des contrôles, la production d’une Déclaration d’applicabilité, la formulation d’un plan de traitement des risques et l’obtention de l’approbation du propriétaire du risque pour le plan et les risques résiduels. Les clauses 8.2 et 8.3 exigent la réalisation d’appréciations et de traitements des risques de sécurité de l’information à intervalles planifiés ou lorsque des changements significatifs surviennent, tout en conservant les résultats documentés.
La politique pour grandes organisations Risk Management Policy de Clarysec s’aligne sur cette structure à la clause 5.1 :
Un processus formel de gestion des risques doit être maintenu conformément à ISO/IEC 27005 et ISO 31000, couvrant l’identification des risques, l’analyse, l’évaluation, le traitement, la surveillance et la communication.
Pour la vie privée, les critères de risque doivent inclure l’impact pour les personnes, et pas seulement l’impact métier. Une faible perte financière peut tout de même correspondre à un impact élevé sur la vie privée si le traitement implique des données de catégories particulières, des personnes vulnérables, du profilage, une opacité, une conservation illicite, une impossibilité d’exercer des droits ou un préjudice immatériel.
Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec l’explique dans la phase Gestion des risques, étape 10 :
Lors de la définition de l’impact, il est judicieux de relier les niveaux à l’échelle propre de votre activité. Par exemple, « Impact financier majeur = perte > 100 k$ » (à adapter à votre contexte). Tenez également compte de l’impact réglementaire : par exemple, une violation de données à caractère personnel peut automatiquement être « Majeure » ou « Sévère » en raison des amendes GDPR et des exigences de notification, même si la perte financière directe n’est pas claire.
Cette recommandation est particulièrement importante pour l’analyse par IA, les données de santé, le profilage financier, la surveillance des employés et la notation des clients. Le préjudice peut être juridique, réputationnel, discriminatoire, opérationnel, contractuel ou personnel.
Exemple pratique : analyse patient par IA
Revenons à Maria et David. Leur plateforme de health-tech traitera des données de santé relevant de catégories particulières au titre de l’Article 9 du GDPR. Elle utilisera l’historique patient, les données de rendez-vous, les notes des cliniciens et les sorties de modèles pour générer des informations de risque.
Avec Zenith Blueprint, ils commencent par l’étape 9, qui consiste à identifier les actifs, les menaces et les vulnérabilités :
Pour chaque actif, consignez les informations clés : Nom/description, propriétaire, emplacement et classification (sensibilité). Par exemple, un actif pourrait être « Base de données clients – détenue par le service informatique – hébergée sur AWS – contient des données à caractère personnel et financières (sensibilité élevée) ».
La même étape ajoute l’angle vie privée :
Veillez à signaler les actifs contenant des données à caractère personnel (pour leur pertinence au regard du GDPR) et à noter les actifs de services critiques (pour une éventuelle applicabilité de NIS2 si vous opérez dans un secteur réglementé).
L’équipe de Maria identifie la plateforme d’analyse patient par IA, la base de données patients, l’entrepôt de données, le pipeline d’entraînement des modèles, le tableau de bord des cliniciens, le stockage cloud, le fournisseur d’identité, les journaux d’audit, la plateforme de tickets de support et l’outil d’analyse tiers. Chaque actif reçoit un propriétaire, un emplacement, une classification et une relation avec les données à caractère personnel.
Ils définissent ensuite les scénarios de risque. L’un porte sur l’accès non autorisé aux dossiers de santé. Un autre concerne la divulgation accidentelle par export d’analyses. Un troisième porte sur un biais du modèle d’IA causé par des données d’entraînement déséquilibrées, entraînant une notation du risque patient inéquitable ou discriminatoire.
L’étape 11 de Zenith Blueprint explique le rôle du registre des risques :
Le registre des risques est généralement une feuille de calcul (notre modèle “Risk Register and SoA Builder.xlsx” comporte un onglet dédié à cet usage). Il sert de journal maître des risques.
Une entrée de risque pour la vie privée pour le scénario de biais du modèle d’IA peut se présenter ainsi :
| Champ | Entrée | Référence Clarysec |
|---|---|---|
| Identifiant du risque | PRV-004 | Zenith Blueprint, étape 11 |
| Actif | Plateforme d’analyse patient par IA | Zenith Blueprint, étape 9 |
| Menace | Biais du modèle d’IA provenant de données d’entraînement déséquilibrées | Zenith Blueprint, étape 9 |
| Vulnérabilité | Absence de validation formelle du modèle et de tests d’équité | Zenith Blueprint, étape 9 |
| Description du risque | Le modèle pourrait produire des scores de risque patient discriminatoires, conduisant à un traitement inéquitable et à une atteinte aux droits des personnes concernées | Risk Management Policy PME, clause 5.1.2 |
| Vraisemblance | Probable, 4 sur 5 | Zenith Blueprint, étape 10 |
| Impact | Majeur, 4 sur 5, en raison des données de catégories particulières et du préjudice potentiel pour les personnes | Zenith Blueprint, étape 10 |
| Score de risque | 16, élevé | Zenith Blueprint, étape 10 |
| Propriétaire du risque | Responsable Data Science | Zenith Blueprint, étape 11 |
| Plan de traitement des risques | Mettre en œuvre la validation du modèle, les tests d’équité, un réentraînement représentatif, une revue d’explicabilité, une revue par le DPO et l’achèvement de l’AIPD | Risk Management Policy PME, clause 5.1.2 |
Cette entrée réalise ce que l’ancienne feuille de calcul ne permettait pas. Elle relie une activité de traitement à un actif, une menace, une vulnérabilité, un risque pour les personnes, un propriétaire, un score, un plan de traitement des risques et une piste d’éléments probants.
Comme le traitement est à haut risque et implique des données de catégories particulières, l’AIPD n’est pas une réflexion ultérieure séparée. Elle devient l’étape d’analyse approfondie pour un risque déjà consigné dans le système. La politique pour grandes organisations Data Protection and Privacy Policy indique :
Toute modification significative des systèmes ou processus impliquant des informations à caractère personnel (PII) doit faire l’objet d’une analyse d’impact relative à la protection des données (DPIA) documentée, revue par le délégué à la protection des données (DPO).
Pour les risques résiduels élevés du responsable du traitement, la Privacy Risk Assessment and DPIA Policy ajoute :
[Responsable du traitement] La direction générale DOIT approuver l’acceptation d’un risque résiduel élevé pour la vie privée dans REG04 avant le début ou la poursuite d’un traitement à haut risque par le responsable du traitement.
La décision de lancement devient alors traçable : ce qui a changé, ce qui a été apprécié, les risques identifiés, les contrôles sélectionnés, le propriétaire du traitement, la personne ayant approuvé le risque résiduel et la date de revue de la décision.
Passer des risques aux contrôles avec Zenith Controls
L’appréciation des risques pour la vie privée n’a de valeur que si elle aboutit à des décisions de contrôle. Zenith Controls: The Cross-Compliance Guide de Clarysec est le guide de cartographie croisée de conformité qui relie les contrôles ISO/IEC 27001:2022 et ISO/IEC 27002:2022 aux exigences connexes de plusieurs référentiels. Il ne s’agit pas d’un ensemble de contrôles distinct. Il aide les équipes à comprendre comment les éléments probants de contrôle soutiennent plusieurs obligations.
Pour l’appréciation des risques pour la vie privée, Zenith Controls met en avant trois contrôles centraux d’ISO/IEC 27002:2022 :
| Contrôle ISO/IEC 27002:2022 | Pourquoi il est important pour l’appréciation des risques pour la vie privée | Exemple d’éléments probants |
|---|---|---|
| 5.34 Protection de la vie privée et des données à caractère personnel | Ancre la gouvernance de la protection des données, les exigences légales, la protection des personnes concernées et les garanties | Procédures PIMS, enregistrements d’AIPD, règles de traitement des données à caractère personnel, mentions d’information |
| 5.9 Inventaire des informations et autres actifs associés | Garantit que l’organisation connaît les actifs informationnels existants, leurs propriétaires, leur emplacement et leur niveau de sensibilité | Inventaire des actifs, références RoPA, enregistrements de classification |
| 5.19 Sécurité de l’information dans les relations avec les fournisseurs | Étend le risque pour la vie privée aux sous-traitants, sous-traitants ultérieurs, plateformes cloud, fournisseurs d’analyse et prestataires de support | Évaluations des fournisseurs, contrats, enregistrements de surveillance, plans de sortie |
Le contrôle 5.34 soutient également l’Article 25 et l’Article 32 du GDPR, les mesures de gestion des risques de cybersécurité prévues à l’Article 21 de NIS2, les attentes de DORA en matière de gestion des risques liés aux TIC et les résultats NIST CSF 2.0 tels que GV.OC-03 pour les obligations légales, réglementaires, contractuelles, relatives à la vie privée et aux libertés civiles, ainsi que PR.DS-01 pour la protection des données au repos.
L’étape 13 de Zenith Blueprint relie ces décisions à la Déclaration d’applicabilité :
Faites des références croisées avec les réglementations : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez l’indiquer soit dans le registre des risques (dans la justification de l’impact du risque), soit dans les notes de la SoA.
C’est ainsi qu’un constat relatif à la vie privée devient une décision de contrôle SMSI et PIMS, et pas seulement un commentaire juridique.
Le risque fournisseur et sous-traitant doit être apprécié avant approbation
De nombreuses défaillances de protection des données commencent dans la gouvernance des fournisseurs. Un sous-traitant ajoute un nouveau sous-traitant ultérieur. Un fournisseur de support obtient un accès à l’environnement de production. Une plateforme d’analyse stocke des données d’événement dans une nouvelle région. Les Achats signent le contrat avant que la fonction Protection des données n’ait examiné le risque.
La politique pour grandes organisations Processor, Subprocessor and Third-Party Privacy Management Policy de Clarysec évite cela en reliant la revue fournisseur, REG04 et le registre des tiers :
[Responsable du traitement et sous-traitant] Le responsable de la protection des données / responsable du PIMS DOIT déclencher l’examen préalable des risques pour la vie privée et de l’AIPD dans REG04 pour les relations de sous-traitance à haut risque et les modifications substantielles d’une relation avec un tiers en matière de protection des données avant approbation, avec la référence REG04 enregistrée dans REG08.
Pour les PME, la Third-Party and Supplier Security Policy établit l’exigence de revue préalable à l’engagement :
Avant tout engagement, chaque fournisseur doit faire l’objet d’une revue afin d’identifier les risques potentiels. Cette revue doit inclure :
Le message opérationnel est clair. Le risque fournisseur est apprécié avant approbation, et non après signature.
Cela soutient également NIS2 et DORA. L’Article 21 de NIS2 exige la sécurité de la chaîne d’approvisionnement dans le cadre des mesures de gestion des risques de cybersécurité. Les Articles 28 à 30 de DORA exigent des entités financières qu’elles gèrent le risque lié aux tiers prestataires de services TIC, réalisent des évaluations précontractuelles, maintiennent des garanties contractuelles, comprennent le risque de sous-traitance, surveillent les dépendances et planifient les sorties pour les fonctions critiques ou importantes.
Si un fournisseur touche des données à caractère personnel ou soutient un traitement critique pour la vie privée, l’enregistrement de risque pour la vie privée doit montrer le fournisseur, le rôle de traitement, la localisation des données, la dépendance à un sous-traitant ultérieur, les garanties contractuelles, les engagements en matière d’incident, les règles de conservation, l’approche de surveillance et le plan de sortie.
Un processus, plusieurs résultats de conformité
L’intérêt d’un processus PIMS intégré est que les mêmes éléments probants soutiennent plusieurs référentiels sans dupliquer le travail.
| Domaine d’obligation | Ce que le processus de gestion des risques pour la vie privée doit montrer | Ancrage Clarysec |
|---|---|---|
| Responsabilité au titre du GDPR | Finalité du traitement, base juridique, catégories de données, risque pour les personnes, décision d’AIPD, contrôles, approbation du risque résiduel | REG02, REG04, Data Protection and Privacy Policy |
| PIMS ISO/IEC 27701:2025 | Gouvernance de la protection des données tenant compte des rôles dans les contextes de responsable du traitement, sous-traitant, responsable conjoint du traitement et sous-traitant ultérieur | Privacy Risk Assessment and DPIA Policy |
| SMSI ISO/IEC 27001:2022 | Critères de risque, appréciation des risques, plan de traitement des risques, Déclaration d’applicabilité, éléments probants conservés | Risk Management Policy, Risk Register and SoA Builder |
| NIS2 | Gestion des risques de cybersécurité, sécurité de la chaîne d’approvisionnement, gestion des incidents, responsabilité de la direction | Cartographies Zenith Controls vers 5.34, 5.9, 5.19 et contrôles associés de l’annexe A |
| DORA | Gestion des risques liés aux TIC, registre des tiers, cartographie des dépendances critiques, processus d’incident, planification de sortie | Processor, Subprocessor and Third-Party Privacy Management Policy |
| NIST CSF 2.0 | Profils actuel et cible, résultats de gouvernance, registre des risques ou POA&M, résultats relatifs au risque fournisseur | Étapes de gestion des risques de Zenith Blueprint |
| COBIT 19 et assurance ISACA | Propriété de gouvernance, conception des contrôles, surveillance de la performance, reporting de gestion, remédiation des problèmes | Revue trimestrielle et éléments probants d’audit interne de protection des données |
NIST CSF 2.0 est particulièrement utile pour la communication à destination de la direction. Sa fonction GOVERN couvre le contexte organisationnel, la stratégie de gestion des risques, la politique, les rôles, la supervision et le risque lié à la chaîne d’approvisionnement. Ses profils organisationnels aident à traduire les résultats actuels et cibles en plan d’action priorisé, par exemple un registre des risques ou un plan d’action et jalons.
Pour les organisations soumises à NIS2, DORA ou à des règles sectorielles, les éléments probants relatifs aux risques pour la vie privée soutiennent également la gouvernance de la cybersécurité, la supervision des fournisseurs, la préparation aux incidents et le reporting de résilience.
Le traitement des risques pour la vie privée va au-delà du chiffrement
Le chiffrement est important, mais il ne peut pas corriger une base juridique invalide, une collecte excessive, un profilage non divulgué, un traitement déloyal, une conservation illicite ou un sous-traitant agissant en dehors des instructions.
La politique PME Data Protection and Privacy Policy indique :
Des contrôles doivent être mis en œuvre pour réduire les risques identifiés, notamment le chiffrement, l’anonymisation, l’élimination sécurisée et les restrictions d’accès.
Ces exemples sont solides, mais le traitement doit être adapté au scénario. Un plan de traitement des risques pour la vie privée peut prévoir de restreindre la finalité du traitement, de supprimer les catégories de données inutiles, d’agréger ou de pseudonymiser les données, de mettre à jour les mentions d’information, de modifier la base juridique le cas échéant, de limiter la conservation, de restreindre les accès, d’ajouter de la journalisation, de mettre à jour les contrats, d’achever une AIPD, de reporter le lancement ou de refuser un traitement qui demeure inacceptable.
La politique pour grandes organisations Risk Management Policy renforce la planification du traitement pour les risques supérieurs au seuil de tolérance :
Tous les risques classés au-dessus du niveau de tolérance doivent disposer d’un plan de traitement des risques associé précisant :
En pratique, cela signifie qu’un risque élevé pour la vie privée ne peut pas être accepté par silence. Il doit être traité, transféré le cas échéant, évité ou formellement accepté par le bon responsable habilité.
Les déclencheurs de revue maintiennent l’appréciation à jour
Une appréciation des risques pour la vie privée qui n’est jamais réexaminée devient un élément probant obsolète. Les clauses 8.2 et 8.3 d’ISO/IEC 27001:2022 exigent l’appréciation et le traitement des risques à intervalles planifiés ou lorsque des changements significatifs surviennent. La responsabilité au titre du GDPR suppose des décisions à jour. ISO/IEC 27701:2025 repose sur la surveillance et l’amélioration continue.
Une appréciation REG04 doit être rouverte lorsque la finalité change, que de nouvelles catégories de données sont ajoutées, que des données de catégories particulières sont impliquées, que la base juridique change, qu’un sous-traitant ou sous-traitant ultérieur change, que le stockage est déplacé vers une nouvelle région, que les durées de conservation changent, que la logique de profilage change, qu’une violation ou un quasi-incident se produit, que les contrats clients changent ou qu’une nouvelle obligation NIS2, DORA ou sectorielle s’applique.
Les processus d’incident doivent alimenter en retour le processus de gestion des risques pour la vie privée. L’Article 23 de NIS2 établit une notification échelonnée des incidents significatifs. Les Articles 17 à 20 de DORA exigent l’enregistrement, la classification, l’escalade, la communication, l’analyse de la cause racine et l’amélioration des incidents liés aux TIC. Les obligations relatives aux violations de données à caractère personnel du GDPR peuvent également être déclenchées. Si un incident révèle des contrôles d’accès faibles, une conservation excessive, une notification fournisseur imprécise ou des instructions client insuffisantes, REG04 doit être mis à jour.
Ce que les auditeurs s’attendront à voir
Un processus robuste de gestion des risques pour la vie privée doit résister à plusieurs angles d’assurance.
| Angle d’audit | Demande probable d’éléments probants | À quoi ressemble une bonne pratique |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 | Domaine d’application du SMSI, méthode de risque, registre des risques, SoA, plans de traitement des risques, éléments probants opérationnels | Les risques pour la vie privée utilisent des critères approuvés, sont liés aux contrôles de l’annexe A, ont des propriétaires et sont revus après les changements |
| Auditeur PIMS ISO/IEC 27701:2025 | Inventaire des données à caractère personnel, contexte des rôles, examen préalable relatif à la vie privée, enregistrements d’AIPD, éléments probants du responsable du traitement et du sous-traitant | REG02 et REG04 montrent comment le traitement est examiné, coté, traité, approuvé et revu |
| Revue orientée GDPR | Base juridique, transparence, justification d’AIPD, contrats de sous-traitants, décisions de violation, impact sur les droits des personnes concernées | L’organisation peut démontrer un traitement licite, loyal, nécessaire, proportionné et maîtrisé |
| Évaluateur NIST CSF | Profils actuel et cible, résultats de gouvernance, registre des risques, résultats relatifs au risque fournisseur | Les risques pour la vie privée et les cyberrisques sont communiqués dans un langage de risque d’entreprise et au moyen de plans priorisés |
| Équipe d’assurance DORA | Cadre de gestion des risques liés aux TIC, registre des tiers, cartographie des fonctions critiques, processus d’incident, stratégies de sortie | Les dépendances TIC pertinentes pour la vie privée sont visibles, contractualisées, surveillées, testées et reliées à la résilience |
| Auditeur COBIT 19 ou ISACA | Propriété de gouvernance, conception des contrôles, reporting, remédiation des problèmes | Les décisions relatives aux risques pour la vie privée sont détenues par les métiers et les organes de direction, et non dissimulées dans des silos juridiques ou informatiques |
La politique pour grandes organisations Data Protection and Privacy Policy exige également une activité d’audit interne :
Un audit interne de conformité à la protection des données doit être réalisé chaque année ou lors de changements organisationnels ou réglementaires majeurs. Le périmètre de l’audit doit inclure :
Cela crée une boucle de retour pour la direction. Les enregistrements REG02 sont-ils complets ? Les examens préalables REG04 sont-ils réalisés dans les délais ? Les AIPD sont-elles effectuées lorsqu’elles sont requises ? Les risques résiduels élevés sont-ils approuvés ? Les changements fournisseurs sont-ils capturés ? Les plans de traitement des risques sont-ils clôturés ? Les mentions d’information sont-elles alignées sur le traitement réel ?
Liste de contrôle pour votre prochaine réunion sur un changement de traitement
Utilisez cette liste de contrôle avant la mise en production d’une nouvelle activité de traitement, fonctionnalité produit, fournisseur, modèle ou processus de support.
| Question | Si la réponse est oui, consignez ceci |
|---|---|
| S’agit-il d’un traitement de données à caractère personnel nouveau ou faisant l’objet d’une modification substantielle ? | Ouvrir ou mettre à jour REG02 et déclencher l’examen préalable REG04 |
| La finalité, la base juridique, la catégorie de données, la conservation ou le destinataire changent-ils ? | Mettre à jour l’inventaire des traitements et les éléments probants de la base juridique |
| Le traitement pourrait-il créer un risque élevé pour les personnes ? | Coter le risque inhérent pour la vie privée et documenter la justification |
| Du profilage, une surveillance à grande échelle, des données de catégories particulières ou des personnes vulnérables sont-ils concernés ? | Évaluer si une AIPD est requise |
| Un nouveau sous-traitant, sous-traitant ultérieur, service cloud ou fournisseur de support est-il impliqué ? | Déclencher la revue protection des données et sécurité du fournisseur |
| Des contrôles sont-ils requis avant le lancement ? | Créer un plan de traitement des risques avec propriétaire et date d’échéance |
| Le risque résiduel reste-t-il supérieur au seuil de tolérance ? | Escalader pour approbation avant le début ou la poursuite du traitement |
| Les mentions d’information, les contrats ou les instructions client vont-ils changer ? | Attribuer les mises à jour juridiques et orientées client |
| Qu’est-ce qui déclenchera une réappréciation ? | Définir la date de revue et les déclencheurs de changement dans REG04 |
Cette liste de contrôle ne remplace pas la politique. C’est un moyen pratique d’opérationnaliser la politique dans les réunions produit, achats, ingénierie, conformité, juridique et direction.
Transformer la responsabilité en matière de vie privée en système opérationnel
ISO/IEC 27701:2025 et la responsabilité au titre du GDPR exigent davantage que des documents. Elles exigent un système opérationnel reliant les enregistrements de traitement, la base juridique, les risques pour la vie privée, les décisions d’AIPD, les fournisseurs, les contrôles, les propriétaires, les approbations et les éléments probants.
Commencez par la phase Gestion des risques de Zenith Blueprint, en particulier les étapes 9 à 13. Utilisez le Risk Register and SoA Builder pour relier les actifs, les menaces, les vulnérabilités, les risques pour la vie privée, les décisions de traitement des risques et les références de contrôle. Utilisez ensuite Zenith Controls pour cartographier la protection des données à caractère personnel, l’inventaire des actifs et la sécurité des fournisseurs avec les attentes d’assurance de GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 et COBIT 19.
Alignez les politiques opérationnelles qui rendent le processus opposable : Privacy Risk Assessment and DPIA Policy, PII Processing Inventory and Lawful Basis Policy, Processor, Subprocessor and Third-Party Privacy Management Policy, Risk Management Policy et Data Protection and Privacy Policy. Les petites équipes peuvent également utiliser les politiques PME de Clarysec, tandis que les grandes organisations peuvent structurer leur gouvernance au moyen des politiques pour grandes organisations.
Si votre équipe lance un nouveau traitement, change de fournisseurs, prépare ISO/IEC 27701:2025 ou cherche à rendre les éléments probants de responsabilité au titre du GDPR reproductibles, commencez par une activité de traitement en production. Ouvrez REG02, réalisez l’examen préalable REG04, cartographiez les risques vers les contrôles, attribuez les propriétaires du traitement des risques et revoyez le risque résiduel avec le bon décisionnaire.
C’est dans ce processus unique que la gouvernance de la protection des données devient opérationnelle.
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