Transferencias y cloud en tu web/app: cómo detectar salidas del EEE, documentarlo en TPRM y qué evidencias miran las autoridades- Post (Serie 1 — TPRM/Transfers)

Posted on by Leocadio Marrero Trujillo

Transferencias y cloud en tu web/app: cómo detectar salidas del EEE, documentarlo en TPRM y qué evidencias miran las autoridades

En 2026, el riesgo no está solo en “tener SCCs”. Está en saber demostrar (con evidencia técnica y gobernanza) qué proveedores sacan datos fuera del EEE, cuándo, con qué finalidad, con qué base y qué medidas complementarias aplicas cuando el tratamiento depende de cloud y cadenas de subencargados.

1) Identificación práctica: “¿Quién está sacando datos fuera del EEE?”

Empieza por el mapa real del tráfico y del ecosistema, no por el organigrama:

Puntos típicos de salida (web y app):

  • CDN/WAF/DDoS (cabeceras, IP, telemetría, logs).

  • Analítica (incluida “medición de audiencia”), heatmaps, session replay.

  • AdTech / pixels / tags (retargeting, atribución, conversion APIs).

  • Fuentes de letras, iconos, mapas, vídeo embebido (requests a terceros).

  • Chat widgets / atención al cliente / CRM.

  • Pasarelas de pago, antifraude, scoring.

  • Monitorización (APM, errores, crash reporting).

  • Servicios de email/SMS/push y verificación (OTP).

Cómo detectarlo de verdad (sin fe):

  • HAR (Chrome/Edge DevTools) y exportación de trazas antes/después del consentimiento.

  • CSP “report-only” para inventariar endpoints de terceros.

  • Logs de proxy / egress (si tienes salida controlada) y DNS logs corporativos.

  • En apps: interceptación controlada (proxy/SSL pinning donde aplique) + inventario de SDKs.

  • Herramientas rápidas para primera criba: Webbkoll y MDN Observatory (no sustituyen auditoría, pero ayudan a priorizar).

  • Si quieres un enfoque más “auditoría”: revisa el website auditing tool promovido en el contexto europeo (útil para automatizar hallazgos repetibles) y herramientas de inspección.

Resultado esperado (artefacto): un Registro de Terceros Web/App (TPRM Web) con dominio/endpoint → proveedor → finalidad → datos → país destino → trigger (evento) → condición (consent/no consent).

2) Decidir si es “transferencia”: el criterio que te van a exigir defender

Con cloud y proveedores globales, el debate frecuente es: ¿hay acceso desde tercer país? y ¿qué medidas compensan el riesgo?.

Para sostenerlo con rigor (y con el lenguaje que suelen usar los equipos de cumplimiento y auditoría):

Regla operativa para el post: si no puedes explicar en 2–3 frases (i) quién accede, (ii) desde dónde, (iii) con qué control criptográfico, (iv) con qué trazabilidad, te falta evidencia.

3) Documentarlo en TPRM: qué campos “de inspección” no pueden faltar

Integra la dimensión “transferencias y cloud” como un bloque obligatorio dentro del expediente TPRM del proveedor (y de cada subservicio relevante).

Campos mínimos (recomendados) por proveedor:

  1. Servicio exacto (producto/feature) y rol (responsable/encargado/subencargado).

  2. Mapa de datos: categorías + sensibilidad + volumen + frecuencia.

  3. Ubicación: hosting, soporte, operaciones y posibles accesos remotos.

  4. Cadena de subencargados (y cambios).

  5. Mecanismo de transferencia (adecuación / SCC / etc.) + anexos aplicables.

  6. Evaluación de impacto de la transferencia (TIA/AITD) y conclusión.

  7. Medidas complementarias (por tipo): cifrado, gestión de claves, seudonimización, minimización, split-processing, logging, control de acceso, etc.

  8. Evidencias (documentos y pruebas) + periodicidad de revisión.

Si trabajas con UK o proveedores británicos, apóyate en TRA como práctica operativa:

4) ¿Qué evidencias miran CNIL/AEPD/EDPB/ICO cuando inspeccionan?

Piensa en “evidencia demostrable”, no en “declaraciones”.

Evidencia técnica (la que suele cerrar discusiones):

  • Prueba de bloqueo preventivo: trazas HAR donde se vea que no hay llamadas a terceros antes del consentimiento (o antes de la condición aplicable).

  • Evidencia de configuración de tags/CMP (y del “modo rechazo” real).

  • Inventario de endpoints y dominios de terceros con responsables internos asignados.

  • Registros de cambios (GTM / release notes / control de cambios).

Evidencia legal y de TPRM:

  • Contrato + DPA + SCCs (si aplica) + anexos técnicos.

  • TIA/AITD y decisión de medidas complementarias.

  • Registro de subencargados y mecanismo de aprobación.

  • Evidencia de auditorías, revisiones periódicas y gestión de incidentes.

Evidencia de gobierno GRC:

  • Criterio de aceptación de riesgo (por qué aceptas/no aceptas).

  • KPI/KRI: nº de proveedores con transferencia, TIAs vencidas, endpoints no inventariados, etc.

  • Plan de remediación con fechas y responsables.

Nota práctica: incluso cuando el foco de entrada es “cookies/trackers”, las autoridades suelen escalar a medición de audiencia y a condiciones de uso de herramientas (si hay salida internacional, subencargados, o perfiles de riesgo).
Ejemplos de guías muy accionables:

5) Mini-checklist

Si hoy te inspeccionaran, ¿puedes mostrar…?

  • Lista de terceros reales (dominios/endpoints) de web y app, con owner interno.

  • Evidencia de bloqueo antes de consentimiento (HAR / pruebas).

  • Para cada tercero con salida potencial del EEE: SCCs/garantía + TIA/AITD + medidas.

  • Cadena de subencargados y cambios controlados.

  • Logs y control de cambios (GTM, releases, CMP).

  • Decisiones GRC: riesgo, aceptación, remediación, plazos.

Referencias base:

EDPB, Recommendations 01/2020, EDPB, Recommendations 02/2020, ICO, TRA, CNIL, AITD

Leocadio Marrero Trujillo