ISO 27701 : Gestion de la vie privée

1) Qu'est-ce que la norme ISO 27701 et pourquoi est-il iGaming-operator

ISO 27701 est un complément aux normes ISO 27001 et 27002 qui étend l'ISMS au PIMS (Privacy Information Management Systems).
Pour iGaming : conformité prouvable aux exigences de confidentialité (GDPR/UK GDPR/ePrivacy et j'en passe), travail accéléré avec les régulateurs/banques/partenaires KYC/PSP, réduction des risques d'amendes et simplification de la gestion du vendeur.

2) Zone et contexte PIMS

• Rôles et limites : dans quels processus vous - Controller, où - Processor ; quelles marques/régions/processus font partie de Scope.
• Catégories de données : enregistrement, paiements, KYC/AML/sanctions, événements comportementaux, signaux RG, sapport, marketing/SDK.
• Obligations légales : lois locales sur la vie privée, conditions de licence, contrats avec des partenaires.

Résultat : document PIMS Scope & Context + carte des parties prenantes.

3) Rôles et responsabilités principaux

4) Liaison ISO 27701 ↔ ISO 27001

ISMS (27001/27002) : base de sécurité (actifs, risques, contrôles).
PIMS (27701) : ajoute la politique de confidentialité, la légalité du traitement, les droits des sujets, le cycle de vie des données, les mécanismes contractuels et transfrontaliers.
SoA/Déclaration d'applicabilité : étendue par les contrôles PIMS privés.

5) Registre de traitement (RoPA) et carte de données

Pour chaque processus : finalité, base juridique, catégories de sujets/données, durée de conservation, destinataires/sous-traitants, géographie, TOMs, drapeau DPIA.

yaml process: account_registration controller_role: controller purpose: account creation and contract execution lawful_basis: contract data_categories: [PII_basic, contact, device_fingerprint]
recipients: [psp, kyc_provider]
retention: P + 5y # storage policy locations: [EU, UK]
toms: [mTLS, encryption_at_rest, RBAC+ABAC, MFA, masking]
dpia_required: false

6) Motifs et consentements légitimes (Lawful Basis & Consent)

Contract/Legal Obligation : paiements, KYC/AML, prévention de la fraude.
Legitimate Interest : analyse de base/sécurité (avec évaluation des intérêts et opt-out si nécessaire).
Consent : marketing, cookies/SDK à des fins inutiles, certains types de profilage.
Catégories spéciales : uniquement pour des motifs clairs et des mesures renforcées.

SMR/gestion du consentement : enregistrement de la version de la politique/bannière, granularité par objectif, probabilité de la révocation.

7) DPIA/PIA - Évaluation de l'impact sur la vie privée

Quand : nouvelle technologie, traitement à grande échelle, données sensibles, profilage systématique, transfrontalisation.
Contenu : description du traitement, nécessité et proportionnalité, risques pour les droits des sujets, mesures de réduction.
Sortie : décision (aller/finaliser/rejeter) + plan CAPA et contrôle des dates.

8) Droits des personnes concernées (DSAR)

Droits : accès, rectification, suppression, limitation, portabilité, opposition, refus de profilage/marketing.
SLA : confirmation rapide de la demande et exécution dans le délai réglementaire.
Flux d'exécution : obtention → vérification de l'identité → collecte des données → réponse/exécution → journal.

Interdiction des « décharges aveugles » : seulement à travers des vitrines masquées et des loges ; limitation des petits échantillons (privacy thresholds).

9) Minimisation, masquage et rétention

Minimisation des données : ne stocker que les données nécessaires aux fins ; Supprimer/anonymiser régulièrement les champs « morts ».
Masquage/pseudonyme : par défaut pour PII ; démasquage - JIT + 'purpose' + audit.
Matrice de rétention : durée de conservation par processus/catégorie, facteurs stop (juridiques), auto-suppression/archive.

10) Transferts transfrontaliers et sous-traitants

Mécanismes contractuels : DPA, SCCs/IDTA, DTIA (évaluation des transferts).
Localisation des données/clés : où sont physiquement les données/clés (KMS/HSM), politique WOOC/clés régionales.
Registre des sous-traitants : notification des modifications, droit d'opposition, niveau TOMs pas inférieur au nôtre.

11) Privacy by Design / by Default

Pendant la phase de conception : Data Protection Requirements dans PRD, modèle threat modeling avec menaces privées.
Dans la mise en œuvre : RLS/CLS, tokenization, cryptage, piles API minimales, télémétry sans PII.
Par défaut : les trackers facultatifs, les clés individuelles/neimspace per region/tenant sont désactivés.

12) Logging, probabilité et vérification PIMS

Логи (WORM+подпись): `READ_PII`, `EXPORT_DATA`, `PII_UNMASK`, `CONSENT_UPDATE`, `DSAR_`, `BREACH_`.
Reporting : statut RoPA, campagnes DPIA, DSAR SLA/backlog, remaniement, modifications vendoriennes, irrégularités/incidents.
Audit : annuellement (ou en cas de changement), vérification du Design/Operating Effectiveness des contrôles privés.

13) Métriques (KPI/KRI) PIMS

