Gouvernance des accords de partage de données pour GDPR et ISO 27701

Il est 16 heures un mardi, et Sarah, RSSI d’une FinTech en forte croissance, examine un accord de partage de données transmis par un partenaire stratégique d’analytique fondée sur l’IA. Les équipes commerciales sont enthousiastes. Le partenaire promet une meilleure connaissance client, une personnalisation renforcée et une prévision plus rapide de l’attrition. Le service juridique reste prudent. L’accord contient de nombreuses formulations vagues, telles que « sécurité commercialement raisonnable », et ne dit presque rien sur les délais de réponse aux incidents, la gestion des droits des personnes concernées, la conservation, la suppression, les droits d’audit ou la planification de sortie.

Sarah identifie immédiatement le risque. Le partenaire agit-il comme sous-traitant, responsable du traitement indépendant ou responsable conjoint du traitement ? Qui valide la base juridique au titre de GDPR ? Si un client exerce son droit à l’effacement, quel processus garantit la suppression des données dans l’environnement du partenaire, les jeux de données dérivés et, le cas échéant, les chaînes de traitement d’entraînement IA ? Si le partenaire subit une violation de données, qui informe qui, à quel moment, et avec quels éléments de preuve ?

Il ne s’agit pas d’un mauvais contrat isolé. C’est le modèle opérationnel qui se dégrade.

Les entreprises SaaS, FinTech, healthtech, de services managés et de plateformes partagent aujourd’hui des données en continu au moyen d’interfaces de programmation (API), d’intégrations, de partenariats analytiques, d’outils de support, de plateformes cloud, d’affiliés, de demandes du secteur public et de services IA. Le discours commercial va souvent plus vite que la gouvernance. Un contrat est signé, une clé API est créée, et des données à caractère personnel commencent à circuler avant que la protection des données, la sécurité, les achats, l’ingénierie et le DPO se soient accordés sur les fondamentaux.

Au titre de GDPR, un accord de partage de données n’est pas seulement un acte juridique. Il constitue un élément de preuve relatif à la licéité, à la loyauté, à la transparence, à la limitation des finalités, à la minimisation des données, à la limitation de la conservation, à l’intégrité, à la confidentialité et à la responsabilité. Dans ISO/IEC 27701:2025, il devient un élément du système de management des informations relatives à la vie privée, ou PIMS, permettant à l’organisation de démontrer que les informations personnelles sont collectées, utilisées, divulguées, partagées, conservées, protégées et éliminées au moyen de processus gouvernés.

Clarysec traite la gouvernance du partage de données comme un système de contrôle interfonctionnel, et non comme un simple exercice de modèle contractuel. En utilisant le Zenith Blueprint, Zenith Controls et l’ensemble de politiques PIMS de Clarysec, les organisations peuvent passer d’une revue ponctuelle des accords à un cycle de vie auditable, reliant clauses juridiques, registres, décisions de risque, contrôles techniques et éléments probants de conformité.

Pourquoi les accords de partage de données échouent lors des audits réels

La plupart des organisations n’échouent pas parce qu’elles n’ont jamais rédigé de contrat. Elles échouent parce que le contrat est détaché de la réalité opérationnelle.

Un examinateur en protection des données demande le registre de partage de données. Le service juridique envoie l’accord signé. L’examinateur demande ensuite la base juridique, la finalité de divulgation, le rôle du destinataire, les catégories de PII, la règle de conservation, le lieu de traitement, la méthode de transfert, le routage des demandes des personnes concernées, les mesures techniques de protection et les éléments probants de revue. Soudain, l’accord signé n’est plus qu’une pièce du dossier.

GDPR Article 5 exige que le traitement des données à caractère personnel respecte les principes de licéité, loyauté, transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, ainsi qu’intégrité et confidentialité. Article 5(2) ajoute la responsabilité, c’est-à-dire l’obligation pour le responsable du traitement d’être en mesure de démontrer la conformité. Article 6 exige une base juridique valide. Article 9 élève le niveau d’exigence pour les catégories particulières de données à caractère personnel, notamment les données de santé, biométriques, génétiques, politiques, religieuses et autres catégories sensibles.

