Gouvernance des AIPD pour ISO 27001, NIS2 et DORA
Il est 17 h 40 un jeudi, et Maria, RSSI d’une fintech en forte croissance, doit approuver une mise en production avant la clôture du trimestre.
L’équipe produit parle d’une avancée majeure : une fonctionnalité d’authentification des paiements fondée sur la biométrie et l’analyse comportementale, destinée à fluidifier l’accès client et à réduire la fraude. L’ingénierie indique qu’aucune nouvelle base de données centrale n’est créée. Les ventes signalent qu’un client financier réglementé l’attend. Le responsable de la mise en production a déjà qualifié le ticket en changement standard.
Puis le DPO pose trois questions.
La fonctionnalité combinera-t-elle des données biométriques ou comportementales avec des attributs de compte ? Un sous-traitant ultérieur cloud recevra-t-il des données de télémétrie ou des signaux d’authentification ? Quelqu’un a-t-il évalué si le changement crée un risque élevé pour les personnes ?
La salle se tait.
Maria dispose d’un registre des risques ISO/IEC 27001:2022. Le service juridique dispose d’un registre des activités de traitement au titre du GDPR. Les achats disposent d’un questionnaire fournisseur. L’équipe cloud dispose d’une revue de sécurité du prestataire. Le responsable de la gestion des changements dispose d’un ticket. Le conseil d’administration vient d’être informé des exigences de responsabilité NIS2 et des attentes de DORA en matière de résilience opérationnelle.
Aucun de ces enregistrements ne raconte, à lui seul, l’ensemble de l’histoire.
C’est le problème de gouvernance des AIPD en 2026. Les analyses d’impact relatives à la protection des données (AIPD, ou DPIA) ne peuvent plus rester dans un dossier Protection des données en attendant une demande d’une autorité de contrôle. Elles doivent devenir des enregistrements de décision reliant les Articles 25, 30, 32, 35 et 36 du GDPR aux éléments probants de gestion des risques ISO/IEC 27001:2022, aux mesures de gestion des risques de cybersécurité NIS2, à la gouvernance des changements TIC au titre de DORA, à l’assurance des fournisseurs et à la responsabilité au niveau du conseil d’administration.
Les organisations en difficulté n’ignorent généralement pas la conformité. Elles réalisent séparément la revue protection des données, la revue de sécurité, la revue cloud et la revue des changements. Les organisations performantes créent un workflow de gouvernance unique et traçable, dans lequel les déclencheurs d’AIPD, l’appréciation des risques, les diligences préalables relatives aux fournisseurs, la cartographie des contrôles, les tests et l’approbation du risque résiduel constituent une seule chaîne d’éléments probants.
Pourquoi les AIPD en silo échouent en 2026
Le GDPR a introduit l’AIPD comme mécanisme formel d’évaluation des traitements susceptibles d’engendrer un risque élevé pour les personnes. Dans de nombreuses entreprises, elle est devenue une tâche juridique ou de protection des données : un formulaire rempli lorsqu’un projet semblait sensible.
Ce modèle n’est plus défendable.
Un changement portant sur un traitement de données à caractère personnel est rarement un simple événement de protection des données. C’est aussi :
- Un événement de risque de sécurité de l’information au titre d’ISO/IEC 27001:2022.
- Un événement de gouvernance de la cybersécurité au titre de NIS2 si les réseaux et systèmes d’information, les fournisseurs ou les mesures de sécurité sont affectés.
- Un événement de changement TIC et de résilience au titre de DORA pour les entités financières et les prestataires de services TIC concernés.
- Un événement de risque fournisseur et cloud lorsque des sous-traitants, sous-traitants ultérieurs, interfaces de programmation (API), SDK ou services hébergés sont impliqués.
Lorsque ces évaluations sont réalisées séparément, les lacunes deviennent dangereuses. Une équipe protection des données peut approuver une AIPD sans comprendre les vulnérabilités d’un SDK biométrique. Une équipe informatique peut mettre en production un changement sans réaliser qu’il implique des données de catégories particulières ou une surveillance comportementale. Une équipe sécurité peut examiner un service cloud sans le relier aux risques spécifiques pour les droits et libertés identifiés dans l’AIPD.
La réponse n’est pas d’ajouter de la paperasse. La réponse est une gouvernance intégrée.
Une AIPD doit être traitée comme le déclencheur d’un workflow coordonné de gestion des risques couvrant la protection des données, la sécurité, le cloud, les fournisseurs, l’ingénierie, le juridique et la direction.
Le socle GDPR : la gouvernance des AIPD commence par la connaissance des traitements
Une AIPD ne peut être fiable si l’organisation ne peut pas expliquer ce qu’elle traite, pourquoi elle le traite, qui le reçoit et combien de temps il est conservé.
Le principe de responsabilité prévu par le GDPR exige davantage qu’une déclaration d’intention. L’Article 5 établit des principes fondamentaux tels que 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é. Il impose également au responsable du traitement de démontrer la conformité. L’Article 25 impose la protection de la vie privée dès la conception et par défaut. L’Article 30 impose la tenue de registres des activités de traitement. L’Article 32 impose la sécurité du traitement. L’Article 35 impose une AIPD lorsque le traitement est susceptible d’engendrer un risque élevé. L’Article 36 impose une consultation préalable lorsqu’un risque élevé demeure sans atténuation suffisante.
Pour les organisations SaaS, fintech, cloud et de services managés, cela signifie que tout changement significatif doit faire l’objet d’un filtrage au regard de son impact sur la protection des données. Le déclencheur n’est pas le fait qu’un projet soit étiqueté « Protection des données ». Le déclencheur est le fait que le changement affecte les données à caractère personnel, la finalité du traitement, la base légale, les destinataires, la conservation, les droits d’accès, les fournisseurs, les localisations cloud ou le risque résiduel.
La Politique de protection des données et de la vie privée - PME de Clarysec en fait une exigence opérationnelle :
« 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, incluant les catégories de données, la finalité, la base légale et les durées de conservation. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.1.
La même politique PME intègre la protection des données dans la livraison :
« La protection de la vie privée dès la conception et par défaut doit être appliquée à tous les nouveaux systèmes et services. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.3.1.
Pour les environnements d’entreprise, la Politique de protection des données et de la vie privée de Clarysec rend le point de contrôle AIPD explicite :
« Tout changement significatif apporté à des systèmes ou processus impliquant des informations permettant d’identifier une personne (PII) doit faire l’objet d’une analyse d’impact relative à la protection des données (AIPD) documentée, revue par le délégué à la protection des données (DPO). »
Extrait de la section « Exigences de gouvernance », clause de politique 5.6.
Cette clause constitue le pont entre la responsabilité au titre du GDPR et le contrôle opérationnel. Elle déplace l’AIPD du statut de réflexion juridique tardive vers la gouvernance de projet et l’approbation des changements.
Relier l’AIPD aux éléments probants de risque ISO/IEC 27001:2022
ISO/IEC 27001:2022 fournit la structure de système de management dont la gouvernance des AIPD a besoin.
Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les parties intéressées, les exigences, le domaine d’application du SMSI et les processus en interaction. Les lois relatives à la protection des données, les contrats clients, les obligations NIS2, les exigences DORA, les obligations des sous-traitants et les dépendances fournisseurs relèvent tous de ce contexte.
Les clauses 5.1 à 5.3 exigent le leadership, l’alignement des politiques, les ressources, les rôles et responsabilités. C’est là que de nombreuses AIPD échouent. Un DPO peut identifier un risque élevé, mais sans propriétaires du risque, règles d’escalade et critères d’acceptation soutenus par la direction, l’AIPD devient un document plutôt qu’une décision.
Les clauses 6.1.1 à 6.1.3 exigent une planification fondée sur les risques, un processus documenté d’appréciation des risques de sécurité de l’information, des critères d’acceptation du risque, des propriétaires du risque, une planification du traitement, une sélection des mesures de sécurité, une Déclaration d’applicabilité et l’approbation du risque résiduel. C’est la structure qu’une AIPD doit utiliser.
Une AIPD peut identifier des préjudices tels que le risque de profilage, la divulgation non autorisée, l’usage secondaire illicite, la fraude à l’identité, la discrimination ou la conservation excessive. Le SMSI traduit ces préjudices en scénarios de risque, en analyse de vraisemblance et d’impact, en actions de traitement, en contrôles de l’Annexe A et en approbations du risque résiduel.
La Politique de gestion des risques - PME de Clarysec définit la discipline minimale :
« Chaque entrée de risque doit inclure : description, vraisemblance, impact, score, propriétaire et plan de traitement des risques. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.1.2.
Pour les environnements d’entreprise, la Politique de gestion des risques de Clarysec relie la planification du traitement aux éléments probants ISO/IEC 27001:2022 :
« Le responsable des risques doit veiller à ce que les traitements soient réalistes, assortis d’échéances et cartographiés avec les contrôles de l’Annexe A d’ISO/IEC 27001. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.2.
Le Zenith Blueprint : feuille de route en 30 étapes pour auditeur, phase Gestion des risques, Étape 13, Planification du traitement des risques et Déclaration d’applicabilité, explique clairement le rôle de la SoA :
« La SoA est en pratique un document passerelle : elle relie votre appréciation/traitement des risques aux contrôles réellement en place. »
C’est le modèle d’AIPD compatible avec les exigences d’audit. Un constat d’AIPD ne doit pas se terminer par « risque accepté ». Il doit être relié au registre des risques, au plan de traitement des risques, à la Déclaration d’applicabilité, à la revue fournisseur, aux diligences préalables cloud, au ticket de changement, aux éléments probants de tests et à la décision de la direction.
Un seul enregistrement de décision, plusieurs livrables de conformité
Un workflow mature de gouvernance des AIPD ne duplique pas chaque réglementation. Il collecte les éléments probants une seule fois et les réutilise intelligemment.
| Question de gouvernance AIPD | Éléments probants créés | Éléments probants ISO/IEC 27001:2022 | Valeur pour la responsabilité GDPR | Valeur NIS2 ou DORA |
|---|---|---|---|---|
| Quel traitement change ? | Mise à jour du registre des activités de traitement et qualification initiale de l’AIPD | Éléments probants relatifs au périmètre, au contexte, aux actifs et aux processus | Soutient les registres des activités de traitement et la protection de la vie privée dès la conception | Montre la connaissance du risque opérationnel |
| Quels préjudices peuvent toucher les personnes ? | Scénario de risque de protection des données et évaluation de l’impact | Résultat de l’appréciation des risques et propriétaire du risque | Soutient le raisonnement et la responsabilité de l’AIPD | S’aligne sur la gouvernance de la cybersécurité fondée sur les risques |
| Quels contrôles réduisent le risque ? | Mesures de protection, MTO et plan de traitement des risques | SoA, plan de traitement des risques et statut de mise en œuvre de l’Annexe A | Soutient la sécurité du traitement et la protection de la vie privée par défaut | Soutient les mesures de cybersécurité et de gestion des risques TIC |
| Qui d’autre traite les données ou y accède ? | Revue fournisseur, sous-traitant et cloud | Éléments probants des contrôles fournisseur et cloud | Soutient la supervision des sous-traitants et la gouvernance des transferts | Soutient la chaîne d’approvisionnement et le risque lié aux tiers TIC |
| Qu’est-ce qui a changé en production ? | Enregistrement de changement, éléments probants de tests et approbation | Éléments probants de gestion des changements et de contrôle opérationnel | Montre que les contrôles ont été examinés avant la mise en production | Soutient les attentes relatives au risque de changement et à la résilience |
| Qui a accepté le risque résiduel ? | Approbation du DPO, du propriétaire du risque et de la direction | Acceptation du risque résiduel et contribution à la revue de direction | Montre une prise de décision responsable | Soutient la supervision par le conseil ou l’organe de direction |
Cette chaîne d’éléments probants s’aligne directement sur la clause 8.1 d’ISO/IEC 27001:2022, qui impose des processus opérationnels planifiés et maîtrisés, des éléments probants documentés, la maîtrise des changements planifiés et la revue des changements non intentionnels. La clause 8.2 impose des appréciations des risques à intervalles planifiés ou lorsque des changements significatifs sont proposés ou surviennent. La clause 8.3 impose la mise en œuvre du plan de traitement des risques. La clause 9 transforme ensuite les éléments probants en assurance par la surveillance, la mesure, l’audit interne et la revue de direction.
La Politique de protection des données et de la vie privée - PME rend le calendrier explicite :
« Le coordinateur de la protection des données doit évaluer les risques pour la vie privée chaque année et lors des changements majeurs apportés aux systèmes. »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.1.1.
Si un changement majeur concernant des données à caractère personnel ne déclenche pas de filtrage AIPD et de réévaluation du SMSI, le processus de gouvernance est incomplet.
NIS2 : la gouvernance des AIPD devient une responsabilité de direction
NIS2 renforce la pression de gouvernance pesant sur les organisations des secteurs essentiels et importants. Elle s’applique à de nombreuses entités publiques et privées appartenant aux secteurs listés qui atteignent les seuils de taille pertinents, et elle peut s’appliquer indépendamment de la taille dans certains cas, notamment les services de confiance, DNS, les registres TLD, les services publics de communications électroniques, les prestataires uniques de services essentiels ou les entités jouant un rôle de risque systémique.
Pour la gouvernance des AIPD, le point clé n’est pas seulement le champ d’application. C’est la responsabilité de la direction.
L’Article 20 de NIS2 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de suivre une formation. L’Article 21 impose des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, fondées sur l’exposition au risque, la taille, la vraisemblance, la gravité, l’impact sociétal et économique, l’état de l’art et les normes pertinentes.
L’Article 21(2) comprend des domaines qui recoupent fréquemment les résultats d’AIPD, notamment :
- Les politiques d’analyse des risques et de sécurité des systèmes d’information.
- La gestion des incidents.
- La continuité d’activité et la gestion de crise.
- La sécurité de la chaîne d’approvisionnement.
- La sécurité dans l’acquisition, le développement et la maintenance des réseaux et systèmes d’information.
- La gestion et la divulgation des vulnérabilités.
- Les politiques d’évaluation de l’efficacité des mesures de gestion des risques de cybersécurité.
- L’hygiène cyber et la formation.
- La cryptographie et le chiffrement.
- La sécurité RH, le contrôle d’accès et la gestion des actifs.
- L’authentification multifacteur, l’authentification continue, les communications sécurisées et les communications d’urgence sécurisées.
Une AIPD relative à une nouvelle activité de traitement biométrique, d’analyse comportementale ou fondée sur le cloud doit donc poser des questions pertinentes au titre de NIS2. Le traitement dépend-il d’un nouveau fournisseur ? Introduit-il une nouvelle interface de programmation (API), un SDK, un flux d’identité ou un modèle d’accès ? Modifie-t-il l’impact d’un incident ? Nécessite-t-il du chiffrement, une journalisation renforcée, des contrôles de développement sécurisé ou une approbation de la direction ?
La question pratique pour la direction devient simple : l’organisation peut-elle prouver qu’un changement ayant un impact sur la protection des données a été examiné dans le cadre de la gestion des risques de cybersécurité avant sa mise en œuvre ?
Cette preuve doit être visible dans la qualification initiale de l’AIPD, le registre des activités de traitement mis à jour, le registre des risques, le plan de traitement des risques, la Déclaration d’applicabilité, les diligences préalables relatives aux fournisseurs, les éléments probants de tests de sécurité, l’approbation du changement et l’acceptation du risque résiduel.
DORA : les éléments probants de changement TIC et de tiers sont incontournables
DORA s’applique depuis le 17 janvier 2025 et crée un cadre uniforme de l’UE pour la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle numérique, le partage d’informations sur les cybermenaces et les vulnérabilités, la gestion des risques liés aux prestataires tiers TIC et la supervision des prestataires tiers critiques de services TIC.
Pour les entités financières, DORA agit généralement comme un acte juridique sectoriel de l’Union pour les obligations de gestion des risques TIC et de notification des incidents, tandis que NIS2 reste pertinente pour la coordination plus large de l’écosystème et pour les entités non soumises à DORA.
La gouvernance des AIPD est importante au titre de DORA parce que les traitements de données à caractère personnel résident généralement dans des systèmes TIC, des services tiers, des environnements cloud et des workflows opérationnels.
L’Article 5 de DORA impose des cadres internes de gouvernance et de contrôle pour la gestion des risques TIC, avec une responsabilité de l’organe de direction. L’Article 6 impose un cadre documenté de gestion des risques TIC intégré à la gestion globale des risques. Les Articles 8 à 14 couvrent l’identification des actifs et des dépendances, la protection et la prévention, la détection, la continuité, la sauvegarde, le rétablissement, le retour d’expérience et les communications de crise.
L’Article 28 de DORA impose aux entités financières de gérer le risque lié aux tiers TIC comme partie intégrante de la gestion des risques TIC et de rester responsables lorsqu’elles utilisent des services TIC. Il impose des registres des contrats de services TIC, des évaluations précontractuelles, des diligences préalables, une appréciation du risque de concentration, une planification des audits et inspections, des droits de résiliation et des stratégies de sortie. L’Article 30 impose des contrats écrits comportant des descriptions claires des services, les localisations des données, des protections de confidentialité, d’intégrité et de disponibilité, la restauration et la restitution des données, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation et des mesures de protection supplémentaires pour les fonctions critiques ou importantes.
Pour une AIPD, cela modifie la question fournisseur. « Avons-nous un accord de traitement des données ? » ne suffit pas. La meilleure question est : pouvons-nous prouver que la dépendance TIC, la localisation des données, la sous-traitance ultérieure, les normes de sécurité, la résilience, les droits d’audit, l’assistance en cas d’incident et la stratégie de sortie ont été évalués avant d’approuver le traitement ?
La Politique d’utilisation du cloud de Clarysec rend explicite ce contrôle préalable à l’activation :
« Toute utilisation du cloud doit faire l’objet de diligences préalables fondées sur les risques avant activation, notamment l’évaluation du prestataire, la validation de la conformité juridique et des revues de validation des contrôles. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.2.
Une AIPD ne doit pas approuver un nouveau sous-traitant d’analyse, fournisseur d’identité, SDK biométrique ou plateforme de télémétrie cloud tant que les diligences préalables cloud, la validation juridique et la validation des contrôles ne sont pas achevées ou explicitement suivies comme actions de traitement.
Les ancrages ISO/IEC 27002:2022 : protection des données, projets et changement
Le Zenith Controls : guide de conformité croisée de Clarysec traite les contrôles ISO/IEC 27002:2022 comme des ancrages de conformité croisée. Pour la gouvernance des AIPD, trois contrôles sont particulièrement importants.
| Contrôle ISO/IEC 27002:2022 | Pourquoi il est important pour la gouvernance des AIPD | Valeur de conformité croisée |
|---|---|---|
| 5.34 Protection de la vie privée et des PII | Exige la connaissance et la protection des données à caractère personnel sur l’ensemble de leur cycle de vie | Soutient la responsabilité GDPR, l’Annexe A d’ISO/IEC 27001:2022, les mesures de risque NIS2 et les attentes DORA en matière de protection des données |
| 5.8 Sécurité de l’information dans la gestion de projet | Intègre la réflexion sur les impacts sécurité et protection des données dans la conception des projets | Soutient la protection de la vie privée dès la conception, le développement sécurisé et les mesures NIS2 d’acquisition et de développement |
| 8.32 Gestion des changements | Veille à ce que les changements soient évalués, autorisés, testés, mis en œuvre et revus | Soutient le contrôle opérationnel ISO, la gouvernance des changements TIC au titre de DORA et la traçabilité pour l’audit |
L’entrée Zenith Controls relative à 5.34, Protection de la vie privée et des PII, la classe comme préventive, associée à la confidentialité, l’intégrité et la disponibilité, alignée sur les concepts de cybersécurité Identify et Protect, et liée aux capacités de protection de l’information ainsi qu’aux capacités juridiques et de conformité.
Le Zenith Blueprint, phase Controls in Action, Étape 23, formule le point pratique ainsi :
« Le fondement de ce contrôle est la connaissance des données. L’organisation doit savoir quelles PII elle collecte, où elles résident, pourquoi elles sont traitées et qui peut y accéder. »
L’entrée Zenith Controls relative à 5.8, Sécurité de l’information dans la gestion de projet, la classe comme préventive, associée à la confidentialité, l’intégrité et la disponibilité, alignée sur Identify et Protect, et positionnée dans les domaines de la gouvernance, de l’écosystème et de la protection.
Le Zenith Blueprint, phase Controls in Action, Étape 22, indique :
« L’objectif de ce contrôle n’est pas d’alourdir les projets par de la bureaucratie. Il est de veiller à ce que la sécurité soit traitée comme une donnée d’entrée de conception, et non comme une phase de test. »
La protection des données doit être traitée de la même manière. Une AIPD réalisée après la mise en production ressemble souvent à un rapport de dommages. Une AIPD réalisée pendant la conception relève de la prévention des risques.
L’entrée Zenith Controls relative à 8.32, Gestion des changements, la classe comme préventive, associée à la confidentialité, l’intégrité et la disponibilité, alignée sur Protect, et liée à la sécurité des applications ainsi qu’aux capacités de sécurité des systèmes et des réseaux.
Le Zenith Blueprint, phase Controls in Action, Étape 21, est direct :
« Le changement est inévitable, mais en cybersécurité, un changement non maîtrisé est dangereux. »
La Politique de gestion des changements - PME de Clarysec capture le déclencheur :
« Si un changement implique des données sensibles, des droits d’accès système ou des intégrations externes, une revue de l’impact sécurité est requise. Le référent sécurité ou conformité désigné doit évaluer si le changement introduit des risques supplémentaires et recommander des mesures de protection supplémentaires. »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.5.1.
Pour les environnements d’entreprise, la Politique de gestion des changements de Clarysec fixe l’attente relative au Comité consultatif des changements :
« Évaluer les changements au regard des risques de sécurité et de conformité avant l’approbation par le Comité consultatif des changements. »
Extrait de la section « Rôles et responsabilités », clause de politique 4.6.1.
Exemple pratique : approuver une fonctionnalité d’analyse biométrique
Maria n’a pas besoin de trois projets de gouvernance distincts. Elle a besoin d’une qualification de projet intégrée et d’un workflow de risque unique.
L’équipe produit propose une authentification biométrique des paiements avec analyse comportementale. La fonctionnalité collecte des modèles biométriques, des métadonnées d’appareil, des attributs de compte, des adresses IP, des événements d’authentification et des signaux de fraude. Elle utilise un prestataire d’analyse cloud et un SDK biométrique tiers. Les équipes de réussite client recevront un accès à des tableaux de bord agrégés.
Le ticket de changement doit déclencher un filtrage AIPD et une appréciation des risques avant l’allocation de ressources ou l’approbation du Comité consultatif des changements.
| Champ de qualification | Exemple de réponse |
|---|---|
| Données à caractère personnel concernées | Modèle biométrique, identifiant utilisateur, adresse IP, métadonnées d’appareil, rôle de compte, événements d’authentification |
| Finalité du traitement | Authentification des paiements, détection de la fraude et analyse de réussite client |
| Base légale à confirmer | Nécessité contractuelle, intérêts légitimes ou consentement explicite, sous réserve de revue par le DPO |
| Nouveau fournisseur ou service cloud | Fournisseur du SDK biométrique et sous-traitant d’analyse cloud en région UE |
| Données sensibles ou de catégories particulières | Les données biométriques exigent une revue à haut risque lorsqu’elles sont utilisées pour l’identification unique |
| Changement de modèle d’accès | L’équipe de réussite client reçoit un accès à un tableau de bord agrégé |
| Changement de conservation | Journaux d’événements conservés 180 jours, modèles biométriques conservés conformément aux conditions de service |
| AIPD requise | Oui, le traitement biométrique, la surveillance et la nouvelle dépendance fournisseur imposent une revue |
L’évaluation intégrée doit ensuite produire un dossier de risque unique.
| Section d’évaluation | Cadre principal | Questions à traiter | Élément probant ou livrable |
|---|---|---|---|
| Description du traitement | GDPR Article 35 | Quelles données sont traitées, pourquoi, par qui et pendant combien de temps ? | Flux de données, mise à jour du RoPA, qualification initiale de l’AIPD |
| Nécessité et proportionnalité | GDPR Article 35 | Le traitement est-il nécessaire et constitue-t-il l’approche viable la moins intrusive ? | Revue et justification du DPO |
| Risque pour les personnes | GDPR Article 35 | Les personnes peuvent-elles subir un vol d’identité, une discrimination, un profilage, une exclusion ou un préjudice financier ? | Analyse des risques AIPD et entrée dans le registre des risques ISO |
| Appréciation des risques de sécurité | ISO/IEC 27001:2022 Clause 6.1.2 | Quelles menaces pèsent sur la confidentialité, l’intégrité et la disponibilité ? | Entrées du registre des risques avec vraisemblance, impact, propriétaire et traitement |
| Analyse d’impact NIS2 | NIS2 Article 21 | Le changement affecte-t-il les fournisseurs, le développement sécurisé, le contrôle d’accès, la gestion des incidents ou la continuité ? | Évaluation fournisseur, liste de contrôle de développement sécurisé, éléments probants de gestion |
| Analyse de résilience DORA | DORA Articles 8, 9, 24 et 30 | S’agit-il d’un changement TIC affectant la résilience, les tests ou les obligations contractuelles ? | Enregistrement de changement, plan de test, revue contractuelle et éléments probants de sortie |
| Traitement des risques et contrôles | ISO/IEC 27001:2022 Clause 6.1.3 | Quelles MTO et quels contrôles de l’Annexe A réduisent le risque ? | Plan de traitement des risques et Déclaration d’applicabilité mise à jour |
Des exemples d’entrées de risque pourraient ressembler à ceci :
| Scénario de risque | Vraisemblance | Impact | Exemples de traitement | Cartographie des contrôles |
|---|---|---|---|---|
| Collecte excessive au-delà de la finalité déclarée | Moyenne | Élevé | Revue de minimisation des données, approbation du schéma d’événements, limite de conservation | 5.34, 5.31, 8.10 |
| Accès non autorisé au tableau de bord biométrique ou comportemental | Moyenne | Élevé | Contrôle d’accès fondé sur les rôles, authentification multifacteur, journalisation, revue d’accès trimestrielle | 5.15, 5.18, 8.15, 8.16 |
| Mauvaise configuration du sous-traitant cloud exposant la télémétrie | Faible | Élevé | Diligences préalables cloud, chiffrement, configuration de référence, surveillance | 5.23, 8.9, 8.24, 8.16 |
| Vulnérabilité du SDK biométrique compromettant les données d’authentification | Moyenne | Élevé | Diligences préalables relatives aux fournisseurs, revue de développement sécurisé, tests de sécurité | 5.21, 8.25, 8.28, 8.29 |
| Profilage créant un impact client inéquitable | Moyenne | Élevé | Revue DPO, formulation de transparence, gestion de l’opposition lorsque applicable | 5.34, 5.8 |
Avant la mise en production, l’enregistrement de changement doit contenir l’achèvement de l’AIPD ou un plan de traitement approuvé par le DPO, le registre des activités de traitement mis à jour, les diligences préalables fournisseur et cloud, la revue de l’impact sécurité, les résultats des tests, le plan de retour arrière, le plan de surveillance et l’approbation du risque résiduel.
Après la mise en production, le propriétaire doit vérifier les journaux, les alertes, les rôles d’accès, les tableaux de bord, les règles de conservation et les workflows de suppression. Cela clôt la boucle du changement planifié au titre de la clause 8.1 d’ISO/IEC 27001:2022 et soutient une discipline de résilience opérationnelle conforme à l’esprit de DORA.
Ce que les auditeurs demanderont
Une AIPD unifiée fournit aux différents auditeurs une piste d’éléments probants cohérente.
| Point de vue de l’auditeur | Point d’attention probable | Éléments probants attendus |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 | Vérifier si les changements significatifs ont déclenché l’appréciation des risques, le traitement, les mises à jour de la SoA et le contrôle opérationnel | Qualification initiale de l’AIPD, registre des risques, plan de traitement des risques, notes SoA, enregistrement de changement, piste d’audit interne |
| Évaluateur protection des données GDPR | Vérifier si le traitement à haut risque a été évalué avant le déploiement et si les mesures de protection ont été documentées | AIPD, registre des activités de traitement, analyse de la base légale, revue DPO, éléments probants de transparence et de conservation |
| Auditeur orienté NIS2 | Vérifier si les mesures de risque approuvées par la direction couvrent les politiques de sécurité, la chaîne d’approvisionnement, la gestion des incidents, la continuité, les accès, le chiffrement et la gestion des vulnérabilités | Enregistrements du conseil ou de revue de direction, cartographie des contrôles, revue fournisseur, articulation avec les incidents et la continuité |
| Auditeur orienté DORA | Vérifier si les éléments probants relatifs aux changements TIC, aux dépendances vis-à-vis de tiers, à la résilience, aux tests et aux contrats sont intégrés à la gouvernance des risques TIC | Appréciation des risques TIC, registre des prestataires, clauses contractuelles, éléments probants de tests, plan de sortie, éléments probants d’assistance en cas d’incident |
| Évaluateur NIST CSF | Vérifier si les résultats de gouvernance, risque, actifs, fournisseurs, protection, détection, réponse et rétablissement sont reliés | Profil actuel et cible, plan d’écarts, inventaire des actifs, enregistrements de risque fournisseur, éléments probants de surveillance et de réponse |
| Auditeur COBIT 2019 ou ISACA | Vérifier si l’activation des changements, la gestion des risques, les services de sécurité et les pratiques d’assurance sont maîtrisés | Enregistrements du Comité consultatif des changements, analyse d’impact, approbations, tests, séparation des tâches, revue post-changement |
NIST CSF 2.0 est utile comme couche de communication, car sa fonction GOVERN place la stratégie, les attentes, la politique, les rôles, la supervision et la gestion des risques liés à la chaîne d’approvisionnement au centre. COBIT 2019 ajoute l’assurance des processus, en particulier autour de l’activation structurée des changements, de l’analyse d’impact, des approbations, des tests et de l’évaluation post-changement.
Une autorité de contrôle GDPR peut commencer par les droits et libertés des personnes. Un auditeur ISO peut commencer par l’appréciation des risques documentée et la mise en œuvre des contrôles. Un évaluateur DORA peut commencer par la dépendance TIC et la résilience. Un évaluateur NIS2 peut commencer par la supervision de la direction et les mesures de cybersécurité proportionnées.
La même chaîne d’éléments probants AIPD doit pouvoir répondre à tous.
Les décisions d’AIPD doivent résister aux incidents
Une AIPD n’est pas seulement un livrable d’approbation avant mise en production. Elle doit améliorer la préparation aux violations et aux incidents.
Le GDPR définit une violation de données à caractère personnel comme une violation de sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel ou l’accès non autorisé à de telles données. NIS2 exige la notification des incidents significatifs sans retard injustifié, avec une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final au plus tard un mois après la notification de l’incident. DORA impose aux entités financières de détecter, gérer, journaliser, classifier, escalader et notifier les incidents majeurs liés aux TIC au moyen de rapports initial, intermédiaire et final, avec notification aux clients lorsque leurs intérêts financiers sont affectés.
Si l’AIPD a consigné les flux de données, les sous-traitants, les contrôles d’accès, la conservation, la journalisation, le chiffrement, la pseudonymisation et les responsabilités en matière d’incident, l’équipe de gestion des incidents peut répondre plus rapidement aux questions critiques. Quelles données à caractère personnel étaient concernées ? Quels systèmes et fournisseurs ont été affectés ? Quelles personnes ou quels clients peuvent être impactés ? Le chiffrement était-il en place ? Quels journaux sont disponibles ? Quels délais de notification s’appliquent ? Quelles communications clients ou avec les autorités de contrôle sont requises ?
C’est pourquoi la gouvernance des AIPD doit être reliée aux contrôles d’incident ISO/IEC 27001:2022, aux contrôles de continuité d’activité et aux contrôles de préparation TIC, ainsi qu’aux attentes NIS2 et DORA relatives au cycle de vie des incidents.
Défaillances courantes de gouvernance des AIPD
Les défaillances proviennent généralement de workflows déconnectés, et non d’un manque d’effort.
| Défaillance | Pourquoi elle crée un risque | Meilleure pratique |
|---|---|---|
| Registre des activités de traitement mis à jour après la mise en production | Le registre devient un inventaire historique au lieu d’un contrôle de conception | Mettre à jour le RoPA avant l’approbation |
| Filtrage AIPD absent de la qualification des changements | Le risque de protection des données est découvert trop tard | Ajouter des questions obligatoires sur les données à caractère personnel, les fournisseurs, les accès et la conservation |
| Risques AIPD conservés dans un dossier Protection des données | Le traitement de sécurité et l’approbation du risque résiduel ne sont pas traçables | Convertir les constats d’AIPD en entrées du registre des risques du SMSI |
| Revues fournisseurs limitées aux questionnaires | La finalité du traitement, la localisation des données, les sous-traitants ultérieurs, les droits d’audit et la sortie peuvent être omis | Combiner les diligences préalables sécurité, protection des données, juridiques et résilience |
| SoA dépourvue de justification protection des données et cloud | Les auditeurs voient les contrôles, mais pas la logique de risque | Cartographier les contrôles avec les constats d’AIPD et les obligations GDPR, NIS2 et DORA |
| Risque résiduel accepté informellement | La responsabilité de la direction n’est pas démontrable | Enregistrer l’approbation du DPO, du propriétaire du risque et de la direction avec conditions |
Liste de contrôle de gouvernance des AIPD
Utilisez cette liste de contrôle pour intégrer les AIPD au SMSI, à la préparation NIS2 et à la gouvernance des changements TIC au titre de DORA.
| Activité de gouvernance | Propriétaire | Élément probant minimal |
|---|---|---|
| Filtrage AIPD intégré à la qualification des projets et des changements | Responsable de la gestion des changements et DPO | Formulaire de qualification, décision de déclenchement et justification |
| Registre des activités de traitement mis à jour avant approbation | Coordinateur de la protection des données ou DPO | Finalité, base légale, catégories de données, conservation et destinataires |
| Risques protection des données traduits en risques SMSI | Responsable des risques et propriétaire du système | Entrées de risque avec vraisemblance, impact, propriétaire et plan de traitement des risques |
| Contrôles cartographiés avec la SoA | Responsable du SMSI | Contrôles applicables de l’Annexe A, justification et statut de mise en œuvre |
| Diligences préalables fournisseur et cloud achevées | Achats, sécurité et juridique | Évaluation du prestataire, clauses contractuelles, localisation des données et éléments probants de sortie |
| Tests de sécurité et protection des données achevés | Ingénierie et sécurité | Résultats des tests, revue d’accès, validation de la journalisation et éléments probants de vulnérabilités |
| Risque résiduel accepté | Propriétaire du risque, DPO et direction lorsque requis | Enregistrement d’approbation, conditions et date de revue |
| Revue post-changement réalisée | Propriétaire du changement et responsable de service | Notes de revue, incidents, indicateurs et actions correctives |
Ce n’est pas de la bureaucratie. C’est une responsabilité opérationnelle. Cela aide le RSSI à prouver que la sécurité a été prise en compte, le DPO à prouver que le risque de protection des données a été évalué, le responsable conformité à prouver que les contrôles sont cartographiés entre référentiels, et le propriétaire métier à prouver que l’innovation a été gouvernée de manière responsable.
Comment Clarysec aide
L’approche de Clarysec est conçue pour les organisations confrontées à des obligations 2026 qui se chevauchent et à des éléments probants fragmentés.
La boîte à outils de politiques fournit le langage de gouvernance. La Politique de protection des données et de la vie privée définit quand les AIPD sont requises et qui les revoit. La Politique de gestion des risques définit comment les entrées de risque doivent être structurées et cartographiées. La Politique de gestion des changements veille à ce que les impacts protection des données et sécurité soient évalués avant approbation. La Politique d’utilisation du cloud impose des diligences préalables avant l’activation du cloud.
Le Zenith Blueprint fournit la feuille de route de mise en œuvre. L’Étape 13 transforme le traitement des risques et la Déclaration d’applicabilité en passerelle de conformité croisée. L’Étape 22 intègre la sécurité dans la gestion de projet. L’Étape 21 rend le changement intentionnel, justifié et vérifiable en audit. L’Étape 23 transforme la protection des PII en contrôle de cycle de vie fondé sur la connaissance des données, l’usage licite, la restriction des accès, la supervision des fournisseurs et les processus opérationnels de protection des données.
Le guide Zenith Controls fournit la boussole de conformité croisée. Pour la gouvernance des AIPD, les contrôles ISO/IEC 27002:2022 5.34, 5.8 et 8.32 relient la protection de la vie privée, la gouvernance de projet et le contrôle des changements à la responsabilité GDPR, aux mesures de cybersécurité NIS2, à la gouvernance des risques TIC au titre de DORA, aux résultats NIST CSF et à l’assurance COBIT 2019.
Si votre organisation se prépare à des revues de responsabilité GDPR, à une certification ISO/IEC 27001:2022, à la préparation NIS2 ou à la résilience opérationnelle DORA, commencez par intégrer les déclencheurs d’AIPD dans la qualification des projets et des changements. Reliez les constats d’AIPD au registre des risques. Cartographiez les traitements dans la SoA. Validez les fournisseurs et les services cloud avant activation. Conservez un seul enregistrement de décision que la direction, les auditeurs et les autorités de contrôle peuvent suivre.
La meilleure AIPD n’est pas celle qui est rédigée après la demande d’une autorité de contrôle. C’est celle qui a façonné le système avant que les clients, les auditeurs ou les incidents ne le mettent à l’épreuve.
Évaluez votre processus AIPD actuel au regard de la boîte à outils de politiques de Clarysec, utilisez le Zenith Blueprint pour bâtir une traçabilité compatible avec les exigences d’audit, et utilisez Zenith Controls pour cartographier un même cadre de contrôle avec GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF et COBIT 2019. Transformez ensuite votre prochain changement ayant un impact sur la protection des données en décision de mise en production gouvernée et étayée par des éléments probants, plutôt qu’en course de conformité de dernière minute.
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
