Serie 1 (TPRM/Transfers) — Post 1 Cookies, trackers y analítica externa: el riesgo “TPRM” que más sanciones está generando (y cómo controlarlo)

Posted on by Leocadio Marrero Trujillo

Serie 1 (TPRM/Transfers) — Post 1 Cookies, trackers y analítica externa: el riesgo “TPRM” que más sanciones está generando (y cómo controlarlo)

En 2024–2025 se ha consolidado una realidad incómoda para muchas organizaciones: tu web o app puede “cumplir” en apariencia… y aun así incumplir por la vía de terceros.

No es solo “poner un banner”. El verdadero riesgo está en la cadena de dependencias (#Analytics, #AdTech, #CMP, Tag Managers, #CDNs, fuentes externas, #píxeles, #SDKs, A/B testing, mapas de calor, antifraude, chat, etc.) que terminan activando:

  • cookies y trackers antes del consentimiento,
  • transferencias internacionales no controladas,
  • corresponsabilidad o responsabilidad solidaria por diseño técnico,
  • pérdida de trazabilidad de evidencias (accountability imposible).

Desde una visión GRC, esto es #TPRM en estado puro: Third-Party Risk Management aplicado al front (web/app).

1) Por qué este tema es “TPRM” y no solo “cookies”

Un responsable #GRC no debe auditar banners: debe auditar el sistema completo de terceros que “vive” en la web/app y que, en la práctica, decide:

  • qué se ejecuta y cuándo,
  • quién recibe datos (y en qué país),
  • si hay tratamiento antes de base legal válida,
  • si podemos demostrar cumplimiento ante auditoría o inspección.

Esto explica por qué las autoridades ya no están actuando “caso a caso”, sino de forma masiva y proactiva.

Ejemplo muy significativo: el regulador británico ICO avisó públicamente a las organizaciones para “poner en orden” cookies publicitarias y confirmó acciones dirigidas a grandes websites (en línea con su actuación masiva iniciada en 2023). ➡️ Referencia: ICO, 2024 – “Proactively make advertising cookies compliant”

Lección GRC: cuando una autoridad pasa a un modo “sweep”, la pregunta ya no es si revisarán tu web, sino cuándo.

2) El mapa de riesgo real: “lo que no se ve” en tu web/app

En auditoría, los mayores incumplimientos no vienen del texto del banner, sino de estas 6 causas:

A) Activación previa a la elección del usuario (“pre-consent”)

  • Tags que se disparan al cargar la home.
  • “Consentimiento por defecto”.
  • Cookies que aparecen incluso tras pulsar “Rechazar”.

📌 Contexto jurídico clave: el consentimiento debe ser previo, informado y realmente libre. ➡️ Referencia estructural: TJUE, C-673/17

B) Rechazo más difícil que aceptar (asimetría)

Si el banner facilita “Aceptar” pero entierra “Rechazar” (o lo hace confuso), el riesgo aumenta: no es consentimiento válido, es “diseño de manipulación”.

C) “Analítica” que en realidad es seguimiento o transferencia

Muchas configuraciones de medición (especialmente externas) terminan enviando datos a proveedores fuera del EEE, o generando identificadores persistentes.

La CNIL (Francia) ha trabajado este punto de forma práctica publicando soluciones y criterios para herramientas de medición de audiencia. ➡️ Referencia: CNIL – “Cookies: solutions pour les outils de mesure d’audience”

D) Dependencias invisibles: CDNs, fuentes y librerías

El “supply chain” del front introduce riesgos típicos:

  • fuentes externas (fonts),
  • recursos de terceros,
  • scripts embebidos,
  • widgets de soporte,
  • píxeles.

Tu equipo puede no “verlos”… pero se ejecutan igualmente.

E) El problema no es el proveedor: es la gobernanza del tercero

El tercero puede “cumplir en su web”, pero tú eres quien lo activa desde tu dominio/app.

En términos de TPRM, el fallo típico es:

  • no inventario real de tags/SDKs,
  • no due diligence técnica,
  • no control contractual + verificación.

