DSAR : demandes de données des utilisateurs

1) Objectif et zone

Fournir un processus unique, prévisible et vérifiable de traitement des demandes des personnes concernées (DSAR) dans tous les canaux et juridictions, en tenant compte des restrictions des licences iGaming, AML/KYC, des exigences de jeu responsable (RG) et de la protection locale des données. Couverture : web/mobile, sapport/CS, CRM/marketing, produit/portefeuille, fournisseurs de jeux/PSP, analyste/DWH, logs/ARM, affiliés et fournisseurs externes.

2) Types DSAR (ce que l'utilisateur peut demander)

Accès aux données personnelles et copie des données.
Correction de données inexactes/incomplètes.
Suppression (« droit d'être oublié ») - sous réserve d'exceptions.
Limitation du traitement (pause d'utilisation).
Portabilité (exportation de données de base lisible par machine).
Objection à la commercialisation/profilage basée sur elle.
Solutions basées uniquement sur le traitement automatisé (AADM) - information et révision si nécessaire.

3) Principes

1. Légalité et bonne foi. Pas de barrières artificielles.
2. Preuve d'identité. Contrôle KYC proportionnel avant émission/retrait.
3. Minimisation et sécurité. Nous donnons « exactement autant que nécessaire », avec l'édition de tiers et de secrets.
4. Délais et transparence. Un accusé de réception, un statut et une réponse finale dans le délai imparti ; une prolongation justifiée est autorisée.
5. La preuve. Ensemble complet d'artefacts pour l'audit/régulateur.
6. Un seul point de contrôle. Portail/file d'attente DSAR centralisé et intégration avec tous les systèmes.

4) Rôles et RACI

DPO/Head of Compliance est le propriétaire du processus, l'interprétation des normes, les cas complexes. (A)

Privacy Ops/DSAR Team - traitement opérationnel, communications, collecte/émission. (R)

Legal - exceptions/restrictions, holds légaux, appels. (C/R)

Sécurité/Infra - canaux sécurisés, cryptage, contrôle d'accès. (R)

Data Platform/Analytics - extraction de données, de-PII, portabilité. (R)

Product/Engineering - API/connecteurs aux systèmes, automatisation. (R)

CS/Trust & Safety - Réception et vérification primaires, modèles de réponses. (R)

Audit interne - échantillons et CAPA. (C)

5) Canaux de réception et d'identification

Chaînes : portail « Privacy », e-mail privacy @..., tiquets CS, courrier.

• Dans le compte : 2FA + attributs de contrôle (partie téléphone/e-mail, opération récente).
• Sans compte/compte privé : proportionnellement - demande d'un ensemble limité de confirmations (pas de documents redondants).
• Représentant : Procuration/mandat ; nous enregistrons le statut et le volume.

Antifrod : drapeaux en cas de non-conformité des attributs/requêtes massives à partir d'un seul IP/agent.

6) SLA et délais

Reçu de réception : Immédiatement/dans les 24 heures.
Réponse quant au fond : dans un délai de 1 mois civil à compter de la date de réception (dans un certain nombre de pays, une prolongation de 2 mois supplémentaires est autorisée en cas de difficulté/volume).
Renouvellement : informer l'utilisateur à l'avance avec une justification.
Refus/restriction : réponse motivée indiquant les motifs et le droit de plainte.

7) Exceptions et restrictions (cadre)

AML/KYC et les licences iGaming : stockage des transactions/journaux dans les délais prescrits - la suppression ne s'applique pas, mais la limitation/minimisation est oui.
Obligations légales et légaux : dans les enquêtes/affaires judiciaires.
Droits et libertés des tiers : édition/impersonnalisation au croisement.
Secrets de trading/sécurité : ne révélons pas les algorithmes antifrod/clés/secrets ; fournir des informations descriptives.
Demandes manifestement infondées/excessives : des frais justifiés ou un refus sont possibles.

8) Systèmes sources et couverture

Compte/Profil : données d'inscription, statuts RG/SE, âge, consentement.
KUS/Documents : ID, selfie/vivacité (artefacts où légal).
Paiements/PSP : dépôts/retraits, jetons de carte (sans PAN), chargeback.
Activité de jeu : sessions, paris, gains, bonus/vader.
CRM/Marketing : accord de canal, historique des envois/campagnes.
Logs/Sécurité : entrées, appareils, événements importants (pas de PII « brut » si c'est une politique de logs).
Affiliations : sources de clic (pas de données personnelles de tiers).
Vendeurs : dossiers reçus de/transmis par lui (précisant les bases juridiques).

9) Processus (de bout en bout)

1. Réception et enregistrement : création de cas ('dsar _ case _ id'), type de requête, date limite.
2. KYC-vérification : vérification de l'identité, fixation de la méthode/résultat.
3. Triage : déterminer la portée, les exceptions, si la colline légale est nécessaire.
4. Collecte de données : extraction automatique des systèmes + demandes aux fournisseurs.
5. Nettoyage/révision : supprimer l'excès, masquer les tiers/secrets, traduire les techniques sous une forme compréhensible.
6. Préparation de la réponse : ensemble de données + note explicative (objectifs, échéances, sources, destinataires, droits).
7. Livraison : portail sécurisé/archives sécurisées ; cryptage et jetons jetables.
8. Fermeture : enregistrement des artefacts, contrôle de la qualité, sondage de satisfaction.
9. CAPA dans les incidents et les plaintes.

