Auditar tu web y app: cómo revisar cookies, trackers, IA y decisiones automatizadas con enfoque GRC (alineado con ISO 19011)

Muchas organizaciones creen que “cumplir” en su web o app es solo tener un banner de cookies, una política de privacidad y un checkbox de consentimiento.

Pero si miramos lo que están haciendo las autoridades —CNIL con sanciones a Condé Nast [CNIL, SAN-2025-010], YAHOO [CNIL, SAN-2023-024], American Express [CNIL, AMEX Cookies], AEPD con casos como Massimo Dutti [AEPD, PS-00051-2023], el ICO con su carta a los “Top 100 websites” [ICO, Cookie Letter 2023], o los barridos de dark patterns en GPEN [GPEN, Sweep 2024]— el mensaje es otro:

Las webs y apps son hoy un objeto central de auditoría de privacidad, seguridad y cumplimiento.

Y si no las auditas tú con rigor, lo acabará haciendo otra autoridad… o un litigante.

En este artículo vamos a aterrizar cómo auditar una web/app desde la visión GRC (Gobernanza, Riesgo y Cumplimiento), apoyándonos en:

  • RGPD + ePrivacy (cookies/trackers, comunicaciones electrónicas).
  • LOPDGDD y LSSI-CE, en clave española.
  • Guías y resoluciones de autoridades (AEPD, CNIL, ICO, APD BE, AP NL, etc.).
  • Buenas prácticas de auditoría según ISO 19011 y estándares de auditoría interna.

1. ¿Por qué auditar tu web y app como si fuera “un proceso crítico más”?

Tu web/app ya no es un simple canal de marketing:

  • Deposita cookies y trackers que pueden construir perfiles muy finos de comportamiento.
  • Integra terceros (analítica, fuentes de letra, CDNs, CMPs, chatbots, pasarelas de pago, pixels publicitarios…).
  • Usa o usará IA/LLMs y chatbots que pueden decidir, recomendar, bloquear, priorizar.
  • Toma o influye decisiones que pueden entrar en el ámbito de perfilado y decisiones automatizadas (art. 22 RGPD).

Al mismo tiempo, las autoridades:

  • Sancionan por no bloquear cookies hasta tener consentimiento (CNIL, AMEX; CNIL, Condé Nast; CNIL, Yahoo).
  • Reprueban banners engañosos (dark patterns: aceptar en un clic, rechazar en tres; colores sesgados).
  • Publican cartas masivas (como el ICO a los top 100 sitios) señalando patrones técnicos concretos a corregir.
  • Analizan patrones adictivos, engañosos y dark patterns [AEPD, Patrones Adictivos; CNIL, Dark Patterns; GPEN, Dark Patterns Sweep].

Desde la óptica GRC, la conclusión es clara:

Tu web/app es un activo de riesgo que debe estar en el mapa de riesgos, el RAT, el programa de auditoría y los planes de mejora.

2. Marco de auditoría: unir RGPD, ePrivacy y ISO 19011

Para auditar webs y apps con rigor, conviene apoyarse en tres capas:

  1. Normativa y criterios de cumplimiento
    • RGPD (principios, art. 5; transparencia, art. 12-14; bases jurídicas; art. 22 decisiones automatizadas; art. 25 privacidad desde el diseño).
    • ePrivacy / LSSI-CE (cookies, comunicaciones electrónicas).
    • LOPDGDD (derechos digitales, dispositivos, videovigilancia, etc.).
    • Guías y criterios de autoridades: AEPD, CNIL, ICO, APD BE, AP NL, Datatilsynet, etc.
  2. Estándares de auditoría y sistemas de gestión
    • ISO 19011 (directrices para auditoría de sistemas de gestión):
      • Principios de auditoría (integridad, presentación imparcial, diligencia profesional, confidencialidad, independencia, enfoque basado en evidencias y riesgos).
      • Gestión de programas de auditoría.
      • Planificación, ejecución, informes y seguimiento.
    • Sinergias con ISO/IEC 27001, 27701, 42001, 37301, etc., si la organización los tiene implantados.
  3. Buenas prácticas técnicas
    • Revisión de implementación de CMPs, scripts, tags, integraciones de terceros.
    • Pruebas funcionales: navegación, aceptación/rechazo cookies, uso de chatbots, formularios, webs móviles y apps.
    • Herramientas de escaneo (no como sustituto, sino como apoyo a la revisión manual).

