Rôles au sein du RGPD

1) Définitions et principes de base

Controller (Responsable du traitement) : détermine de manière indépendante les finalités et les modalités du traitement des données à caractère personnel (DP). Est principalement responsable de la légalité, la transparence, les droits des sujets, la sécurité-TOMs, le choix et le contrôle des processeurs.
Processeur (Processeur) : Traite le DP uniquement sur les instructions documentées du contrôleur, fournit les TOMs, aide avec les droits des sujets et les incidents, maintient les dossiers et permet les audits.
Contrôleurs communs (Contrôleurs conjoints) : Deux + personnes définissent ensemble des objectifs et des méthodes ; une répartition transparente des responsabilités et un point de contact pour les sujets sont nécessaires.
Sous-processeur (Sous-processeur) : fournisseur engagé par le processeur ; seulement avec l'autorisation écrite préalable du responsable du traitement et des obligations équivalentes.

La règle d'or : qui décide pourquoi et comment traiter - ce contrôleur ; qui ne fait que « exécuter sur instruction » est le processeur.

2) Comment définir le rôle dans la pratique (arbre de décision)

1. Qui définit les objectifs commerciaux du traitement ?

→ êtes-vous ? Plutôt un contrôleur.

2. Pouvez-vous réutiliser les données à vos propres fins (analyse, marketing) ?

→ Oui → le responsable du traitement (ou le contrôleur conjoint, si les objectifs sont communs).

3. Est-ce que les moyens/restrictions exacts de l'autre partie vous sont indiqués et vos objectifs sont dérivés ?

→ Oui → processeur.

4. Existe-t-il un produit/une plate-forme commune avec des objectifs définis par les deux parties ?

→ Oui → contrôleurs communs (besoin d'art. 26 arrangement).

5. Attirez-vous le cloud/vendeur sur votre mission ?

→ Wendor est sous-traitant ; vous êtes le responsable du traitement ; votre processeur principal est tenu d'obtenir votre autorisation.

3) Rôles dans l'écosystème iGaming - matrice d'exemples

4) Responsabilités par rôle (RACI de haut niveau)

5) Documents et accords

DPA (Data Processing Agreement) : contrôleur obligatoire pour le schéma → processeur.
Minimum : objet/catégorie PD, objectifs/instructions, TOMs, confidentialité, assistance avec DSAR/DPIA, notification d'incident, suppression/retour de données, audit, sous-processeurs (liste/mécanisme de consentement).
Art. 26 Arrangement (Contrôleurs communs) : répartition transparente des responsabilités (information, DSAR, point de contact), essence des rôles en politique publique.
SCCs/UK IDTA + DTIA : obligatoire pour les transmissions hors EEE/UK en l'absence d'adéquation.
RoPA : registre des opérations de traitement du contrôleur et du processeur (de son ensemble).
Conditions de commercialisation/SDK : interdiction des utilisations secondaires, rôles et objectifs clairs.

6) Zones critiques et erreurs types

1. Mélange de rôles : Le « processeur » utilise les données à ses propres fins → en fait, il s'agit d'un responsable du traitement/d'un responsable conjoint.
2. Sous-processeurs sans autorisation : le processeur ajoute un fournisseur sans votre consentement.
3. "Vide" DPA : il n'y a pas d'instructions précises selon retention/удалению/инцидентам/аудиту.
4. Contrôle collaboratif opaque : pas d'art. 26 - plaintes et risques punitifs.
5. SDK marketing : les fournisseurs tirent la DP pour eux-mêmes - vous êtes responsable de la divulgation et de la légalité.
6. PSP/Banques : les considérer comme des processeurs est une erreur ; plus souvent, ce sont des contrôleurs distincts.

7) Mini-modèle DPA (fragments de formulation)

Finalités et nature du traitement : « Le processeur traite PD uniquement pour la vérification KYC selon les instructions du Contrôleur ».
Instructions : « Toute modification des objectifs nécessite le consentement écrit du Contrôleur ».
Sous-processeurs : "Le processeur n'engage pas de sous-processeurs sans autorisation écrite préalable ; tient et publie un registre à jour".
Sécurité : « Le processeur prend en charge les TOMs (cryptage, pseudonyme, contrôle d'accès, journal) qui ne sont pas inférieurs à ceux décrits à l'annexe A ».
Incidents : « Le processeur avise le Contrôleur sans retard excessif et fournit toutes les informations pour les notifications du régulateur et des sujets ».
Suppression/Retour : « À la fin du service, le processeur supprime/renvoie le PD et supprime les copies dans les backaps selon le graphique ».
Audit : « Le contrôleur est habilité à effectuer des audits/questionnaires/rapports externes (SOC2/ISO), avec un préavis raisonnable ».

8) DPIA/DTIA et transfrontalière

DPIA : le contrôleur lance ; le processeur fournit des informations sur les systèmes, les risques, TOMs.
DTIA : sous SCCs/IDTA - évaluation de l'environnement d'exécution du bénéficiaire, mesures supplémentaires (E2EE, clés clients, quasi-anonymisation, stockage des clés dans EC/UK).

