Adaptación GDPR y gestión de cookies en más de 10 sites del Grupo Damm con Drupal

En 2021, el Grupo Damm necesitaba adaptar más de 10 sites corporativos y de marca a la normativa europea de cookies y protección de datos (GDPR/RGPD). El reto: implementar una solución homogénea en un ecosistema diverso de webs construidas sobre Drupal, cada una con su propia identidad visual y requisitos funcionales.

Este caso sigue siendo, cinco años después, uno de los que más consultas nos genera: la mayoría de grupos empresariales con varias marcas se enfrentan al mismo problema de gobernanza, y la normativa no ha hecho más que endurecerse desde entonces. Por eso lo hemos actualizado con el contexto regulatorio de 2026 (guía de cookies de la AEPD, Consent Mode v2, Drupal 11 y el fin de soporte de Drupal 10) y con lo que hemos aprendido aplicando el mismo enfoque en otros ecosistemas multi-site.

El reto: GDPR en un ecosistema multi-site

La regulación europea de protección de datos exige que cada sitio web ofrezca al usuario un control granular sobre las cookies que acepta: analíticas, de marketing, funcionales y necesarias. Con más de 10 sites activos — desde marcas de cerveza hasta aguas minerales y logística — el desafío no era solo técnico, sino de gobernanza: cada site debía cumplir la misma normativa pero respetando su diseño y estructura particular.

Qué exige realmente la normativa

Conviene separar las dos capas legales que suelen mezclarse. El RGPD (Reglamento 2016/679, aplicable desde mayo de 2018) regula el tratamiento de datos personales y define qué es un consentimiento válido: libre, específico, informado e inequívoco, otorgado mediante una acción afirmativa clara. La LSSI (artículo 22.2) es la norma española que traspone la directiva ePrivacy y obliga a informar y obtener consentimiento antes de instalar cookies no necesarias. La guía de cookies de la AEPD aterriza ambas en criterios concretos: qué debe mostrar el banner, cómo deben presentarse las opciones y cuánto puede durar un consentimiento (recomendación de no superar los 24 meses).

En 2021, cuando arrancó el proyecto, la guía vigente ya exigía que no se cargara ninguna cookie no esencial antes del consentimiento y que existiera un panel de configuración por categorías. Lo que todavía se toleraba era que la opción de rechazar quedara en una segunda capa. Ese margen desapareció con la revisión de la guía de julio de 2023, de obligado cumplimiento desde el 11 de enero de 2024: rechazar debe ser tan fácil como aceptar, con un botón de «Rechazar» en la primera capa y con el mismo protagonismo visual que «Aceptar». Los llamados dark patterns (botón de aceptar en color y el de rechazar como enlace gris, por ejemplo) invalidan el consentimiento y exponen a sanción.

Por qué un grupo multi-marca lo tiene más difícil

En una única web el problema se resuelve con un plugin o un CMP comercial y una tarde de configuración. En un grupo con más de diez dominios, cada uno con su agencia de marketing, su Google Tag Manager, sus píxeles y su calendario de campañas, el riesgo se multiplica: basta que un site cargue un píxel de Meta antes del consentimiento para que todo el grupo quede expuesto. Y las sanciones no son teóricas: la AEPD publica resoluciones con multas de decenas de miles de euros por banners que no ofrecen rechazo en primera capa o que instalan cookies analíticas antes de que el usuario decida. Lo que necesitaba el Grupo Damm no era «un banner», sino una política de consentimiento aplicada de forma uniforme y verificable en todo el ecosistema, algo que explicamos con más detalle en nuestro artículo sobre estrategias Drupal multisite para gestionar varias webs desde una sola plataforma.

Solución técnica en Drupal

Desarrollamos un módulo de consentimiento de cookies reutilizable en Drupal que se integró como componente transversal en todos los sites del grupo. La solución incluía:

