ISO 27701: gestión de la privacidad

1) Qué es ISO 27701 y por qué es un operador de iGaming

ISO 27701 es un complemento de ISO 27001 y 27002 que amplía ISMS a PIMS (sistemas de gestión de información de privacidad).
Para iGaming: cumplimiento probado de los requisitos de privacidad (GDPR/UK GDPR/ePrivacy, etc.), trabajo acelerado con reguladores/bancos/socios KYC/PSP, reducción del riesgo de multas y simplificación de la gestión de vendedores.

2) Ámbito y contexto PIMS

• Roles y bordes: en qué procesos es Controller, donde es Processor; qué marcas/regiones/procesos entran en Scope.
• Categorías de datos: registro, pagos, KYC/AML/sanciones, eventos de comportamiento, señales RG, sapport, marketing/SDK.
• Obligaciones legales: leyes locales de privacidad, términos de licencia, contratos con socios.

Resultado: documento PIMS Scope & Context + mapa de partes interesadas.

3) Funciones y responsabilidades básicas

4) Ligamento ISO 27701 ↔ ISO 27001

ISMS (27001/27002): base de seguridad (activos, riesgos, controles).
PIMS (27701): añade la política de privacidad, la legalidad del tratamiento, los derechos de las entidades, el ciclo de vida de los datos, los mecanismos contractuales y transfronterizos.
SoA/Statement of Applicability: expandido por los controles privados de PIMS.

5) Registro de procesamiento (RoPA) y mapa de datos

Para cada proceso: objetivo, base legal, categorías de sujetos/datos, vida útil, destinatarios/subprocesadores, geografías, TOMs, bandera 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) Motivos y consentimiento legítimos (Lawful Basis & Consent)

Contrato/Obligación legal: pagos, KYC/AML, prevención del fraude.
Interés Legitimate: análisis básico/seguridad (con evaluación de intereses y opt-out donde se requiera).
Contenido: marketing, cookies/SDK para fines no esenciales, ciertos tipos de perfiles.
Categorías especiales: sólo con bases claras y medidas reforzadas.

CMR/gestión del consentimiento: registro de la versión de la política/banners, granularidad por objetivos, probabilidad de la revocación.

7) DPIA/PIA - Evaluación del impacto sobre la privacidad

Cuándo: nueva tecnología, procesamiento a gran escala, datos sensibles, perfiles sistemáticos, transfronterizos.
Contenidos: descripción del tratamiento, necesidad y proporcionalidad, riesgos para los derechos de las entidades, medidas de reducción.
Salida: solución (ir/modificar/rechazar) + plan CAPA y control de fechas.

8) Derechos de los interesados (DSAR)

Derechos: acceso, rectificación, supresión, restricción, portabilidad, objeción, rechazo al perfilado/marketing.
SLA: confirmación rápida de la solicitud y ejecución dentro del plazo reglamentario.
Flujo de ejecución: obtención → verificación de identidad → recopilación de datos → respuesta/ejecución → registro.

Prohibición de «descargas ciegas»: sólo a través de vitrinas con camuflaje y guaridas; restricción de muestras pequeñas (privacy thresholds).

9) Minimización, enmascaramiento y retiro

Minimización de datos: almacenar sólo lo necesario para fines; eliminar/anonimizar regularmente los campos «muertos».
Enmascaramiento/seudonimización: por defecto para PII; desenmascaramiento - JIT + 'purpose' + auditoría.
Matriz de retiro: tiempo de almacenamiento por proceso/categoría, factores de parada (legal), auto-eliminación/archivo.

10) Transmisiones transfronterizas y subprocesadores

Mecanismos contractuales: DPA, SCCs/IDTA, DTIA (evaluación de la transferencia).
Ubicación de datos/claves: donde físicamente se encuentran los datos/claves (KMS/HSM), la política VWOC/claves regionales.
Registro de subprocesadores: notificación de cambios, derecho de oposición, nivel TOMs no inferior al nuestro.

11) Privacy by Design / by Default

En la fase de diseño: Requisitos de Protección de Datos en PRD, una plantilla de threat modeling con amenazas privadas.
En implementación: RLS/CLS, tokenización, cifrado, scops mínimos de API, telemetría sin PII.
De forma predeterminada: se han desactivado los rastreadores opcionales, las teclas individuales/los nymspaces por región/tenant.

12) Lógica, probabilidad y auditoría de PIMS

