Lección 56 — Cumplimiento

Stack: RGPD / SOC 2 / ISO 27001 · Proyecto: TicketFlow Estado: Publicada — el marco regulatorio en visión de backend Prerrequisito: Lección 55 — Escalado

Objetivos

1. Situar el RGPD en el ciclo de vida del dato de TicketFlow: licitud, minimización, derechos y las pruebas que el backend debe poder mostrar.
2. Entender SOC 2 / ISO 27001 como sistemas de control (no de papeles): qué auditan y qué evidencias produce el backend.
3. Diseñar la auditoría de cumplimiento: el audit log append-only (23), la retención, y el DPO interno del sistema.

1. El RGPD en el ciclo de vida del dato

El RGPD (el 23 ya construyó el cómo; aquí el marco): los PRINCIPIOS operativos: (1) licitud: la base legal de cada dato — el comprador: ejecución del contrato (la venta); el marketing: consentimiento revocable (el checkbox del 15); (2) minimización: solo el dato necesario — el checkout pide email, NO el DNI (el 23: el dato que no pides no lo proteges); (3) limitación del fin: el email de la compra no alimenta el perfil publicitario sin base nueva; (4) exactitud y limitación del plazo: la retención (§3); (5) integridad y confidencialidad: el cifrado/seguridad del 22-23; (6) responsabilidad proactiva: PODER DEMOSTRARLO (el registro de tratamiento del §4).

Los DERECHOS y su implementación backend (la 23 los construyó; aquí el mapa completo): acceso (el export del 23), rectificación (el perfil editable), supresión (el borrado con las excepciones: la FACTURACIÓN se retiene por ley — el dato del dinero no se borra, se anonimiza), portabilidad (el export en formato machine-readable: el JSON del 23), oposición/limitación (el flag del perfil), y la notificación de brecha (el incidente del 47 con datos: 72 h al regulador — el runbook de brecha del §4).

2. El mapa de datos (el documento que el DPO pide)

El registro de actividades de tratamiento (el Art. 30): el mapa de QUÉ dato, para QUÉ, BASE legal, DÓNDE vive, CUÁNTO se retiene y QUIÉN lo toca:

Las tres claves del mapa: el dato de tarjeta VIVE en la pasarela (la 23: jamás en tu BD — el PCI del §3); el mapa ES el documento que la supresión/portabilidad consultan (¿qué borrar? el mapa lo dice); y el mapa vive en docs/compliance/ (48: docs-as-code) con revisión trimestral.

3. SOC 2 / ISO 27001: los controles que el backend produce

El SOC 2 (y su primo ISO 27001) auditan CONTROLES operando: no "hay política", sino "la política se ejecuta y hay evidencia". Los controles que el backend de TicketFlow YA produce con el curso:

La lección del backend senior: el cumplimiento se CONSTRUYE con la misma ingeniería del curso (el 23/45/47) — el audit del certificador pide las evidencias y las herramientas del curso las generan solas. El costo real de SOC 2: el 80% es ordenar lo que la buena ingeniería ya hace; el 20% restante es el papel del registro y el DPO.

4. El audit log y la retención: el sistema que responde al auditor

El audit log (23) completado a sistema: append-only (sin UPDATE/DELETE: el permiso de BD del 21), con quién/qué/cuándo/resultado/origen, y las consultas del auditor: "¿quién vio el dato del usuario X?", "¿quién descargó el export?", "¿quién cambió el precio del evento Y?" — cada una es UNA query (45: la consulta del auditor). La retención por tipo (el mapa del §2): el audit log 12 meses caliente + 2 frío (el 45: la retención del log del diagnóstico ES distinta: 30 días); el dato del comprador 5-6 años (fiscal); el consentimiento de marketing: la evidencia del opt-in guarda la fecha y el texto de la versión del consentimiento (el "dijo que sí a ESTA versión" es la prueba del auditor).

El runbook de brecha (el 72 h): detectar (la alerta del 46), acotar (47: el protocolo), contener (el flag/rollback del 41), notificar (el regulador + los afectados si alto riesgo: la plantilla del doc del 48), y el postmortem con la acción regulatoria cerrada. El runbook SE ESCRIBE HOY (48: el doc con caducidad): el día de la brecha no se improvisa con el reloj corriendo.

5. El DPO interno del sistema: la automatización del cumplimiento

Lo que el backend automatiza del cumplimiento (el "DPO interno"): (1) el export/supresión como API con SLA (el 23: 30 días legales, tu sistema lo hace en minutos) y el audit de cada ejecución; (2) el mapa de datos generado (los esquemas del 00b anotados con base/retención: la referencia del 48 que el registro del Art. 30 consume); (3) la retención como job (31: los datos que caducan se purgan SOLos con el audit del purgado); (4) el escaneo de PII (el test que falla si un nuevo campo de texto libre entra a una tabla sin anotación de base legal — el linter del cumplimiento); (5) las evidencias SOC 2 como reportes del sistema (el login report, el acceso report: los queries del §4 en cron del 31). El principio de cierre: el cumplimiento no es un proyecto aparte: es la consecuencia observable de la ingeniería del curso — cada control ya está; queda documentarlo y probarlo.

Autoevaluación

1. Los 6 principios RGPD: ¿qué base legal tiene el email del comprador y qué la del marketing? ¿Qué excepción impide borrar el dato del dinero?
2. El mapa del Art. 30: ¿por qué el dato de tarjeta jamás vive en tu BD y qué documento consume el DPO?
3. ¿Qué audita el SOC 2 y qué evidencia produce cada control del curso (la tabla del §3)? ¿Cuál es el 80/20 del certificado?
4. El audit log: ¿qué 3 consultas del auditor responde y qué retención tiene cada tipo de dato?
5. ¿Qué automatiza el "DPO interno" y por qué el cumplimiento es consecuencia de la ingeniería del curso?

Continúa con los ejercicios. Las solutions.md solo tras intentarlo.