Gráficos de almacenamiento y eliminación de datos

1) Objetivo y área

Forme un registro único de retenciones (Retention Schedule) y gráficos de eliminación/anonimato administrados para todos los sistemas y jurisdicciones para:

Cumplir las leyes/licencias (GDPR/ePrivacy/AML/actos locales);
minimizar el volumen de PII;
garantizar la probabilidad de la ejecución (artefactos/revistas);
reducir los riesgos de incidentes y el costo de almacenamiento.

Cobertura: cuenta/perfil, KYC/AML, pagos/PSP, telemetría de juegos, RG/SE, CRM/marketing, afiliados, logs/ARMH, analítica/DWH, backups/archivos, proveedores/vendedores, todos los mercados objetivo.

2) Principios

1. Lawful & Purpose-bound. Los plazos están vinculados a los motivos y fines legítimos del procesamiento.
2. Data Minimization. Mínimo de campos/plazos; «anonimización en lugar de almacenamiento indefinido».
3. Local-first. La retencia se respeta dentro de la región (residencia de datos).
4. Policy-as-Data. Los gráficos se almacenan como registros (esquemas) legibles por máquina, versionados y aplicados por automatización.
5. Fail-Closed. Caducado/desconocido motivo → prohibición de uso/desencadenante de eliminación.
6. Auditability. Cada eliminación/anonimización → un artefacto en el almacén WORM.
7. Backups-aware. Los backups/archivos están sujetos a las mismas fechas límite (crypto-shredding de segmentos).

3) Roles y RACI

DPO/Head of Compliance (Owner) - política, registro, interpretación de normas, excepciones. (A)

Legal - bases legales/plazos según los mercados, Legal Holds. (R)

Seguridad/Infra - KMS/cifrado, crypto-shred, acceso a registros. (R)

Plataforma de datos/Análisis - de-PII/anonimización, reglas DWH/DL. (R)

Ingeniería/SRE es un orquestador de retenciones, cascadas, integraciones con sistemas/vendedores. (R)

Product/CRM - Coincidencia de los flujos de filo y suppression con los plazos. (C)

Vendor Manager - DPA/SLA de eliminación, confirmaciones de proveedores. (R)

Auditoría interna - muestras, CAPA, verificación independiente. (C)

4) Taxonomía de los datos y bases

Categorías (ejemplo):

CUS/Edad/Biometría - documentos, selfies/vitalidad, veredictos. (Motivos: ley/licencia, interés público; a menudo 5-7 años)
Pagos/PCI - tokens, transacciones/registros, chargeback. (Motivos: contrato/ley de contabilidad/PCI)
Actividad de juego - apuestas/ganancias, bonos, descuentos. (Motivos: contrato/licencia, interés del operador)
RG/SE - estados de autoexclusión, comprobación de disponibilidad/cheques de reality. (Motivos: ley/licencia, interés público)
CRM/Marketing - contactos, concordancia, historias de campañas. (Motivos: consentimiento/interés legítimo)
Los afiliados son click-id, placement, terms-hash (sin PII del jugador). (Motivos: contrato, interés legítimo)
Logs/ARMS - Documentos técnicos (PII-free por defecto). (Motivos: interés legítimo/seguridad)
Análisis/DWH - agregados/alias, fichas ML. (Motivos: interés legítimo/investigación)

5) Matriz de plazos (marco)

Categoría	Composición	Retención (básica)	Después de la fecha límite
CUS/biometría	pasaporte/selfie/veredicto	5-7 años (o por mercado)	cascada + crypto-shred en archivos
Pagos	operaciones, tokens	Contabilidad/PCI	tokens revoke + enmascaramiento de datos
Eventos de juegos	apuestas/ganancias/bonos	necesidad comercial/licencia (por ejemplo, 5 años)	de-PII → agregados (cohortes)
RG/SE	estados/banderas	plazo de licencia/prevención	guardar el indicador sin PII, eliminar los ligamentos
CRM/consentimiento	e-mail/SMS/push, cadenas TC	hasta otzyva/≤24 mes de inactividad	suppression inmediata + eliminación
Registros/ARMH	errores/tracks (PII-free)	30-180 días	auto-purge/rotación
Análisis/DWH	unidades/k-anon. sin plazo (si es anónimo)	—

💡 Los plazos específicos se establecen a nivel de jurisdicción en los perfiles (ver § 7).

6) Excepciones y bloques