En pratique, un processus de gouvernance des accords de partage de données doit répondre aux questions suivantes avant tout partage externe récurrent :

• Qui est le destinataire, et quel est son rôle en matière de protection des données ?
• Quelles données à caractère personnel sont partagées, et pour quelle finalité ?
• Quelle base juridique fonde la divulgation ?
• La nouvelle finalité est-elle compatible avec la finalité initiale de collecte ?
• Les personnes concernées ont-elles été informées au moyen d’une notice d’information ou d’un autre mécanisme de transparence ?
• Quels registres, approbations et décisions de risque constituent les éléments de preuve du partage ?
• Comment les droits des personnes concernées sont-ils routés entre les parties ?
• Quelles obligations de conservation, de suppression, de restitution et de fin de relation s’appliquent ?
• Quelles garanties protègent le transfert, le stockage, l’accès, la journalisation, la divulgation ultérieure et l’auditabilité ?
• Que se passe-t-il si le partenaire modifie la finalité, la localisation, les sous-traitants ou les catégories de données ?

Le Zenith Blueprint, phase Controls in Action, Step 23, résume clairement la réalité d’audit :

Le fondement de ce contrôle est la connaissance des données. L’organisation doit savoir quelles PII elle collecte, où elles se trouvent, pourquoi elles sont traitées et qui peut y accéder. Sans ce socle, toute promesse en matière de protection des données est creuse. La classification et l’étiquetage (5.12–5.13) deviennent ici essentiels, car les PII ne peuvent pas être protégées si elles ne sont pas identifiées.

Si l’accord n’est pas relié à l’inventaire, à la classification, à la conservation, aux contrôles de sécurité et au processus d’exercice des droits, ce n’est pas de la gouvernance. C’est un document dans un référentiel.

Le partage de données n’est pas identique au traitement pour le compte d’un client

Une erreur fréquente consiste à traiter toute relation impliquant des données à caractère personnel avec un tiers comme un cas de sous-traitance. GDPR impose une analyse des rôles. Un sous-traitant agit pour le compte d’un responsable du traitement. Un responsable du traitement détermine les finalités et les moyens. Des responsables conjoints du traitement déterminent conjointement les finalités et les moyens. Certains destinataires sont des responsables du traitement indépendants recevant des données pour leurs propres finalités.

Cette distinction modifie le modèle d’accord.

Un accord avec un sous-traitant porte principalement sur les instructions documentées, la confidentialité, les sous-traitants ultérieurs, l’assistance, la sécurité, la notification des violations, la suppression ou la restitution, et l’appui à l’audit. Un accord de partage de données entre responsables du traitement met davantage l’accent sur la base juridique, la finalité, la transparence, l’indépendance du destinataire, les limites de divulgation ultérieure, la coordination des demandes des personnes concernées, la conservation, les mesures de sécurité et la répartition des responsabilités. Un accord entre responsables conjoints du traitement exige une répartition transparente des obligations et une clarification des décisions prises conjointement.

Les politiques PIMS de Clarysec font de cette classification un point de contrôle obligatoire. La politique Enterprise Politique de gestion des sous-traitants, sous-traitants ultérieurs et tiers en matière de protection des données indique :

[Les deux] Le responsable fournisseurs / achats DOIT classifier chaque relation avec un tiers en matière de protection des données comme responsable du traitement, responsable conjoint du traitement, sous-traitant, sous-traitant ultérieur ou autre relation avec un tiers dans REG08 avant l’approbation du contrat ou avant le début du traitement de PII, selon la première de ces échéances.

Pour les PME, le même principe est formulé plus simplement. La Politique de protection des données et de confidentialité - PME, exigences de gouvernance 5.2.2, exige :

Les contrats avec des tiers traitant des données à caractère personnel doivent inclure des clauses de protection des données et doivent être revus par le directeur général ou le conseil juridique.