3. Fase 1 – Preparar la auditoría: alcance, criterios y riesgos

Siguiendo ISO 19011, lo primero es definir el alcance de la auditoría web/app:

  • ¿Solo sitio corporativo?
  • ¿También subdominios, landings de campañas, microsites, blog, tienda online, área privada?
  • ¿Incluye apps móviles (iOS/Android) y PWA?
  • ¿Incluye APIs expuestas a terceros?

a) Definir criterios de auditoría

  • RGPD + ePrivacy + LOPDGDD + LSSI-CE.
  • Guías específicas (cookies, dark patterns, chatbots, IA, scraping, DPIA, etc.).
  • Políticas internas (privacidad, seguridad, desarrollo seguro, cookies, uso de IA).
  • Compromisos contractuales (cláusulas con terceros, SLAs, DPA con proveedores de analítica/IA/hosting).

b) Analizar riesgos antes de auditar

  • ¿La web/app usa cookies de marketing, analítica avanzada, fingerprinting, pixels?
  • ¿Integra chatbots, IA, scoring, motores de recomendación?
  • ¿Procesa datos de colectivos vulnerables (menores, enfermos, deudores, etc.)?
  • ¿Se utilizan transferencias internacionales, CDNs o proveedores extracomunitarios?

Con ello, priorizas dónde poner más profundidad de revisión, en línea con el enfoque basado en riesgos de ISO 19011.

4. Fase 2 – Trabajo de campo: qué mirar (y cómo) en una auditoría web/app

Aquí es donde bajamos a la práctica. Algunos ejes clave:

4.1. Cookies, trackers y banner de consentimiento

  • Antes de cualquier acción del usuario, comprobar:
    • Qué cookies/trackers se cargan (navegador + herramientas de red).
    • Si son estrictamente necesarias o no.
    • Si hay scripts de terceros que disparan cookies sin control.
  • Revisión del banner:
    • ¿Hay botón “Aceptar todo” y otro “Rechazar todo” igual de visible?
    • ¿Se usan patrones oscuros (colores, tamaños, rutas más largas para rechazar)?
    • ¿El usuario puede gestionar preferencias por finalidad?
  • Verificar que rechazar implica:
    • No cargar cookies no esenciales.
    • No disparar llamadas a terceros que permitan seguir rastreando.
  • Comparar con lecciones de casos CNIL, AEPD, ICO y NOYB (donde se sanciona precisamente la falta de igualdad en aceptar/rechazar o el “consentimiento forzado”).

4.2. Formularios, scraping y terceros

  • Formularios de contacto, registro, newsletter, CV, soporte, etc.:
    • Minimización de datos.
    • Información en el propio formulario (quién, para qué, base jurídica, derechos).
    • Checks de consentimiento específicos, no pre-marcados.
  • Terceros:
    • Analítica (Google Analytics u otros).
    • CMPs, CDNs, fuentes, plugins sociales, reproductores de vídeo, pasarelas de pago.
    • ¿Se ha evaluado su rol (encargado/corresponsable/tercero independiente)?
    • ¿Hay contratos de encargo y cláusulas de transferencia?
  • Scraping y reuso de datos:
    • ¿Se están recopilando datos de otras webs/redes sociales (web scraping) para enriquecer perfiles?
    • ¿Se han aplicado las directrices de autoridades y grupos internacionales sobre scraping y reutilización de datos?