Логи (WORM+подпись): `READ_PII`, `EXPORT_DATA`, `PII_UNMASK`, `CONSENT_UPDATE`, `DSAR_`, `BREACH_`.
Reporting: estado de RoPA, campañas de DPIA, DSAR SLA/backlog, desinstalaciones de retén, cambios vendedores, irregularidades/incidentes.
Auditoría: cada año (o en caso de cambios), verificación de los controles privados de Diseño/Funcionamiento.

13) Métricas (KPI/KRI) PIMS

• DSAR on-time ≥ 95%
• Relevancia de RoPA ≥ 98%
• Cobertura de DPIA por objeto de riesgo = 100%
• Porcentaje de desinstalaciones automáticas por retransmisión ≥ 95%
• Nivel de inclusión CMP (registros de consentimiento registrados) = 100%

• Acceso a PII sin 'purpose' = 0
• Exportación/transferencia no autorizada = 0
• Incidentes/fugas notificados más tarde del plazo = 0
• DPA/SCC faltantes para la transmisión activa = 0

14) Integración con los controles existentes

IGA/RBAC/ABAC/JIT/PAM: minimización de derechos y condiciones contextuales de acceso.
Política de registros y revistas de auditoría: la probabilidad de las acciones con PII.
TPRM y contratos: DPA/SCCs/DTIA, derechos de auditoría, avisos SLA ≤ 72 h.
ISO 27001/ISMS: modelo de riesgo común, SoA y auditorías internas.
Incidentes y filtraciones: playbook breach, war-room colaborativo con vendedores.

15) Patrones de artefactos (fragmentos)

15. 1 Política de privacidad (extracto interno)

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 Política de desenmascaramiento

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 proceso 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 Matriz de retiro (fragmento)

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 (procedimientos)

16. 1 Actualización de RoPA

1. El iniciador del cambio (Product/Owner) → una tarjeta de proceso → rugido Legal/Privacy → Security TOMs → publicación y versión.

16. 2 Realización del DPIA

1. Cribado de riesgos → plantilla DPIA → consulta DPO → CAPA → solución y control de plazos.

16. 3 DSAR

1. Tome → verifique → monte y filtre a través de los escaparates → respuesta/ejecución → lógica y cierre.

16. 4 Vendedores/transmisiones

1. Due diligence → DPA/SCCs/DTIA → registro de subprocesadores → monitoreo de cambios → offboarding y confirmación de eliminación.

17) RACI (ampliado)

18) Hoja de ruta para la implementación (8-10 semanas)

Semanas 1-2: Scope/contexto, roles y RACI, inventario de procesos/datos, borrador de RoPA y matrices de retén.
Semanas 3-4: política de privacidad, CMP/consent-flow, proceso DSAR, plantillas DPIA, actualización DPA/SCCs/DTIA con proveedores.
Semanas 5-6: implementación de TOMs (enmascaramiento, RLS/CLS, JIT/PAM), escaparates para DSAR, registros WORM, informes KPI/KRI.
Semanas 7-8: Realizar DPIA por alto riesgo, cerrar CAPA, auditoría interna PIMS, revisión de gestión (PIMS).
Semanas 9-10: ajustes, lanzamiento de informes regulares, preparación para una evaluación externa (si es necesario).

19) Errores frecuentes y cómo evitarlos

RoPA «para marcar»: vincular cada entrada a los objetivos, bases y retoque; Mantenga la versión en vivo.
DSAR a través de «crudo» DB: sólo a través de escaparates/exportaciones con enmascaramiento y logotipos.
No hay DTIA en la transfronteriza: formalice con antelación, fije la ubicación de los datos/claves.
SDK de marketing sin CMP: prohibición antes de incluir CMP y TOMs contractuales.
Sin Pbd/PbD: incluya los requisitos de privacidad en PRD y Definición de Don.

20) Mantenimiento de la conformidad (Run PIMS)

Mensualmente: informes KPI/KRI, auditoría de cambios de RoPA, monitoreo de subprocesadores, DSAR SLA.
Trimestralmente: rugido de retenciones/eliminaciones, comprobaciones temáticas (marketing, SDK, KYC).
Todos los años: auditoría interna de PIMS, actualización de contextos/riesgos, formación del personal, revisión de gestión.

TL; DR

ISO 27701 = PIMS sobre ISMS: RoPA + fundamentos/consentimientos legales + DPIA/DSAR + minimización/retencion + transfronterizos y subprocesadores + TOMs probados. Incorporamos RBAC/ABAC/JIT/logs y TPRM existentes, y obtenemos privacidad manejable y medible, lista para inspecciones internas y externas.