Medidas complementarias que sí resisten en cloud y AdTech

Cifrado, claves, minimización, seudonimización y split-processing (con evidencias)

En la práctica, el debate sobre transferencias internacionales no se gana con “tenemos SCCs”. Se gana cuando puedes demostrar que, aunque exista acceso desde un tercer país (por cloud, soporte, subencargados o tooling publicitario), has implementado medidas complementarias efectivas y evidenciables.

Este Post 7 es el “manual operativo” para el punto más exigente del expediente: medidas técnicas y organizativas que de verdad cambian el riesgo (y que, bien documentadas, sostienen una TIA/TRA).

1) La regla de oro: la medida tiene que “romper el vínculo” o “romper el acceso”

Si la ley/práctica del tercer país pudiera permitir acceso, el estándar práctico es:

• Romper el vínculo (que los datos no sean atribuibles a una persona) mediante seudonimización + separación del “extra info”; o

• Romper el acceso (que aunque haya acceso no sea inteligible) mediante cifrado robusto + control de claves; o

• Reducir radicalmente el valor (minimización/limitación de finalidades) + controles de activación (pre/post consentimiento) + auditoría continua.

Este enfoque está en el corazón de las Recomendaciones 01/2020 del EDPB sobre medidas suplementarias (y sus casos de uso, incluidos seudonimización y split-processing).

2) Medida 1 — Cifrado fuerte + claves bajo tu control

Cuándo aplica (muy común)

• Cloud/SaaS con soporte global.

• Logs, telemetría, APM/crash reporting.

• Almacenamiento o tránsito por infraestructuras fuera del EEE (CDN, WAF, etc.).

Qué funciona (en serio)

• Cifrado de contenido end-to-end (cuando sea posible), o al menos cifrado fuerte en reposo y en tránsito.

• Gestión de claves: lo decisivo es quién controla las claves y bajo qué condiciones se usan.

Evidencias que debes poder mostrar

• Arquitectura de cifrado (diagrama + configuración).

• Política de gestión de claves (KMS/HSM), segregación de roles, rotación, control de acceso.

• Registros de acceso a claves y evidencias de revisión (logs).

Nota operativa: si el proveedor puede descifrar “por diseño” sin controles adicionales, el cifrado no te aporta la garantía que crees.

3) Medida 2 — Seudonimización “de verdad” (y separación del extra info)

La seudonimización suele citarse de forma ligera. Pero el estándar de calidad se ha reforzado: el EDPB publicó Guidelines 01/2025 on Pseudonymisation, que explican con detalle qué es “información adicional” y por qué debe estar protegida para impedir reidentificación.

Cuándo aplica (web/app)

• Analítica externa.

• A/B testing.

• Herramientas de producto que no necesitan identidad real.

• Identificadores persistentes (IDs de usuario, device IDs, etc.).

Qué funciona

• Tokenización/seudónimos por finalidad y contexto (“IDs distintos por dominio/finalidad”).

• Extra info (tablas de correspondencia/keys) solo bajo tu control, separada del flujo de transferencia.

Evidencias

• Diseño de seudonimización (qué campo se reemplaza, con qué método).

• Ubicación y controles del extra info (quién accede, cómo se audita).

• Pruebas de no reidentificación razonable (tests/validaciones internas).

4) Medida 3 — Split-processing (o “multi-party processing”) para eliminar atribución

Esta es de las medidas más potentes cuando estás atado a terceros, porque busca que el receptor nunca tenga “la película completa”. El EDPB la contempla explícitamente como caso de uso.

Cuándo aplica

• AdTech / medición compleja.

• CDPs/marketing stacks donde el tercero no necesita identidad.

• Analítica avanzada donde puedes separar señales.

Ejemplos web/app (muy prácticos)

• Separar eventos funcionales (producto) de señales identificativas.

• Enviar a un tercero solo métricas agregadas o troceadas (sin IDs persistentes).

• Mantener el join (unión) de datasets dentro de tu entorno (EEE) o bajo tus llaves.

Evidencias

• Esquema de separación (qué parte va a qué proveedor).

• Justificación de que el proveedor no puede atribuir a personas “ni siquiera cruzando” sin tu extra info.

