Dos regulaciones de la UE, dos trabajos distintos
Es fácil meter en el mismo saco al GDPR y al Cyber Resilience Act (CRA) de la UE —ambos son regulaciones europeas, ambos llevan multas serias, y ambos se mencionan en las mismas conversaciones de "checklist de cumplimiento". Pero regulan cosas genuinamente distintas, y tratarlos como intercambiables deja brechas reales.
El GDPR trata sobre datos: qué información personal recoges, por qué, cuánto tiempo la conservas, y qué derechos tienen las personas detrás de esos datos. El CRA trata sobre seguridad del software: con qué nivel de seguridad está construido un producto digital, cómo se divulgan las vulnerabilidades, y cómo se entregan las actualizaciones de seguridad durante la vida del producto.
Un sitio WordPress puede ser totalmente conforme al GDPR —consentimiento de cookies correcto, política de privacidad clara, acuerdos de tratamiento de datos— y no tener nada de lo que el CRA espera. Lo contrario también es cierto. No son casillas que se superponen en la misma lista; son dos listas separadas.
Lo que realmente cubre el GDPR
El Reglamento General de Protección de Datos, en vigor desde 2018, rige cómo se recogen, almacenan, procesan y comparten los datos personales. Para un sitio WordPress típico, esto afecta a:
- Consentimiento de cookies —las cookies de analítica, publicidad y seguimiento requieren consentimiento explícito (opt-in) antes de cargarse, no solo un banner informativo.
- Política de privacidad —una explicación clara y accesible de qué datos recoges (formularios de contacto, comentarios, analítica, pedidos de e-commerce) y qué haces con ellos.
- Derechos del interesado —mecanismos para que los visitantes soliciten sus datos, pidan su corrección, o soliciten su eliminación.
- Acuerdos de tratamiento de datos —contratos con cualquier servicio externo que procese datos en tu nombre (proveedores de correo, herramientas de analítica, hosting).
- Notificación de brechas —un proceso para reportar brechas de datos a la autoridad correspondiente dentro de 72 horas, si se exponen datos personales.
Nada de esto concierne a la seguridad de tu código, tus plugins, o cómo se reportan las vulnerabilidades. Al GDPR no le importa si tu plugin de formulario de contacto tiene un bug de inyección SQL sin parchear —le importa qué pasa con los datos que fluyen a través de él una vez recogidos.
Lo que realmente cubre el CRA
El Cyber Resilience Act, cuya aplicación se introduce de forma escalonada hasta 2027, rige la seguridad de los productos con elementos digitales vendidos en el mercado de la UE. Está dirigido principalmente a los fabricantes —incluidos los proveedores de software, lo que cubre a los desarrolladores de plugins y temas de WordPress— más que a cada operador de sitio web. Para un desarrollador o proveedor, esto significa:
- Desarrollo seguro desde el diseño (secure-by-design) —construir software teniendo en cuenta la seguridad desde el principio, no añadida después.
- Política de divulgación de vulnerabilidades —un proceso documentado y público para que los investigadores de seguridad reporten vulnerabilidades (aquí entra en juego security.txt).
- Actualizaciones de seguridad —un compromiso de parchear vulnerabilidades conocidas durante un período de soporte definido, y notificar a los usuarios cuando haya disponible una actualización de seguridad.
- Lista de materiales de software (SBOM) —para muchos productos, una lista documentada de los componentes de software y dependencias usados, para que usuarios y reguladores puedan evaluar la exposición cuando un componente tenga una vulnerabilidad conocida.
- Notificación de incidentes —notificar a las autoridades correspondientes (ENISA) sobre vulnerabilidades activamente explotadas dentro de plazos ajustados.
Si eres un operador de sitio que simplemente instala plugins de WordPress.org en lugar de alguien que construye y distribuye software, las obligaciones directas del CRA recaen más sobre los desarrolladores de plugins que sobre ti —pero si tu negocio construye y vende un plugin, un tema, o cualquier producto digital con clientes en la UE, esto te aplica directamente.
Comparación lado a lado
| GDPR | Cyber Resilience Act de la UE | |
|---|---|---|
| Qué regula | El tratamiento de datos personales | La seguridad del producto de software |
| A quién se dirige | A quien procese datos de residentes de la UE | A fabricantes de productos con elementos digitales |
| Documentos clave | Política de privacidad, acuerdos de tratamiento | Política de divulgación de vulnerabilidades, SBOM |
| Requisito principal | Base legal para el tratamiento de datos | Seguro desde el diseño, actualizaciones de seguridad continuas |
| Aplicación | Hasta 20M€ o 4% de la facturación global | Hasta 15M€ o 2,5% de la facturación global |
| En vigor desde | 2018 | Implementación escalonada hasta 2027 |
Por qué ambos importan para un negocio de WordPress
Si gestionas una agencia de WordPress, desarrollas plugins o temas, u operas un sitio que procesa datos de visitantes de la UE, ambas regulaciones son realmente relevantes —solo para partes distintas de tu operación:
- La recogida de datos de tu sitio web (formularios de contacto, analítica, e-commerce) cae bajo el GDPR.
- Cualquier software que construyas y distribuyas —un plugin, un tema, un producto SaaS— cae bajo el CRA.
Muchos negocios de WordPress ya tienen resuelto el lado del GDPR, ya que se aplica desde 2018 y la mayoría de agencias lo integraron en su proceso hace años. El CRA es más reciente y se aborda con mucha menos frecuencia, que es exactamente donde suele estar la brecha.
Cerrar la brecha del CRA
Si desarrollas y distribuyes un plugin o tema de WordPress, el punto de partida práctico para estar preparado para el CRA es la documentación: una política de divulgación de vulnerabilidades, un archivo security.txt, e idealmente un SBOM que liste tus dependencias. Erdo CRA Compliance escanea un sitio WordPress frente a los requisitos del CRA, el GDPR y NIS2, y genera la documentación que espera el CRA —política de divulgación de vulnerabilidades, SBOM, security.txt— en una sola pasada, en lugar de construir cada pieza manualmente.
Resumiendo
El GDPR y el CRA no son regulaciones competidoras ni dos versiones del mismo requisito —cubren riesgos completamente distintos. Tratar "cumplimos con el GDPR" como prueba de un cumplimiento más amplio deja el lado de la seguridad del software completamente sin abordar. Si tu negocio de WordPress construye o distribuye software, ambos merecen atención separada, documentación separada, abordando riesgos separados.