MatricúlateAuditoría continua de terceros en tu web y app: herramientas, muestreo, pruebas repetibles y reporting para Comité GRC
En los posts anteriores hemos dejado claro lo incómodo: tu web/app ya no es “tuya”. Es un ecosistema de terceros (tags, SDKs, CDNs, analítica, chat, fuentes, anti-fraude, AdTech…), y eso activa riesgos de cookies/trackers, transferencias internacionales “silenciosas”, cadenas de subencargados y decisiones técnicas que cambian… sin que Legal se entere.
El salto de madurez no es “cumplo” ni “tengo SCCs”. Es: puedo demostrarlo y lo controlo de forma continua.
Este post baja a práctica: cómo montar un programa de auditoría continua que aguante una inspección y que sea entendible por un Comité GRC.
1) El objetivo real: convertir “stack” en evidencia
Una auditoría continua de terceros no es un escaneo puntual. Es un sistema para:
Detectar cambios (nuevos endpoints, nuevos tags, cambios en CMP/GTM, SDKs).
Probar controles clave de forma repetible (pre-consent, reject/accept, minimización, destinos).
Generar un “expediente vivo”: evidencia técnica + evidencia legal/TPRM + decisiones GRC.
Reportar con KPI/KRI: qué está bajo control, qué no, y qué se acepta/remedia.
¿Por qué esto es relevante ahora? Porque varias autoridades han reforzado expectativas operativas sobre banners, elección real y cumplimiento efectivo, no solo documental. Por ejemplo, el enfoque de supervisión programática del ICO y el tipo de cartas/plantillas que envía muestran exactamente el “estilo” de evidencia que piden.
2) Define el perímetro: “qué audito” y “con qué frecuencia”
No intentes auditar todo cada semana. Define perímetro y criticidad.
Perímetro mínimo recomendado (web/app):
Tags/CMP (qué carga antes/después de consentir).
Inventario de endpoints y dominios de terceros.
Proveedores con potencial de transferencia fuera del EEE.
SDKs en app + destinos de red.
Trazabilidad de cambios (releases, GTM, CMP, configuración).
Frecuencia por riesgo (ejemplo operativo):
Alta criticidad (AdTech, session replay, conversión, fingerprinting, proveedores con transferencia): mensual o por release.
Media (analítica, A/B testing, chat): trimestral.
Baja (fuentes/íconos, mapas, embeds): semestral o por cambio.
Esto se alinea con lo que varias guías describen como “control efectivo” en cookies/analítica: no basta con declarar; hay que garantizar que la configuración real cumple.
3) Tooling: del escaneo rápido a la prueba auditable
Necesitas dos capas:
Capa A — descubrimiento rápido (priorización)
Webbkoll para ver terceros, requests y señales típicas.
Mozilla Observatory para postura básica (cabeceras, TLS, etc.) como evidencia complementaria.
Capa B — evidencia repetible (auditoría)
Herramienta de auditoría web del EDPB: prepara, ejecuta, evalúa y genera reportes.
Software/herramientas de inspección del EDPS y su recolector de evidencias: automatiza recolección sobre almacenamiento/transferencia y puede integrarse con el enfoque de auditoría web.
Nota clave GRC: el escaneo “A” te dice qué mirar. La evidencia “B” te permite decir esto es lo que ocurrió (y adjuntar pruebas).
4) Diseña tus “pruebas repetibles” (los 8 test cases que más rinden)
Piensa en pruebas que puedas ejecutar igual hoy y dentro de 3 meses.
Pre-consent: no se disparan tags/requests no necesarios antes de elegir.
Rechazar ≈ aceptar: la opción de rechazo es equivalente en facilidad/visibilidad a aceptar (y se ejecuta).
Persistencia de preferencia: la elección se respeta en páginas/sesiones.
Vendor list y finalidades: lo declarado coincide con lo que realmente se carga (no “vendors fantasma”).
Geografía: mismas reglas para IPs/idiomas relevantes (si aplican variantes).
Endpoints: los dominios que aparecen en tráfico están inventariados y “mapeados” a proveedor/finalidad.
Transferencias: si hay destino fuera del EEE o acceso remoto, existe TIA/TRA y medidas complementarias.
Cambios: cualquier alta de tag/SDK pasa por control (ticket + aprobación + evidencia post-implementación).
Guías y prácticas de autoridades refuerzan que el control debe ser real (configuración), especialmente en analítica/medición de audiencia.
5) Muestreo inteligente: cómo auditar sin ahogarte
Tu web no es una página; es un sistema. Audita por muestras bien justificadas.
Criterios de muestreo útiles:
Páginas con más tráfico (home, pricing, checkout, landing ads).
Páginas con mayor densidad de terceros (blog, embeds, formularios).
Flujos críticos (registro/login, compra, soporte, reclutamiento).
Experiencias con más riesgo (chatbot, pixel, A/B testing, session replay).
Triggers (auditoría “event-driven”):
Cambios en CMP/GTM.
Nueva campaña de marketing.
Nuevo proveedor (o nuevo subencargado).
Cambio de arquitectura (CDN/WAF, migración cloud).
Incidente o queja.
Esto es muy consistente con enfoques de “sweeps” y revisiones sectoriales que han hecho autoridades como la DPC, donde seleccionan webs y piden información para evaluar cumplimiento de cookies/trackers.
6) El “pack de evidencias” que deberías poder enseñar en 10 minutos
Aquí está el núcleo GRC. No es un documento: es un conjunto de artefactos.
Evidencia técnica
HAR “pre-consent / post-consent / reject” (3 archivos).
Reporte de herramienta de auditoría (EDPB/EDPS).
Capturas de configuración CMP (vendors/finalidades) y timestamp.
Export de contenedor de Google Tag Manager (o equivalente) + control de cambios.
Evidencia TPRM / transferencias
Ficha TPRM del proveedor: servicio exacto, rol, finalidad, datos, ubicaciones, subencargados.
SCCs / mecanismo aplicable y TIA/TRA con medidas.
Evidencia de criterio (cookies/analítica)
Checklist y documentación de configuración (p. ej., criterios de exención y autoevaluación).
Evidencia de gobernanza
Matriz de decisiones: riesgo → control → evidencia → responsable → caducidad.
Excepciones aprobadas (y por qué).
Plan de remediación con fechas.
7) Reporting a Comité GRC: KPI/KRI que sí mueven la aguja
No reportes “cumple/no cumple”. Reporta control y tendencia.
KPI sugeridos
% endpoints inventariados vs detectados.
% proveedores con ficha TPRM completa y vigente.
% TIAs/TRAs vigentes vs vencidas.
Tiempo medio de remediación de hallazgos críticos.
KRI sugeridos
Nº llamadas a terceros pre-consent detectadas.
Nº vendors “fantasma” (declaro X, cargo Y).
Nº cambios de tags sin ticket/aprobación.
Nº servicios con transferencia sin medidas complementarias evidenciables.
El resultado: un Comité que puede decidir (aceptar riesgo, priorizar remediación, parar una campaña) con datos.
8) Cierre: el estándar ya no es “tener papeles”
La tendencia clara es pasar de “papel” a “control verificable”. Un ejemplo muy ilustrativo (y reciente) de enforcement operativo es el trabajo de noyb y decisiones sobre tracking en contextos educativos, que vuelven a poner el foco en cookies no necesarias y falta de base.
Si tu auditoría continua está bien montada, puedes responder a la pregunta clave en inspección:
“¿Qué terceros tratan datos en mi web/app, cuándo se activan, bajo qué condiciones, a dónde van los datos, y qué evidencia tengo de que lo controlo?”
Bibliografía y recursos top (directos)
EDPB — Website Auditing Tool (noticia + página del recurso).
EDPS — Website Evidence Collector / repositorios.
ICO — Guidance on the use of storage and access technologies (PECR).
ICO — Cookie letters / template (muestra qué exigen corregir).
CNIL — Soluciones para medición de audiencia + herramienta de autoevaluación (PDF).
AEPD — Guía cookies analíticas externas (PDF).
DPC — Report on cookies and tracking technologies (2020).