4.3. Chatbots, IA y lógica algorítmica

  • ¿El chatbot solo informa o también decide, filtra, prioriza?
  • ¿Puede influir en el resultado de una solicitud, reclamación o contratación?
  • ¿Se informa claramente al usuario de que está ante un chatbot/IA, qué datos se usan y con qué fines?
  • ¿Se reutilizan las conversaciones para entrenar modelos? ¿Con qué base jurídica?
  • ¿Hay mecanismos reales de escalado a humano, supervisión y revisión?

4.4. Perfilado y decisiones automatizadas

  • Identificar:
    • Regla de scoring fraude/negocio.
    • Lógicas que aceptan/rechazan automáticamente.
    • Segmentaciones que limitan acceso, condiciones o precios.
  • Revisar:
    • ¿Se ha analizado si entran en el ámbito del art. 22 RGPD?
    • ¿Hay salvaguardas (intervención humana, recurso, explicación comprensible)?
    • ¿Se ha realizado EIPD/DPIA si el riesgo es alto?

5. Fase 3 – Evidencias, hallazgos y clasificación GRC

Siguiendo ISO 19011, la auditoría debe basarse en evidencias verificables, no en impresiones:

  • Capturas de pantalla, HAR files, listados de cookies/trackers.
  • Registros de prueba (navegaciones con distintas opciones de consentimiento).
  • Ejecución de casos de prueba de chatbots y flujos algorítmicos.
  • Contratos, políticas internas, matrices de riesgos, EIPD/DPIA, logs de revisión, etc.

Luego, clasificar los hallazgos:

  • No conformidades (incumplimiento claro de norma/criterio).
  • Observaciones (riesgos emergentes o debilidades).
  • Oportunidades de mejora (madurez, eficiencia, mejor UX cumpliendo más).

Y siempre conectándolos con:

  • Riesgos para derechos y libertades de las personas.
  • Riesgos para la organización (sanciones, reputación, contratos, litigios).

6. Fase 4 – Plan de acciones y ciclo de mejora continua

Una buena auditoría no termina con el informe, sino con un plan de acciones que:

  • Priorice según riesgo y esfuerzo.
  • Defina responsables, plazos y recursos.
  • Incluya quick wins (ej. corregir banner de cookies) y cambios estructurales (política de desarrollo, gestión de terceros, gobierno de IA).
  • Se integre en la gestión de riesgos y en el programa anual de auditoría interna.

En organizaciones con sistemas de gestión ISO (27001, 27701, 42001, 37301…), esto alimenta el ciclo PDCA y refuerza:

  • La rendición de cuentas (“accountability”).
  • La capacidad de defensa ante una autoridad de control.
  • La alineación entre jurídico, tecnología, negocio y seguridad.

7. Conclusión: auditar la web/app es invertir en resiliencia regulatoria

El mensaje que llega hoy desde autoridades, tribunales, guías y estudios es contundente:

  • Los sitios web y apps ya no son un “detalle” de cumplimiento: son uno de los primeros lugares donde se mira cuando hay un incidente o una investigación.
  • Las sanciones por cookies, dark patterns, scraping, chatbots e IA muestran patrones repetidos de falta de diseño, gobernanza y auditoría.

Desde GRC, la respuesta pasa por:

  • Tratar la web/app como activo crítico.
  • Integrarla en el mapa de riesgos, RAT, EIPD y programa de auditoría.
  • Aplicar un enfoque sistemático, profesional y basado en ISO 19011 y en buenas prácticas internacionales de auditoría.

El objetivo no es tener una web “sin riesgo”, sino una web bien gobernada, explicable, auditable y defendible cuando haya que dar explicaciones.

 

8. Bibliografía

Bloque 1. «Web & Apss desde la óptica GRC». Post 1 «Cookies: de aviso molesto a «problema muy serio». Cookies, banners y sanciones millonarias