La leçon est pratique : avant de rédiger les clauses, il faut classifier la relation. Le rôle détermine l’accord, les approbations, les garanties, les responsabilités et les éléments de preuve.

Le cycle de vie de la gouvernance du partage de données

Un workflow mature d’accord de partage de données doit ressembler à un processus métier contrôlé, et non à une escalade juridique d’urgence. Clarysec le met généralement en œuvre au moyen de sept points de contrôle connectés.

La politique Enterprise Politique de collecte, d’utilisation, de divulgation et de partage des PII rend explicite l’exigence côté responsable du traitement :

[Responsable du traitement] Le responsable fournisseurs / achats DOIT enregistrer l’identité du destinataire, son rôle, la finalité de divulgation, les catégories de PII, la fréquence de partage, le lieu de traitement et la source faisant autorité dans REG08 avant le début de tout partage externe récurrent.

REG08 est le registre des destinataires et des relations avec des tiers en matière de protection des données. Il ne doit pas être géré séparément de l’inventaire des traitements. La politique Enterprise Politique d’inventaire des traitements de PII et de base juridique exige :

[Les deux] Le responsable fournisseurs / achats DOIT vérifier que les entrées relatives aux destinataires externes, aux sous-traitants, aux sous-traitants ultérieurs et au partage de données dans REG02 sont alignées avec REG08 avant l’approbation de l’accord ou toute modification substantielle de la relation.

Cela ferme une lacune d’audit fréquente. REG02 peut indiquer « analytique produit pour amélioration interne », tandis que REG08 indique « partenaire analytique pour benchmarking ». Si la finalité, le destinataire, la base juridique, les catégories de données ou les règles de conservation ne sont pas alignés, l’organisation présente une défaillance de responsabilité.

Ce que tout accord de partage de données doit contenir

Un accord de partage de données au titre de GDPR et ISO 27701:2025 ne doit pas reposer sur des clauses génériques de confidentialité. Il doit refléter le flux de données réel, la classification des rôles, le profil de risque et les interfaces opérationnelles.

Le Zenith Blueprint, phase Controls in Action, Step 23, donne l’angle des accords fournisseurs :

Les domaines clés généralement traités dans les accords fournisseurs incluent :

✓ les obligations de confidentialité, notamment le périmètre, la durée et les restrictions de divulgation à des tiers ; ✓ les responsabilités de contrôle d’accès, par exemple qui peut accéder à vos données, comment les identifiants sont gérés et quelle surveillance est en place ; ✓ les mesures techniques et organisationnelles de protection des données, de chiffrement, de transmission sécurisée, de sauvegarde et les engagements de disponibilité ; ✓ les délais et protocoles de notification des incidents, souvent assortis de délais définis, par exemple « notifier sous 24 heures » ; ✓ le droit d’audit, notamment la fréquence, le périmètre et l’accès aux éléments probants pertinents, par exemple rapports de tests d’intrusion, SoA, certifications ; ✓ les contrôles des sous-traitants, imposant au fournisseur de répercuter des obligations de sécurité équivalentes à ses partenaires en aval ; ✓ les dispositions de fin de contrat, telles que la restitution ou la destruction des données, la récupération des actifs et la désactivation des comptes.

La gouvernance juridique d’entreprise renforce ce point. La Politique de conformité juridique et réglementaire, exigences de gouvernance 5.3.1.2, identifie les contrats impliquant :

des contrats impliquant le partage de données, les droits de propriété intellectuelle, les limitations de responsabilité ou les clauses d’audit.

Cela place la gouvernance du partage de données à l’intersection de la protection des données, du juridique, du risque commercial, de l’assurance des fournisseurs et des opérations de sécurité.

La classification et le transfert sécurisé sont le chaînon manquant

De nombreux échecs de partage de données commencent par une classification insuffisante. Si le responsable métier ne peut pas indiquer si le jeu de données est public, interne, confidentiel, restreint ou contient des PII réglementées, l’accord sera vague et les contrôles techniques seront incohérents.

