Risques liés aux flux de données transfrontaliers

Une compagnie d'assurance établie au Royaume-Uni a transféré des données de sinistres de ses clients à un fournisseur d'analytique américain dans le cadre de clauses contractuelles types, le mécanisme approuvé pour transférer des données personnelles du Royaume-Uni vers des pays tiers ne bénéficiant pas d'une décision d'adéquation. Les CCT avaient été correctement signées, le fournisseur avait fourni une documentation appropriée sur les garanties, et le transfert de données était licitement autorisé. Ce que le dispositif SCC ne traitait pas, parce que la question n'avait pas été posée, c'était ce qu'il adviendrait des données une fois parvenues chez le fournisseur américain. Le fournisseur disposait d'une infrastructure AWS dans us-east-1 pour ses opérations principales, dans eu-west-1 pour le support des clients de l'UE et dans ap-southeast-1 pour les charges de travail analytiques Asie-Pacifique. Les données des clients arrivées dans le cadre du dispositif SCC du Royaume-Uni étaient régulièrement traitées par la charge de travail analytique exécutée à Singapour, pour des raisons de performance. Le traitement à Singapour n'était pas couvert par le dispositif SCC. La compagnie d'assurance avait licitement transféré des données vers les États-Unis. Les données avaient ensuite été déplacées vers Singapour sans aucun mécanisme de transfert.

Que recouvre réellement le problème des risques liés aux flux de données transfrontaliers ?

Le risque lié aux flux de données transfrontaliers apparaît lorsque des données personnelles circulent entre des juridictions dotées de normes de protection des données différentes, ce qui crée des obligations de conformité réglementaire à remplir pour chaque transfert. Le chapitre V du GDPR, le GDPR du Royaume-Uni et les cadres équivalents au Brésil, en Inde, en Chine et dans d'autres juridictions restreignent le transfert de données personnelles vers des pays qui n'offrent pas un niveau équivalent de protection des données, en l'absence d'un mécanisme de transfert approprié : décisions d'adéquation, clauses contractuelles types, règles d'entreprise contraignantes ou dérogations spécifiques. Ces mécanismes existent pour garantir que les droits des personnes en matière de protection des données accompagnent leurs données au-delà des frontières internationales.

Le problème des transferts ultérieurs est le point où la gouvernance des flux de données transfrontaliers échoue le plus systématiquement. Les mécanismes de transfert sont généralement établis pour le transfert direct de l'exportateur de données vers l'importateur de données, c'est-à-dire de l'organisation vers le fournisseur. Ils ne couvrent pas automatiquement les transferts que le fournisseur effectue ensuite vers des sous-traitants ultérieurs, des fournisseurs d'infrastructure ou des sites opérationnels situés dans d'autres juridictions. Un fournisseur qui reçoit des données dans le cadre d'un dispositif SCC valide, puis les traite chez un sous-traitant ultérieur situé dans une juridiction non couverte par les SCC, a créé au deuxième saut un transfert non autorisé que le mécanisme de transfert du premier saut ne traite pas. L'article 44 du GDPR indique clairement que la restriction des transferts s'applique à chaque transfert de la chaîne de traitement, et pas seulement au transfert initial du responsable du traitement vers le sous-traitant.

La géographie de l'infrastructure cloud ajoute une dimension particulièrement complexe à la gouvernance des flux de données transfrontaliers. Les architectures cloud modernes répartissent les charges de travail entre plusieurs régions pour des raisons de performance, de redondance et d'optimisation des coûts. Un fournisseur dont la région AWS principale est us-east-1 peut exécuter des charges de travail analytiques dans eu-west-1, sa reprise après sinistre dans ap-southeast-1, et assurer la diffusion de contenu via des sites périphériques dans des dizaines de pays. Chacun de ces sites peut traiter des données des clients dans le cadre des opérations normales. Le mécanisme de transfert signé pour la relation principale avec le fournisseur couvre le site principal. Chaque autre site par lequel transitent les données dans le cadre des opérations multirégions du fournisseur exige sa propre base juridique au titre des cadres applicables de restriction des transferts, une exigence de gouvernance rarement traitée de manière systématique.

