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 que entrega un componente comercial a un cliente regulado queda bajo el CRA por el lado del producto y bajo NIS2 o DORA por el lado de la entidad. Para una entidad financiera, DORA sustituye las normas de gestión de riesgos y notificación de NIS2 en lugar de sumarse a ellas. La buena noticia: un único paquete de evidencias puede cubrir todo esto 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 plan de incidentes de 24 horas y el texto sobre accesibilidad BFSG y EAA.
Requisitos de CRA, NIS2 y DORA en resumen
- El CRA es regulación de productos. NIS2 es regulación de entidades. DORA es regulación de entidades financieras.
- Un proyecto de WordPress headless puede quedar bajo el CRA por sus componentes comerciales y bajo NIS2 o DORA por el cliente que lo explota.
- Para las entidades financieras, DORA se aplica en lugar de los artículos 21 y 23 de NIS2 (artículo 4 y considerando 28 de NIS2).
- Un paquete de evidencias organizado por control supera a tres rastros documentales separados.
- Obligaciones de notificación del CRA desde el 11 de septiembre de 2026, aplicación plena desde el 11 de diciembre de 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 puede ser 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 suministra en el curso de una actividad comercial. WordPress en sí, como software libre de código abierto publicado por una comunidad y no monetizado por sus autores, no está dentro del ámbito del CRA (considerandos 15 y 18 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. El artículo 21, apartado 2, letra d), de NIS2 pide a las entidades incluidas que aseguren su relación con los proveedores directos, y el artículo 28, apartado 3, de DORA exige a las entidades financieras un registro de información sobre todos los acuerdos contractuales de servicios TIC. Ambos llevan a un inventario de esta cadena con control contractual.
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: una evaluación documentada de los riesgos de ciberseguridad (artículo 13, apartados 2 y 3), los requisitos esenciales de la parte I del anexo I, como la configuración segura por defecto, la gestión de vulnerabilidades durante el periodo de soporte según la parte II del anexo I, las actualizaciones de seguridad y una lista de materiales de software (SBOM, parte II, punto 1, del anexo I). El artículo 14 añade la notificación: las vulnerabilidades explotadas activamente y los incidentes graves se notifican a la vez al CSIRT designado como coordinador y a ENISA, a través de la plataforma única de notificación del artículo 16, con una alerta temprana 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 del artículo 14 desde el 11 de septiembre de 2026.
- Capítulo IV sobre organismos notificados (artículos 35 a 51) desde el 11 de junio de 2026.
- Todo lo demás, incluidas las obligaciones completas de los fabricantes, desde el 11 de diciembre de 2027.
- Los requisitos de evaluación de la conformidad para productos con elementos digitales “importantes” y “críticos” siguen vías propias (artículo 32).
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, apartado 2, enumera diez medidas de gestión de riesgos, letras a) a j) (en detalle en el artículo sobre el rastro de evidencias del anexo II). El artículo 23, apartado 4, fija la alerta temprana en 24 horas, la notificación en 72 horas y el informe final al cabo de un mes (en detalle en el plan de respuesta a incidentes en 24 horas). El artículo 21, apartado 2, letra d), arrastra a los proveedores de forma indirecta: la entidad debe cubrir la seguridad de la cadena de suministro, incluida su relación con proveedores directos y prestadores de servicios, y el artículo 21, apartado 3, le pide tener en cuenta las prácticas de desarrollo seguro de cada proveedor.
El plazo de transposición venció el 2024-10-17 (artículo 41). 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 con arreglo al artículo 31. Los artículos 28 a 30 tratan el riesgo de terceros en materia de TIC: los principios generales, el registro de información y las estrategias de salida están en el artículo 28 (en detalle en el artículo sobre la auditoría de proveedores del artículo 28 de DORA), y las cláusulas contractuales obligatorias en el artículo 30. Los artículos 17 a 19 cubren el proceso de gestión de incidentes relacionados con las TIC, su clasificación y la notificación de incidentes graves. 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 (artículo 64).
Si NIS2 sigue aplicándose cuando DORA cubre a una entidad financiera
No en lo que importa aquí. El artículo 4, apartado 1, de NIS2 desactiva sus propias disposiciones sobre gestión de riesgos, notificación y supervisión cuando un acto jurídico sectorial de la Unión impone requisitos de efecto al menos equivalente. El considerando 28 de NIS2 nombra a DORA como ese acto para las entidades financieras: las normas de DORA sobre gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia, intercambio de información y riesgo de terceros se aplican en lugar de las de NIS2.
Para un encargo de WordPress headless, esto divide a los clientes en dos grupos:
- Un banco, una aseguradora, una entidad de pago o una empresa de servicios de inversión trabaja bajo DORA. El paquete de evidencias remite a artículos de DORA, y las notificaciones de incidentes van a la autoridad financiera competente según el artículo 19 de DORA.
- Un hospital, una empresa energética, un organismo de la administración pública u otra entidad del anexo I o II trabaja bajo la ley nacional que transpone NIS2. El paquete de evidencias remite al artículo 21, apartado 2, y las notificaciones de incidentes van al CSIRT o a la autoridad competente según el artículo 23.
El CRA atraviesa ambos grupos: si la agencia entrega un producto comercial, sus obligaciones de fabricante se aplican sea cual sea el régimen del cliente. Por eso la tabla de solapamientos de más abajo tiene una columna NIS2 y una columna DORA, pero un mismo encargo solo rellena una de ellas.
Cuándo la propia agencia queda bajo NIS2
NIS2 no solo alcanza al cliente. El anexo I, punto 9, incluye la “gestión de servicios de TIC (de empresa a empresa)”, que abarca a los proveedores de servicios gestionados y a los proveedores de servicios de seguridad gestionados. El artículo 6, punto 39, define al proveedor de servicios gestionados como la entidad que presta servicios relacionados con la instalación, gestión, funcionamiento o mantenimiento de productos, redes, infraestructuras o aplicaciones de TIC, mediante asistencia o administración activa en los locales del cliente o a distancia.
Una agencia que gestiona el alojamiento, las actualizaciones y la monitorización de las instalaciones de WordPress de sus clientes mediante un contrato de mantenimiento encaja en esa descripción. La prueba de tamaño del artículo 2, apartado 1, decide si está incluida: la directiva se aplica a las entidades que son medianas empresas según la Recomendación 2003/361/CE de la Comisión o que superan esos umbrales. Según el artículo 2 de esa Recomendación, una pequeña empresa tiene menos de 50 trabajadores y un volumen de negocios o balance de hasta 10 millones de euros, así que una agencia con 50 o más trabajadores y una línea de alojamiento gestionado es el caso que hay que comprobar. Si está incluida, necesita sus propias medidas del artículo 21 y su propia vía de notificación del artículo 23, separadas de las de sus clientes.
Si un sitio en WordPress headless es un producto según el CRA
Normalmente no, y el reglamento lo dice expresamente. El considerando 12 del CRA establece que los sitios web que no apoyan la funcionalidad de un producto con elementos digitales quedan fuera de su ámbito, y que los servicios en la nube como SaaS, PaaS e IaaS se rigen en cambio por NIS2. Un sitio de marketing o un frontal de banca en línea sobre WordPress headless es un sitio web explotado como servicio, no un producto introducido en el mercado.
El CRA entra por tres puertas más estrechas:
- Un producto comercial vendido a muchos clientes. Un tema premium, un plugin de pago o un kit de inicio de frontend con licencia, suministrado en el curso de una actividad comercial, es un producto con elementos digitales (artículo 3, punto 1).
- Una app con backend propio. El artículo 3, punto 2, y el considerando 11 tratan como parte del producto el “tratamiento de datos a distancia” desarrollado por el fabricante o bajo su responsabilidad, sin el cual el producto no puede realizar una de sus funciones. Cuando una app móvil depende de un endpoint REST de WordPress propio, ese endpoint entra en el ámbito del CRA de la app.
- Componentes de código abierto dentro de un producto comercial. El artículo 13, apartado 5, exige a los fabricantes diligencia debida al integrar componentes de terceros, también los libres y de código abierto, y el artículo 13, apartado 6, les obliga a notificar una vulnerabilidad detectada en un componente a quien lo mantiene.
Ninguno de los tipos de producto de los anexos III (productos importantes) y IV (productos críticos) es un CMS, un tema o un frontend web. Un producto típico de WordPress usa por tanto el procedimiento de control interno (módulo A del anexo VIII), sin organismo notificado.
Cómo se comparan los plazos de notificación de CRA, NIS2 y DORA
Cada norma tiene su propio reloj, que arranca en un momento distinto:
| Paso | CRA artículo 14 (fabricante) | NIS2 artículo 23, apartado 4 (entidad) | DORA artículo 19 + RTS 2025/301 artículo 5 (entidad financiera) |
|---|---|---|---|
| Desencadenante | Vulnerabilidad explotada activamente o incidente grave | Incidente significativo | Incidente grave relacionado con las TIC |
| Primer informe | Alerta temprana en 24 h desde el conocimiento | Alerta temprana en 24 h desde el conocimiento | Notificación inicial en 4 h desde la clasificación como grave, y no más tarde de 24 h desde el conocimiento |
| Segundo informe | Notificación en 72 h desde el conocimiento | Notificación del incidente en 72 h desde el conocimiento | Informe intermedio en 72 h desde la notificación inicial |
| Informe final | 14 días después de disponer de una corrección (vulnerabilidad) o un mes después de la notificación (incidente) | Un mes después de la notificación del incidente | Un mes después del último informe intermedio |
| Destinatario | CSIRT coordinador y ENISA, por la plataforma única | CSIRT nacional o autoridad competente | Autoridad financiera competente (artículo 46) |
Los plazos de DORA proceden del Reglamento Delegado (UE) 2025/301 de la Comisión, no del propio DORA. Una consecuencia práctica para un stack headless: la agencia de frontend que además es fabricante según el CRA puede deber su propia notificación de 24 horas a ENISA sobre la misma vulnerabilidad que el banco notifica a su supervisor. Las dos notificaciones deberían remitirse entre sí, y el runbook debería indicar quién presenta cada una.
Dónde se solapan CRA, NIS2 y DORA
Un encargo de WordPress headless que incluya un bundle de frontend comercial se encuentra con los siguientes solapamientos. La columna NIS2 se aplica a clientes fuera del sector financiero y la columna DORA a entidades financieras:
| Área de control | Referencia CRA | Referencia NIS2 | Referencia DORA |
|---|---|---|---|
| Gestión de vulnerabilidades | Artículo 13(8), anexo I parte II | Artículo 21(2)(e) | Artículo 8(2) (identificación de vulnerabilidades TIC) |
| Actualizaciones de seguridad | Artículo 13(8) y 13(9), anexo I parte II puntos 2, 7 y 8 | Artículo 21(2)(e) | Artículo 9(4)(f) (parches y actualizaciones) |
| Lista de materiales de software | Anexo I parte II punto 1 | Artículo 21(2)(e) (adquisición y desarrollo) | Artículo 8(1) y 8(4) (inventario de activos TIC) |
| Notificación de incidentes | Artículo 14 (CSIRT y ENISA, 24 h) | Artículo 23 (24/72/30) | Artículo 19 (plazos de las entidades financieras) |
| Cadena de suministro | Artículo 13(5) (diligencia debida con componentes de terceros) | Artículo 21(2)(d) | Artículos 28 y 30 (riesgo de terceros y contratos) |
| Gestión de riesgos | Artículo 13(2) y 13(3) (evaluación de riesgos) | Artículo 21(2)(a) | Artículo 6 (marco de gestión del riesgo TIC) |
| Autenticación | Anexo I parte I punto 2, letra d) (protección frente a accesos no autorizados) | Artículo 21(2)(j) (MFA) | Artículo 9(4)(d) (autenticación robusta) |
| Criptografía | Anexo I parte I punto 2, letra e) | Artículo 21(2)(h) | Artículo 9(4)(d) (protección de claves criptográficas) |
Ocho controles solapados. Un paquete de evidencias con ocho carpetas, cada una con referencias cruzadas al CRA y al régimen del cliente, 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. La CLI de npm la genera con
npm sbom --sbom-format cyclonedx(ospdx);npm audit signatureses una comprobación aparte que verifica las firmas del registro. La SBOM es un entregable de la parte II del anexo I del CRA; en NIS2 y DORA sirve para la gestión de vulnerabilidades y el inventario de activos. - SBOM del backend de WordPress. Inventario de plugins y temas con versión y licencia. WP-CLI lo exporta con
wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=jsonywp theme list --format=json; la licencia figura en la cabecera de cada plugin, 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. Según el artículo 32, los productos importantes de clase I que no aplican normas armonizadas, todos los productos importantes de clase II y los productos críticos necesitan el examen UE de tipo o el aseguramiento de calidad total del anexo VIII, con intervención de un organismo notificado, o un esquema europeo de certificación de la ciberseguridad cuando exista. 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 cuando el producto entre en el anexo III o IV.
TLPT según el artículo 26 de DORA. Las pruebas de penetración basadas en amenazas para entidades financieras designadas se realizan al menos cada tres años sobre sistemas de producción en funcionamiento, y las normas técnicas que las desarrollan 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 las autoridades financieras competentes del artículo 46 y, para cada proveedor tercero crítico de servicios TIC, un supervisor principal asistido por un equipo conjunto de examinadores (artículo 40). El CRA tiene autoridades de vigilancia del mercado según el artículo 52. Tres canales de supervisión distintos siguen necesitando procesos de comunicación separados.
Qué multas fijan CRA, NIS2 y DORA
Los topes difieren porque las normas regulan a partes distintas:
- CRA, artículo 64. Incumplimiento de los requisitos esenciales del anexo I o de los artículos 13 y 14: hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial, la cifra que sea mayor. Otras obligaciones de los operadores económicos: hasta 10 millones de euros o el 2 %. Información incorrecta o engañosa a organismos notificados o autoridades de vigilancia del mercado: hasta 5 millones de euros o el 1 %.
- NIS2, artículo 34. Incumplimiento del artículo 21 o 23: un máximo de al menos 10 millones de euros o el 2 % para las entidades esenciales, y de al menos 7 millones de euros o el 1,4 % para las entidades importantes. Los Estados miembros pueden ir más allá.
- DORA, artículo 50. Las cuantías las fijan los Estados miembros, que deben dotar a las autoridades competentes de facultades sancionadoras. Frente a los proveedores terceros críticos de servicios TIC, el supervisor principal puede imponer con arreglo al artículo 35 una multa coercitiva diaria de hasta el 1 % del volumen de negocios diario medio mundial, durante un máximo de seis meses.
Para la agencia, la línea del CRA es la que llega a su propio balance, porque la agencia es el fabricante. Las sanciones de NIS2 y DORA recaen en el cliente, y por eso los clientes las trasladan hacia abajo en la cadena mediante cláusulas contractuales.
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 y delegados que la Comisión adopte en virtud del CRA, y conocer la plataforma única de notificación de ENISA antes de que el artículo 14 se aplique el 11 de septiembre de 2026.
El precio es individual; la duración del encargo depende del alcance del cumplimiento, no de una cuota mensual fija.
Guías relacionadas sobre CRA, NIS2 y DORA
- Pilar: NIS2 y DORA en WordPress: qué debe cumplir un sitio en 2026
- NIS2 anexo II para agencias WordPress: alcance, plazos y rastro de evidencias
- DORA artículo 28, riesgo de terceros TIC: auditoría del proveedor de hosting y WAF
- WordPress y NIS2: plan de respuesta a incidentes en 24 horas
- BFSG y EAA: el plazo alemán de 2025 para tiendas WordPress
