Demandes de divulgation de données à caractère personnel au titre du GDPR et d’ISO 27701

La demande arrive à 16 h 47 un vendredi
Un responsable de la réussite client transfère un courriel au service juridique avec l’objet : « DEMANDE POLICE URGENTE ». En pièce jointe figure une lettre scannée demandant les informations du compte, l’historique de connexion, les adresses IP, les enregistrements de paiement et « toute autre information pertinente » concernant une personne nommément désignée. L’expéditeur affirme appartenir à une unité de lutte contre la cybercriminalité. Le courriel demande une divulgation sous 24 heures et indique que l’organisation ne doit « pas notifier la personne concernée ».
Au même moment, l’équipe des opérations de sécurité enquête sur une activité inhabituelle dans le même compte client. Le DPO se trouve dans un autre fuseau horaire. Le RSSI demande s’il s’agit d’un incident, d’une demande juridique, d’une divulgation au titre du GDPR, ou des trois à la fois. L’équipe commerciale veut « coopérer pleinement ». Le support veut savoir s’il peut exporter le profil client. Quelqu’un propose d’envoyer l’enregistrement CRM complet parce que « les autorités ont tout demandé ».
C’est là que se situe la faille de gouvernance.
La plupart des organisations disposent d’une politique de protection des données, d’un plan de réponse aux incidents et d’un processus pour les demandes d’exercice du droit d’accès. Beaucoup savent gérer les diligences fournisseurs, les échanges réglementaires et la notification des violations de données à caractère personnel. Beaucoup moins disposent d’un processus reproductible pour traiter les demandes officielles ou contraignantes de divulgation de données à caractère personnel émanant des autorités chargées de l’application de la loi, des autorités de contrôle, des tribunaux, des autorités fiscales, des superviseurs financiers, des régulateurs des télécommunications, des unités de lutte contre la cybercriminalité ou d’autorités publiques de pays tiers.
Cette faille est dangereuse. Répondre à une demande frauduleuse peut constituer une violation de données à caractère personnel. Refuser une demande légitime peut créer une exposition juridique. Répondre sans processus maîtrisé peut entraîner une divulgation excessive, une rupture de la chaîne de conservation, des délais manqués, des transferts internationaux illicites et un échec en audit.
Au titre du GDPR, d’ISO 27701:2025 et d’ISO/IEC 27001:2022, une demande officielle de divulgation de données à caractère personnel n’est pas simplement un sujet à traiter dans la boîte de réception du service juridique. Elle touche à la base légale, à la responsabilité au titre du GDPR, à la limitation des finalités, à la minimisation des données, à la confidentialité, à l’approbation fondée sur les rôles, à la gouvernance des transferts internationaux, aux instructions du responsable du traitement au sous-traitant, à la préservation des éléments de preuve, au transfert sécurisé et aux pistes d’audit.
Le test pratique est simple : lorsque la demande arrive, votre organisation peut-elle prouver qu’elle a validé le demandeur, évalué l’autorité juridique invoquée, minimisé la divulgation, obtenu les approbations appropriées, protégé les éléments de preuve, consigné la décision et conservé une piste auditable ?
La position de Clarysec est claire. Les demandes de divulgation de données à caractère personnel émanant des autorités chargées de l’application de la loi et des autorités de contrôle doivent être traitées comme un processus maîtrisé de protection des données et de sécurité de l’information, et non comme une réponse improvisée par courriel.
Pourquoi les demandes officielles de divulgation de données à caractère personnel sont différentes
Un dispositif habituel de partage externe de données commence généralement par une finalité métier. Un fournisseur a besoin des données des employés pour la paie. Un prestataire SaaS traite des identifiants clients. Un partenaire reçoit des données de transaction dans un cadre contractuel. Le schéma de gouvernance est connu : diligences préalables, accord de traitement des données, exigences de sécurité, évaluation du transfert, clauses de conservation et surveillance continue.
Les demandes de divulgation de données à caractère personnel émanant des autorités chargées de l’application de la loi et des autorités de contrôle sont différentes. Elles sont déclenchées par un événement, soumises à des délais courts, souvent confidentielles et parfois juridiquement contraignantes. Elles peuvent arriver en dehors des canaux d’achat ou de gestion fournisseurs. Elles peuvent demander de larges catégories de données à caractère personnel. Elles peuvent interdire toute notification. Elles peuvent impliquer des autorités étrangères. Elles peuvent arriver pendant un incident, une enquête sur une fraude, un gel légal, un examen réglementaire ou une enquête de cybercriminalité.
Cela crée trois exigences immédiates de gouvernance.
Premièrement, l’organisation doit savoir qui est habilité à répondre. Un employé en première ligne ne doit pas décider si une demande de la police est valable, si la formulation d’une autorité de contrôle est contraignante, ou si la notification du client est interdite.
Deuxièmement, la coopération doit être distinguée de la divulgation excessive. Le GDPR n’empêche pas une coopération licite avec les autorités, mais il exige toujours une base légale valable, la loyauté, la transparence lorsqu’elle s’applique, la limitation des finalités, la minimisation des données, l’intégrité, la confidentialité et la responsabilité.
Troisièmement, les éléments de preuve doivent être préservés. Si la demande se rapporte à un incident, à un événement de fraude, à un litige ou à une enquête d’une autorité de contrôle, supprimer des journaux, modifier des enregistrements ou exporter des données sans traçabilité peut compromettre à la fois la conformité et la défendabilité juridique.
Le modèle opérationnel le plus robuste relie dans un même processus la gouvernance de la protection des données, l’approbation juridique, la gestion des éléments de preuve, la réponse aux incidents, la transmission sécurisée et le contact avec les autorités.
Le groupe de contrôles Clarysec : autorités, protection des données et éléments de preuve
Dans Zenith Controls : le guide de conformité croisée, Clarysec traite la gouvernance des divulgations aux autorités chargées de l’application de la loi et aux autorités de contrôle comme un groupe de contrôles connecté, et non comme une tâche isolée de protection des données. Les contrôles ISO/IEC 27002:2022 centraux sont 5.5 Contact avec les autorités, 5.28 Collecte des éléments de preuve et 5.34 Protection de la vie privée et des données à caractère personnel. Les relations de contrôle associées couvrent notamment la classification et l’étiquetage, le contrôle d’accès, les relations fournisseurs, la gestion des incidents, la journalisation, la synchronisation des horloges, la cryptographie, le masquage, la suppression et le transfert d’informations.
C’est important, car les demandes officielles de divulgation peuvent échouer à plusieurs niveaux. Une équipe protection des données peut valider la base légale mais omettre de préserver les éléments de preuve. Un SOC peut préserver les journaux mais divulguer trop de données à caractère personnel. Le service juridique peut approuver une réponse mais oublier de mettre à jour le registre de divulgation. Un sous-traitant peut répondre directement à une autorité alors qu’il aurait dû réorienter la demande vers le responsable du traitement.
Le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs renforce ce lien opérationnel dans la phase Controls in Action, étape 22, sous Contact avec les autorités :
Le contrôle 5.5 garantit qu’une organisation est prête à interagir avec les autorités externes lorsque cela est nécessaire, non pas de manière réactive ou dans la panique, mais au moyen de canaux prédéfinis, structurés et bien compris.
La même section cadre les questions auxquelles il faut répondre avant qu’une demande réelle n’arrive :
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 enquête, qui prendrait contact avec les autorités ? Comment saurait-elle quoi dire ? Dans quelles conditions ce contact serait-il initié ? Ces questions doivent être résolues à l’avance, et non après coup.
Pour la protection des données à caractère personnel, Zenith Blueprint, dans la phase Controls in Action, étape 23, présente la protection des données comme une obligation couvrant tout le cycle de vie :
Le contrôle 5.34 exige des organisations qu’elles protègent la vie privée des personnes en mettant en œuvre des mesures appropriées pour le traitement des données à caractère personnel tout au long de leur cycle de vie.
Pour les éléments de preuve, la même phase et la même étape expliquent pourquoi une gestion informelle est risquée :
Le contrôle 5.28 reconnaît qu’après un incident, ce que vous pouvez prouver compte autant que ce qui s’est réellement produit.
Ensemble, ces trois principes définissent le modèle de gouvernance : savoir qui communique avec les autorités, protéger les données à caractère personnel tout au long du cycle de vie de la divulgation et préserver les éléments de preuve de manière défendable.
La lecture GDPR et ISO 27701:2025 des divulgations contraintes
ISO 27701:2025 renforce la nécessité d’une discipline propre au système de management de la protection des informations personnelles. Un PIMS doit définir la façon dont les responsables du traitement de données à caractère personnel et les sous-traitants de données à caractère personnel traitent les demandes officielles de divulgation, y compris la réception, la validation, la revue juridique, l’autorisation, l’enregistrement, la minimisation, la transmission sécurisée, la conservation et la revue après réponse.
Pour un responsable du traitement, la question centrale est de savoir si l’organisation détermine les finalités et les moyens du traitement et doit donc décider si et comment la divulgation est licite. Pour un sous-traitant, la question est de savoir s’il peut divulguer quoi que ce soit sans instruction du responsable du traitement, sauf obligation légale. Pour un sous-traitant ultérieur, les règles d’orientation et les obligations répercutées deviennent encore plus sensibles.
Le GDPR renforce les mêmes exigences opérationnelles. Une divulgation à une autorité publique reste un traitement. L’organisation a besoin d’une base légale au titre de l’Article 6, d’une finalité documentée, de mesures de sécurité appropriées, d’une minimisation des données au titre de l’Article 5(1)(c) et d’éléments probants de responsabilité au titre de l’Article 5(2). Dans de nombreux cas, la base légale sera l’Article 6(1)(c), c’est-à-dire un traitement nécessaire au respect d’une obligation légale, mais seulement après validation de la demande et de la juridiction par le service juridique.
Lorsque la demande provient d’une autorité publique d’un pays tiers, la gouvernance des transferts et la revue par le DPO deviennent essentielles. Lorsque la demande implique un sous-traitant, les règles contractuelles de notification et d’instruction doivent être vérifiées. Lorsque la demande se rapporte à un incident de cybersécurité, la réponse doit être alignée sur les exigences de gestion des incidents et de collecte des éléments de preuve.
L’ensemble de politiques Clarysec transforme ces exigences en règles opérationnelles.
La politique d’entreprise P17 Politique de protection des données et de la vie privée, clause 6.1.1, indique :
Tout traitement doit reposer sur une base juridique valable, par exemple le consentement, le contrat ou une obligation légale.
La même politique, clause 6.2.1, ajoute le principe de minimisation :
Seules les données nécessaires à une finalité métier spécifique et légitime peuvent être collectées et traitées.
Pour les PME, la P17S Politique de protection des données et de la vie privée - PME, clause 6.2.1, indique :
Seules les données à caractère personnel minimales nécessaires doivent être collectées et conservées.
Ces clauses sont essentielles lorsque la demande vise « toutes les informations », « l’historique complet » ou « tous les enregistrements associés ». La bonne réponse n’est pas d’exporter tous les champs. Elle consiste à valider la demande, à identifier le périmètre juridiquement requis, à divulguer uniquement les données à caractère personnel nécessaires, à documenter la décision et à conserver les éléments de preuve.
De la panique par courriel à une divulgation maîtrisée
Un processus mature doit être suffisamment simple pour être suivi par les employés en première ligne et suffisamment rigoureux pour les auditeurs, les autorités de contrôle et les tribunaux. Clarysec recommande un modèle en sept étapes.
| Étape | Objectif de contrôle | Responsable principal | Éléments de preuve créés |
|---|---|---|---|
| 1. Réception et mise en quarantaine | Empêcher une réponse informelle ou une divulgation accidentelle | Centre de services, réception juridique, responsable de la protection des données | Ticket de demande, message original, pièces jointes, horodatage |
| 2. Validation de l’authenticité | Confirmer l’identité du demandeur, son autorité, la juridiction et l’acte juridique | Juridique, DPO, conformité | Notes de validation, vérification du contact auprès de l’autorité, évaluation de la base légale |
| 3. Détermination du rôle | Déterminer si l’organisation agit en tant que responsable du traitement, sous-traitant, responsable conjoint du traitement ou sous-traitant ultérieur | Responsable de la protection des données, responsable du contrat | Évaluation du rôle PIMS, enregistrement de l’instruction du client si l’organisation est sous-traitant |
| 4. Minimisation du périmètre | Traduire la demande en catégories précises de données à caractère personnel et en plages de dates | Responsable de processus, sécurité, juridique | Extrait de cartographie des données, décision de minimisation, notes de caviardage |
| 5. Approbation | Garantir une décision autorisée avant toute divulgation | DPO, juridique, RSSI, responsable métier | Enregistrement d’approbation, enregistrement d’exception en cas d’urgence |
| 6. Divulgation sécurisée | Transmettre uniquement les données approuvées via des canaux maîtrisés | Sécurité, opérations juridiques | Journal de transfert, éléments probants de chiffrement, confirmation du destinataire |
| 7. Enregistrement et revue | Conserver les éléments probants de responsabilité et les enseignements tirés | Responsable du PIMS, conformité | Entrée REG08, REG09 ou REG12, piste d’audit, revue de clôture |
La première règle est l’orientation de la demande. Chaque employé doit savoir que les demandes officielles relatives aux données à caractère personnel doivent emprunter un circuit de réception défini. Personne ne doit répondre depuis une boîte aux lettres personnelle. Personne ne doit appeler le demandeur à un numéro de téléphone imprimé dans une lettre non vérifiée. Personne ne doit exporter des données client avant que les services juridique et protection des données aient examiné la demande.
La politique d’entreprise P30 Politique de réponse aux incidents, clause 6.5.5, soutient cette discipline d’orientation :
Toute interaction avec les autorités chargées de l’application de la loi ou des prestataires de services d’investigation numérique doit être coordonnée par l’équipe juridique et le RSSI.
Cette clause est particulièrement importante lorsque la demande de divulgation est liée à une fraude, à la cybercriminalité, à une compromission de compte, à un rançongiciel, à une menace interne ou à une enquête sur une violation de données. Les fonctions juridique et sécurité doivent se coordonner, et non travailler en parallèle.
La politique d’entreprise P37 Politique de conformité juridique et réglementaire, clause 7.3.1.2, encadre les déclarations externes :
Toute déclaration orale ou écrite adressée aux autorités de contrôle doit être préalablement approuvée.
La clause 7.3.1.3 ajoute une discipline relative aux délais et aux éléments de preuve :
Les délais de réponse doivent être suivis et les journaux des éléments de preuve tenus à jour.
Ces règles ne sont pas une friction bureaucratique. Elles préviennent les admissions accidentelles, les divulgations non maîtrisées, les délais manqués et les éléments de preuve insuffisants.
Discipline d’approbation et de registre : les éléments probants d’audit que la plupart des équipes oublient
Beaucoup d’organisations peuvent produire le courriel de demande initial. Beaucoup moins peuvent démontrer qui a approuvé la divulgation, quelle base légale a été utilisée, pourquoi certains champs ont été inclus ou exclus, comment le demandeur a été validé, si la personne concernée a été notifiée ou licitement non notifiée, et où la réponse a été consignée.
C’est ici que les registres PIMS de Clarysec deviennent centraux.
Pour les responsables du traitement, la politique d’entreprise PII09 Politique de collecte, d’utilisation, de divulgation et de partage des données à caractère personnel, clause 4.4.1, exige :
[Responsable du traitement] Le responsable de processus / responsable métier DOIT consigner dans REG08 le résultat de la revue du responsable de la protection des données / responsable du PIMS avant toute nouvelle divulgation externe ou tout nouveau dispositif de partage de données.
La clause 4.4.2 précise ce qui doit être capturé pour les partages récurrents :
[Responsable du traitement] Le responsable fournisseurs / achats DOIT consigner dans REG08 l’identité du destinataire, le rôle du destinataire, la finalité de la divulgation, les catégories de données à caractère personnel, la fréquence du partage, le lieu du traitement et la source d’autorité avant tout partage externe récurrent.
Pour les sous-traitants, la politique d’entreprise PII12 Politique de gestion de la protection des données applicable aux sous-traitants, sous-traitants ultérieurs et tiers, clause 4.5.3, prévoit une règle spécifique pour les demandes juridiquement contraignantes et les demandes autorisées par le client :
[Sous-traitant] Le responsable fournisseurs / achats DOIT consigner dans REG08 les demandes de divulgation émanant de tiers, les demandes de divulgation juridiquement contraignantes ou les demandes de divulgation autorisées par le client avant la divulgation, ou dans un délai de deux jours ouvrés lorsque l’enregistrement préalable n’est pas autorisé ou n’est pas opérationnellement possible.
Pour les demandes émanant d’autorités publiques de pays tiers, la politique d’entreprise PII13 Politique relative aux transferts internationaux de données à caractère personnel, clause 4.4.3, est plus spécifique :
[Les deux] Le responsable de la protection des données / responsable du PIMS DOIT consigner les demandes de divulgation émanant d’autorités publiques de pays tiers dans REG09 ou REG12 avant la divulgation lorsque cela est praticable, ou dans un délai d’un jour ouvré lorsque l’enregistrement préalable n’est pas praticable.
La clause 4.4.4 ajoute une discipline de revue :
[Les deux] Le délégué à la protection des données / conseiller en protection des données DOIT examiner les demandes de divulgation émanant d’autorités publiques de pays tiers présentant un enjeu significatif pour la vie privée dans REG09 ou REG12 avant la réponse lorsque cela est praticable.
Un registre de divulgation constitue la source unique de vérité de l’organisation. Il ne doit pas être remplacé par des courriels épars, des fils de discussion privés ou des feuilles de calcul ad hoc.
| Champ du registre | Ce qu’il démontre |
|---|---|
| ID de demande | La demande a fait l’objet d’un suivi unique |
| Source de la demande | L’autorité ou le demandeur a été identifié |
| Source de l’autorité juridique | L’acte juridique ou l’autorité invoquée a été évalué |
| Rôle PIMS | Les obligations de responsable du traitement, de sous-traitant, de responsable conjoint du traitement ou de sous-traitant ultérieur ont été prises en compte |
| Catégories de données à caractère personnel demandées | Le périmètre initial de la demande a été capturé |
| Catégories de données à caractère personnel approuvées | La divulgation finale a été maîtrisée |
| Données à caractère personnel exclues | La minimisation des données a été appliquée activement |
| Chaîne d’approbation | Les approbations juridique, DPO, RSSI et métier ont été consignées |
| Méthode de transmission | Des contrôles de transfert sécurisé ont été utilisés |
| Décision de notification | Les restrictions ou reports de transparence ont été examinés |
| Conservation et clôture | Les éléments de preuve ont été conservés et le dossier a été clôturé |
Exemple pratique : une demande d’autorité de contrôle dans REG08
Imaginons qu’une fintech réglementée reçoive une demande écrite d’un régulateur financier national sollicitant des données à caractère personnel liées à des transactions suspectes pour un client sur une période de 90 jours. La demande vise les enregistrements de vérification de l’identité, les journaux de transaction, les identifiants des appareils, les tickets de support et les notes internes de risque.
En utilisant la boîte à outils Clarysec, le responsable de la protection des données ouvre un enregistrement de divulgation REG08.
| Champ REG08 | Exemple d’entrée |
|---|---|
| ID de demande | REG08-2026-041 |
| Source de la demande | Régulateur financier national, vérifié via l’annuaire officiel des contacts de supervision |
| Type de demande | Demande de divulgation de données à caractère personnel émanant d’une autorité de contrôle |
| Rôle PIMS | Responsable du traitement |
| Source de l’autorité juridique | Demande d’information de supervision prévue par la loi, référence FIN-REQ-7781 |
| Objet | Enquête sur des transactions suspectes pour un client nommé |
| Catégories de données à caractère personnel demandées | Données de vérification de l’identité, journaux de transaction, identifiants d’appareils, communications de support, notes de risque |
| Catégories de données à caractère personnel approuvées | Journaux de transaction, identifiants d’appareils, champs pertinents de vérification de l’identité, deux tickets de support dans la plage de dates |
| Données à caractère personnel exclues | Historique de support sans lien, opinions d’analystes internes hors plage de dates, références à des clients tiers |
| Justification de la minimisation | Périmètre limité au client nommé, à la période de 90 jours et aux enregistrements pertinents pour les transactions identifiées dans la demande |
| Revue du DPO | Approuvée avec instructions de caviardage |
| Approbation juridique | Approuvée, formulation de la réponse revue |
| Revue du RSSI | Export sécurisé et méthode de transfert approuvés |
| Méthode de transmission | Archive chiffrée via le portail sécurisé du régulateur |
| Notification de la personne concernée | Reportée en raison d’une restriction légale figurant dans la demande, date de revue fixée |
| Conservation | Enregistrement de la demande et dossier de divulgation conservés selon le calendrier de gel légal |
| Éléments probants de clôture | Accusé de réception du portail, hachage du dossier de divulgation, chaîne d’approbation |
C’est la différence entre « nous nous sommes conformés » et « nous pouvons prouver que nous nous sommes conformés de manière licite et proportionnée ». Si le client dépose ultérieurement une réclamation, si l’autorité pose des questions complémentaires, ou si un auditeur échantillonne la divulgation, l’enregistrement montre la logique de gouvernance.
Préservation des éléments de preuve : ne pas détériorer les faits en voulant aider
Lorsqu’une demande émanant des autorités chargées de l’application de la loi ou d’une autorité de contrôle est liée à une enquête, la gouvernance de la protection des données recoupe l’analyse forensique et le gel légal. Les données divulguées constituent souvent des éléments de preuve, et leur collecte doit préserver leur intégrité.
La Politique de conformité juridique et réglementaire - PME, clause 6.4.1, pose le contexte :
En cas de litige, d’enquête ou de demande juridique :
La clause 6.4.1.2 donne une instruction claire :
Les employés ne doivent pas supprimer ni modifier les éléments susceptibles de faire partie d’une enquête.
La P31S Politique de collecte des éléments de preuve et d’investigation forensique - PME, clause 2.2.5, inclut explicitement :
Les demandes des autorités de contrôle ou des autorités chargées de l’application de la loi.
La clause 5.2.1 établit une discipline de journalisation :
Chaque élément de preuve numérique doit être consigné avec :
Sur le plan opérationnel, le journal des éléments de preuve doit capturer un identifiant unique, la date et l’heure de collecte, le nom du collecteur, l’emplacement source et une valeur de hachage cryptographique lorsque cela est approprié. L’objectif est la traçabilité. Si les journaux sont exportés manuellement, que les noms de fichiers sont modifiés, que les horodatages sont incertains ou qu’aucun hachage n’est conservé, l’organisation peut avoir des difficultés à démontrer l’intégrité par la suite.
Un processus robuste de gestion des éléments de preuve limite également les accès. Les dossiers de divulgation doivent être stockés dans des emplacements restreints, chiffrés en transit, suivis dans des journaux de transfert et conservés conformément aux exigences de gel légal et de conservation. Si une demande de divulgation recoupe une réponse aux incidents, l’équipe doit savoir quand passer d’un mode de remédiation à une posture d’investigation.
Cartographie croisée de conformité : un processus, plusieurs obligations
Un processus bien conçu pour les demandes de divulgation de données à caractère personnel peut satisfaire plusieurs référentiels sans dupliquer les travaux. Zenith Controls aide les organisations à cartographier les mêmes éléments probants opérationnels avec les attentes de protection des données, de cybersécurité, de résilience opérationnelle et de gouvernance.
| Référentiel | Ce qu’attend l’auditeur ou l’autorité de contrôle | Comment le processus Clarysec y répond |
|---|---|---|
| ISO 27701:2025 | Rôles PIMS, gouvernance des divulgations licites, instructions des sous-traitants, enregistrements des divulgations de données à caractère personnel, traitement des risques relatifs à la vie privée | Détermination du rôle, REG08, REG09, REG12, revue du DPO, justification de la minimisation |
| GDPR | Base légale, responsabilité, minimisation des données, sécurité, décisions de transparence, gouvernance des sous-traitants et des transferts | Évaluation de l’autorité juridique, chaîne d’approbation, dossier de divulgation limité, éléments probants de transfert sécurisé |
| ISO/IEC 27001:2022 et ISO/IEC 27002:2022 | Contact avec les autorités, collecte des éléments de preuve, protection des données à caractère personnel, contrôle d’accès, journalisation, cryptographie, suppression | Matrice des contacts avec les autorités, journal des éléments de preuve, export sécurisé, enregistrement de hachage, décision de conservation |
| NIS2 | Discipline de notification des incidents, coopération avec les autorités compétentes, responsabilité de gouvernance, connaissance de la chaîne d’approvisionnement | Coordination juridique et RSSI, délais de réponse, registre des contacts avec les autorités, lien avec l’incident |
| DORA | Gouvernance des incidents TIC des entités financières, interaction avec les autorités de contrôle, préparation des éléments de preuve, risque lié aux prestataires TIC tiers | Orientation des demandes des autorités de contrôle, enregistrements de divulgation sécurisée, préservation des éléments de preuve d’incident, interface fournisseur |
| NIST Cybersecurity Framework | Résultats de gouvernance, d’identification, de protection, de détection, de réponse et de rétablissement pour les événements de cybersécurité | Responsabilité de la politique, inventaire des données, contrôles d’accès, journalisation, processus de réponse, revue après réponse |
| COBIT 2019 | Objectifs de gouvernance relatifs à la conformité, au risque, à la sécurité, à la gestion de l’information et à l’assurance | Droits de décision, responsabilité des processus, enregistrements d’audit, supervision par la direction, amélioration continue |
Les normes ISO de support sont également pertinentes. ISO/IEC 27035 aide à structurer la gestion des incidents lorsque la demande est liée à un incident. ISO/IEC 27037 soutient l’identification, la collecte, l’acquisition et la préservation des éléments de preuve numériques. ISO/IEC 27018 est utile lorsque des sous-traitants de cloud public traitent des données à caractère personnel. ISO/IEC 27017 soutient les responsabilités de sécurité cloud. ISO 22301 devient pertinente si les obligations de contact avec les autorités et de divulgation doivent se poursuivre en situation de crise. ISO/IEC 27006-1:2024 est pertinente indirectement, car les auditeurs de certification attendent une mise en œuvre cohérente et auditable des contrôles du système de management dans le domaine d’application.
L’objectif n’est pas de construire un processus de conformité séparé pour chaque référentiel. Il s’agit de concevoir un processus défendable qui produit des éléments probants réutilisables.
Comment les différents auditeurs testeront le processus
Un auditeur ISO/IEC 27001:2022 commencera généralement par l’intégration au système de management. Il demandera si l’organisation a déterminé les parties intéressées, les exigences légales et réglementaires, les risques, les objectifs de contrôle, les procédures documentées, les responsabilités attribuées et les éléments de preuve conservés. Pour les demandes de divulgation, il pourra échantillonner des incidents, des échanges avec des autorités de contrôle, des listes de contacts avec les autorités, des journaux des éléments de preuve et des enregistrements de protection des données. Il testera probablement les contrôles de l’Annexe A A.5.5 Contact avec les autorités, A.5.28 Collecte des éléments de preuve et A.5.34 Protection de la vie privée et des données à caractère personnel.
Un évaluateur ISO 27701:2025 se concentrera sur la clarté des rôles PIMS. Étiez-vous responsable du traitement, sous-traitant, responsable conjoint du traitement ou sous-traitant ultérieur ? Si vous étiez responsable du traitement, où se trouvent la base légale et l’enregistrement de divulgation ? Si vous étiez sous-traitant, avez-vous agi sur instruction du responsable du traitement, sauf contrainte légale contraire ? Le client a-t-il été notifié lorsque c’était requis ou attendu contractuellement ? Les demandes émanant d’autorités publiques de pays tiers ont-elles été enregistrées et revues ?
Une autorité de contrôle au titre du GDPR se concentrera sur la responsabilité. La question ne sera pas seulement « aviez-vous une obligation légale ? ». Elle sera : « pourquoi cette quantité de données a-t-elle été divulguée, qui l’a approuvée, comment le demandeur a-t-il été validé, quelle sécurité a protégé le transfert, comment avez-vous évalué la transparence et où se trouve l’enregistrement ? »
Un évaluateur orienté NIST examinera la gouvernance et les résultats de réponse. Il demandera si les rôles ont été définis, si les journaux ont été préservés, si l’accès aux dossiers de divulgation a été restreint, si les activités de réponse ont été documentées et si les enseignements tirés ont amélioré le programme.
Un auditeur COBIT 2019 ou ISACA testera la gouvernance des droits de décision. Il pourra demander si la direction a défini le responsable du processus, si les responsabilités juridique, protection des données, sécurité et métier sont séparées, si les exceptions sont approuvées, si les indicateurs sont reportés et si l’assurance peut s’appuyer sur les éléments de preuve.
Une autorité de contrôle, un auditeur, un RSSI et un DPO peuvent tous lire le même enregistrement différemment. Un professionnel de la protection des données y voit un enregistrement de divulgation licite. Un auditeur sécurité y voit la préservation des éléments de preuve et le transfert sécurisé. Un auditeur gouvernance y voit la responsabilité et les droits de décision. L’organisation doit pouvoir leur répondre à tous à partir des mêmes éléments probants de contrôle.
Schémas d’échec fréquents
Clarysec observe régulièrement les mêmes défaillances évitables.
La première est le contact informel avec l’autorité. Un policier appelle le support, le support veut aider, et l’employé confirme oralement des informations de compte. Aucune validation, aucune approbation, aucun enregistrement.
La deuxième est la divulgation excessive. L’organisation envoie un dossier client complet au lieu des enregistrements précis et de la plage de dates requis. Cela crée un risque GDPR évitable et affaiblit la confiance.
La troisième est le dépassement de rôle du sous-traitant. Un prestataire SaaS reçoit une demande des autorités chargées de l’application de la loi concernant des données à caractère personnel contrôlées par le client et y répond sans notifier ni impliquer le client, alors même que le contrat et le rôle PIMS imposent une orientation de la demande, sauf interdiction légale.
La quatrième est l’absence de revue des demandes d’autorités étrangères. Une demande émanant d’une autorité publique non nationale est traitée comme une divulgation ordinaire, sans évaluation du transfert, revue du DPO ni entrée REG09 ou REG12.
La cinquième est une gestion insuffisante des éléments de preuve. Les journaux sont exportés manuellement, les horodatages sont incertains, les noms de fichiers sont modifiés, et aucun hachage ni enregistrement de chaîne de conservation n’existe.
La sixième est une confidentialité non maîtrisée. Trop d’employés sont mis en copie de la demande, y compris des personnes n’ayant pas besoin d’en connaître. Des détails sensibles de l’enquête se diffusent dans les canaux de messagerie instantanée.
La septième est la confusion sur les délais. L’organisation manque une date de réponse juridiquement significative parce que la demande reste dans une boîte aux lettres au lieu d’être gérée dans un processus suivi.
Chaque défaillance peut être évitée par des canaux prédéfinis, des registres, des approbations et des standards de gestion des éléments de preuve.
Rôles et droits de décision
Un modèle pratique de gouvernance définit les droits de décision avant l’arrivée de la première demande.
| Rôle | Responsabilité dans le processus de divulgation |
|---|---|
| Employé en première ligne | Transférer la demande vers le canal de réception approuvé, ne pas répondre sur le fond, ne pas divulguer de données à caractère personnel |
| Équipe juridique | Valider l’acte juridique, la juridiction, l’autorité, la restriction de confidentialité et la formulation de la réponse |
| DPO ou conseiller en protection des données | Évaluer les implications GDPR et ISO 27701:2025, la minimisation, la transparence, le rôle PIMS et les questions de transfert |
| RSSI | Approuver la collecte sécurisée des éléments de preuve, l’export sécurisé, la méthode de transfert et le lien avec un incident |
| Responsable de processus | Identifier les systèmes et catégories de données pertinents, confirmer le contexte métier |
| Responsable du PIMS | Tenir à jour REG08, REG09 ou REG12, suivre le résultat de la revue, conserver les éléments probants d’audit |
| Approbateur exécutif | Approuver les divulgations à haut risque, étrangères, stratégiques ou sensibles sur le plan réputationnel |
| Responsable fournisseurs ou achats | Coordonner les enregistrements de demande liés aux tiers ou aux sous-traitants et les obligations contractuelles |
Ce modèle doit être intégré à la formation de sensibilisation. Les employés n’ont pas besoin de connaître toutes les nuances juridiques, mais ils doivent connaître la règle : les demandes officielles passent par le canal défini, et les données à caractère personnel ne sont pas divulguées sans autorisation.
Liste de contrôle de préparation pour votre prochain exercice sur table
Utilisez cette liste de contrôle dans un atelier de gouvernance de la protection des données, un audit interne ou un exercice sur table.
- Disposons-nous d’un canal unique de réception pour les demandes de divulgation de données à caractère personnel émanant des autorités chargées de l’application de la loi et des autorités de contrôle ?
- Les employés savent-ils qu’ils ne doivent pas répondre de manière informelle ?
- Validons-nous l’identité du demandeur au moyen de sources de contact indépendantes ?
- Distinguons-nous les demandes des autorités de contrôle, les décisions judiciaires, les demandes des autorités chargées de l’application de la loi, les demandes autorisées par le client et les demandes d’autorités publiques de pays tiers ?
- Déterminons-nous si nous sommes responsable du traitement, sous-traitant, responsable conjoint du traitement ou sous-traitant ultérieur avant de répondre ?
- Documentons-nous la base légale, l’autorité juridique, la juridiction et les restrictions de confidentialité ?
- Appliquons-nous la minimisation des données et caviardons-nous les données à caractère personnel sans lien ?
- Exigeons-nous une revue par le DPO ou le conseiller en protection des données pour les demandes présentant un enjeu significatif pour la vie privée ?
- Exigeons-nous une coordination entre le juridique et le RSSI lorsque des enjeux liés aux autorités chargées de l’application de la loi ou à l’analyse forensique sont présents ?
- Consignons-nous les divulgations du responsable du traitement dans REG08 ?
- Consignons-nous les demandes d’autorités publiques de pays tiers dans REG09 ou REG12 ?
- Suivons-nous les délais de réponse et tenons-nous à jour des journaux des éléments de preuve ?
- Préservons-nous les éléments potentiellement pertinents et empêchons-nous leur suppression ou leur modification ?
- Sécurisons-nous les dossiers de divulgation par le chiffrement, le contrôle d’accès et la journalisation des transferts ?
- Réalisons-nous une revue après réponse pour les demandes à haut risque ?
- Reportons-nous les indicateurs et les enseignements tirés à la direction ?
Si la réponse à l’une de ces questions est « nous gérons généralement cela par courriel », le processus n’est pas encore auditable.
Intégrer le processus au SMSI et au PIMS
Le meilleur modèle de gouvernance ne réside pas uniquement au service juridique. Il fait partie du SMSI et du PIMS.
Dans Zenith Blueprint, la phase ISMS Foundation & Leadership, étape 5, recommande de planifier la communication externe et d’identifier qui communique avec les autorités de contrôle, les clients, les partenaires et le public. Elle précise que le conseil juridique peut être impliqué dans la formulation des communications adressées aux autorités de contrôle. Ce principe s’applique directement aux demandes officielles de divulgation de données à caractère personnel.
La phase Controls in Action opérationnalise ensuite le processus par le contact avec les autorités, la protection des données à caractère personnel et la collecte des éléments de preuve. C’est pourquoi le guide en 30 étapes de Clarysec ne traite pas la protection des données, la sécurité et la conformité comme des flux de travail déconnectés. Une demande réelle traverse les trois domaines.
Pour les responsables métier, le bénéfice est une réduction du chaos. Pour les RSSI, le processus clarifie quand les éléments de preuve de sécurité peuvent être collectés, divulgués ou préservés. Pour les DPO, il crée une responsabilité démontrable au titre du GDPR et d’ISO 27701:2025. Pour les responsables conformité, il produit des registres et des pistes d’audit. Pour les auditeurs, il crée un chemin clair entre l’exigence de politique et les éléments probants opérationnels.
Prochaines étapes avec Clarysec
Une demande d’une autorité de contrôle ou des autorités chargées de l’application de la loi n’est pas le moment d’inventer votre processus de gouvernance de la protection des données. C’est le moment où ce processus est mis à l’épreuve.
Commencez par un exercice sur table. Utilisez une demande réaliste liée à la cybercriminalité, à une autorité de contrôle ou à une autorité publique d’un pays tiers. Demandez au service juridique, au DPO, au RSSI, au support et au responsable de processus concerné de parcourir la réception, la validation, la détermination du rôle, la minimisation, l’approbation, le transfert sécurisé, l’enregistrement dans les registres, la préservation des éléments de preuve et la revue de clôture.
Comparez ensuite vos réponses au modèle opérationnel de Clarysec :
- Utilisez Zenith Blueprint : feuille de route en 30 étapes pour auditeurs pour intégrer le contact avec les autorités, la communication externe, la protection des données à caractère personnel et la collecte des éléments de preuve à votre plan de mise en œuvre du SMSI et du PIMS.
- Utilisez Zenith Controls : le guide de conformité croisée pour cartographier les attentes d’ISO 27701:2025, du GDPR, d’ISO/IEC 27001:2022, d’ISO/IEC 27002:2022, de NIS2, de DORA, du NIST et de COBIT 2019 dans un récit de contrôle unique et auditable.
- Utilisez les politiques Clarysec relatives à la protection des données et de la vie privée, à la réponse aux incidents, à la conformité juridique et réglementaire, à la collecte des éléments de preuve et aux investigations forensiques, à la divulgation des données à caractère personnel, à la gestion des sous-traitants et aux transferts internationaux pour définir les règles de processus, les registres, les approbations et les exigences relatives aux éléments de preuve.
Clarysec aide les équipes à passer de la panique réactive à une exécution maîtrisée. Téléchargez les boîtes à outils Clarysec pertinentes, exécutez l’exercice sur table et planifiez une évaluation de la gouvernance des divulgations afin de vous assurer que votre prochaine réponse est licite, minimale, approuvée, consignée, sécurisée et auditable.
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