Les risques liés aux flux de données transfrontaliers se concentrent autour de cinq types précis de défaillances de gouvernance :

Transferts ultérieurs vers des sous-traitants ultérieurs dans des pays tiers : le fournisseur transfère des données à des sous-traitants ultérieurs situés dans des juridictions non couvertes par le mécanisme de transfert d'origine, sans mettre en place de mécanismes de transfert appropriés pour chaque site de sous-traitant ultérieur
Traitement cloud multirégion sans mécanismes de transfert : l'infrastructure cloud du fournisseur répartit le traitement entre plusieurs régions, dont certaines traitent les données des clients sans que les mécanismes de transfert couvrent ces sites
Dégradation du mécanisme de transfert : recours à des mécanismes de transfert invalidés, modifiés ou remplacés sans mise à jour. L'arrêt Schrems II a invalidé le Privacy Shield, ce qui a imposé de le remplacer par des CCT ou d'autres mécanismes pour les transferts vers les États-Unis
Mécanisme de transfert ne couvrant pas le traitement réel : des CCT ou un équivalent couvrent la relation avec le fournisseur principal, alors que le traitement sensible réel a lieu dans un site d'un sous-traitant ultérieur qui ne relève pas du champ du mécanisme
Changement d'infrastructure sans revue de la gouvernance des transferts : migrations de l'infrastructure du fournisseur vers de nouvelles régions sans évaluer si elles créent de nouveaux transferts transfrontaliers nécessitant une autorisation

Pourquoi c’est important

La gouvernance des flux de données transfrontaliers est importante pour la TPRM, car les obligations réglementaires applicables aux transferts internationaux de données (CCT, règles d'entreprise contraignantes, décisions d'adéquation) relèvent de la responsabilité de l'exportateur de données, et non de l'importateur. Une organisation cliente qui transfère des données à un fournisseur dans le cadre d'un dispositif SCC est tenue de s'assurer que ce dispositif couvre tous les transferts que subiront les données au cours du traitement par le fournisseur, y compris les transferts ultérieurs vers des sous-traitants ultérieurs et des infrastructures situées dans d'autres juridictions. Si la charge de travail analytique du fournisseur à Singapour traite les données sans mécanisme de transfert couvrant Singapour, l'organisation cliente a créé un transfert non autorisé, même si le fournisseur a pris cette décision de traitement unilatéralement.

Le paysage des mesures d'application rend ce risque concret. Les autorités européennes de protection des données ont infligé de lourdes amendes pour des transferts transfrontaliers de données non autorisés, qu'il s'agisse non seulement du transfert initial sans garanties adéquates, mais aussi des transferts ultérieurs vers des sous-traitants ultérieurs établis dans des pays tiers qui n'étaient pas couverts par le mécanisme de transfert d'origine. L'arrêt Schrems II a explicitement relevé l'insuffisance de l'hypothèse selon laquelle les mécanismes de transfert couvrent toute la chaîne de traitement, et les mesures d'application ultérieures ont confirmé que les responsables du traitement sont tenus de cartographier et d'autoriser chaque transfert subi par leurs données.

Pour les professionnels de la TPRM, l'obligation pratique consiste à comprendre où vont les données, non seulement lors du transfert initial mais tout au long de la chaîne de traitement du fournisseur : quelles régions cloud, quels sous-traitants ultérieurs et quels sites opérationnels traitent les données dans le cadre du service contracté. Cela suppose de demander aux fournisseurs de cartographier l'ensemble de leur empreinte géographique de traitement, et pas seulement de confirmer où se trouve leur infrastructure principale.

Là où la plupart des équipes se trompent

La défaillance la plus constante consiste à considérer la signature d'un mécanisme de transfert comme l'aboutissement de la gouvernance des flux de données transfrontaliers. Un dispositif SCC signé confirme que le transfert initial du client vers le fournisseur est licitement autorisé. Il ne traite pas des transferts ultérieurs vers des sous-traitants ultérieurs, du traitement dans des régions cloud situées en dehors du site principal, ni des migrations d'infrastructure intervenant après la mise en place du mécanisme. La signature du mécanisme de transfert est le point de départ de la gouvernance transfrontalière, et non sa conclusion.

