Cuando el tercero “pone la cookie”: TPRM real y responsabilidad compartida (más allá del contrato)

En muchas organizaciones, el riesgo web se gestiona como si fuera “solo” un tema de banner y consentimiento. Pero la realidad regulatoria y judicial está yendo en otra dirección:

Si un tercero participa en el depósito/lectura de cookies o identificadores, el riesgo (y la posible responsabilidad) ya no se queda solo en el editor del sitio.

Este Post 3 baja al terreno de TPRM operativo (Third-Party Risk Management): cómo gobernar en serio a los proveedores que “tocan” tu web/app (AdTech, analítica, tag managers, CDPs, personalización, antifraude, chatbots, etc.), y qué controles debes exigir para sobrevivir a una auditoría (o a un litigio).

 

1) El caso que cambia el enfoque: OLG Frankfurt (6 U 81/23)

Una sentencia reciente del Tribunal Superior Regional de Frankfurt es especialmente valiosa porque rompe un “mito” muy extendido:

“Si el proveedor dice que solo se activa con consentimiento, yo ya estoy cubierto.”
No basta.

En el caso, el tribunal concluye (en esencia) que:

  • No se puede depositar/leer un cookie con fines de tracking sin consentimiento informado.
  • Un proveedor tercero que participa en ese depósito puede responder (no solo el dueño de la web).
  • Incluso habiendo contrato, si técnicamente se deposita sin consentimiento, hay problema.
  • El tribunal reconoce indemnización (en el caso, 100 €) por el impacto del seguimiento sin consentimiento. (rv.hessenrecht.hessen.de)

📌 Referencias directas (para hemeroteca y cita):

Lección GRC brutal:
👉 El TPRM web exige controles verificables, no promesas contractuales.

2) Marco legal mínimo (para justificar el control en auditoría)

Aunque en cada país haya matices (ePrivacy, leyes nacionales tipo TTDSG/TDDDG), el “núcleo duro” europeo que debes tener presente es:

A) Consentimiento real y demostrable (no “diseño de marketing”)

El TJUE en Planet49 (C-673/17) dejó muy consolidado que el consentimiento debe ser activo, y que hay obligaciones claras de información (incluida duración y acceso de terceros). (otto-schmidt.de)

B) “La web recolecta más de lo que crees”

En asuntos como C-252/21 Meta Platforms, el TJUE entra en la lógica de recolección de datos a través de interfaces integradas y tecnologías de tracking, elevando el foco sobre cómo se capturan datos “en cadena” entre actores. (curia)

3) El problema real: tu web es un “ecosistema de terceros”

En auditoría, el fallo típico no es “no pusimos banner”, sino:

  • Scripts que se cargan antes del consentimiento (pre-consent leakage)
  • Tags disparados por eventos invisibles (scroll, time-on-page, clicks)
  • Cambios en GTM por marketing sin control de cambios
  • Proveedores que subencargan (y tú no lo sabes)
  • Transferencias internacionales “silenciosas” (CDNs, píxeles, fuentes, chat widgets)

✅ Y esto es exactamente lo que convierte el tema en TPRM:
no controlas tu cumplimiento si no controlas a tus terceros.

 

4) Controles “de verdad” para TPRM en web/app (modo auditor ISO)

Aquí va el bloque práctico. Si yo estuviera auditando tu organización, te pediría evidencias de estos puntos:

4.1 Inventario técnico real (no solo contractual)

Lo mínimo exigible:

  • Registro de proveedores web (AdTech / analítica / chat / antifraude / A/B testing / CMP / mapas de calor).
  • Finalidad, base de licitud, cookies/IDs, y momento exacto de activación.
  • Entorno (web / app / staging / prod).

📌 Evidencia fuerte: export de red (HAR) + escaneo de tags + lista de endpoints.

4.2 “Consent Gate” obligatorio (control estructural)

Este es el control que te salva en serio:

No hay consentimiento → no se dispara el tercero.

No solo “ocultarlo visualmente”. Debe estar bloqueado técnicamente hasta que el usuario consienta.

Evidencias top:

  • Configuración CMP con bloqueo previo (pre-consent).
  • Pruebas repetibles: “rechazo todo” → 0 llamadas a terceros no necesarios.

4.3 Prueba de consentimiento (Accountability real)

En un procedimiento, lo que mata es esto: “No puedo demostrarlo”.

Apóyate en estándares para madurez (muy alineado con nuestra serie):

  • ISO/IEC 29184 (avisos y consentimiento online)
  • ISO/IEC TS 27560 (estructura de registro/recibo de consentimiento)

📌 Evidencia fuerte:

  • Logs de consentimiento con versión de banner/texto, timestamp, finalidades aceptadas, y cambios.

4.4 Gestión de cambios: marketing NO puede “romper” cumplimiento

El 80% de los problemas graves vienen por cambios no controlados en:

  • Google Tag Manager
  • Integraciones de píxeles
  • Widgets embebidos
  • SDKs y plugins

✅ Control mínimo:

  • “Pull request” o workflow de aprobación para cambios de etiquetas
  • Revisión por Privacy/GRC cuando hay nuevos terceros o nuevas finalidades

4.5 Auditoría del proveedor (derecho a verificar, no solo a confiar)

En contratos TPRM web, exige:

  • Derecho de auditoría / verificación
  • Subencargados y cadena de transferencias
  • Medidas técnicas y organizativas
  • Compromiso de no activación sin señal de consentimiento válida
  • Kill switch (capacidad de desconectar rápido el tercero)

🔎 El caso OLG Frankfurt refuerza exactamente esta lógica: la práctica técnica manda sobre el papel. (rv.hessenrecht.hessen.de)

5) Toolkit de verificación (rápido, objetivo y repetible)

Herramientas muy útiles para tu rutina GRC:

(Estas herramientas no sustituyen al análisis legal, pero dan evidencia técnica muy potente para auditoría.)

6) Mini-checklist (si solo haces 10 cosas, haz estas)

  1. ✅ Inventario real de terceros web/app (con finalidad + endpoints)
  2. ✅ Consent gate técnico “pre-consent”
  3. ✅ Prueba de rechazo = 0 llamadas indebidas
  4. ✅ Registro auditable de consentimiento (versionado)
  5. ✅ Control de cambios sobre tags y scripts
  6. ✅ Revisión de subencargados y transferencias
  7. ✅ “Kill switch” y plan de respuesta rápida
  8. ✅ Auditoría periódica con herramientas de escaneo
  9. ✅ Política interna: “sin aprobación, no se integra proveedor”
  10. ✅ Evidencias listas para inspección (capturas, HAR, logs)

Bibliografía y recursos (citas directas)