NIS2 y DORA en WordPress: qué debe cumplir un sitio en 2026
Dos actos de la UE definen en 2026 lo que se exige desde el lado de la ciberseguridad a un sitio WordPress que desarrolla actividad regulada en la Unión: la Directiva NIS2 (2022/2555) y el Reglamento DORA (2022/2554). No son intercambiables. NIS2 es una directiva con un ámbito sectorial amplio, transpuesta al derecho naciónal. DORA es un reglamento sectorial (finanzas), de aplicación directa. Ambos se aplican a WordPress si y solo si la entidad que opera el sitio entra en el ámbito.
El artículo se conecta con el pillar de servicios headless WordPress, donde se describe la capa técnica, y con el pillar sobre WCAG, BFSG y EAA, porque la conformidad de accesibilidad y la de ciberseguridad caen cada vez más en la misma consulta de compras.
TL;DR
- Plazo de transposición de NIS2: 2024-10-17. DORA aplica desde 2025-01-17.
- NIS2: 18 sectores, divididos en entidades esenciales e importantes.
- DORA: sector financiero más proveedores críticos de TIC.
- Requisitos: gestión de riesgos documentada, notificación de incidentes (24/72/30), auditorías.
- WordPress en sí mismo no está en el ámbito; lo está la entidad que opera el sitio, si está regulada.
Tres cosas que hay que saber de inmediato
Primero, NIS2 y DORA aplican a la entidad, no a la tecnología. WordPress no es “compliant” ni “non-compliant” como CMS. Compliant o no lo es la entidad que opera el sitio. Si un hospital, un banco, un proveedor de cloud o un operador de e-commerce por encima del umbral entra en el ámbito, su sitio WordPress entra en el ámbito como parte de la infraestructura de esa entidad.
Segundo, la transposición naciónal de NIS2 está retrasada en muchos Estados miembros. El plazo del 2024-10-17 ha vencido, pero varios países se encontraban en distintas fases del proceso legislativo después de esa fecha. El estado de la transposición varía entre Estados miembros; consulte la base de datos jurídica naciónal pertinente antes de la auditoría final. Para el estado del Estado miembro polaco, el proyecto de modificación de la ley sobre el sistema naciónal de ciberseguridad está disponible públicamente y su estado actual debe verificarse en ISAP antes de cualquier auditoría final. El estado a 2026-04 requiere una revisión jurídica separada; este artículo no sustituye el asesoramiento legal.
Tercero, DORA aplica directamente. El reglamento no requiere transposición. Si una entidad financiera o un proveedor crítico de TIC opera un sitio WordPress, las obligaciónes de DORA se aplican desde el 2025-01-17 con independencia del estado legislativo naciónal.
NIS2: ámbito subjetivo
La Directiva NIS2 enumera 18 sectores. Los casos más habituales en los que WordPress entra en el ámbito:
Entidades esenciales (essential entities):
- Energía (electricidad, gas, petróleo, calor, hidrógeno).
- Transporte (aéreo, ferroviario, marítimo, por carretera).
- Banca.
- Infraestructuras de los mercados financieros.
- Sanidad (hospitales, laboratorios de referencia, fabricantes de medicamentos, productos sanitarios).
- Agua potable y aguas residuales.
- Infraestructura digital (proveedores de DNS, registros de dominios, proveedores de cloud computing, prestadores de servicios de centros de datos, redes de distribución de contenidos, prestadores de servicios de confianza, proveedores de redes públicas de comunicaciones electrónicas).
- Gestión de servicios TIC (B2B).
- Administración pública (condiciones definidas en el art. 2).
- Espacio.
Entidades importantes (important entities):
- Servicios postales y de mensajería.
- Gestión de residuos.
- Fabricación, transformación y distribución de productos químicos.
- Fabricación, transformación y distribución de alimentos.
- Fabricación en los sectores: médico, informático y electrónico, maquinaria, automóvil.
- Proveedores de servicios digitales (mercados en línea, motores de búsqueda, plataformas sociales).
- Organismos de investigación.
Umbral básico: empresa mediana (50+ empleados o cifra de negocios anual o balance superior a 10 millones EUR). Microempresas y pequeñas empresas suelen quedar fuera del ámbito, con excepciones (por ejemplo, prestadores de servicios de confianza, registros de TLD, ciertos proveedores de DNS).
La entidad esencial tiene obligaciónes más estrictas. La entidad importante tiene los mismos requisitos técnicos pero con supervisión menos intensiva.
DORA: ámbito subjetivo
DORA aplica a unos 20 tipos de entidad financiera:
- Entidades de crédito.
- Entidades de pago.
- Entidades de dinero electrónico.
- Empresas de servicios de inversión.
- Proveedores de servicios de criptoactivos.
- Depositarios centrales de valores.
- Entidades de contrapartida central.
- Centros de negociación (bolsas).
- Registros de operaciones.
- Entidades aseguradoras y reaseguradoras.
- Mediadores de seguros y reaseguros.
- Fondos de pensiones de empleo.
- Agencias de calificación crediticia.
- Auditores que auditen los estados financieros de entidades cubiertas por DORA.
- Administradores de índices de referencia críticos.
- Fondos de inversión (UCITS, AIFM).
- Proveedores de servicios de financiación participativa.
- Repositorios de titulizaciones.
Más los proveedores críticos de TIC terceros (Critical ICT Third-Party Providers, CTPP) designados por la supervisión europea. Es el mecanismo por el cual DORA arrastra a socios comerciales a su ámbito sin que estos se registren como entidad financiera.
Un sitio WordPress operado por un banco, una aseguradora o un fondo de inversión entra en el ámbito de DORA como parte de los sistemas TIC de la entidad.
Qué hay que hacer en concreto: el núcleo común
NIS2 y DORA tienen un núcleo convergente de exigencias técnicas y organizativas. Implementación en WordPress:
Gestión del riesgo cibernético. Registro de riesgos documentado, procedimiento para su evaluación y aceptación, políticas de seguridad aprobadas por el consejo de administración. Son documentos, no solo configuración del servidor.
Control de acceso y autenticación. Autenticación multifactor (MFA) obligatoria para los administradores de WordPress. Contraseñas robustas obligatorias. Caducidad de sesión obligatoria. Todas las cuentas de administrador deben ser nominales, no compartidas.
Gestión de incidentes. Procedimiento para la detección, clasificación y notificación de incidentes. Un incidente significativo bajo NIS2 es aquel con un impacto significativo en la prestación del servicio. Notificación al CSIRT o autoridad competente en 24 horas desde la detección (alerta temprana), 72 horas con evaluación inicial, un mes con informe final.
Seguridad de la cadena de suministro. Un plugin de WordPress, hosting, CDN, proveedor de correo transacciónal, proveedor de SMS, proveedor de IA. Cada uno forma parte de la cadena. Hay que mantener un registro, evaluaciones de riesgo y cláusulas contractuales.
Continuidad de negocio y recuperación ante desastres. Backup, plan de continuidad, recuperación ante desastres, probados con regularidad, no solo ejecutados.
Formación del personal. Exigida a nivel del consejo y de la organización en sentido amplio. Una “presentación interna” no basta; se requiere un plan de formación documentado.
Seguridad del proceso de desarrollo y mantenimiento. Políticas sobre desarrollo de software, pruebas y gestión de vulnerabilidades. El core de WordPress se actualiza; los plugins también deben actualizarse, con un proceso de pruebas en staging antes de producción.
Criptografía. Una política de criptografía, incluyendo TLS, cifrado de datos en reposo, firmas digitales. WordPress no cifra la base de datos por defecto; la solución es cifrar a nivel de sistema de ficheros o de base de datos.
Específico de DORA: gestión de terceros TIC
DORA tiene un capítulo V dedicado a la gestión de proveedores TIC. Exige:
- Un registro de todos los contratos con proveedores TIC.
- Clasificación de los contratos (críticos, no críticos).
- Cláusulas contractuales obligatorias en contratos con proveedores de funciones críticas.
- Procedimiento de finalización con plan de migración.
- Pruebas de penetración guiadas por amenazas (TLPT) al menos cada 3 años para entidades seleccionadas.
Para el operador WordPress esto significa que el proveedor de hosting y los plugins críticos (security plugin, backup plugin, payment gateway plugin) entran en el registro TIC.
Específico de NIS2: sanciones y supervisión
La Directiva NIS2 establece sanciones administrativas que las transposiciones naciónales traducen en cuantías concretas. Los topes superiores en la propia directiva:
- Entidad esencial: hasta 10 millones EUR o el 2 por ciento de la cifra de negocios anual a nivel mundial, lo que sea mayor.
- Entidad importante: hasta 7 millones EUR o el 1,4 por ciento de la cifra de negocios anual a nivel mundial, lo que sea mayor.
Las transposiciones naciónales pueden introducir sus propios topes; verificar en la versión vigente de la ley en la jurisdicción correspondiente.
Sanciones complementarias: suspensión temporal de la certificación, prohibiciones temporales de ejercer funciones directivas para la persona responsable. Esto es el cambio más notorio de NIS2: la dirección tiene responsabilidad personal por la gestión del riesgo cibernético.
El artículo 20 de la NIS2 lo recoge directamente: los órgaños de dirección deben aprobar las medidas de gestión del riesgo cibernético, supervisar su implementación y completar la formación correspondiente. En España la transposición se articula a través del real decreto-ley que adapta NIS2, con INCIBE-CERT como CSIRT de referencia para el sector privado y CCN-CERT para el ámbito público; el Esquema Nacional de Seguridad (ENS) sigue siendo el marco aplicable a las administraciones. En la práctica la responsabilidad personal no recae solo en el consejo de administración, sino también en la capa ejecutiva que supervisa operativamente las áreas en el ámbito: director de TI, CISO, responsable de compliance, DPO y director de operaciones. Para una agencia WordPress eso cambia quién debe firmar el entregable por parte del cliente: el registro de riesgos, el runbook de incidentes y el inventario de proveedores deben ser aprobados por esa capa y entregados en formato probatorio que aguante una inspección de INCIBE o CCN-CERT.
Mapa práctico de implementación en WordPress
Cuatro categorías de trabajo, una auditoría:
Capa 1, infraestructura. Hosting conforme. Backup off-site. TLS 1.3. WAF. Monitorización 24/7 o contrato con SOC. Política de actualización del core, themes, plugins.
Capa 2, aplicación. MFA para administradores. Contraseñas robustas. Registro de todas las acciones administrativas en un flujo separado. Anti-CSRF. Anti-XSS a nivel de plantillas. Validación de input. Límite de intentos de login.
Capa 3, organización. Políticas de seguridad. Registro de riesgos. Plan de IR. Plan de BCDR. Registro de proveedores TIC. Procedimiento de notificación de incidentes al CSIRT/regulador. Formación.
Capa 4, documentación y auditoría. Documentación de procesos. Registros de auditoría. Auditoría externa o interna periódica. Retención conforme al RGPD.
WordPress como CMS cubre alrededor del 30 por ciento de los requisitos técnicos “out of the box”, tras hardening y plugins alrededor del 60 por ciento. El 40 por ciento restante es organización, documentación y procedimientos.
Triaje de alcance: de la entidad a la ruta WordPress
Una evaluación útil empieza por la entidad y el servicio regulado, no por una lista genérica de plugins. Registre sociedad, sector, tamaño, mercados, autoridad competente y fundamento utilizado para incluir o excluir la operación. Para NIS2, confirme la transposición nacional vigente y no trate la directiva como única regla operativa. Para DORA, determine el tipo de entidad financiera, las funciones críticas o importantes y los contratos TIC que las sostienen.
Después recorra la cadena hasta WordPress. ¿Qué rutas participan en el servicio? ¿Qué datos recoge cada formulario y adónde llegan? ¿Quién presta hosting, monitorización, correo, DNS, CDN, autenticación, pagos y soporte? Incluya tareas programadas, API, cuentas administrativas, staging, copias y despliegues. Una página corporativa puede tener poca criticidad, mientras un formulario de incidentes, un área privada o una integración de pago puede formar parte del proceso esencial.
El resultado es una matriz de servicio, activo, dependencia, propietario, criticidad y justificación. No resuelve por sí sola la aplicabilidad jurídica. Expone las premisas y evita que una auditoría técnica afirme más de lo que realmente revisó.
Vincular controles con evidencias verificables
“Tenemos MFA” es una afirmación. La configuración, las funciones cubiertas, el procedimiento de recuperación y una prueba fechada constituyen evidencia. Para cada control relacione requisito, riesgo, implementación, propietario, frecuencia y prueba. Evite capturas aisladas sin fecha o contexto, porque envejecen rápido y resultan difíciles de revisar.
El expediente WordPress puede contener inventario de versiones y componentes, política de actualización, aprobaciones de cambio, análisis de vulnerabilidades, configuración de privilegios, registros administrativos enviados a almacenamiento separado, pruebas de restauración, flujos de datos y excepciones. La retención de logs debe ser proporcional y compatible con privacidad; conservarlo todo sin límite no equivale a controlar mejor.
Cada hallazgo necesita reproducción, impacto, activo, prioridad, responsable y criterio de cierre. Si varios sitios comparten pipeline o plugin, corrija la fuente común. El objetivo es un rastro que otra persona pueda revisar, no un PDF que queda obsoleto al entregarlo.
Incidentes: decidir antes de que corra el plazo
Los plazos formales hacen insuficiente un plan que solo conoce el proveedor. Defina quién recibe alertas, declara el incidente, evalúa su significación, conserva evidencias y comunica con autoridad, clientes y dirección. El operador técnico aporta hechos; la entidad y sus responsables designados conservan la decisión regulatoria y la notificación.
El runbook WordPress debería cubrir cuenta administrativa comprometida, explotación de plugin, cambio no autorizado, fuga por formulario, indisponibilidad prolongada, corrupción de base de datos y fallo de proveedor. Para cada escenario indique señales, contención, canales alternativos, preservación de logs, aislamiento, recuperación y criterios para volver a producción.
Separe ejercicios de mesa y pruebas técnicas. El ejercicio comprueba contactos, escalado y decisiones; una restauración demuestra que la copia recupera el servicio. Registre tiempos, fallos y acciones. No espere a un incidente para descubrir que las credenciales de emergencia están dentro del sistema caído.
Proveedores y plugins como controles contractuales
El registro debe distinguir empresa contratada, servicio, subcontratistas conocidos, ubicación, datos tratados, dependencia, salida y evidencias. Un plugin gratuito también crea dependencia aunque no exista contrato negociado. Documente soporte, divulgación de vulnerabilidades, posibilidad de sustitución y riesgo aceptado.
Para funciones críticas o importantes, valore derechos de acceso y auditoría, notificación, continuidad, subcontratación, portabilidad y asistencia de salida. No todas las cláusulas se aplican igual a cada proveedor. El equipo jurídico adapta el contrato y el equipo WordPress aporta inventario y dependencia técnica.
Pruebe la salida antes de necesitarla. Una copia alojada solo en la cuenta del proveedor no es un plan independiente. Documente cómo recuperar código, medios, base de datos, DNS, secretos, configuraciones e historial, y quién puede ejecutar cada paso.
Aceptación, limitaciones y gobierno continuo
Defina la aceptación por riesgo. Una corrección se cierra cuando está aplicada en el entorno correcto, probada, aprobada por el propietario y vinculada a evidencia. Para controles continuos indique frecuencia y disparadores: versión principal, cambio de proveedor, incidente, nueva arquitectura o revisión periódica.
La revisión final debe mostrar controles implantados, brechas, riesgos aceptados, dependencias y límites de la muestra. Una prueba de seguridad no demuestra cumplimiento integral; una auditoría WordPress no evalúa toda la organización; ningún informe garantiza que no habrá incidentes. Estas limitaciones hacen la decisión más defendible y permiten a la dirección comprender el trabajo pendiente.
Tras la entrega, incorpore inventario, parches, accesos, proveedores, ejercicios y evidencias al proceso normal de cambios. La dirección necesita información breve para decidir y concreta para cuestionar retrasos, excepciones y riesgo residual.
Preparar un briefing escrito para la evaluación
Envíe países y entidades, sector, servicio regulado, arquitectura, URL, proveedores críticos, integraciones, entornos, auditorías previas y plazo. Incluya incidentes conocidos y cambios previstos. No comparta secretos ni datos personales en el primer contacto; indique qué evidencias existen y cómo podrían facilitarse de forma segura.
Nuestra auditoría de cumplimiento UE para WordPress incluye una línea NIS2/DORA de triaje, mapeo de evidencias, proveedores y runbooks. La propuesta delimita WordPress y las integraciones observadas; no ofrece certificación jurídica genérica ni garantía frente a incidentes. Un briefing escrito permite separar decisiones legales, remediación técnica y responsabilidades operativas.
Qué sigue
Consecuencias prácticas para la elección del equipo que opera WordPress: una agencia que opera el sitio para una entidad cubierta por NIS2 o DORA entra ella misma en la cadena de suministro. Nuestro modelo de entrega headless deja explícitos la jurisdicción UE y el cumplimiento como estándar, porque es un filtro de procurement en 2026.
Dónde encaja este artículo
El artículo se conecta con el pillar de servicios headless WordPress (capa técnica), con el pillar sobre WCAG/BFSG/EAA (cumplimiento de accesibilidad en el mismo scoreboard de procurement), con el artículo sobre nearshore Polonia (jurisdicción UE como valor para el comprador occidental) y con la auditoría práctica de accesibilidad para la parte operativa.
