Gouvernance des réclamations en matière de protection des données pour GDPR et ISO 27701

Il est 16 h 45 un vendredi lorsque le RSSI d’une plateforme SaaS fintech en forte croissance voit arriver le courriel. L’objet est court, formel et immédiatement préoccupant : « Demande formelle concernant la réclamation réf. : [Numéro de dossier] ».
L’expéditeur est une autorité nationale de protection des données.
Le courriel fait référence à une réclamation client datant de six mois. Le client indique que sa demande d’accès a été ignorée, que ses données sont restées visibles dans des exports analytiques et que l’entreprise n’a pas expliqué la base légale du traitement poursuivi. L’autorité demande désormais la demande initiale, toute la correspondance, les journaux internes de décision, les enregistrements des activités de traitement, les mentions d’information, les éléments probants relatifs aux mesures protégeant le compte, les contrats de sous-traitance et une explication du retard.
L’organisation dispose de 10 jours ouvrés pour répondre.
À cet instant, la gouvernance de la protection des données cesse d’être théorique. La mention d’information peut exister. La politique de protection des données peut avoir été approuvée l’année précédente. Le processus de traitement des demandes d’exercice des droits peut être enregistré quelque part dans un lecteur partagé. Mais l’autorité ne demande pas si l’organisation avait de bonnes intentions. Elle demande des éléments probants.
Qui porte la réponse ? Le DPO ou le responsable de la protection des données peut-il échanger directement avec l’autorité ? L’équipe support peut-elle envoyer rapidement un courriel explicatif ? S’agit-il seulement d’une réclamation GDPR, ou également d’une violation de données à caractère personnel, d’un incident majeur lié aux TIC au sens de DORA, ou d’un incident significatif au sens de NIS2 ? Quels enregistrements peuvent être communiqués à l’extérieur, et qui les approuve ?
C’est précisément à ce stade que la gouvernance du système de management de la protection de la vie privée ISO/IEC 27701:2025 doit devenir opérationnelle. Un PIMS n’est pas un dossier de documents relatifs à la protection des données. C’est le système de management qui transforme les réclamations, les escalades de demandes des personnes concernées, la correspondance avec les autorités de contrôle, les indicateurs de violation, la divulgation d’éléments probants, les actions correctives et la revue de direction en une traçabilité de responsabilité défendable.
L’approche de Clarysec est simple : traiter les réclamations en matière de protection des données et les demandes des autorités de contrôle comme des flux de travail gouvernés, et non comme des événements juridiques ad hoc. Cela implique des canaux de réception prédéfinis, une escalade fondée sur les rôles, des registres d’éléments probants, des règles de communication avec les autorités, des actions correctives et une cartographie croisée de conformité avec les attentes d’assurance de GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST CSF 2.0, NIS2, DORA et COBIT 19.
Pourquoi la gouvernance des réclamations en matière de protection des données échoue sous pression
La plupart des programmes de protection des données sont conçus autour de demandes prévisibles : accès, effacement, rectification, opposition, portabilité et retrait du consentement. Le modèle opérationnel suppose souvent que le demandeur coopère, que la demande est claire et que l’équipe chargée de la protection des données dispose du temps nécessaire pour instruire le dossier.
Les réclamations sont différentes.
Une réclamation arrive généralement avec une forte charge émotionnelle, des accusations, des faits incomplets et un risque d’escalade externe. Une demande d’une autorité de contrôle ajoute une sensibilité juridique, des échéances, un risque réputationnel et une exigence probatoire plus élevée. Une escalade de demande d’exercice des droits peut révéler des faiblesses plus profondes, telles qu’une vérification d’identité insuffisante, des responsabilités de sous-traitants mal définies, des règles de conservation manquantes, un contenu de mention d’information incohérent ou l’absence d’éléments probants montrant que la demande initiale a été traitée dans les délais légaux.
GDPR rend ce problème probatoire incontournable. Article 5 impose aux responsables du traitement de traiter les données à caractère personnel de manière licite, loyale et transparente, pour des finalités déterminées, avec minimisation des données, exactitude, limitation de la conservation et sécurité appropriée. Article 5(2) ajoute l’obligation de responsabilité : le responsable du traitement doit être en mesure de démontrer la conformité. Article 6 exige une base légale, Article 9 ajoute des conditions renforcées pour les données relevant de catégories particulières, et Article 4 définit les rôles, les activités de traitement et la notion de violation de données à caractère personnel, souvent centrales dans les investigations liées aux réclamations.
Le problème n’est pas seulement que la réclamation peut être fondée. Le risque le plus important est que l’organisation ne puisse pas reconstituer ce qui s’est passé.
Une autorité peut demander :
- La demande initiale relative à la protection des données et son accusé de réception.
- Les enregistrements de vérification d’identité.
- Les journaux internes de routage et de décision.
- Les copies des communications adressées au réclamant.
- La version applicable de la mention d’information.
- Le registre des activités de traitement et la base légale.
- L’implication des sous-traitants et sous-traitants ultérieurs.
- Les éléments probants de DPIA, le cas échéant.
- Les mesures de sécurité protégeant les données à caractère personnel.
- L’évaluation d’une violation de données à caractère personnel et la justification de notification.
- Les actions correctives et les éléments de sortie de la revue de direction.
Si ces pièces justificatives sont dispersées entre la messagerie électronique, les outils de gestion des tickets, les dossiers juridiques, les notes CRM, les messages de messagerie instantanée et les portails fournisseurs, l’organisation est déjà en retard.
Le modèle opérationnel de Clarysec : les réclamations sont des événements maîtrisés par le PIMS
Dans l’ensemble de politiques PIMS ISO/IEC 27701:2025 de Clarysec, le traitement des réclamations n’est pas considéré comme un processus annexe. Il relie la réception, les mentions d’information, la gestion des droits, les échanges réglementaires, la divulgation d’éléments probants, le triage des incidents de sécurité et l’amélioration continue.
La version PME de la Politique de protection des données et de la vie privée de Clarysec Politique de protection des données et de la vie privée PME attribue clairement la responsabilité :
« Répond aux demandes individuelles relatives à la vie privée et aux demandes réglementaires »
Extrait de la section « Rôles et responsabilités », clause de politique 4.2.2.
Cette responsabilité unique est importante, car de nombreuses petites organisations ne disposent pas d’un DPO dédié. La politique fait de la réponse aux demandes réglementaires une fonction attribuée, et non une activité menée au mieux des capacités disponibles.
La même Politique de protection des données et de la vie privée PME impose une escalade immédiate :
« Toutes les préoccupations, tous les incidents ou tous les risques relatifs à la vie privée doivent être escaladés immédiatement au DG ou au Coordinateur Protection des données »
Extrait de la section « Exigences de gouvernance », clause de politique 5.4.1.
Elle ferme également la boucle probatoire :
« Les journaux d’escalade doivent être conservés, y compris les résultats finaux et les actions correctives »
Extrait de la section « Exigences de gouvernance », clause de politique 5.4.2.
Pour les environnements d’entreprise, la Politique de protection des données et de la vie privée de Clarysec Politique de protection des données et de la vie privée attribue au DPO un rôle plus large en matière de relations avec les autorités et de gestion des violations :
« Pilote les échanges réglementaires, réalise les analyses d’impact relatives à la protection des données (DPIA) et gère les processus de notification des violations. »
Extrait de la section « Rôles et responsabilités », clause de politique 4.2.3.
C’est essentiel, car une même réclamation en matière de protection des données peut rapidement se scinder en trois flux de travail liés : réponse à la réclamation, correspondance avec l’autorité de contrôle et évaluation d’une violation de données à caractère personnel. La même Politique de protection des données et de la vie privée formalise la gouvernance des demandes des personnes concernées :
« Le délégué à la protection des données (DPO) doit maintenir des processus documentés pour la réception, la validation, le suivi et la réponse aux demandes des personnes concernées (DSR). »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.1.
« Les demandes doivent faire l’objet d’un accusé de réception sous 72 heures et être résolues dans les délais légaux. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.2.
C’est ainsi qu’un PIMS devient opérationnel. L’organisation n’attend pas que le service juridique, le support, la sécurité et le DPO improvisent. Elle dispose déjà d’un processus de réception, d’un délai de réponse, d’un responsable désigné et d’une obligation de tenue des enregistrements.
De la boîte de réception dédiée à la protection des données à la réponse à l’autorité : le flux de travail gouverné
Un bon flux de gouvernance des réclamations en matière de protection des données et des demandes des autorités de contrôle répond à cinq questions dans la première heure :
- De quel type d’événement s’agit-il ?
- Qui en est responsable ?
- Quelle échéance s’applique ?
- Quels éléments probants sont nécessaires ?
- Quelle communication externe est autorisée ?
Clarysec traduit ces questions dans un flux de travail PIMS structuré.
| Étape | Question pratique | Élément probant Clarysec | Résultat de gouvernance |
|---|---|---|---|
| Réception | S’agit-il d’une réclamation, d’une demande d’exercice des droits, d’une demande d’une autorité, d’une allégation de violation, ou de l’ensemble de ces éléments ? | REG06, boîte de réception dédiée à la protection des données, canal de réclamation | Enregistrement unique de la réception et de la classification |
| Validation | Le demandeur est-il identifiable, autorisé et dans le champ d’application ? | Procédure DSR, journal de vérification d’identité | Prévention d’une divulgation illicite et confirmation du rôle |
| Escalade | L’événement nécessite-t-il l’intervention du DPO, du juridique, du DG, du RSSI ou d’un sous-traitant ? | Journal d’escalade, ticket d’incident, REG12 | Responsabilité claire et routage auditable |
| Collecte des éléments probants | Quels enregistrements prouvent la conformité ou expliquent une non-conformité ? | Registre de conformité, politiques, DPIA, RoPA, enregistrements relatifs aux sous-traitants | Dossier d’éléments probants maîtrisé |
| Communication | Qui peut répondre au réclamant ou à l’autorité ? | Politique de conformité juridique et réglementaire | Communications avec les autorités approuvées et cohérentes |
| Clôture | Qu’est-ce qui a été décidé, envoyé, refusé, prolongé, corrigé ou escaladé ? | REG06, REG12, plan d’actions correctives | Responsabilité et amélioration continue |
La Politique de conformité juridique et réglementaire pour les entreprises Politique de conformité juridique et réglementaire est directe sur le risque de communication avec les autorités :
« Toute déclaration verbale ou écrite aux régulateurs doit être préalablement approuvée »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.3.1.2.
Elle impose également la maîtrise des échéances et des éléments probants :
« Les échéances de réponse doivent être suivies et les journaux d’éléments probants maintenus »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.3.1.3.
Pour les PME, la Politique de conformité juridique et réglementaire PME Politique de conformité juridique et réglementaire PME propose un modèle de réponse pratique :
« Si les régulateurs demandent des éléments probants de conformité : »
Extrait de la section « Application et conformité », clause de politique 8.4.1.
« Le DG doit fournir le registre de conformité, les enregistrements et les politiques. »
Extrait de la section « Application et conformité », clause de politique 8.4.1.1.
Cette différence est intentionnelle. Les entreprises peuvent disposer de conseils juridiques, de DPO, d’équipes opérationnelles dédiées à la protection des données et de fonctions chargées des affaires réglementaires. Les PME peuvent nécessiter une ligne de responsabilité plus simple. Les deux modèles exigent le même résultat : éléments probants approuvés, divulgation maîtrisée, réponse traçable et responsabilité claire.
Les canaux de réception doivent être visibles, à jour et auditables
Un constat d’audit fréquent est étonnamment basique : la mention d’information indique aux personnes qu’elles disposent de droits, mais ne fournit pas de canal de réception fiable pour les demandes d’exercice des droits ou les réclamations.
Au regard des exigences de transparence de GDPR, les personnes doivent savoir où envoyer leurs demandes et préoccupations. Au titre de la gouvernance PIMS ISO/IEC 27701:2025, ce canal doit alimenter un registre maîtrisé.
La Privacy Notice and Transparency Policy de Clarysec Politique relative aux mentions d’information et à la transparence traite ce point au moment de l’approbation de la mention :
« [Responsable du traitement] Le responsable de processus / propriétaire de l’entreprise DOIT inclure le canal REG06 de réception des demandes d’exercice des droits à jour ainsi que le canal de réclamation ou de contact Protection des données dans REG07 avant de soumettre une mention d’information à approbation. »
Extrait de la section « Contenu des mentions et informations relatives à la transparence », clause de politique 4.2.4.
Cette clause est importante opérationnellement. Elle empêche les équipes métier de publier des mentions d’information avec des boîtes aux lettres DPO obsolètes, des formulaires web défectueux ou des liens génériques « contactez-nous » que le support client ne reconnaît pas comme des canaux dédiés à la protection des données.
Le résultat est une boucle fermée :
- Les mentions d’information indiquent le bon canal de réception des réclamations et des demandes d’exercice des droits.
- Les demandes et réclamations entrent dans REG06.
- Le responsable de la protection des données ou le responsable du PIMS les classifie et les route.
- Les résultats et les communications sont enregistrés.
- Les tendances et les actions correctives sont revues dans REG12.
La PII Principal Rights Management Policy Politique de gestion des droits des personnes concernées définit l’exigence de registre :
« [Tous] Le Responsable Protection des données / responsable du PIMS DOIT enregistrer chaque demande d’exercice des droits d’une personne concernée dans REG06 dans les deux jours ouvrés suivant sa réception. »
Extrait de la section « Réception, journalisation et classification », clause de politique 4.1.1.
Pour les scénarios de responsable du traitement, elle exige également que la communication de clôture soit enregistrée :
« [Responsable du traitement] Le Responsable Protection des données / responsable du PIMS DOIT communiquer au demandeur le résultat, le statut d’exécution de la demande, la justification du refus, le statut de prolongation ou le circuit d’escalade disponible, et enregistrer cette communication dans REG06. »
Extrait de la section « Refus, prolongation, restriction et clôture », clause de politique 4.4.4.
Et pour l’amélioration continue :
« [Tous] Le Responsable Protection des données / responsable du PIMS DOIT revoir les thèmes récurrents des demandes d’exercice des droits, les réclamations, les litiges et les actions correctives dans REG12 au moins une fois par trimestre. »
Extrait de la section « Indicateurs et mesure », clause de politique 8.1.6.
La gouvernance des réclamations en matière de protection des données n’est pas achevée lorsque le réclamant reçoit une réponse. Elle l’est lorsque l’organisation peut démontrer comment les tendances ont été revues, les causes racines traitées et le PIMS amélioré.
La transmission d’éléments probants à une autorité de contrôle est une activité maîtrisée
Lorsqu’une autorité demande des enregistrements, l’organisation fait face à un second risque relatif à la protection des données : la divulgation excessive.
Une réponse précipitée peut exposer des données client sans rapport avec la demande, des données à caractère personnel d’employés, des analyses juridiques couvertes par un privilège, des schémas sensibles pour la sécurité, des informations confidentielles relatives aux sous-traitants ou des indicateurs internes d’incident qui auraient dû être cadrés et approuvés. La coopération avec l’autorité est importante, mais une transmission non maîtrisée d’éléments probants crée ses propres risques de conformité, contractuels et de sécurité.
C’est pourquoi la PIMS Documented Information and Evidence Management Policy de Clarysec Politique de gestion des informations documentées et des éléments probants du PIMS impose l’approbation et le cadrage de la divulgation :
« [Tous] Le Responsable Protection des données / responsable du PIMS DOIT enregistrer l’approbation et le périmètre de divulgation dans REG12 avant de communiquer des éléments probants PIMS à un auditeur externe, un client, un sous-traitant, un responsable du traitement, une autorité de contrôle ou toute autre partie externe. »
Extrait de la section « Accès, protection, récupération et divulgation », clause de politique 4.4.5.
C’est le contrôle de gouvernance que de nombreuses organisations omettent. La question n’est pas seulement « pouvons-nous retrouver les éléments probants ? ». La question est : « pouvons-nous prouver que les éléments probants étaient autorisés, pertinents, suffisamment complets et non excessifs ? »
Pour les demandes des autorités de contrôle, Clarysec recommande un dossier de réponse à l’autorité comprenant :
- La référence de la demande de l’autorité, la date de réception et l’échéance.
- Le responsable de la réponse et l’approbateur désignés.
- La base légale de la divulgation, si nécessaire.
- Le périmètre des éléments probants et les exclusions.
- Les sources d’enregistrement utilisées.
- Un journal de toutes les communications.
- La copie de la réponse finale.
- Les actions correctives ouvertes en conséquence.
Ce dossier doit être lié à REG12 et, lorsque l’affaire a commencé comme une demande d’exercice des droits ou une réclamation, faire l’objet d’un renvoi croisé vers REG06.
Comment ISO/IEC 27002:2022 rend la gouvernance de la protection des données auditable
Les réclamations en matière de protection des données révèlent souvent des faiblesses dans la gouvernance de la sécurité de l’information. Un réclamant peut alléguer un accès non autorisé, des enregistrements inexacts, une conservation excessive, un transfert non sécurisé ou un accès non maîtrisé par un sous-traitant. Les éléments probants du PIMS doivent donc être reliés aux mesures du SMSI.
Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls place la mesure ISO/IEC 27002:2022 5.5, Contact avec les autorités, au centre de la gouvernance des interactions avec les autorités. Il décrit la mesure 5.5 comme préventive et corrective, soutenant la confidentialité, l’intégrité et la disponibilité, et liée aux notions d’identification, de protection, de réponse et de rétablissement.
Zenith Controls explique le lien opérationnel entre le contact avec les autorités et la gestion des incidents :
« La mesure 5.5 soutient l’efficacité de la gestion des incidents en veillant à ce que les organisations disposent de contacts préétablis avec les autorités compétentes, telles que les autorités chargées de l’application de la loi, les régulateurs, les CERT nationaux ou les agences de protection des données. »
Extrait de Zenith Controls, mesure 5.5, Contact avec les autorités.
Le guide met en correspondance la mesure 5.5 avec des mesures ISO/IEC 27002:2022 de support qui sont directement pertinentes lorsqu’une réclamation devient un dossier exposé à l’autorité.
| Mesure ISO/IEC 27002:2022 | Pourquoi elle est importante pour les réclamations en matière de protection des données et les demandes des autorités |
|---|---|
| 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information | Les réclamations alléguant une divulgation non autorisée peuvent nécessiter un triage de violation et une planification de notification à l’autorité |
| 6.8 Signalement des événements de sécurité de l’information | Les employés doivent savoir comment signaler les préoccupations relatives à la protection des données, les enregistrements perdus, les accès suspects ou les escalades de réclamation |
| 5.7 Renseignement sur les menaces | Les avis des autorités peuvent éclairer l’appréciation des risques et l’investigation d’incident |
| 5.6 Contact avec des groupes d’intérêt particuliers | Les groupes sectoriels et les ISAC peuvent soutenir la connaissance de la situation lors d’événements sectoriels de protection des données ou de sécurité |
| 5.26 Réponse aux incidents de sécurité de l’information | Si la réclamation indique une violation, la coordination de la réponse dépend de contacts préparés avec les autorités |
Zenith Controls met également en avant la mesure 5.31, Exigences légales, statutaires, réglementaires et contractuelles. Cette mesure est directement liée à la gouvernance des réclamations en matière de protection des données, car l’organisation doit savoir quelles obligations légales s’appliquent avant de pouvoir répondre correctement. La mesure 5.31 s’articule avec la conservation, la vie privée et la protection des informations à caractère personnel, la revue indépendante et la conformité interne aux politiques et normes.
La mesure 5.34, Vie privée et protection des informations à caractère personnel, est tout aussi centrale. Zenith Controls la relie aux inventaires des actifs, à la gouvernance des services cloud, à la classification de l’information, au transfert d’informations, au contrôle d’accès, à la gestion des identités et à la revue de sécurité des projets et des changements. En matière de réclamation, ces liens répondent aux questions clés de l’autorité : quelles informations à caractère personnel existent ? Où sont-elles stockées ? Qui peut y accéder ? Quels sous-traitants sont impliqués ? Le transfert était-il maîtrisé ? Le projet a-t-il fait l’objet d’une revue d’impact sur la vie privée ?
Ne rencontrez pas l’autorité pour la première fois pendant une crise
Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint traite le contact avec les autorités comme une capacité planifiée, et non comme une réponse dans la panique. Dans la phase Controls in Action, étape 22, Contrôles organisationnels, la mesure 5.5 est décrite au moyen d’un défi direct :
« Le principe est simple : si votre organisation était ciblée par une cyberattaque, impliquée dans une violation de données ou faisait l’objet d’une investigation, qui appellerait les autorités ? Comment cette personne saurait-elle quoi dire ? Dans quelles conditions ce contact serait-il initié ? Ces questions doivent recevoir une réponse à l’avance, et non après coup. »
Extrait de Zenith Blueprint, phase Controls in Action, étape 22, Contrôles organisationnels, mesure 5.5, Contact avec les autorités.
Pour la gouvernance des réclamations en matière de protection des données, le guide opérationnel doit identifier :
- Les autorités de contrôle de la protection des données par juridiction.
- Les autorités de cybersécurité, CSIRT et régulateurs sectoriels pertinents.
- Les responsables internes des contacts avec les autorités, tels que le DPO, le RSSI, le juridique, le DG ou le responsable de la protection des données.
- Les canaux de communication approuvés.
- Les règles de revue juridique et d’approbation par la direction.
- Les exigences de conservation des éléments probants et de maîtrise de la divulgation.
- Les déclencheurs d’escalade liés aux violations, à NIS2, à DORA, aux clients ou aux sous-traitants.
Zenith Blueprint traite également la communication externe dans la phase ISMS Foundation and Leadership, étape 5, Communication, sensibilisation et compétence :
« Déterminez qui communique : il est probable que votre RSSI/responsable du SMSI gère les communications opérationnelles de sécurité avec les partenaires/clients (par exemple les réponses aux questionnaires d’audit de sécurité), tandis que la haute direction ou un responsable des relations publiques gère les déclarations publiques relatives aux incidents. Le conseil juridique peut intervenir dans la formulation des communications adressées aux régulateurs. »
Extrait de Zenith Blueprint, phase ISMS Foundation and Leadership, étape 5, clause 7.4, Communication externe.
Le DPO ou le responsable de la protection des données peut être responsable du fond, le juridique peut approuver la formulation, le RSSI peut fournir les éléments probants de sécurité et la direction générale peut approuver les positions sensibles. Le mode de défaillance survient lorsque ces rôles sont découverts pendant l’incident.
Cartographie croisée de conformité : lorsqu’une réclamation en matière de protection des données dépasse GDPR
Une réclamation en matière de protection des données peut rester une affaire strictement GDPR. Mais dès qu’elle allègue un accès non autorisé, une interruption de service, une compromission d’identifiants, un rançongiciel, une mauvaise configuration cloud ou une défaillance d’un sous-traitant, d’autres référentiels peuvent devenir pertinents.
GDPR s’applique largement aux responsables du traitement et aux sous-traitants établis dans l’UE, ainsi qu’aux organisations non établies dans l’UE qui offrent des biens ou services à des personnes dans l’UE ou surveillent leur comportement. Une entreprise SaaS située hors de l’UE peut donc être soumise à des obligations GDPR de traitement des réclamations et d’échange avec les autorités lorsqu’elle sert des utilisateurs de l’UE.
NIS2 peut s’appliquer lorsque l’organisation est une entité essentielle ou importante, notamment certaines infrastructures numériques, des fournisseurs de services d’informatique en nuage, des centres de données, des MSP, des MSSP, des infrastructures de marchés financiers, des fournisseurs numériques et d’autres secteurs. NIS2 Article 21 impose des mesures techniques, opérationnelles et organisationnelles de gestion des risques couvrant la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, la gestion des vulnérabilités, l’évaluation de l’efficacité, la formation, la cryptographie, le contrôle d’accès, la gestion des actifs et l’authentification. Article 23 introduit une notification par étapes des incidents significatifs, comprenant l’alerte précoce, la notification d’incident et le rapport de suivi. Si une réclamation en matière de protection des données révèle un incident affectant la fourniture du service, une analyse NIS2 peut être nécessaire.
DORA s’applique à de nombreuses entités financières et crée, à compter du 17 janvier 2025, un cadre spécifique de résilience opérationnelle numérique. Il couvre la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience, le partage d’informations sur les menaces, le risque lié aux prestataires tiers TIC et la supervision. Articles 17 à 20 exigent un processus de gestion des incidents liés aux TIC, une classification, une escalade vers la direction, une communication aux clients et une notification réglementaire. Si une réclamation en matière de protection des données dans une fintech allègue une perte de données, une compromission d’accès ou une défaillance d’un prestataire tiers de services TIC, le processus d’incident DORA peut s’exécuter en parallèle de l’évaluation GDPR.
NIST CSF 2.0 fournit une couche pratique de gouvernance. Sa fonction GOVERN attend que les obligations légales, réglementaires, contractuelles, relatives à la vie privée et aux libertés civiles soient comprises et gérées. Ses fonctions RESPOND et RECOVER soutiennent le triage, l’escalade, la communication avec les parties prenantes, la préservation des éléments probants, le confinement, l’éradication, le rétablissement et la documentation.
COBIT 19, dans une perspective d’audit et de gouvernance, s’intéresse à l’intégration du traitement des réclamations en matière de protection des données et des demandes des autorités dans les objectifs de gouvernance, les pratiques de gestion, la propriété du risque, la mesure de performance et l’assurance. Un évaluateur orienté COBIT demandera si le processus est défini, mesuré, contrôlé et amélioré.
| Référentiel | Pertinence pour la gouvernance des réclamations | Éléments probants attendus par les auditeurs ou autorités |
|---|---|---|
| GDPR | Droits, transparence, base légale, responsabilité, évaluation de violation, échange avec l’autorité de contrôle | Journaux des demandes, mentions, enregistrements de base légale, communications, justification de violation, éléments probants relatifs aux sous-traitants |
| ISO/IEC 27701:2025 | Rôles PIMS, obligations de responsable du traitement et de sous-traitant relatives aux informations à caractère personnel, éléments probants, surveillance, amélioration | Domaine d’application du PIMS, procédures, REG06, REG12, attributions de rôles, actions correctives |
| ISO/IEC 27001:2022 | Système de management, traitement des risques, informations documentées, maîtrise opérationnelle | Domaine d’application du SMSI, appréciation des risques, Déclaration d’applicabilité, enregistrements d’incident et d’éléments probants |
| ISO/IEC 27002:2022 | Contact avec les autorités, exigences légales, protection de la vie privée, signalement des événements, réponse aux incidents | Matrice de contact, registre juridique, rapports d’événements, plans d’incident, mesures de protection des informations à caractère personnel |
| NIS2 | Gouvernance des incidents significatifs pour les entités essentielles et importantes relevant du champ d’application | Classification d’incident, rapports par étapes, approbation par la direction, communications aux destinataires du service |
| DORA | Gouvernance des incidents TIC, de la résilience, des tiers et de la communication client pour les entités financières | Registre des incidents, classification, rapports aux autorités, registre des tiers, éléments probants de tests et de remédiation |
| NIST CSF 2.0 | Gouvernance, réponse, rétablissement, risque fournisseur, gestion des obligations légales | Profils actuel et cible, plans d’action, rôles, éléments probants de réponse, suivi des améliorations |
| COBIT 19 | Système de gouvernance, capacité des processus, assurance et performance | RACI, indicateurs de processus, éléments probants de contrôle, résultats d’assurance, reporting à la direction |
Exemple pratique : une demande d’autorité adressée à un fournisseur SaaS
Prenons le cas d’un fournisseur SaaS agissant à la fois comme sous-traitant pour ses clients entreprises et comme responsable du traitement pour ses propres données de gestion de compte. Un utilisateur se plaint que sa demande d’effacement a été ignorée et que ses données à caractère personnel restent visibles dans des exports analytiques. L’autorité de contrôle demande des éléments probants dans un délai défini.
Une réponse alignée sur Clarysec fonctionnerait comme suit.
Premièrement, le responsable de la protection des données ouvre ou met à jour l’enregistrement REG06 dans les deux jours ouvrés. L’événement est classifié comme une escalade de demande d’exercice des droits, une réclamation en matière de protection des données, un dossier d’autorité de contrôle et un problème potentiel lié à un sous-traitant. L’enregistrement inclut la date de réception, le statut de vérification de l’identité du demandeur, les systèmes affectés, le rôle de responsable du traitement ou de sous-traitant, et l’échéance initiale.
Deuxièmement, le responsable de la protection des données vérifie si la mention d’information contenait le bon canal de demande d’exercice des droits et de réclamation. Si le canal était obsolète, ce point est consigné comme action corrective potentielle et lié à REG07.
Troisièmement, le DPO ou le responsable de la protection des données détermine le contexte de rôle. Pour les données de compte dont le fournisseur SaaS détermine les finalités et les moyens, il agit comme responsable du traitement. Pour les enregistrements utilisateurs téléversés par les clients, il peut agir comme sous-traitant et doit suivre les instructions documentées du responsable du traitement. Si un sous-traitant ultérieur ou un fournisseur d’analytique est impliqué, le circuit des éléments probants fournisseur et sous-traitant est ouvert.
Quatrièmement, le juridique et le DPO préparent le plan de réponse à l’autorité. Au titre de la Politique de conformité juridique et réglementaire, les déclarations aux régulateurs sont préapprouvées et les échéances de réponse sont suivies. Au titre de la PIMS Documented Information and Evidence Management Policy, REG12 enregistre l’approbation et le périmètre de divulgation avant toute transmission d’éléments probants.
Cinquièmement, le RSSI ou le responsable sécurité vérifie si la réclamation indique une divulgation non autorisée, une perte accidentelle ou un accès à des données à caractère personnel. Si c’est le cas, le processus d’incident est déclenché. Cela relie l’affaire aux mesures ISO/IEC 27002:2022 relatives au signalement des événements, à la planification des incidents, à la réponse, au traitement des éléments probants, à la journalisation, à la surveillance et aux exigences légales.
Sixièmement, le dossier d’éléments probants est constitué. Il peut inclure l’enregistrement REG06, la version de la mention d’information, l’accusé de réception DSR, les étapes de validation, la justification de l’exécution de la demande ou du refus, les journaux des tâches d’effacement, la règle de conservation, l’enregistrement des instructions du sous-traitant, la configuration des exports analytiques, les journaux des accès, la DPIA, les clauses contractuelles fournisseur et les actions correctives.
Septièmement, la clôture ne se limite pas à l’envoi de la réponse. Le responsable de la protection des données enregistre la communication finale avec l’autorité, met à jour REG06 avec le résultat, consigne la divulgation approuvée dans REG12 et ouvre des actions correctives pour toute cause racine : canal de mention obsolète, défaut du flux d’effacement, incohérence de conservation analytique, ambiguïté des instructions au sous-traitant ou lacune de formation de l’équipe support.
Cela transforme une demande d’autorité stressante en un flux de travail PIMS auditable et reproductible.
Le regard de l’auditeur : comment la même réclamation est testée
Un dossier de réclamation en matière de protection des données est l’un des échantillons d’audit les plus révélateurs, car il traverse les politiques, les opérations, les éléments probants, la conformité juridique, la sécurité et la revue de direction.
Un auditeur PIMS ISO/IEC 27701:2025 suivra le cycle de vie des informations à caractère personnel. Il demandera comment la demande a été reçue, si l’organisation a correctement identifié son rôle PIMS, si le processus d’exercice des droits a été suivi, si les circuits de réclamation et d’escalade étaient disponibles, si les communications ont été enregistrées et si les thèmes récurrents ont alimenté l’amélioration continue.
Un auditeur ISO/IEC 27001:2022 examinera la discipline du système de management. Il testera si l’organisation a identifié les exigences légales et contractuelles, attribué les rôles, maîtrisé les informations documentées, apprécié les risques, sélectionné les mesures, exploité les processus d’incident et de gestion des éléments probants, et revu la performance. L’auditeur peut tracer la réclamation vers le registre des risques, la Déclaration d’applicabilité, les enregistrements d’incident et le plan d’actions correctives.
Une autorité de contrôle GDPR sera plus directe : montrez l’enregistrement, montrez la décision, montrez l’échéance, montrez la communication, montrez les éléments probants, montrez l’action corrective.
Un évaluateur NIS2 ou DORA cherchera à déterminer si l’événement a été correctement classifié, si les délais de notification ont été évalués, si la direction a été informée, si des prestataires tiers de services TIC étaient impliqués et si les communications aux clients ou aux destinataires du service ont été traitées de manière appropriée.
Un auditeur COBIT 19 ou de type ISACA se concentrera sur la gouvernance et l’assurance. Il demandera si la responsabilité du processus est définie, si les rôles sont séparés, si des indicateurs de performance existent, si la direction reçoit un reporting, si les exceptions sont approuvées et si le processus de réclamation est surveillé au regard de sa maturité et de son efficacité.
| Auditeur ou autorité | Priorité principale | Principaux éléments probants demandés |
|---|---|---|
| Auditeur ISO/IEC 27001:2022 et ISO/IEC 27701:2025 | Conformité du processus et discipline du système de management | Politiques, REG06, REG12, journaux d’escalade, comptes rendus de revue de direction, actions correctives |
| Autorité de contrôle GDPR | Responsabilité et droits des personnes concernées | RoPA, DPIA, enregistrement de réclamation, correspondance, base légale, justification de la décision |
| Évaluateur NIS2 ou DORA | Résilience, classification, notification et supervision par la direction | Classification d’incident, horodatages de notification, rapports finaux, analyse de la cause racine, éléments probants de management |
| Évaluateur COBIT 19 | Gouvernance, capacité des processus, performance et assurance | RACI, indicateurs de processus, approbations d’exceptions, résultats d’assurance, reporting à la direction |
Zenith Blueprint traite les actions correctives dans la phase Audit, Review and Improvement, étape 29, Amélioration continue :
« Assurez-vous que chaque action corrective est spécifique, attribuable et limitée dans le temps. En pratique, vous créez un mini-projet pour chaque problème. »
Extrait de Zenith Blueprint, phase Audit, Review and Improvement, étape 29, Amélioration continue, actions correctives et enseignements tirés.
C’est exactement le niveau attendu après qu’une réclamation a révélé une faiblesse systémique. « Nous avons rappelé les consignes à l’équipe » suffit rarement. Une action corrective doit avoir un propriétaire, une date d’échéance, une cause racine, des éléments probants d’achèvement et un contrôle d’efficacité.
Liste de contrôle pratique pour les RSSI, DPO, responsables conformité et propriétaires métier
Utilisez cette liste de contrôle pour vérifier si votre organisation peut résister à une investigation déclenchée par une réclamation.
- Confirmer que les mentions d’information incluent les canaux à jour de demande d’exercice des droits et de contact pour les réclamations.
- Vérifier que REG06 ou un registre équivalent enregistre toutes les demandes d’exercice des droits, réclamations, escalades, résultats et communications.
- Définir quand les réclamations deviennent des incidents, des évaluations de violation, des affaires juridiques ou des dossiers d’autorité de contrôle.
- Attribuer les rôles de contact avec les autorités pour le DPO, le responsable de la protection des données, le juridique, le RSSI, le DG et l’approbateur exécutif.
- Maintenir une matrice de contact avec les autorités de contrôle par juridiction et par secteur.
- Exiger une approbation avant toute déclaration verbale ou écrite à une autorité.
- Suivre les échéances de réponse dans un registre d’éléments probants maîtrisé.
- Définir le périmètre de divulgation des éléments probants avant toute transmission externe d’enregistrements.
- Relier les dossiers de réclamation aux DPIA, aux enregistrements RoPA, aux accords avec les sous-traitants, aux règles de conservation et aux journaux de sécurité.
- Revoir chaque trimestre les thèmes récurrents des réclamations et enregistrer les actions correctives.
- Tester le processus au moyen d’un exercice sur table impliquant protection des données, juridique, sécurité, support et direction.
- Inclure les circuits d’escalade fournisseur et sous-traitant, en particulier pour le cloud, l’analytique, le support et les prestataires de services managés.
- Cartographier la gouvernance des réclamations avec la responsabilité au titre de GDPR, les mesures PIMS ISO/IEC 27701:2025, les exigences SMSI ISO/IEC 27001:2022 et les mesures ISO/IEC 27002:2022 relatives aux autorités et à la vie privée.
- Pour les secteurs relevant du champ d’application, ajouter les points de décision de notification d’incident NIS2 ou DORA.
L’analyse de rentabilité : la confiance de l’autorité se construit en amont
Les autorités de contrôle n’attendent pas la perfection. Elles attendent la maîtrise, la responsabilité et des éléments probants.
Une organisation bien gouvernée peut dire : voici quand nous avons reçu la réclamation, voici comment nous l’avons classifiée, voici le rôle que nous avons exercé, voici la mention que la personne a vue, voici le journal de la demande, voici les éléments probants relatifs au sous-traitant, voici l’évaluation de violation, voici la réponse approuvée à l’autorité et voici les actions correctives que nous avons ouvertes.
Cette posture change la discussion. Au lieu de paraître désorganisée ou évasive, l’organisation démontre que la gouvernance de la protection des données est intégrée au PIMS et au SMSI.
Pour les RSSI, cela réduit le risque qu’une réclamation en matière de protection des données devienne une investigation de sécurité non maîtrisée. Pour les DPO et les responsables de la protection des données, cela crée une responsabilité défendable. Pour les responsables conformité, cela produit des enregistrements compatibles avec les exigences d’audit. Pour les propriétaires métier, cela protège la confiance, réduit les frictions avec les autorités et rend les opérations de protection des données extensibles.
Prochaines étapes avec Clarysec
Si votre processus de traitement des réclamations en matière de protection des données dépend encore de la mémoire d’une boîte de réception, d’une revue juridique informelle ou d’une recherche manuelle d’éléments probants, il est temps de l’opérationnaliser.
Clarysec peut vous aider à construire un flux de travail prêt pour les autorités pour les réclamations en matière de protection des données et les demandes des autorités de contrôle, au moyen de :
- Politiques PIMS ISO/IEC 27701:2025 et procédures opérationnelles fondées sur les rôles.
- Modèles d’éléments probants REG06 et REG12 pour les demandes d’exercice des droits, les réclamations, les divulgations et les actions correctives.
- Matrices de responsabilités DPO, responsable de la protection des données, DG, juridique et RSSI.
- Guides opérationnels de contact avec les autorités basés sur Zenith Blueprint Zenith Blueprint.
- Cartographies croisées de conformité utilisant Zenith Controls Zenith Controls.
- Packs de politiques entreprise et PME, incluant Politique de protection des données et de la vie privée Politique de protection des données et de la vie privée, Politique de protection des données et de la vie privée PME Politique de protection des données et de la vie privée PME, Politique de conformité juridique et réglementaire Politique de conformité juridique et réglementaire, Politique de conformité juridique et réglementaire PME Politique de conformité juridique et réglementaire PME, PII Principal Rights Management Policy Politique de gestion des droits des personnes concernées, Privacy Notice and Transparency Policy Politique relative aux mentions d’information et à la transparence et PIMS Documented Information and Evidence Management Policy Politique de gestion des informations documentées et des éléments probants du PIMS.
Commencez par un scénario : une réclamation copiée à l’autorité de contrôle. Faites-la passer dans votre processus actuel. Si vous ne pouvez pas produire un dossier d’éléments probants complet sous 48 heures, la boîte à outils de Clarysec vous fournit la structure nécessaire pour combler cette lacune avant que l’autorité ne la demande.
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