Roles dentro del GDPR

1) Definiciones y principios básicos

Controller (Controlador): determina de forma independiente los objetivos y las modalidades del tratamiento de los datos personales (PD). Es el principal responsable de la legalidad, transparencia, derechos de los sujetos, security-TOMs, selección y control de los procesadores.
Processor (Procesador): Procesa PD sólo por instrucciones documentadas del controlador, proporciona TOMs, ayuda con los derechos de los sujetos e incidentes, mantiene registros y permite auditorías.
Controladores conjuntos: dos + personas definen conjuntamente objetivos y formas; se requiere una asignación transparente de responsabilidades y un punto de contacto para los sujetos.
Sub-Processor (Subprocesador): proveedor atraído por el procesador; sólo se permite con autorización previa por escrito del interventor y obligaciones equivalentes.

Regla de oro: quién decide por qué y cómo procesar es ese controlador; quien sólo «ejecuta las instrucciones» es el procesador.

2) Cómo definir el papel en la práctica (árbol de decisiones)

1. ¿Quién establece los objetivos comerciales de procesamiento?

→ ¿Es usted? Más bien un controlador.

2. ¿Puede reutilizar los datos para sus propios fines (análisis, marketing)?

→ Sí → controlador (o control conjunto si los objetivos son comunes).

3. ¿Le indican los medios/limitaciones exactos la otra parte y sus objetivos se derivan?

→ Sí → procesador.

4. ¿Existe un producto/plataforma colaborativa común con objetivos definidos por ambas partes?

→ Sí → joint controllers (necesita arte. 26 arrangement).

5. ¿Estás atrayendo una nube/vendedor en tu misión?

→ Vendedor - subprocesador; Usted es el contralor; su procesador principal está obligado a obtener su permiso para ello.

3) Roles en el ecosistema iGaming - Matriz de ejemplos

4) Responsabilidades de roles (RACI de alto nivel)

5) Documentos y acuerdos

DPA (Data Processing Agreement): controlador → procesador obligatorio para el esquema.
Mínimo: tema/categoría PD, objetivos/instrucciones, TOMs, privacidad, asistencia con DSAR/DPIA, notificaciones de incidentes, eliminación/devolución de datos, auditoría, subprocesadores (lista/mecanismo de consentimiento).
Art. 26 Arrangement (Joint Controllers): reparto transparente de responsabilidades (información, DSAR, punto de contacto), esencia de los roles en el orden público.
SCCs/UK IDTA + DTIA: obligatorios en transmisiones fuera del EEE/UK en ausencia de adecuación.
RoPA: registro de operaciones de procesamiento en el controlador y en el procesador (su conjunto).
Condiciones de comercialización/SDK: prohibición de uso secundario, funciones y objetivos claros.

6) Zonas críticas y errores de tipo

1. Mezcla de funciones: el «procesador» utiliza los datos para sus propios fines → en realidad es un controlador/controlador conjunto.
2. Subprocesadores sin permiso: el procesador agrega un proveedor sin su consentimiento.
3. "Vacío" DPA: no hay instrucciones precisas por retention/удалению/инцидентам/аудиту.
4. Control colaborativo opaco: no art. 26 - quejas y riesgos punitivos.
5. SDK de marketing: los proveedores tiran de PD por sí mismos - usted es responsable de la divulgación y la legalidad.
6. PSP/Bancos: considerarlos procesadores es un error; más a menudo son controladores individuales.

7) Mini plantilla DPA (fragmentos de formulación)

Objetivos y naturaleza del tratamiento: «El procesador procesa PD exclusivamente para verificación KYC siguiendo las instrucciones del Controlador».
Instrucciones: «Cualquier cambio en los objetivos requiere el consentimiento por escrito del Contralor».
Subprocesadores: "El procesador no atrae subprocesadores sin autorización previa por escrito; mantendrá y publicará un registro actualizado".
Seguridad: «El procesador admite TOMs (cifrado, seudonimización, control de acceso, registro) no inferior a lo descrito en el Apéndice A».
Incidencias: «El procesador notificará al Contralor sin demora indebida y facilitará toda la información para notificaciones al regulador y a las entidades».
Eliminación/Devolución: «Al finalizar el servicio, el procesador elimina/devuelve el PD y elimina las copias de seguridad en el gráfico».
Auditoría: «El Contralor tiene derecho a realizar auditorías/cuestionarios/informes externos (SOC2/ISO), con una notificación razonable».

8) DPIA/DTIA y transfronterizos

DPIA: el controlador inicia; el procesador proporciona información sobre sistemas, riesgos, TOMs.
DTIA: bajo SCCs/IDTA - evaluación del entorno de aplicación del destinatario, medidas adicionales (E2EE, claves de cliente, cuasi-anonimización, almacenamiento de claves en EC/UK).