La Politique de classification et d’étiquetage des données - PME de Clarysec indique :

Les accords de partage de données ou les accords de non-divulgation (NDA) doivent faire référence aux exigences de traitement liées à la classification.

Pour les environnements d’entreprise, la Politique de classification et d’étiquetage des données exige que certaines données :

ne puissent être partagées en externe que dans le cadre d’un NDA ou de garanties contractuelles équivalentes.

L’étiquette de classification doit apparaître dans l’accord ou l’annexe de sécurité. Si l’historique des tickets de support est classé Confidentiel et contient des PII, l’accord doit définir les destinataires autorisés, les méthodes de transfert approuvées, les lieux de stockage, les contrôles d’accès, la surveillance, les attentes de suppression et les éléments probants d’assurance.

Le Zenith Blueprint, phase Controls in Action, Step 22, explique le volet opérationnel du transfert d’informations :

Dans son principe, ce contrôle exige que l’organisation :

✓ définisse comment les informations peuvent être transférées, en interne comme en externe ; ✓ détermine les méthodes autorisées, par exemple courriel chiffré, portails sécurisés, SFTP, interfaces de programmation (API), remise physique avec chiffrement ; ✓ aligne les méthodes de transfert sur la classification de l’information, telle que définie en 5.12 et rendue visible via 5.13 ; ✓ et veille à ce que toutes les parties impliquées dans le transfert comprennent leurs rôles, responsabilités et obligations.

Pour les PME, la Politique de sécurité des tiers et des fournisseurs - PME exprime directement l’attente :

Toutes les données partagées avec les fournisseurs doivent être protégées par chiffrement et transmises au moyen de protocoles sécurisés, par exemple HTTPS ou SFTP.

La gouvernance fournisseur en entreprise ajoute davantage de précision. La Politique de sécurité des tiers et des fournisseurs exige des exigences de traitement des données comprenant :

des exigences de traitement des données, notamment le lieu de stockage, les contrôles d’accès et les clauses de restitution ou de destruction.

Ces exigences ne doivent pas être enfouies dans un questionnaire. Elles doivent constituer des clauses contractuelles opposables et être traçables jusqu’à REG08, à la configuration technique et aux éléments probants d’audit.

Exemple : approuver le partenaire d’analytique IA de Sarah

La FinTech de Sarah souhaite partager avec un partenaire d’analytique IA des identifiants clients pseudonymisés, des schémas de transactions, des métriques d’usage et des informations de niveau de support, à des fins de personnalisation et de prévision de l’attrition. Le partenaire peut combiner ces données avec ses modèles analytiques et restituer des insights à la FinTech.

Un workflow gouverné se présenterait comme suit.

Premièrement, le responsable fournisseurs ou achats crée l’entrée REG08. Le référent protection des données ou responsable du PIMS classifie la relation. Si le partenaire détermine les finalités analytiques et la conception du modèle au-delà des instructions de Sarah, le rôle peut être celui de responsable du traitement indépendant ou de responsable conjoint du traitement plutôt que de sous-traitant.

Deuxièmement, REG02 est rapproché. Si l’inventaire des traitements ne décrit que « l’analytique produit interne », il doit être mis à jour avant le début du partage externe. La base juridique doit être documentée et, si la finalité a changé, un test de compatibilité ou une analyse de l’intérêt légitime peut être nécessaire.

Troisièmement, le propriétaire des données applique la classification et la minimisation. Les domaines de messagerie administrateur peuvent ne pas être nécessaires. Les identifiants de compte peuvent être remplacés par des identifiants pseudonymes propres au partenaire. Le niveau de support ne peut être conservé que s’il est requis pour la finalité approuvée.

Quatrièmement, les équipes juridique, protection des données et sécurité négocient l’accord de partage de données et l’annexe de sécurité. L’accord interdit la ré-identification, restreint la divulgation ultérieure, définit la conservation, exige des éléments probants de suppression, précise les délais de notification des incidents, inclut des droits d’audit ou d’assurance, et définit les étapes de sortie.

