Transfert de données entre pays

1) Objectif et zone

Créer un modèle gérable et sécurisé des transferts transfrontaliers de données personnelles (PII) et des kits d'exploitation (KYC/AML, paiements, RG/SE, CRM/marketing, télémétrie des jeux, logs/ARM, analyse/DWH) en tenant compte des exigences des licences iGaming et des lois sur la protection des données de différentes juridictions. Le document complète les sections « Localisation des données », « Suppression et anonymisation », « RGPD : consentement », « DSAR ».

2) Concepts et principes de base

Transfert transfrontalier - tout accès/réplique/traitement en dehors de la juridiction « d'origine » de la personne/des données.
Adéquation/équivalence - Décisions de l'organisme de réglementation sur l'adéquation de la protection du pays bénéficiaire.
Arrangements contractuels - clauses contractuelles types, analogies locales, accords de dopage.
TIA (Transfer Impact Assessment) - évaluation des risques juridiques/techniques d'un transfert particulier.
Souveraineté/résidence - lieu de stockage et droit de contrôle local.

1. Local-first : si possible, nous le traitons localement ; dehors - minimum et selon les règles.

2. Minimisation : « exactement autant que nécessaire » ; de préférence les agrégats/pseudonymes.

3. Cryptographie et isolation : cryptage, clés dans la région, séparation control/data plane.

4. Probabilité : journal de chaque transmission, artefacts TIA et bases.

5. Fail-closed : pas de base ou TIA - pas de transmission.

3) Rôles et RACI

DPO/Tête de conformité (Owner) - Politiques, tolérances, TIA, exceptions. (A)

Légal - le choix du mécanisme de transfert, les contrats, les exigences locales. (R)

Sécurité/Infra - cryptage, KMS/HSM, périmètres réseau, audit. (R)

Data Platform/Analytics - de-PII/anonymisation, rapports fédérés/cohortes. (R)

Engineering/SRE - routage, tokenisation, contrôle des exportations. (R)

Vendor Manager - Registre des sous-processeurs, confirmation, offboarding. (R)

Audit interne - échantillons d'artefacts, CAPA. (C)

4) Carte de transfert de données

Source → destination (pays/nuage/fournisseur) → catégorie de données → objectif → base juridique → mécanisme de transfert → de protection (t/org) → durée de conservation → responsabilité.
Il est enregistré graphiquement pour : support/CS, analyse/reporting, frod/risk scors, fournisseurs de jeux et PSP, affiliations.

5) Mécanismes juridiques (cadre)

1. Décision d'adéquation (le cas échéant) : une voie simplifiée, mais des artefacts TIA et des contrats avec le vendeur sont toujours nécessaires.
2. Clauses contractuelles types/types et analogies locales : comprennent les annexes obligatoires (catégories, objectifs, mesures).
3. Binding/accords supplémentaires : clarifient les responsabilités des sous-traitants, notifient les demandes des organismes publics.
4. Exceptions légales : ponctuelles et rares (intérêts vitaux, exigence contractuelle) - pas pour l'exportation systémique.
5. Règles intragroupe : pour les holdings - outils d'entreprise avec contrôle.

6) Transfer Impact Assessment (TIA)

Occasion : nouveau fournisseur/pays, nouvel objectif, nouvelles catégories (biométrie, RG/SE), changement de mode clé ou d'itinéraire.

• Description de la transmission (données/volume/fréquence/participants).
• L'environnement juridique du pays bénéficiaire (risques d'accès des organismes publics, moyens juridiques de protection des sujets).
• Mesures techniques : cryptage, clés (BYOK/HYOK), pseudonymisation, split-processing.
• Mesures organisationnelles : NDA, formation, « need-to-know », journal, réponses aux demandes.
• Risque résiduel/décision : autoriser/modifier/interdire ; délai de révision.

Modèle de formulaire bref TIA : voir § 15C.

7) Mesures techniques et organisationnelles

7. 1 Cryptographie et clés

At rest: AES-256-GCM; in transit: TLS 1. 2+/mTLS; PFS.
KMS : BYOK (nous avons les clés), de préférence HYOK (les clés restent dans la région) ; segmentation par marché/tenants ; Vérification inaltérable des opérations relatives aux clés.
Crypto-shredding : pour les backups et les archives dans les délais.

7. 2 Minimisation et de l'identification

Pseudonyme avant exportation (token gateway), stockage de mapping séparément dans la région.
Agrégats, k-anonymat/Binning Date et geo, suppression des catégories rares.
IPI-free logi/ARM et server-side tagging avec remise à zéro des identifiants sans consentement.

7. 3 Isolation des plans

Plan de contrôle global sans PII ; data-plane avec PII localement.
Accès au PII via la couche proxy avec justification de la demande et journal.

7. 4 Demandes d'organismes publics

Boucle de réaction : vérification de la légalité, contestation, minimisation du volume, notification (si autorisée), inscription dans le registre des demandes.

8) Catégories de données et règles de transmission

9) Vendeurs et sous-traitants

Registre : Jura. personne, pays DC, sous-traitants, certifications, mécanismes de transmission, mode clé.
Contrats : DPA + SCC/équivalents, avis de changement de lieu/sous-traitement de ≥30 jours, droit d'audit/interrogateur, obligations de localisation des backups, SLA des incidents et DSAR.
Onbording/rhubarbe : TIA, pentest/certifications, test « sample transfer ».
Offboarding : exportation/suppression/crypto-shred + confirmation (evidence).

