Cyber Resilience Act + NIS2 + DORA: el cumplimiento en 2026 para WordPress headless
Entre 2024 y 2026, tres normas de la UE han convergido en la misma sustancia operativa. El Cyber Resilience Act (Reglamento (UE) 2024/2847) regula los productos con elementos digitales comercializados en el mercado de la UE. La Directiva NIS2 (2022/2555) regula las entidades que prestan servicios esenciales o importantes. El Reglamento DORA (2022/2554) regula las entidades financieras y los proveedores terceros de servicios TIC de los que dependen. Un proyecto de WordPress headless para una entidad regulada que incluya un componente comercial queda bajo las tres normas a la vez. La buena noticia: un único paquete de evidencias puede cumplir con las tres si se estructura por control y no por norma.
Este artículo cierra el pilar sobre NIS2 y DORA en WordPress y conecta el rastro de evidencias del anexo II, la auditoría de proveedores del artículo 28 de DORA, el playbook de incidentes de 24 horas y el texto sobre accesibilidad BFSG y EAA.
¿Qué es, en resumen, el conjunto de requisitos de CRA, NIS2 y DORA?
- El CRA es regulación de productos. NIS2 es regulación de entidades. DORA es regulación de entidades financieras.
- WordPress headless para entidades reguladas puede quedar bajo las tres.
- Un paquete de evidencias organizado por control supera a tres rastros documentales separados.
- Obligaciones de notificación del CRA desde 2026, obligaciones completas de los fabricantes desde 2027.
- NIS2 desde el plazo de transposición del 2024-10-17; DORA de aplicación directa desde el 2025-01-17.
¿Cómo afecta WordPress headless al cumplimiento de CRA, NIS2 y DORA?
Un proyecto de WordPress headless separa dos capas. La capa de contenido utiliza WordPress como editor y fuente de verdad, y expone el contenido mediante la REST API o GraphQL. La capa de presentación utiliza un framework de frontend (Next.js, Astro, Nuxt, SvelteKit) que consume ese contenido y lo muestra a los usuarios.
Para el cumplimiento normativo, esta separación cambia la superficie de riesgo de tres maneras.
El frontend es un producto. Una aplicación Next.js con librerías comerciales, desplegada por una agencia, puede ser un “producto con elementos digitales” según el CRA cuando se vende o se licencia a una entidad financiera. WordPress en sí, como software libre de código abierto publicado por una comunidad, no está dentro del ámbito del CRA según el considerando 15 del Reglamento (UE) 2024/2847; los paquetes comerciales construidos encima sí pueden estarlo.
La cadena de suministro es más amplia. Los proyectos headless incorporan dependencias npm (a menudo cientos), funciones edge de CDN, servicios de optimización de imágenes, proveedores de búsqueda y sistemas de comentarios. Tanto el artículo 21(2)(d) de NIS2 como el artículo 28(2) de DORA exigen que esta cadena esté inventariada, clasificada y controlada por contrato.
La superficie de incidentes está dividida. Una vulnerabilidad puede estar en el backend de WordPress, en el bundle del frontend, en una función edge o en una API de terceros. El reloj de 24 horas de NIS2 y los plazos de notificación de DORA se aplican a la entidad, esté donde esté el fallo. El runbook de la agencia tiene que detectar y clasificar incidentes en las cuatro capas.
¿Qué exigen CRA, NIS2 y DORA?
CRA (Reglamento (UE) 2024/2847)
Cubre los productos con elementos digitales comercializados en el mercado de la UE. El artículo 13 fija las obligaciones del fabricante: ciberseguridad desde el diseño y por defecto, gestión de vulnerabilidades durante el periodo de soporte, actualizaciones de seguridad, lista de materiales de software (SBOM), notificación a ENISA de las vulnerabilidades explotadas activamente en un plazo de 24 horas desde que se tiene conocimiento y notificación de incidentes graves en un plazo de 24 horas desde que se tiene conocimiento.
Calendario de aplicación según el artículo 71:
- Obligaciones de notificación de vulnerabilidades e incidentes desde 2026.
- Obligaciones completas de los fabricantes desde 2027 (36 meses después de la entrada en vigor).
- Los requisitos de evaluación de la conformidad para productos con elementos digitales “importantes” y “críticos” siguen vías propias.
El software de código abierto desarrollado y suministrado sin actividad comercial queda fuera del ámbito del CRA. Los considerandos distinguen entre la contribución no comercial al código abierto y el empaquetado comercial. El núcleo de WordPress es código abierto no comercial; una oferta de WordPress gestionado vendida como producto, con plugins premium incluidos bajo una única licencia, puede entrar en el ámbito del CRA.
NIS2 (Directiva 2022/2555)
Cubre las entidades (esenciales e importantes) enumeradas en los anexos I y II. El artículo 21(2) enumera diez medidas de gestión de riesgos. El artículo 23 fija la alerta temprana en 24 horas, la notificación en 72 horas y el informe final al cabo de un mes. El artículo 21(2)(d) incorpora a los proveedores al ámbito mediante obligaciones contractuales.
El plazo de transposición venció el 2024-10-17. Varios Estados miembros se retrasaron; compruebe la situación nacional antes de cualquier auditoría final.
DORA (Reglamento 2022/2554)
Cubre las entidades financieras enumeradas en el artículo 2 y los proveedores terceros críticos de servicios TIC (CTPP) designados por las Autoridades Europeas de Supervisión. El artículo 28 trata la gestión del riesgo de terceros en materia de TIC. Los artículos 16 a 19 cubren el ciclo de vida de la gestión de incidentes TIC. Los artículos 24 a 27 cubren las pruebas de resiliencia operativa digital, incluidas las TLPT.
Se aplica directamente en toda la UE desde el 2025-01-17.
¿Dónde se solapan CRA, NIS2 y DORA?
Un encargo de WordPress headless para una entidad financiera que incluya un bundle de frontend comercial se encuentra con los siguientes solapamientos:
| Área de control | Referencia CRA | Referencia NIS2 | Referencia DORA |
|---|---|---|---|
| Gestión de vulnerabilidades | Artículo 13 (obligaciones del fabricante) | Artículo 21(2)(e) | Artículo 16, artículo 17 |
| Actualizaciones de seguridad | Artículo 13 (periodo de soporte) | Artículo 21(2)(e) | Artículo 8 (mantenimiento de sistemas TIC) |
| Lista de materiales de software | Artículo 13 (SBOM) | Artículo 21(2)(e) (adquisición y desarrollo) | Artículo 8 |
| Notificación de incidentes | Artículo 14 (incidentes graves a ENISA, 24 h) | Artículo 23 (24/72/30) | Artículo 19 (plazos de las entidades financieras) |
| Cadena de suministro | Anexo I, sección II (diligencia debida del fabricante) | Artículo 21(2)(d) | Artículo 28 (gestión del riesgo de terceros) |
| Gestión de riesgos | Artículo 13(1) | Artículo 21(2)(a) | Artículo 6 (marco de gestión del riesgo TIC) |
| Autenticación | Artículo 13(1) (seguridad por defecto) | Artículo 21(2)(j) (MFA) | Artículo 8 (seguridad de la información) |
| Criptografía | Anexo I, sección I | Artículo 21(2)(h) | Artículo 9 (protección de datos) |
Ocho controles solapados. Un paquete de evidencias con ocho carpetas, cada una con referencias cruzadas a los tres reglamentos, los cumple todos.
¿Cómo estructurar un paquete conjunto de evidencias para CRA, NIS2 y DORA?
Estructuro el paquete por área de control, no por reglamento. Cada carpeta de control contiene:
- Política. Aprobada por el órgano de dirección de la entidad. Con referencias cruzadas a los artículos pertinentes del CRA / NIS2 / DORA.
- Responsable del proceso. Un rol identificado en la entidad, más el contacto identificado de la agencia.
- Evidencias de implementación. Logs, informes de auditoría, resultados de escaneos, resultados de pruebas, cláusulas contractuales.
- Tabla de correspondencias. Tres columnas: artículo del CRA, artículo de NIS2, artículo de DORA. Dónde encaja la política en cada uno.
- Registro de revisión. Revisión anual o más frecuente, fechada y firmada.
- Historial de auditorías. Auditorías externas, pruebas de penetración, consultas del regulador, todo fechado y etiquetado.
El paquete conjunto evita el desperdicio más habitual en el cumplimiento de varias normas: redactar el mismo registro de riesgos tres veces para tres reguladores. Un registro, tres referencias de artículos en los metadatos.
¿Qué evidencias exige un proyecto headless para CRA, NIS2 y DORA?
Un proyecto headless añade artefactos que un encargo de WordPress monolítico no necesita:
- SBOM del bundle del frontend. Un archivo CycloneDX o SPDX que lista cada dependencia npm con su versión y licencia. Se genera con
npm audit signaturesmás un generador CycloneDX. La SBOM es un entregable del artículo 13 del CRA; en NIS2 y DORA sirve para la gestión de vulnerabilidades. - SBOM del backend de WordPress. Inventario de plugins y temas con versión y licencia. Plugin checker de WordPress.org más archivos internos de bloqueo de versiones.
- Inventario de funciones edge. Cloudflare Workers, Netlify Functions, Vercel Edge. Cada función es una pieza de la cadena de suministro y una pieza de la superficie de incidentes.
- Documentación del contrato de la API. Esquema OpenAPI o GraphQL de la API headless, con definiciones de seguridad, límites de peticiones y autenticación.
- Evidencias del pipeline de despliegue del frontend. Logs de CI/CD, resultados del escaneo de contenedores, evidencias del escaneo de secretos, revisión de dependencias en cada PR.
- Monitorización entre capas. Un único dashboard o runbook que correlaciona eventos del backend de WordPress, la aplicación de frontend, la capa edge y las APIs de terceros.
Para una entidad regulada, este conjunto de artefactos es obligatorio. Para una entidad no regulada, es una buena práctica, pero la conversación sobre presupuesto se vuelve más ajustada.
¿Qué no cubre un paquete conjunto para CRA, NIS2 y DORA?
Hay tres áreas que un único paquete no cubre.
Evaluación de la conformidad según el CRA. Los productos con elementos digitales “importantes” y “críticos” necesitan una evaluación de la conformidad por terceros conforme al anexo VII del CRA. NIS2 y DORA no tienen una base equivalente de certificación por terceros (las TLPT de DORA son lo más parecido). Planifique la evaluación de la conformidad como una línea de trabajo independiente.
TLPT según el artículo 26 de DORA. Las pruebas de penetración basadas en amenazas para entidades financieras significativas designadas siguen el marco TIBER-EU. NIS2 y el CRA no exigen pruebas de esta profundidad.
Supervisión sectorial. NIS2 tiene autoridades competentes sectoriales. DORA tiene los equipos de examen conjunto del artículo 31. El CRA tiene autoridades de vigilancia del mercado según el anexo VIII. Tres canales de supervisión distintos siguen necesitando procesos de comunicación separados.
¿Qué exigen CRA, NIS2 y DORA a las agencias WordPress?
Una agencia de WordPress que quiera entregar proyectos headless a entidades reguladas en 2026 tiene que:
- Construir una vez la plantilla del paquete conjunto de evidencias y reutilizarla en todos los encargos.
- Generar las SBOM como parte del pipeline de despliegue, no a posteriori.
- Mantener el registro de proveedores al día como documento vivo.
- Mantener la preparación para responder a incidentes en las dos capas (WordPress y frontend).
- Seguir los actos de ejecución del CRA a medida que ENISA los publique a lo largo de 2026.
El precio es individual; la duración del encargo depende del alcance del cumplimiento, no de una cuota mensual fija.