Cinquièmement, la notice d’information et le workflow des demandes des personnes concernées sont mis à jour. La politique Enterprise Politique de gestion des droits des personnes concernées par les PII exige :

[Les deux] Le responsable fournisseurs / achats DOIT suivre dans REG08 l’accusé de réception par un tiers des notifications liées aux droits avant la clôture de la demande REG06 correspondante.

Pour les PME, la Politique de protection des données et de confidentialité - PME donne une attente pratique en matière de niveau de service :

Le coordinateur protection des données doit accuser réception des demandes dans un délai de 3 jours ouvrés et répondre dans un délai de 30 jours.

Enfin, l’ingénierie met l’accord en application. Les identifiants API sont limités au périmètre requis. Les transferts utilisent HTTPS. Les journaux enregistrent les extractions de données. Les alertes détectent les activités inhabituelles. Les accès sont revus. La conservation est automatisée lorsque cela est possible. L’accord devient un système de contrôle vivant, et non un PDF.

Cartographie croisée de conformité pour GDPR, ISO 27701, DORA, NIS2, NIST et COBIT 19

La gouvernance du partage de données ne relève presque jamais d’un seul référentiel. Elle touche à la responsabilité au titre de GDPR, aux opérations de protection des données d’ISO/IEC 27701:2025, aux exigences de système de management d’ISO/IEC 27001:2022, aux contrôles de sécurité d’ISO/IEC 27002:2022, au risque lié aux tiers de DORA, à la sécurité de la chaîne d’approvisionnement de NIS2, aux résultats NIST CSF 2.0 et aux attentes de gouvernance de COBIT 19.

ISO/IEC 27001:2022 clause 4.2 exige que les organisations comprennent les parties intéressées et leurs exigences pertinentes. Clause 5.1 exige que la direction intègre les exigences de sécurité de l’information dans les processus métier. Pour le partage de données, cela signifie que les dépendances partenaires, les exigences contractuelles, les obligations réglementaires et les décisions de risque doivent être intégrées au SMSI et au PIMS, et non rester en dehors.

Les contrôles ISO/IEC 27002:2022 les plus pertinents sont :

• 5.14 Transfert d’informations
• 5.20 Prise en compte de la sécurité de l’information dans les accords avec les fournisseurs
• 5.34 Protection de la vie privée et des informations personnellement identifiables (PII)

Zenith Controls aide les organisations à utiliser ces contrôles comme points d’ancrage de cartographie. Il relie ISO/IEC 27002:2022 contrôle 5.14 à la protection des données en transit et aux exigences contractuelles, notamment NIST CSF 2.0 PR.DS-02 et GV.SC-05, DORA Article 30(2)(d) et GDPR Article 46 lorsque des garanties de transfert international sont pertinentes. Il relie contrôle 5.20 à la gouvernance des accords fournisseurs, notamment NIS2 Article 21(2)(d) sur la sécurité de la chaîne d’approvisionnement et DORA Chapter V sur le risque lié aux prestataires tiers de services TIC. Il relie contrôle 5.34 à la protection des données et à la protection des PII, notamment GDPR Article 5(2) sur la responsabilité et des contrôles de soutien tels que le chiffrement, la suppression, la gestion des fournisseurs et la limitation des finalités.

L’objectif n’est pas de créer sept programmes de conformité. L’objectif est un seul cycle de vie gouverné du partage de données qui produit des éléments probants réutilisables.

Comment les auditeurs testeront vos accords de partage de données

Un processus de gouvernance solide doit résister à l’échantillonnage. Les auditeurs ne s’arrêteront pas à l’accord signé. Ils testeront le cycle de vie.

Un auditeur ISO/IEC 27001:2022 et ISO/IEC 27701:2025 demandera si le domaine d’application du SMSI et du PIMS inclut les partages externes, si l’appréciation des risques couvre la relation, si les contrôles ont été sélectionnés et opérés, et si la direction revoit les risques de protection des données et de sécurité liés aux tiers.