10) Backups, logs et analytiques

Becaps : dans la même région ; exportation à l'étranger - seulement sous forme cryptée + HYOK ; lorsque l'échéance est atteinte, crypto-shred.
Logi/ARM : PII-free par défaut ; sinon - stockage local, courte rétention.
Analysis/DWH : rapports mondiaux uniquement sur les agrégats/cohortes ; interdiction des identifiants bruts hors de la région.

11) Processus et événements

Le procès de part en part : la demande de la transmission → le contrôle du profil du marché → le choix du mécanisme → TIA → les coordinations → les mesures techniques → la mise en marche → le monitoring → les artefacts/audits.

• `xborder_transfer_requested/approved/denied`
• « transfer _ executed » (volume/temps/fournisseur)
• `key_accessed_for_transfer` (KMS audit)
• `gov_request_received/responded`
• `vendor_location_changed`
• `transfer_review_due`

12) Données et artefacts (modèle)

transfer_record {
id, market_from, market_to, vendor, purpose, lawful_basis,
mechanism{adequacy    scc    local_clause    exception}, tia_id,
data_classes[], pii{yes/no}, deidentification{pseudo    anon    none},
encryption{at_rest, in_transit, keys{scope: BYOK    HYOK, kms_region}},
executed_at_utc, volume{rows, mb}, retention_days, backups{region, crypto_shred:true},
approvals{legal, dpo, security}, status, evidence_uri(WORM)
}

tia {
id, date, countries_involved[], legal_risk_summary, gov_access_risk,
technical_measures[], organizational_measures[], residual_risk{low    med    high},
decision{allow    modify    deny}, review_at
}

13) KPI/KRI et dashboard

Taux de transfert X-Border (par cible/fournisseur/pays).
Coverage TIA (% des transmissions avec TIA à jour).
BYOK/HYOK Coverage (proportion de transmissions avec clés régionales).
Partager l'exportation anonymisée (% des exportations en agrégats/pseudonymes).
Vendor Location Drift (incidents de changement d'emplacement).
Gov Request Count et temps de réponse moyen.
Auditability Score (% des entrées avec un paquet complet d'artefacts).

14) Chèques-feuilles

A) Avant le début du transfert

• La nomination et l'objectif légitime sont confirmés.
• Mécanisme choisi (adéquation/contrat/analogique), TIA mis en œuvre.
• Pseudonymisation/anonymisation configurée ; le volume est minimisé.
• KMS/clés : BYOK/HYOK, journal inclus.
• Contrat avec le fournisseur : DPA + SCC/équivalent, avis de changement de DC/sous-traitants.
• Résidence des backups et crypto-shred dans le plan.

B) Dans les opérations

• Surveillance de 'vendor _ location _ changed' et alertes.
• Examen périodique de l'ATI et des mécanismes.
• Les DSAR/suppressions sont correctement appliquées dans le périmètre du destinataire (ou via l'anonymisation).
• Les logs de transmission et l'audit KMS sont disponibles pour l'audit.

C) Audit/améliorations

• Échantillons trimestriels de 'transfer _ record' par exhaustivité.
• ACPA sur les incidents/plaintes/découvertes réglementaires.
• Test « revoke access » chez le vendeur + confirmation de suppression.

15) Modèles (inserts rapides)

A) La clause « transfert transfrontalier »

B) Notification de la demande de l'organisme public

C) Bref TIA (one-pager)

16) un plan de mise en œuvre de 30 jours

Semaine 1

1. Approuver la politique de transmission transfrontalière, le RACI et les modèles TIA/DPA.
2. Créer une carte des flux actuels et un registre des fournisseurs/emplacements/clés.
3. Configurer KMS par marché (BYOK/HYOK), activer l'audit de clé immuable.

Semaine 2

4) Activer la pseudonymisation avant l'exportation et PII-free logi/ARM.
5) Démarrer le registre 'transfer _ record '/' tia' (WORM-artefacts).
6) Mettre à jour les contrats avec les fournisseurs critiques : emplacements, notifications, procédures offboarding.

Semaine 3

7) Pilote 2-3 flux (CS, rapports DWH) : Mesurer l'exportation anonymisée Partager, couverture BYOK.
8) Former Product/CS/BI/Legal sur les procédures de demande des organismes publics et les escalades.
9) Connectez alerte'vendor _ location _ changed '.

Semaine 4

10) Sortie complète ; le dashboard KPI/KRI et la revue trimestrielle TIA.
11) CAPA selon les découvertes ; plan v1. 1 - Analyse fédérale/diff. la confidentialité dans les rapports.
12) Test Offboarding One Vendor : Suppression/crypto-shred, confirmations.

17) Sections interconnectées

Localisation des données par juridiction

Suppression et anonymisation des données/Graphiques de stockage et de suppression

GDPR : Gestion du consentement/Politique de cookies et CMP

Privacy by Design / DSAR

Cryptage At Rest/In Transit, KMS/BYOK/HYOK

Dashboard Complience & Monitoring/Audit interne et externe