• DSAR on-time ≥ 95%
• Pertinence de la RoPA ≥ 98 %
• Couverture DPIA par objet à risque = 100 %
• Proportion de suppressions automatiques ≥ 95 %
• Taux d'inclusion du PMC (enregistrements de consentements enregistrés) = 100 %

• Accès à PII sans 'purpose' = 0
• Exportations/transferts non autorisés = 0
• Incidents/fuites notifiés après le délai = 0
• DPA/SCCs manquants pour la transmission active = 0

14) Intégration avec les contrôles existants

IGA/RBAC/ABAC/JIT/PAM : minimisation des droits et conditions d'accès contextuelles.
Politique des loges et pistes d'audit : Probabilité des actions avec PII.
TPRM et contrats : DPA/SCCs/DTIA, droits d'audit, avis SLA ≤ 72 h.
ISO 27001/ISMS : modèle de risque global, SoA et audits internes.
Incidents et fuites : playbook breach, salle de guerre conjointe avec les vendeurs.

15) Modèles d'artefacts (fragments)

15. 1 Politique de confidentialité (extrait interne)

yaml privacy_policy:
principles: [lawfulness, fairness, transparency, minimization, accuracy, storage_limitation, integrity_confidentiality, accountability]
roles: {controller: true, processor: true}
data_subject_rights: enabled consent_management: CMP_v2 retention_policy: matrix_ref:v1. 4

15. 2 Politique de démasquage

yaml pii_unmask:
allowed_roles: [aml_officer, dpo, fraud_analyst_jit]
approvals: [data_owner, privacy]
ttl_minutes: 30 logging: [PII_UNMASK, READ_PII]

15. 3 processus DSAR

yaml dsar:
intake_channels: [portal, email]
verification: kyc_level>=2 sla_days: 30 export_mechanism: curated_vitrines_only audit_events: [DSAR_OPEN, DSAR_VERIFY, DSAR_FULFILL, DSAR_CLOSE]

15. 4 Matrice de rétention (fragment)

yaml retention:
registration_logs: {basis: legal, period: "P5Y"}
marketing_events: {basis: consent, period: "P12M", on_withdraw: "delete"}
kyc_documents:   {basis: legal, period: "P5Y", storage: "vault_encrypted"}

16) SOP (procédures)

16. 1 Mise à jour de RoPA

1. L'initiateur de la modification (Product/Owner) → la carte de processus de → Legal/Privacy rhubarbe → Security TOMs → la publication et la version.

16. 2 Conduite de la DPIA

1. L'examen préalable des risques → le modèle de DPIA → la consultation du DPO → du CAPA → la décision et le contrôle des délais.

16. 3 DSAR

1. Accepter → vérifier → assembler et filtrer à travers les vitrines → réponse/exécution → loging et fermeture.

16. 4 Vendeurs/transmissions

1. Diligence raisonnable → DPA/SCCs/DTIA → registre des sous-processeurs → surveillance des modifications → offboarding et confirmation de la suppression.

17) RACI (agrandi)

18) Feuille de route pour la mise en œuvre (8-10 semaines)

Semaines 1 à 2 : Scope/contexte, rôles et RACI, inventaire des processus/données, brouillon RoPA et matrice de rétention.
Semaines 3 à 4 : Politique sur la protection de la vie privée, PMC/conseil-flow, processus DSAR, modèles DPIA, mise à jour DPA/SCC/DTIA avec les fournisseurs.
Semaines 5 à 6 : mise en œuvre de TOMs (masquage, RLS/CLS, JIT/PAM), vitrines pour DSAR, WORM logs, rapports KPI/KRI.
Semaines 7 à 8 : Mener une EIPD sur le risque élevé, fermer l'APCA, vérification interne du SGPI, examen de gestion (SGPI).
Semaines 9 à 10 : ajustements, lancement de rapports réguliers, préparation d'une évaluation externe (si nécessaire).

19) Erreurs fréquentes et comment les éviter

RoPA « pour cocher » : attacher chaque entrée aux objectifs, aux bases et à la rétention ; Gardez la version en direct.
DSAR via des OBD « crues » : uniquement via des vitrines/exportations masquées et des loges.
Pas de DTIA lorsque vous êtes transfrontalier : formalisez à l'avance, enregistrez la localisation des données/clés.
SDK marketing sans CMP : interdiction d'inclure les CMP et les TOMs contractuels.
Absence de Pbd/PbD : inclure les exigences de confidentialité dans PRD et Definition of Done.

20) Maintien de la conformité (Run PIMS)

Chaque mois : rapports KPI/KRI, audit des changements de RoPA, surveillance des sous-processeurs, DSAR SLA.
Trimestriel : Rébellion/suppressions, contrôles thématiques (marketing, SDK, KYC).
Annuellement : vérification interne du SGIP, mise à jour du contexte/des risques, formation du personnel, examen de gestion.

TL; DR

ISO 27701 = PIMS au-dessus de l'ISMS : RoPA + motifs légitimes/consentements + DPIA/DSAR + minimisation/rétention + transfrontaliers et sous-processeurs + prouvés par TOMs. Nous intégrons RBAC/ABAC/JIT/logs et TPRM existants - et obtenons une vie privée gérable et mesurable, prête pour les contrôles internes et externes.