Requisitos de licencia/AML - prioridad sobre la solicitud de eliminación (DSAR-erase), aplicar restricción y minimización.
Legal Hold/disputas/investigaciones - stop-flag para remover; fijamos la base y el plazo.
Derechos de terceros/secretos - edición/despersonalización en la emisión/exportación.
Registros operativos (por ejemplo, contabilidad): enmascarar en lugar de eliminar claves primarias.

7) Perfiles regionales (plantilla)


Юрисдикция: ______
KYC/биометрия: срок ___; особые запреты/форматы: ___
Платежи/бухучет: срок ___; маскирование: ___
Игровая активность: срок ___; анонимизация: k≥__
RG/SE: срок ___; политика хранения флага: ___
CRM/согласия: неактивность ≤ __ мес; double opt-in: да/нет
Логи/APM: __ дней; PII-free: да/нет
Бэкапы/архивы: локализация ___; crypto-shred SLA ___
Исключения/легал-холд: условия ___

8) Policy-as-Data: modelo de gráficos

Almacene los gráficos como entradas en el DB/registro de configuración:


retention_rule {
rule_id, version, market, data_class{KYC    PCI    GAME    RG    CRM    LOG    ANON},
lawful_basis{consent    contract    legal_obligation    legit_interest    public_interest},
retention_days, grace_days, action_after{erase    anonymize    mask    revoke_token},
pii{yes/no}, residency_region, backups_policy{crypto_shred:true, kms_key_scope:region},
dsar_applicable{yes/no}, exceptions{aml:true, legal_hold:true},
owner{dpo    legal    security    data}, approved_at_utc, next_review_at_utc
}

Versionar es obligatorio: cualquier edición → nueva versión + plan de migración.

9) Flujos de trabajo (sketch)

1. Detección: 'retention _ due _ detected' (cron/stream por eventos de creación).
2. Elegibilidad: verificación de excepciones (AML/hold/residency).
3. Orchestration: se forma un paquete de sistemas/vendedores, estrategia (erase/anonymize).
4. Ejecución: delete jobs en cascada, revoke tokens, claves de segmento crypto-shred en los backups.
5. Validación: conciliación de registros, orphan-scan, verificación selectiva de DWH/registros.
6. Evidence: informe (sumas de cheques, id de claves, tiempo, volúmenes) en WORM; enlace a dashboard.
7. Reporting: KPI, alertas, CAPA en caso de fallas.

10) Backups, archivos y DR

Localización: backups en la misma región/bloque.
Cifrado: por región KMS/HSM; las claves están segmentadas por mercados/tenantes.
Crypto-shredding: cuando se alcanza el plazo, se destruye la clave del segmento, el informe con 'kms _ key _ id'.
Almacenamiento inmutable: la etiqueta «espera crypto-shred» en el planificador.

11) Análisis/DWH y anonimato

De-PII Pipeline: antes de exportar a DWH - tokenización/truncamiento/k-anon, bining de fechas/geo, supresión de valores raros, diff. privacidad en los informes.
Informes globales: sólo agregados; prohibición de los PII «crudos» fuera de la región.
El destino de los historiadores: después del término, la ruptura de los vínculos con los identificadores primarios.

12) Integraciones con DSAR/CMP/Localización

DSAR-erase: utiliza los mismos mecanismos de orquestación/artefactos; en conflictos con AML, → restricción en lugar de eliminación.
CMP/Consent: revocar el consentimiento → detener inmediatamente el proceso y activar el temporizador de retención de los datos de marketing.
Residencia: los horarios se aplican en el perímetro regional, las exportaciones de PII están subordinadas a mecanismos transfronterizos.

13) Modelo de artefactos de eliminación


erasure_artifact {
job_id, rule_version, market, region, scope{subject    partition    cohort},
systems[], vendors[], method{cascade    crypto_shred    anonymize    mask    revoke_token},
started_at_utc, completed_at_utc, status{ok    partial    failed},
counts{records, tables, bytes}, checksum{before, after},
kms_keys_destroyed[{id, destroyed_at_utc}], orphan_scan{passed    failed},
dsar_case_id?, approvers{dpo, security}, evidence_uri(WORM)
}

14) KPI/KRI y dashboard