• Banner de cookies personalizable por site, adaptado a la identidad visual de cada marca sin duplicar código.
• Panel de preferencias granular donde el usuario elige qué categorías de cookies acepta (necesarias, analíticas, marketing, funcionales).
• Bloqueo previo de scripts — ninguna cookie no esencial se carga hasta que el usuario da su consentimiento explícito, garantizando el cumplimiento estricto del RGPD.
• Registro de consentimientos con marca temporal para auditorías legales.
• Integración con GTM — el módulo comunica el estado de consentimiento a Google Tag Manager para activar o desactivar tags según las preferencias del usuario.

Cómo se diseñó el módulo para ser transversal

Sin entrar en detalles propietarios del cliente, el patrón que aplicamos es reproducible en cualquier instalación Drupal y merece la pena describirlo, porque es lo que marca la diferencia entre un proyecto que se mantiene solo y uno que hay que rehacer cada vez que cambia la normativa.

El módulo se construyó como un módulo custom con configuración exportable (Configuration Management), de modo que la política de categorías, los textos legales base y la lógica de bloqueo viven en código versionado, y cada site solo sobreescribe lo que le es propio: colores, tipografía, posición del banner, textos de marca y el identificador de su contenedor de GTM. Esa separación entre «política» y «presentación» es la que permitió desplegar el mismo módulo en sites con temas completamente distintos sin tocar una línea de PHP en cada uno.

El bloqueo previo de scripts se resolvió en dos frentes. Por un lado, en el lado del servidor: los scripts de terceros gestionados por Drupal (librerías adjuntas al tema o a otros módulos) se registran con una categoría y solo se adjuntan a la página si existe consentimiento para ella. Por otro, en el navegador: cualquier script que llegue por otras vías (GTM, código incrustado por marketing) se inserta con un tipo MIME neutro y un atributo de categoría, y el módulo los reactiva únicamente cuando el usuario acepta. Ese doble control es lo que garantiza que un píxel añadido a última hora por una agencia externa no rompa el cumplimiento.

El registro de consentimientos guarda, por cada decisión, un identificador anónimo, la versión de la política aceptada, las categorías elegidas y la marca temporal. No almacena la IP en claro ni datos que permitan identificar al usuario más allá de lo necesario para acreditar el consentimiento, siguiendo el principio de minimización del propio RGPD. Es el registro que un DPO necesita para responder a un requerimiento de la AEPD o a una auditoría interna del tipo que describimos en nuestra guía de controles organizativos de ISO 27001.

Despliegue coordinado

El proyecto se ejecutó en 2 meses, coordinando el despliegue en más de 10 sites de forma escalonada. Cada site requirió su propia fase de testing para verificar que el bloqueo de cookies funcionaba correctamente con los scripts específicos de cada marca (pixels de Facebook, analytics personalizados, herramientas de A/B testing).

La clave fue diseñar la arquitectura del módulo como un componente desacoplado que se configuraba vía panel de administración de Drupal, sin necesidad de tocar código en cada despliegue individual.

El plan de despliegue, site a site

El orden de despliegue no fue arbitrario. Se empezó por un site corporativo con poco tráfico de campaña y pocos scripts de terceros, que sirvió de piloto para validar el módulo y el procedimiento de pruebas. Después se abordaron los sites de marca de mayor complejidad, agrupados por agencia de marketing responsable, para que cada agencia tuviera que revisar su inventario de tags una sola vez. Los últimos fueron los sites con integraciones más delicadas (formularios conectados a CRM, promociones con registro), donde un bloqueo demasiado agresivo podía romper funcionalidad de negocio.

Para cada site se siguió el mismo protocolo: inventario de cookies y scripts en un entorno de pruebas (con herramientas de auditoría automática y navegación manual), clasificación de cada elemento en su categoría, configuración del módulo, verificación de que sin consentimiento no se escribía ninguna cookie no necesaria, verificación de que cada categoría activaba exactamente lo que debía y, por último, comprobación de que revocar el consentimiento eliminaba las cookies ya instaladas. Solo entonces se pasaba a producción, normalmente en franja de bajo tráfico y con la posibilidad de desactivar el módulo en segundos si aparecía algo inesperado.