10) Formats et portabilité

Accès/copie : fichiers lisibles par machine (CSV/JSON/Parquet) + fichier PDF lisible.
Portabilité : noyau profil/transaction dans un format structuré et couramment utilisé ; les schémas sont annexés.
Correction : nous apportons des modifications et nous confirmons à l'utilisateur.
Suppression : jobs en cascade, crypto-suppression des archives, confirmation des gammes de systèmes/dates.

11) Livraison sûre

Un portail avec des liens MFA/jetables ; la durée de vie du lien est de 7 jours ≤.
Archives avec mot de passe, transfert de mot de passe sur un canal distinct.
Journaux de téléchargement/de navigation ; limitation du nombre de copies.

12) Modèle de données (minimum)

dsar_case {
case_id, subject_id_hash, market, type{access    rectify    erase    restrict    port    object    aadm},
received_at_utc, acknowledged_at_utc, due_at_utc, extended_to_utc, status,
id_verification{method, result, evidence_id, verified_at_utc},
scope{systems[], date_range, include_vendors{true    false}},
legal_basis_notes, exemptions[], legal_hold{yes/no, reason},
data_packages[{system, format, size_mb, records_count, redactions[]}],
delivery{channel, url, password_hint, expires_at_utc, downloaded_at_utc},
communications[], owner, approvers{dpo, legal}, closed_at_utc, outcome,
audit_artifacts[]
}

13) KPI/KRI et dashboard

DSAR SLA (médiane, 95e percentile) par type de requête.
Taux d'extension et raisons des extensions.
Taux d'échec de la vérification (problèmes KYC).
Taux d'erreur de redaction (fuites de tiers détectées).
Taux de réussite de portabilité (validation du format, plaintes de lisibilité).
Complaint/Appeal Rate et les découvertes réglementaires.
End-to-End Time-to-Deliver et part de l'automatisation (auto-extraction coverage).

14) Chèques-feuilles

A) Acceptation/vérification

• Demande enregistrée, type/marché déterminé.
• Reçu envoyé, date limite.
• La vérification KYC a été effectuée/demandée proportionnellement au risque.
• Le statut de représentant (le cas échéant) a été vérifié.

B) Collecte/préparation

• Tous les systèmes/fournisseurs pertinents sont couverts.
• Les exceptions AML/legal hold ont été appliquées.
• Rédaction de tiers/secrets accomplie.
• Les formats sont lisibles, les schémas sont appliqués.

C) Livraison/fermeture

• Paquet chargé dans le canal sécurisé, mot de passe transmis séparément.
• Une lettre explicative avec droits et contacts a été envoyée.
• Logs de téléchargement et de confirmation à l'utilisateur.
• Artefacts enregistrés dans WORM, KPI mis à jour.

15) Modèles de communication (fragments)

Reçu de réception

Demande de preuve d'identité (KYC-light)

Avis de prorogation de délai

Refus/restriction avec base

Achèvement (émission du lot)

16) Automatisation et intégration

Orchestrateur DSAR : file d'attente unique, minuteurs SLA, webhooks pour systèmes.
Auto-extraction : connecteurs au profil, portefeuille, CRM, DWH, logs (PII-free).
Modèle d'édition : masques tiers/secrets, suppression EXIF.
Portabilité : générateur de circuits (JSON Schema) et validateur avant l'émission.
Livraison sécurisée : liens jetables, contrôle des téléchargements, arrêt automatique des affaires.

17) Erreurs fréquentes et prévention

Délivrance de « fromage » avec les données des tiers → Révision rigoureuse et double examen.
Délai expiré. → des minuteries SLA, renouvellements précoces, hiérarchisation.
Contrôle KYC redondant. → Proportionnalité et minimisation.
Incohérence des formats. → Schémas/validateurs uniques.
Sources non comptabilisées (fournisseurs/affiliés). → Registre des systèmes et revues régulières.
Fuite lors de la livraison. → Seulement un portail sécurisé, cryptage, canal de mot de passe séparé.

18) Plan de mise en œuvre de 30 jours

Semaine 1

1. Approuver les politiques DSAR, RACI, SLA et les modèles de lettres.
2. Établir un registre des systèmes/fournisseurs et une carte de données.
3. Démarrer le portail DSAR (MVP) et la file d'attente.

Semaine 2

4) Implémenter KYC-light et les journaux d'artefacts (WORM).
5) Connexion auto-extraction (profil/portefeuille/CRM/DWH).
6) Configurer l'édition et les formats d'exportation standard.

Semaine 3

7) Pilote 10-20 demandes (synthétique + réelle) ; mesurer le SLA/qualité.
8) Activer la livraison sécurisée (liens jetables, mot de passe séparé).
9) Formation CS/Privacy Ops (scripts, escalade).

Semaine 4

10) Sortie complète ; dashboard KPI/KRI, alertes de retard.
11) Plan trimestriel de vérification/échantillonnage et APA.
12) Plan v1. 1 : connecteur aux logs (PII-free), auto-portabilité, modèles multilingues.

19) Sections connexes

GDPR : Gestion du consentement de l'utilisateur/Politique de cookies et CMP

Localisation des données par juridiction

Privacy by Design : principes de conception

Vérification de l'âge et filtres d'âge

Procédures AML/KYC et rétention

Dashboard Complience & Monitoring/Regulatory Reports

Audit interne et externe/Listes de vérification