La deuxième défaillance consiste à ne pas interroger le fournisseur sur l'ensemble de son empreinte géographique de traitement : toutes les régions cloud, tous les sites des sous-traitants ultérieurs et tous les sites opérationnels qui touchent les données. La plupart des évaluations TPRM demandent où se trouve le centre de données ou la région cloud principale du fournisseur et s'en servent pour choisir le mécanisme de transfert. La géographie réelle des traitements du fournisseur peut être bien plus étendue, avec des charges de travail réparties entre plusieurs régions pour des raisons opérationnelles qui n'ont jamais été communiquées lors de l'évaluation du fournisseur.

Considérer la signature des SCC comme l'aboutissement de la gouvernance transfrontalière : le mécanisme de transfert initial ne couvre pas les transferts ultérieurs
Empreinte géographique complète des traitements non évaluée : le site du centre de données principal est connu, mais le traitement cloud multirégion et les sites des sous-traitants ultérieurs sont inconnus
Actualité du mécanisme de transfert non vérifiée : recours à des mécanismes susceptibles d'avoir été affectés par des évolutions réglementaires sans réexamen
Notification des migrations d'infrastructure non exigée : des fournisseurs peuvent migrer vers de nouvelles régions sans en informer leurs clients, créant ainsi de nouveaux transferts transfrontaliers sans autorisation
Sites des sous-traitants ultérieurs non évalués quant à la couverture des transferts : la géographie des sous-traitants ultérieurs n'est pas comparée à la couverture des mécanismes de transfert

À quoi ressemblent les bonnes pratiques

Les programmes matures de gouvernance des flux de données transfrontaliers tiennent à jour une carte complète des destinations géographiques des données des clients (site principal du fournisseur, régions cloud utilisées pour le traitement, sites des sous-traitants ultérieurs et sites opérationnels) et vérifient que des mécanismes de transfert appropriés couvrent chaque transfert figurant sur cette carte. Les mécanismes de transfert sont tenus à jour à mesure que les cadres réglementaires évoluent. Les changements d'infrastructure qui créent de nouveaux transferts transfrontaliers déclenchent une revue de gouvernance avant leur mise en œuvre.

Empreinte géographique complète des traitements documentée : toutes les régions cloud, tous les sites des sous-traitants ultérieurs et tous les sites opérationnels traitant des données des clients sont cartographiés, et la couverture par les mécanismes de transfert est vérifiée
Dispositions relatives aux transferts ultérieurs dans le DPA : le fournisseur est tenu de garantir des mécanismes de transfert appropriés pour tous les transferts ultérieurs vers des sous-traitants ultérieurs et des régions cloud
Notification des changements d'infrastructure avec revue de la gouvernance des transferts : le fournisseur est tenu d'informer le client avant toute migration d'infrastructure créant de nouveaux transferts transfrontaliers
Maintien à jour des mécanismes de transfert : réexamen périodique confirmant que les mécanismes de transfert reflètent les exigences réglementaires en vigueur et n'ont pas été affectés par des évolutions réglementaires
Confirmation des mécanismes de transfert des sous-traitants ultérieurs : tous les sous-traitants ultérieurs situés dans des pays tiers sont couverts par des mécanismes de transfert appropriés, et pas seulement mentionnés dans la liste des sous-traitants ultérieurs

Outils

La gouvernance des flux de données transfrontaliers exige des outils de cartographie de l'empreinte géographique des traitements et des outils de gestion de la confidentialité pour maintenir les mécanismes de transfert.

Cartographie des flux de données : OneTrust, TrustArc, Privado

Les plateformes de gestion de la confidentialité et des flux de données facilitent la cartographie des flux de données transfrontaliers, en identifiant tous les sites vers lesquels des données personnelles sont transférées et les mécanismes de transfert couvrant chaque flux. La fonction de cartographie des flux de données de OneTrust permet aux organisations de documenter la géographie des traitements des fournisseurs et d'associer des mécanismes de transfert à chaque flux identifié. Pour les professionnels de la TPRM, demander au fournisseur s'il peut fournir une carte de l'empreinte géographique de ses traitements couvrant toutes les régions et tous les sous-traitants ultérieurs constitue une demande documentaire précise qui fait apparaître toute la chaîne de transfert.