• Validación técnica periódica (auditoría continua: tráfico/endpoints).

5) Medida 4 — Minimización y “privacy by default” en activación (pre/post consentimiento)

Muchas transferencias “silenciosas” ocurren antes de que el usuario elija, o por configuraciones por defecto demasiado amplias. Aquí, la medida complementaria no es solo criptográfica: es control de activación + minimización de datos.

Qué funciona

• Bloqueo preventivo (nada no necesario pre-consent, cuando aplique).

• Configuraciones de analítica “privacy-friendly” (retención, IP, desactivación de features intrusivas).

• Reducción de campos (no enviar IDs persistentes si no son imprescindibles).

Evidencias

• HAR pre/post/reject + capturas de CMP y configuración real.

• Evidencias de configuración (retención, desactivaciones, etc.).

• Inventario de endpoints: qué se llama, cuándo y por qué.

6) Medida 5 — Controles de acceso, logging y detección de abuso (la parte “auditada”)

Para cloud y cadenas de soporte global, en inspección suele importar:

• ¿Quién puede acceder?

• ¿Cómo se autoriza y se registra?

• ¿Cómo detectas y respondes?

Qué funciona

• Acceso privilegiado “just-in-time”, MFA fuerte, segregación, approvals.

• Logging centralizado y revisiones.

• Alertas por accesos anómalos (horarios, geos, volúmenes).

Evidencias

• Registros de accesos privilegiados.

• Procedimientos de revisión periódica (muestras, auditorías internas).

• Evidencia de incident response.

7) Medida 6 — “Artículo 48” y solicitudes de autoridades de terceros países

Este punto es clave para cloud: ¿qué pasa si un proveedor recibe una solicitud de una autoridad de un tercer país?

El EDPB publicó la versión final de las Guidelines 02/2024 sobre el Art. 48 RGPD (junio 2025). Es muy útil para tu expediente porque refuerza que hay un “two-step test” y que las solicitudes de autoridades de terceros países no “automatizan” la transferencia.

Evidencias/controles esperables:

• Cláusulas de transparencia y challenge (impugnación) cuando sea posible.

• Procedimiento interno: quién decide, cómo se documenta, qué se notifica.

• Logs/registro de solicitudes (aunque sea “cero solicitudes”, documentado).

8) Lo que más falla en la práctica (y cómo evitarlo)

1. “Cifrado” sin control de claves (el proveedor puede descifrar sin fricción).

2. Seudonimización que no separa extra info (o extra info accesible por el tercero).

3. Split-processing “teórico” sin pruebas de no atribuibilidad.

4. Minimización sin control pre-consent (se dispara antes).

5. Sin control de cambios: entra un tag nuevo y rompe tu TIA/TRA.

6. Evidencias dispersas: nadie puede enseñar el pack en 10 minutos.

9) Pack de evidencias “mínimas” (para anexar al expediente)

Si quieres que tu Post 6 (expediente) quede sólido, este Post 7 se traduce en anexos muy concretos:

• Matriz de medidas complementarias por proveedor/flujo (qué medida, por qué, evidencia).

• Evidencias criptográficas (KMS/HSM, llaves, accesos, rotación).

• Diseño de seudonimización/split-processing + pruebas de validación.

• HAR pre/post/reject + CMP/GTM versionado.

• Logs de accesos privilegiados y revisiones.

• Procedimiento Art. 48 (solicitudes de autoridades) + registro.

Bibliografía y recursos top (para citar en el artículo)

• EDPB — Recommendations 01/2020 (v2.0) sobre medidas suplementarias (base del enfoque).

• EDPB — Casos de uso (seudonimización, cifrado, split-processing) (resumen de trabajo del EDPB).

• EDPB — Guidelines 01/2025 on Pseudonymisation (calidad de seudonimización y extra info).

• EDPB — Guidelines 02/2024 on Article 48 (final) (solicitudes de autoridades de terceros países).

• CNIL — Practical Guide on TIA (final) (guía operativa para estructurar la evaluación).

• ICO — Completing a TRA (actualizada 15/01/2026) (enfoque práctico UK para evaluación y documentación).