9) Trabajar con los derechos de los sujetos (DSAR) en roles distribuidos

Contralor: acepta la solicitud, verifica la identidad, coordina la recaudación, responde en un plazo (generalmente de ≤30 días).
Procesador: Proporciona rápidamente las descargas/desinstalaciones por instrucciones, no responde directamente al sujeto (a menos que se prescriba lo contrario).
Controladores conjuntos: en el acuerdo especificar el «punto de contacto» y el intercambio de datos para la respuesta.

10) Seguridad e incidentes: quién hace qué

Controlador: política de incidentes, plan de notificación de DPA/usuarios, gestión de CAPA.
Procesador: alerta inmediata del controlador, forensic técnico, contenido, registros, asistencia con notificaciones.
Controladores conjuntos: matriz de notificación armonizada; una sola línea de comunicación.

11) Retiro, eliminación, datos de prueba

Contralor: establece los plazos de retención por objetivos/leyes (AML, contabilidad), publica en política.
Procesador: implementa la eliminación/anonimización programada, por separado, la limpieza de backups; prohibición de usar PD en un entorno de prueba sin enmascarar/sintético.

12) Integración operativa (práctica)

AMB/Change: cualquier cambio de roles/sub-procesadores/territorios - a través de AMB y revisiones DPA/SCCs.
Mapa de datos & RoPA: mapa de flujo en vivo; el controlador tiene objetivos y destinatarios, el procesador tiene categorías y operaciones.
Gestión de vendedores: due diligence antes de hacer onboarding (ISO/SOC2, pentesto, política de incidentes, geografía de datos).
Auditorías: hojas de comprobación, cuestionarios, registros de acceso a PII selectivos, lógica de eliminación.

13) Check-list «Definimos el papel»

• ¿Quién establece los objetivos y los parámetros clave de procesamiento?
• ¿Es posible reutilizar el PD para sus propios fines?
• ¿Existe una base jurídica independiente para la segunda parte?
• ¿Quién es responsable ante la entidad (DSAR)?
• ¿Necesita DPA (art. 28) o arrangement (art. 26)?
• ¿Hay subprocesadores y un mecanismo de alineación?
• ¿Habrá transferencias transfronterizas y qué mecanismo (SCCs/IDTA)?

14) Preguntas frecuentes (FAQ)

PSP - ¿procesador o controlador?
Normalmente, un controlador separado: objetivos propios (servicio de pago, prevención de fraudes, informes normativos).

¿Un proveedor de KYC puede almacenar fotos para entrenar modelos?
Sólo bajo la condición de controlador (con una base separada y divulgación) o con su consentimiento expreso y base legal correcta. De lo contrario, está prohibido.

¿El afiliado que trajo al jugador es el procesador?
Más a menudo, un controlador separado: recoge el PD de sí mismo para sus propios fines. Las campañas conjuntas requieren una asignación explícita de roles.

Cloud Server-Logic - ¿de quién son los datos?
Procesamiento de registros: es responsabilidad del procesador garantizar la seguridad; la reutilización para sus propios fines requiere una base separada (de lo contrario no se puede).

15) Mini política de roles (fragmento para el estándar interno)

1. De forma predeterminada, el operador actúa como controlador de todos los flujos PD de jugadores/socios.
2. Cualquier proveedor con acceso a PD - se formaliza como un procesador (DPA) o como un controlador separado (con sus propios fines).
3. La adición de un subprocesador requiere el consentimiento por escrito y la actualización del registro.
4. Cualquier cambio de roles/territorios/objetivos es a través de AMB, DPO y Legal.
5. DSAR e incidentes: coordinados por el controlador, los procesadores responden en SLA.

16) Hoja de ruta para la implementación

Semanas 1-2: inventario de flujos de datos y roles; borrador de la matriz «quién es quién»; actualización de RoPA.
Semanas 3-4: conclusión/actualización del DPA, art. 26 (donde sea necesario), registro de subprocesadores; Preparación de cuestionarios de auditoría.
Mes 2: DTIA/SCCs/IDTA, actualización de políticas públicas, formación de equipos.
Mes 3 +: auditorías periódicas de vendedores, prueba DSAR, tabletop sobre incidentes, revisión de roles en cambios de producto/marketing.

17) Plantilla corta «Matriz de roles» (ejemplo)

TL; DR

Definimos el papel a través de los objetivos y los métodos de procesamiento: se decide «por qué/cómo» - el controlador; se ejecuta según lo especificado - procesador; decidir juntos - joint controllers. Formalizamos esto en DPA/art. 26, conducir RoPA, controlar los subprocesadores, proporcionar DPIA/DTIA, derechos de las entidades y seguridad. Una matriz clara de roles = menos riesgos regulatorios, menos zonas en disputa y auditorías más rápidas.