Géographie de l'infrastructure cloud : AWS Config, Azure Policy, GCP Asset Inventory

Les outils de gestion de la configuration cloud inventorient les régions cloud dans lesquelles les charges de travail d'une organisation ou d'un fournisseur sont déployées, ce qui apporte une confirmation technique de l'empreinte géographique des traitements qui complète les déclarations contractuelles. Pour les professionnels de la TPRM qui évaluent des fournisseurs hébergés dans le cloud, demander un inventaire des régions cloud en plus de la documentation des mécanismes de transfert apporte une confirmation, au niveau technique, de la portée géographique du traitement des données.

Clauses contractuelles types : CCT de l'UE (2021), IDTA du Royaume-Uni, APEC CBPR

Les cadres actuels de mécanismes de transfert comprennent les CCT de la Commission européenne de 2021 (qui remplacent les versions de 2010 invalidées par l'arrêt Schrems II), l'International Data Transfer Agreement du Royaume-Uni et les Cross-Border Privacy Rules de l'APEC pour les transferts en Asie-Pacifique. Pour les professionnels de la TPRM, confirmer que les mécanismes de transfert reposent sur les versions en vigueur, et non sur des mécanismes anciens qui ont été remplacés, constitue un contrôle précis de l'actualité de la gouvernance que la plupart des programmes n'effectuent pas systématiquement.

Enjeux de gouvernance

Le défi de gouvernance des flux de données transfrontaliers tient à leur nature dynamique. L'empreinte géographique de traitement d'un fournisseur évolue avec son infrastructure : de nouvelles régions cloud sont ajoutées pour des raisons de performance, les sous-traitants ultérieurs changent au gré de l'évolution des relations du fournisseur, et les migrations d'infrastructure déplacent les charges de travail d'un site à l'autre. Chaque changement peut créer de nouveaux transferts transfrontaliers nécessitant une autorisation. Un programme de gouvernance qui cartographie le paysage des transferts lors de l'intégration du fournisseur sans jamais le réexaminer s'écartera progressivement du paysage réel des transferts à mesure que l'infrastructure du fournisseur évoluera.

Pour les programmes de TPRM, la réponse pratique en matière de gouvernance consiste à combiner une cartographie initiale de l'empreinte géographique, des exigences de notification des changements d'infrastructure et une réévaluation périodique. L'empreinte géographique de traitement du fournisseur doit être documentée lors de l'intégration, mise à jour lorsque des changements d'infrastructure surviennent grâce au mécanisme de notification, et comparée à la réalité du moment à chaque cycle de réévaluation. L'actualité des mécanismes de transfert doit être confirmée à chaque cycle, avec des mises à jour exigées lorsque les cadres réglementaires changent.

Documenter l'empreinte géographique des traitements lors de l'intégration : toutes les régions cloud, tous les sites des sous-traitants ultérieurs et tous les sites opérationnels
Exiger une notification des changements d'infrastructure avant toute migration vers de nouvelles régions créant de nouveaux transferts transfrontaliers
Vérifier que le mécanisme de transfert est à jour à chaque réévaluation : versions en vigueur utilisées, évolutions réglementaires prises en compte
Confirmer la couverture des sous-traitants ultérieurs par des mécanismes de transfert : pas seulement la liste des sous-traitants ultérieurs, mais les mécanismes de transfert couvrant chaque sous-traitant ultérieur situé dans un pays tiers
Intégrer la géographie des traitements à la réponse aux incidents : la situation des transferts transfrontaliers est pertinente pour les obligations de notification des violations

Si vous êtes une petite équipe

Ajoutez à votre évaluation des transferts transfrontaliers une question qui va au-delà du mécanisme de transfert : en dehors de votre centre de données ou de votre région cloud principal, dans quels autres sites géographiques le traitement des données de nos clients a-t-il lieu, y compris les charges de travail analytiques, la reprise après sinistre, la diffusion de contenu et le traitement par des sous-traitants ultérieurs, et quels mécanismes de transfert couvrent chacun de ces sites ? Cette question cartographie toute la chaîne de transfert plutôt que le seul premier saut, et fera apparaître la réalité du traitement multirégion que la signature d'un mécanisme de transfert pour un site unique ne traite pas.

Demander l'empreinte géographique complète des traitements, et pas seulement le site principal
Ajouter des exigences de notification des changements d'infrastructure à votre DPA
Vérifier que le mécanisme de transfert est à jour : confirmer que les CCT de 2021 sont utilisées, et non les versions de 2010
Confirmer que les sites des sous-traitants ultérieurs sont couverts par des mécanismes de transfert, et pas seulement déclarés

Ce qu’il faut exiger

Demandez directement :

« Dans quels sites géographiques (régions cloud, centres de données et sites de sous-traitants ultérieurs) le traitement des données de nos clients a-t-il lieu, au-delà du site de votre infrastructure principale ? »

« Quels mécanismes de transfert couvrent chacun des sites où nos données sont traitées en dehors de notre juridiction, et pouvez-vous confirmer que tous les transferts ultérieurs vers des sous-traitants ultérieurs sont couverts par des mécanismes appropriés, et pas seulement mentionnés dans votre liste de sous-traitants ultérieurs ? »

« Quel est votre processus pour nous informer lorsque vous migrez votre infrastructure vers une nouvelle région ou ajoutez un sous-traitant ultérieur dans une nouvelle juridiction, créant ainsi de nouveaux transferts transfrontaliers impliquant nos données ? »

Preuves attendues

Carte de l'empreinte géographique des traitements : tous les sites où les données des clients sont traitées
Inventaire des mécanismes de transfert : type de mécanisme et version en vigueur pour chaque site de transfert
Confirmation des mécanismes de transfert des sous-traitants ultérieurs : pas seulement la liste, mais la couverture par un mécanisme
Documentation du processus de notification des changements d'infrastructure

Un fournisseur qui répond à la question sur l'empreinte géographique par « notre infrastructure principale se trouve dans us-east-1 » a confirmé un seul site. Demandez-lui quelles autres régions AWS, Azure ou GCP ses charges de travail utilisent et si l'une de ces régions traite des données des clients. Le site principal est celui auquel il pense. La charge de travail analytique à Singapour est celle à laquelle il ne pense pas.

Comment le prouver

Les restrictions de transfert des articles 44 à 49 du GDPR, le chapitre V du UK GDPR et les cadres équivalents créent des obligations pour chaque transfert de la chaîne de traitement. Les mesures d'application des autorités ont confirmé que les responsables du traitement sont tenus de cartographier et d'autoriser l'ensemble du paysage des transferts, et pas seulement le transfert initial. Démontrer sa diligence raisonnable exige de prouver que toute l'empreinte géographique des traitements a été évaluée et que tous les transferts ont été autorisés.

Documentation de l'empreinte géographique des traitements pour tous les fournisseurs soumis à des obligations en matière de transferts transfrontaliers
Inventaire des mécanismes de transfert avec confirmation de la version en vigueur
Preuves de la couverture des sous-traitants ultérieurs par un mécanisme de transfert
Registres de notification des changements d'infrastructure
Registres de réévaluation périodique du paysage des transferts

À retenir

Les SCC couvrent le transfert que vous avez autorisé. Elles couvrent la frontière à laquelle vous avez pensé. La charge de travail analytique du fournisseur à Singapour, son sous-traitant ultérieur dans l'UE, son infrastructure de diffusion en périphérie : chacun de ces éléments est une frontière que les données franchissent dans le cadre du traitement normal. Le GDPR s'applique à chaque transfert. Les SCC n'en couvrent qu'un. L'écart entre le mécanisme de transfert que vous avez signé et les transferts que subissent réellement les données, c'est le transfert non autorisé qu'une autorité de régulation risque de remarquer avant vous. Cartographier les destinations des données n'est pas un exercice ponctuel lors de l'intégration du fournisseur. C'est une obligation de gouvernance continue qui doit être maintenue à mesure que l'infrastructure du fournisseur évolue. Les SCC sont l'instrument. La carte est la gouvernance.