Retention Compliance Rate es la proporción de registros que han llegado a término y procesados en SLA.
Time-to-Erase - mediana/95 percentil desde el disparador hasta la finalización.
Backup Crypto-Shred SLA es la proporción de segmentos con claves destruidas a tiempo.
Orphaned Data Rate son registros «huérfanos »/réplicas no sincrónicas.
Vendor Erasure Ack - confirmaciones de los vendedores a tiempo.
DSAR Linkage es la proporción de desinstalaciones asociadas con casos DSAR.
Auditability Score -% de las tareas con un paquete completo de artefactos.
Exceptions Mix es la proporción de registros retenidos por AML/hold.

15) Hojas de cheques

A) Diseño y política

Registro de Retenciones por Categoría y Mercado Aprobado por DPO/Legal.
Se han definido la base de lawful y la action_after para cada registro.
Versionar los gráficos y la fecha de la próxima revisión.
Mapa de sistemas/vendedores/llaves y perímetros de localización.

B) Técnicas y operaciones

El orquestador de retención está conectado a todos los sistemas.
Se han probado las eliminaciones en cascada/enmascaramiento/anonimización.
Crypto-shred para backups: las claves están segmentadas, los informes se generan.
Orphan-scans y muestras de validación según lo programado.
El almacén de artefactos WORM está disponible para la auditoría.

C) Vendedores

DPA/SLA: plazo de eliminación, formato de confirmación, multas.
Confirmaciones trimestrales, eliminaciones de prueba.
Lista negra de proveedores con irregularidades.

16) Plantillas (inserciones rápidas)

A) Escritura de gráficos (ejemplo YAML)

yaml
- rule_id: CRM-MKT-EMAIL version: 1.3 market: EU data_class: CRM lawful_basis: consent retention_days: 730  # ≤24 мес неактивности grace_days: 30 action_after: erase pii: true residency_region: EU backups_policy: { crypto_shred: true, kms_key_scope: region }
dsar_applicable: true exceptions: { aml: false, legal_hold: true }
owner: dpo

B) Cláusula de venta (eliminación/confirmación)

💡 El proveedor se compromete a eliminar/anonimizar los datos en el plazo de N días a partir de la fecha de la solicitud, de acuerdo con el calendario de retenciones adjunto, y a proporcionar una confirmación (volumen, método, hora, identificadores de claves/lotes).

C) Decisión de anonimato (DWH)

💡 Los eventos individuales han caducado. Solo guardamos los agregados c k≥20, el binning de fechas (semana), el geo a «región», la supresión de categorías raras <0,5%.

17) Errores frecuentes y prevención

Borrado del prod-DB, pero no de los backups. → Crypto-shred, contabilidad de claves de mercado.
Los PIIs entran en los archivos ARM/logs. → PII-free por defecto, enmascaramiento en el agente, retén corto.
DWH con «colas» PII. → Obligatorio de-PII pipeline antes de la exportación.
Sin artefactos → Generación obligatoria de 'erasure _ artifact' y almacenamiento WORM.
Vendor no ha confirmado la eliminación. → Hold pagos/sanciones, escalada y offboarding.

18) Plan de implementación de 30 días

Semana 1

1. Aprobar la taxonomía/bases y el registro primario de retenciones por categoría.
2. Preparar perfiles regionales (EU/UK/...): plazos, excepciones, backups.
3. Especificar el modelo 'retention _ rule' y 'erasure _ artifact'.

Semana 2

4) Despliegue el orquestador de retención (cron/stream), conecte los sistemas clave.
5) Personalizar crypto-shred (KMS por mercado), registro de operaciones clave.
6) Incluir pipelina de-PII para DWH/informes.

Semana 3

7) Piloto: 2 categorías (CRM/registros) + 1 lote de evento de juego → anonimización.
8) Pruebas de vendedores: solicitudes de eliminación y confirmación.
9) Dashboard KPI/KRI y alertas (Time-to-Erase, Orphan Rate).

Semana 4

10) Lanzamiento completo; los rugidos trimestrales de gráficos y perfiles regionales.
11) CAPA por residuos/irregularidades encontradas.
12) Plan v1. 1: orphan-scans automáticos e informes de vendedores.

19) Secciones interrelacionadas

Eliminación y anonimización de datos

DSAR: solicitudes de datos de los usuarios

Localización de datos por jurisdicciones

GDPR: Gestión del Consentimiento/Política de Cookies y CMP

Privacy by Design

Encriptación en Tránsito/En, KMS/BYOK/HYOK

Dashboard de cumplimiento y monitoreo/Auditoría interna y externa