F) Evidencia débil: sin logs auditables no hay compliance defendible

Sin trazabilidad de:

  • versión del banner,
  • preferencias del usuario,
  • momento exacto de aceptación/rechazo,
  • activación y bloqueo técnico real,

…el cumplimiento se vuelve “declarativo”.

3) Lecciones de enforcement: lo que sancionan “de verdad”

Para entender el estándar real, hay que mirar sanciones y actuaciones públicas:

3.1. CNIL: sanción a American Express por cookies

La CNIL sancionó a American Express (Francia) por incumplimientos relacionados con cookies. Más allá del importe, lo importante es el patrón repetido: la autoridad castiga el diseño y la ejecución real, no la “intención”. ➡️ Referencias:

Lección GRC: una marca global puede tener equipos legales excelentes… y aun así fallar si el control técnico (y el control de terceros) no es operativo.

3.2. ICO: escalado masivo y enfoque “proactivo”

El ICO dejó claro que espera que las organizaciones corrijan antes de la sanción (“proactively”). Esto marca tendencia: la carga de la diligencia es preventiva. ➡️ Referencia: ICO – “Proactively make advertising cookies compliant”

Lección GRC: la inspección ya no es reactiva. Es un modelo de “supervisión continua”.

4) Marco GRC operativo: cómo gobernarlo en serio (sin burocracia)

Si tu organización quiere ir “a prueba de sanción”, este bloque se gestiona con un mini-sistema GRC de 6 piezas:

4.1) Inventario de terceros (TPRM real)

Una tabla viva y auditada de:

  • proveedor / tecnología,
  • finalidad (analítica, publicidad, medición, funcional),
  • base legal,
  • datos tratados (incluye identificadores),
  • países / transferencias,
  • subencargados,
  • evidencia técnica de bloqueo hasta consentimiento.

4.2) Control técnico verificable (no solo jurídico)

La regla no es lo que dice el banner: la regla es lo que se ejecuta en red.

Herramientas útiles para esto (rápidas y accionables):

Y a nivel institucional europeo:

4.3) Contrato + anexos “auditable-ready”

El contrato del tercero debe aterrizar en anexos verificables:

  • qué se activa,
  • cuándo se activa,
  • cómo se bloquea,
  • logs / evidencias,
  • subencargos.

4.4) Gestión de transferencias (si aplica)

Cuando hay proveedores fuera del EEE, el control GRC mínimo incluye:

  • identificación de transferencias,
  • mecanismo aplicable,
  • evaluación y medidas complementarias si procede.

4.5) KPIs de cumplimiento “web/app”

Ejemplos prácticos:

  • % tags bloqueados hasta consentimiento (objetivo 100%)
  • Imagen: IAImagen: IAnº de terceros con inventario completo
  • nº de cambios en el Tag Manager sin aprobación
  • tiempo de corrección tras hallazgo (SLA)

4.6) Auditoría periódica y evidencia reproducible

Sin evidencia, no hay defensa. Por eso, este tema se conecta con ISO 19011: planificación, muestreo, trazabilidad y conclusiones robustas.

5) Checklist mínimo (para que tu equipo lo aplique mañana)

Si quieres una versión ejecutiva para dirección, usa estas 10 preguntas:

  1. ¿Tenemos inventario completo de terceros (web/app)?
  2. ¿Sabemos qué tags/SDKs se ejecutan antes de consentir?
  3. ¿Rechazar es igual de fácil que aceptar?
  4. ¿La analítica está justificada y configurada para minimizar?
  5. ¿Hay transferencias internacionales? ¿Están gobernadas?
  6. ¿Hay subencargados no declarados?
  7. ¿Podemos demostrar evidencia “en red” (requests/logs)?
  8. ¿Existe control de cambios (Tag Manager / Releases)?
  9. ¿Los contratos aterrizan en requisitos técnicos verificables?
  10. ¿Hacemos auditoría periódica y seguimiento de hallazgos?

Bibliografía recomendada (selección “top”)

Leocadio Marrero Trujillo