Resultado

Todos los sites del Grupo Damm quedaron plenamente adaptados a la normativa GDPR con una solución coherente, mantenible y escalable. El módulo sigue activo y se ha reutilizado para nuevos sites incorporados al ecosistema del grupo posteriormente.

Lo que ha cambiado desde 2021 y cómo afecta a una solución así

Un proyecto de cumplimiento no termina en el despliegue; la normativa y las plataformas se mueven. Estos son los cambios relevantes que cualquier módulo de consentimiento desplegado hace unos años debe haber incorporado ya:

• Botón de rechazo en primera capa (enero de 2024). Es el cambio más visible de la guía de la AEPD. Un módulo con la presentación desacoplada de la lógica lo absorbe con un ajuste de plantilla y textos, sin rehacer nada. Los que tenían el banner «hardcodeado» en cada tema tuvieron que tocar diez sites.
• Google Consent Mode v2 (marzo de 2024). Google exige que los sites que usen sus productos publicitarios en el Espacio Económico Europeo le comuniquen el estado de consentimiento mediante las señales ad_storage, analytics_storage, ad_user_data y ad_personalization. Como el módulo ya hablaba con GTM a través de la dataLayer, añadir las dos señales nuevas fue una extensión natural de la integración existente.
• Caducidad del consentimiento. La AEPD recomienda renovar el consentimiento al menos cada 24 meses y siempre que cambie la finalidad. El registro con versión de política permite forzar la re-solicitud de forma selectiva cuando se añade una categoría o un proveedor nuevo.
• Accesibilidad del propio banner. Con la Ley Europea de Accesibilidad en vigor desde junio de 2025, el banner de cookies es a menudo el primer elemento con el que interactúa un usuario, y debe ser operable con teclado y lector de pantalla. Lo tratamos en detalle en accesibilidad web y GDPR en Drupal y en nuestra guía sobre la EAA y la accesibilidad web obligatoria.
• Versiones de Drupal. El módulo nació en la era Drupal 8/9. Hoy la base recomendada es Drupal 11 (11.4 desde junio de 2026), Drupal 10 llega a su fin de vida el 9 de diciembre de 2026 y Drupal 12 está previsto para esa misma semana. Un módulo custom bien construido (sin dependencias de APIs obsoletas, con tests) se actualiza entre versiones mayores en horas; uno improvisado puede bloquear la migración de todo el grupo. Si todavía estás en Drupal 10, nuestra guía de migración a Drupal 10 y el análisis de las novedades de Drupal 11 te ayudarán a planificar el salto.

Módulo propio o CMP comercial: qué elegir en 2026

La pregunta que nos hacen con más frecuencia al leer este caso es si hoy volveríamos a desarrollar un módulo propio o recomendaríamos un CMP de mercado (Cookiebot, Didomi, OneTrust, Usercentrics y similares). La respuesta honesta es que depende de tres factores.

El primero es el número de sites y su heterogeneidad. Un CMP comercial cobra por dominio o por volumen de páginas vistas; en un grupo con más de diez dominios de alto tráfico, la factura anual puede superar con holgura el coste de desarrollar y mantener un módulo propio. El segundo es el grado de control que necesita el departamento legal: un módulo propio permite auditar exactamente qué se guarda, dónde y durante cuánto tiempo, y adaptar el registro a las exigencias del DPO sin esperar a que el proveedor añada la función. El tercero es la capacidad de mantenimiento: un CMP externaliza la vigilancia normativa (cuando la AEPD cambia un criterio, el proveedor actualiza el banner), mientras que un módulo propio exige que alguien siga la normativa y aplique los cambios, tarea que en nuestros clientes suele quedar cubierta por el contrato de mantenimiento de software.