Un examinateur GDPR ou une autorité de contrôle se concentrera sur la responsabilité. Il demandera quelles données à caractère personnel ont été partagées, pourquoi, sur quelle base juridique, si les personnes concernées ont été informées, combien de temps les données ont été conservées, si des données relevant de catégories particulières étaient concernées, si les transferts internationaux ont été évalués, et si les demandes d’exercice des droits ont été routées et étayées par des éléments de preuve.

Un examinateur DORA, en particulier dans les services financiers, demandera si le dispositif soutient une fonction critique ou importante, s’il figure dans le registre contractuel TIC, si le contrat inclut l’assistance en cas d’incident, les droits d’audit, la localisation des données, les conditions de sous-traitance, les droits de résiliation et une planification de sortie testée.

Un évaluateur NIST CSF 2.0 recherchera les résultats GOVERN dans la gestion des risques fournisseurs, les résultats PROTECT dans les contrôles des données en transit, les résultats RESPOND dans les interfaces incident et les résultats RECOVER dans la planification de sortie et de continuité.

Un auditeur COBIT 19 ou de type ISACA se concentrera sur les droits de décision, l’appétence au risque, la réalisation des bénéfices, l’optimisation des ressources, les obligations de conformité, les indicateurs, les exceptions et l’amélioration continue.

Si votre équipe ne peut pas rassembler rapidement ces éléments probants, le processus dépend trop de la mémoire collective.

Pièges fréquents dans la gouvernance du partage de données

Clarysec observe régulièrement cinq schémas de défaillance.

Le premier consiste à confondre un accord de sous-traitance avec un accord de partage de données. Les clauses applicables aux sous-traitants ne résolvent pas la responsabilité entre responsables du traitement ni entre responsables conjoints du traitement.

Le deuxième est une hygiène insuffisante des registres. REG02 et REG08 divergent. La notice d’information fait référence de manière générale à des « partenaires commerciaux », mais l’inventaire des traitements ne contient aucune finalité de divulgation correspondante.

Le troisième est un mauvais routage des demandes des personnes concernées. Une personne concernée demande l’effacement, mais personne ne sait quels destinataires doivent être notifiés ni comment l’accusé de réception est suivi.

Le quatrième est un langage de sécurité générique. « Sécurité appropriée » ne suffit pas. L’accord doit préciser les méthodes de transfert, le chiffrement, les contrôles d’accès, la journalisation, le lieu de stockage, les délais d’incident, la suppression et l’assurance.

Le cinquième est l’oubli de la divulgation ultérieure. Les écosystèmes SaaS modernes comprennent des plateformes cloud, des services IA, des fournisseurs d’analytique, des outils de support, des prestataires managés, des affiliés et des organismes publics. La gouvernance du partage de données doit contrôler la divulgation en aval lorsqu’elle affecte la responsabilité.

La Politique de gestion des sous-traitants, sous-traitants ultérieurs et tiers en matière de protection des données capture l’articulation opérationnelle pour les relations avec les sous-traitants et sous-traitants ultérieurs :

[Les deux] Le responsable fournisseurs / achats DOIT s’assurer que les contrats de sous-traitants et de sous-traitants ultérieurs incluent l’assistance en matière de protection des données, l’assurance de sécurité, l’interface incident via PII15, la restitution ou la suppression via PII10, l’articulation des transferts via PII13 et la coopération en matière d’audit ou d’assurance avant approbation.

Même lorsque la relation est entre responsables du traitement, la logique de gouvernance reste utile : l’assistance en matière de protection des données, l’assurance de sécurité, l’interface incident, l’articulation des transferts, la restitution ou suppression, et la coopération d’audit doivent être conçues délibérément.

Liste de contrôle pratique pour votre prochain accord de partage de données

Utilisez cette liste de contrôle avant d’approuver un partage externe récurrent de données à caractère personnel.