9) Travailler avec les droits des sujets (DSAR) dans des rôles distribués

Le responsable du traitement : accepte la demande, vérifie l'identité, coordonne la collecte, répond dans les délais (généralement ≤30 jours).
Processeur : Fournit rapidement le déchargement/retrait comme indiqué, ne répond pas directement au sujet (sauf indication contraire).
Contrôleurs conjoints : dans l'accord, indiquer le « point de contact » et l'échange de données pour la réponse.

10) Sécurité et incidents : Qui fait quoi

Contrôleur : Politique sur les incidents, plan de notification DPA/utilisateurs, gestion CAPA.
Processeur : Alerte immédiate du contrôleur, forensisme technique, containment, logs, aide aux notifications.
Contrôleurs conjoints : matrice harmonisée des notifications ; une seule ligne de communication.

11) Rétention, suppression, données de test

Le responsable du traitement : fixe les délais de conservation selon les objectifs/lois (AML, compte), publie dans la politique.
Processeur : implémente la suppression/anonymisation programmée, séparément - nettoyage des backups ; interdiction d'utiliser des PD dans un environnement de test sans masquage/synthétiseurs.

12) Intégration opérationnelle (pratique)

ACR/Changement : tout changement de rôle/sous-traitement/territoires - via l'ACR et les modifications DPA/SCC.
Data Map & RoPA : carte de flux en direct ; le contrôleur a les objectifs et les destinataires, le processeur a la catégorie et l'opération.
Gestion du vendeur : diligence raisonnable devant l'onbording (ISO/SOC2, pentest, politique des incidents, géographie des données).
Audits : chèques-feuilles, questionnaires, journaux d'accès PII sélectifs, logique de suppression.

13) Chèque-liste « Nous déterminons le rôle »

• Qui définit les objectifs et les paramètres clés du traitement ?
• La DP peut-elle être réutilisée à ses propres fins ?
• La deuxième partie a-t-elle des fondements juridiques distincts ?
• Qui est responsable envers l'entité (DSAR) ?
• Est-ce que DPA (art. 28) ou arrangement (art. 26)?
• Existe-t-il des sous-processeurs et un mécanisme d'harmonisation ?
• Y aura-t-il des transferts transfrontaliers et quel mécanisme (SCCs/IDTA) ?

14) Foire aux questions (FAQ)

PSP - processeur ou contrôleur ?
En général, un contrôleur distinct : ses propres objectifs (service de paiement, prévention de la fraude, rapports réglementaires).

Le fournisseur KYC peut-il stocker des photos pour la formation des modèles ?
Seulement avec le statut du responsable du traitement (avec une base et une divulgation séparées) ou avec votre consentement explicite et une base juridique correcte. Sinon, c'est interdit.

L'affiliation qui a amené le joueur est le processeur ?
Plus souvent, un contrôleur distinct : il recueille la DP chez lui à ses fins. Les campagnes conjointes exigent une répartition explicite des rôles.

Serveur Cloud Loging - À qui les données ?
Traitement des logs - obligation du processeur pour assurer la sécurité ; la réutilisation à ses fins nécessite un motif distinct (il ne peut en être autrement).

15) Mini-politique des rôles (fragment pour la norme interne)

1. Par défaut, l'opérateur agit comme contrôleur pour tous les flux de joueurs/partenaires PD.
2. Tout vendeur ayant accès à un PD - est formé comme un processeur (DPA) ou comme un contrôleur distinct (à ses propres fins).
3. L'ajout d'un sous-processeur nécessite un consentement écrit et une mise à jour du registre.
4. Tout changement de rôles/territoires/objectifs - par l'intermédiaire de l'ACR, du DPO et du Legal.
5. DSAR et incidents - coordonnés par le contrôleur, les processeurs répondent à la SLA.

16) Feuille de route pour la mise en œuvre

Semaines 1 à 2 : inventaire des flux de données et des rôles ; brouillon de la matrice « qui est qui » ; mise à jour du RoPA.
Semaines 3-4 : conclusion/mise à jour du DPA, art. 26 (si nécessaire), registre des sous-processeurs ; préparation des questionnaires d'audit.
Mois 2 : DTIA/SCCs/IDTA, mise à jour de la politique publique, formation des équipes.
Mois 3 + : audits réguliers des fournisseurs, test DSAR, tabletop par incident, révision des rôles lors des changements de produits/marketing.

17) Modèle court « Matrice des rôles » (exemple)

TL; DR

Nous déterminons le rôle à travers les objectifs et les méthodes de traitement : vous décidez « pourquoi/comment » - le contrôleur ; vous exécutez selon les instructions - processeur ; vous décidez ensemble - contrôleurs communs. Nous formalisons cela dans DPA/art. 26, nous menons RoPA, nous contrôlons les sous-traitants, nous assurons la DPIA/DTIA, les droits des sujets et la sécurité. Une matrice claire des rôles = moins de risques réglementaires, moins de zones contestées et des audits plus rapides.