Un enfoque intermedio, cada vez más habitual, es usar el módulo contribuido de Drupal para la capa de bloqueo y categorización (la comunidad mantiene varios maduros y compatibles con Drupal 11) y desarrollar únicamente la capa de gobernanza multi-site y el registro de consentimientos a medida. Se reduce el código propio sin renunciar al control sobre los datos.

Checklist de cumplimiento de cookies para un grupo multi-site

Si gestionas varias webs y quieres saber si estás al día, estas son las comprobaciones que hacemos en una auditoría técnica antes de proponer cambios:

• Sin interacción con el banner, ¿se escribe alguna cookie que no sea estrictamente necesaria? Comprobarlo en cada dominio y en cada idioma, no solo en la home.
• ¿Existe un botón «Rechazar» en la primera capa, con el mismo tamaño, color y posición que «Aceptar»?
• ¿Se puede modificar o retirar el consentimiento en cualquier momento desde un enlace visible en el pie de página, y al retirarlo se eliminan las cookies ya instaladas?
• ¿La política de cookies enumera cada cookie con su finalidad, proveedor y duración, y coincide con lo que realmente se instala? La divergencia entre la política escrita y la realidad técnica es el hallazgo más común.
• ¿Se envían las señales de Consent Mode v2 a Google y se respeta el estado de consentimiento en el resto de plataformas publicitarias?
• ¿Existe un registro de consentimientos exportable, con versión de política y marca temporal, que permita acreditar una decisión concreta ante un requerimiento?
• ¿Hay un procedimiento para que marketing añada un nuevo tag o píxel sin saltarse el bloqueo? Si la respuesta es «confiamos en que avisen», no hay procedimiento.
• ¿El banner es accesible (foco visible, operable con teclado, etiquetas para lector de pantalla) y no tapa contenido esencial en móvil?

Si además tu grupo está sujeto a ISO 27001 o al Esquema Nacional de Seguridad, la gestión del consentimiento y de los scripts de terceros encaja directamente en los controles técnicos de desarrollo seguro: un script de terceros que se carga sin control es tanto un problema de privacidad como de seguridad de la cadena de suministro.

Si tu empresa gestiona múltiples sites y necesita una solución GDPR centralizada — ya sea para sites corporativos o plataformas ecommerce —, contacta con nuestro equipo para diseñar una estrategia de cumplimiento a medida.

Preguntas frecuentes

¿Es obligatorio el botón de rechazar en la primera capa del banner?

Sí. Desde el 11 de enero de 2024 la guía de la AEPD exige que rechazar sea tan sencillo como aceptar, con un botón equivalente en la primera capa. Un banner con «Aceptar» y «Configurar» ya no es válido en España.

¿Un módulo de consentimiento sirve para cumplir también con Consent Mode v2?

Sirve si comunica a Google Tag Manager, además del estado de las categorías, las señales ad_user_data y ad_personalization. Si el módulo es anterior a 2024 y no se ha actualizado, lo más probable es que solo envíe las dos señales originales y que las campañas de Google Ads estén perdiendo datos de conversión o incumpliendo.

¿Cuánto tiempo lleva adaptar un grupo de diez sites Drupal?

En el caso del Grupo Damm, dos meses con despliegue escalonado. El tiempo depende menos del desarrollo del módulo que del inventario de scripts de cada site y de la coordinación con las agencias que los gestionan; con una plantilla de auditoría y un site piloto bien elegido, el resto se convierte en un proceso repetible.

¿Qué pasa con los sites que siguen en Drupal 7 o Drupal 9?

Drupal 7 y Drupal 9 llevan tiempo sin soporte de seguridad, y Drupal 10 lo pierde el 9 de diciembre de 2026. Un módulo de consentimiento no resuelve el problema de fondo de una plataforma sin parches; en esos casos planteamos primero la migración y aprovechamos para desplegar el consentimiento en la versión de destino, en lugar de invertir en adaptar código que se va a tirar.