• Confirmer le rôle du destinataire en matière de protection des données dans REG08.
• Confirmer l’alignement de REG02 et REG08 avant approbation.
• Documenter la finalité de divulgation et la base juridique.
• Vérifier si une nouvelle finalité exige un test de compatibilité.
• Identifier les catégories de PII, les catégories de personnes concernées et les données relevant de catégories particulières.
• Appliquer la minimisation des données et retirer les champs inutiles.
• Référencer les exigences de traitement liées à la classification dans l’accord.
• Définir les méthodes de transfert approuvées et les exigences de chiffrement.
• Préciser les attentes relatives au contrôle d’accès, à la journalisation, à la surveillance et au lieu de stockage.
• Répartir les responsabilités de transparence et les mises à jour des notices d’information.
• Définir le routage, l’accusé de réception, le suivi et les éléments probants de clôture des demandes des personnes concernées.
• Définir les éléments probants de conservation, de suppression, de restitution et de fin de relation.
• Restreindre la divulgation ultérieure et exiger une notification des changements.
• Inclure les délais de notification des incidents et les exigences de coopération.
• Inclure des droits d’audit, d’assurance ou de revue des éléments probants.
• Planifier la revue périodique et les déclencheurs de réévaluation.

Où Clarysec intervient

La valeur de Clarysec ne se limite pas aux modèles. Elle réside dans le lien entre politiques, registres, éléments de preuve, logique d’audit et cartographie croisée de conformité.

Le Zenith Blueprint fournit aux équipes de mise en œuvre une feuille de route en 30 étapes pour transformer les exigences de contrôle en pratiques opérationnelles. Pour le partage de données, Step 22 aide les équipes à concevoir des règles de transfert d’informations, tandis que Step 23 relie la protection des données, les accords fournisseurs, les exigences juridiques, la protection des PII et les obligations contractuelles.

Zenith Controls fournit la boussole de cartographie croisée de conformité. Pour ce sujet, il relie les contrôles ISO/IEC 27002:2022 5.34, 5.14 et 5.20 à l’histoire d’audit plus large : protection de la vie privée, transfert d’informations et gouvernance des accords fournisseurs. Il aide les RSSI, DPO, responsables conformité, équipes achats et auditeurs à parler le même langage lors de la cartographie des attentes GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 et COBIT 19.

L’ensemble de politiques PIMS de Clarysec fournit ensuite les règles opérationnelles : classifier les relations en matière de protection des données, maintenir les registres de traitements et de destinataires, vérifier l’alignement des registres, définir la base juridique, gérer les droits des personnes concernées, contrôler les clauses fournisseurs et tiers, appliquer les exigences de traitement liées à la classification et préserver les éléments de preuve.

Si votre organisation partage des données à caractère personnel avec des partenaires, plateformes, affiliés, organismes publics, fournisseurs d’analytique, services IA ou participants d’un écosystème SaaS, ne commencez pas par le contrat. Commencez par la gouvernance.

Utilisez Zenith Blueprint: An Auditor’s 30-Step Roadmap pour intégrer le partage de données dans votre plan de mise en œuvre du SMSI et du PIMS. Utilisez Zenith Controls: The Cross-Compliance Guide pour cartographier les contrôles ISO/IEC 27002:2022 5.34, 5.14 et 5.20 avec les attentes d’assurance de GDPR, NIS2, DORA, NIST et COBIT. Puis mettez en œuvre les politiques PIMS de Clarysec, notamment la Politique de collecte, d’utilisation, de divulgation et de partage des PII, la Politique d’inventaire des traitements de PII et de base juridique et la Politique de gestion des sous-traitants, sous-traitants ultérieurs et tiers en matière de protection des données, afin que chaque accord soit soutenu par des registres, des workflows, des garanties et des éléments de preuve.

L’action pratique suivante est simple : sélectionnez vos trois relations de partage externe de données les plus risquées et testez-les au regard de REG02, REG08, de la base juridique, du routage des demandes des personnes concernées, des contrôles de transfert, de la conservation et des éléments probants d’audit. Si la chaîne d’éléments probants se rompt, Clarysec peut vous aider à la reconstruire sous la forme d’un modèle de gouvernance du partage de données auditable.