NIS2 frente a DORA: solapamiento de alcance para agencias WordPress en 2026
La Directiva 2022/2555 (NIS2) y el Reglamento 2022/2554 (DORA) cubren un terreno similar, pero con mecánicas distintas. NIS2 es una directiva que cada Estado miembro transpone a su derecho nacional. DORA es un reglamento de aplicación directa. NIS2 cubre un amplio conjunto de sectores esenciales e importantes. DORA es específica del sector financiero. Donde se solapan (la mayor parte de la gestión de riesgos, la gestión de incidentes, la cadena de suministro), un rastro de evidencia bien construido puede satisfacer ambas. Donde DORA va más allá (Registro de Información, pruebas de penetración basadas en amenazas), la agencia WordPress necesita añadir las diferencias.
Este es un artículo de apoyo dentro del pilar de NIS2 y DORA en WordPress, con referencias cruzadas al rastro de evidencia del Anexo II, la guía del artículo 28 de DORA, la guía de campos del Registro de Información y la línea de tiempo de notificación 24/72/30.
Resumen
- DORA es lex specialis para entidades financieras; NIS2 se aplica en el resto de los casos.
- Solapamiento: gestión de riesgos, gestión de incidentes, continuidad de negocio, cadena de suministro, notificación.
- Solo DORA: esquema del Registro de Información, TLPT para entidades críticas, cláusulas prescriptivas para terceros.
- Solo NIS2: alcance sectorial más amplio (energía, transporte, salud, administración pública), variantes de transposición nacional.
- Regla práctica: si algún cliente está bajo DORA, construya el rastro de evidencia al nivel DORA y redúzcalo para NIS2.
Cómo la propia NIS2 nombra a DORA
El artículo 1(2) de NIS2 dice: donde actos legislativos sectoriales de la Unión exijan a entidades esenciales o importantes gestionar riesgos de ciberseguridad o notificar incidentes significativos, se aplican esas disposiciones sectoriales. DORA es uno de esos actos. Por lo tanto, una entidad financiera dentro del alcance de DORA no cumple doblemente: cumple DORA, y las disposiciones equivalentes de NIS2 se consideran cumplidas.
Lo que DORA no aborda explícitamente (por ejemplo, parte de la responsabilidad del órgano de dirección según NIS2, la formación, la cooperación sectorial entre CSIRT), sigue estando cubierto por la base de NIS2.
Para una agencia WordPress esto significa: si el cliente es un banco, una empresa de inversión, una entidad de pago, una aseguradora, un gestor de activos, un TPP bajo PSD2, domina DORA. Construya sobre DORA. Si el cliente es un hospital, un registro TLD, un distribuidor de energía, un operador postal, domina NIS2. Construya sobre NIS2.
Árbol de decisión: ¿NIS2, DORA, o ambas?
La regla anterior (“DORA para finanzas, NIS2 para todo lo demás”) se mantiene en los casos obvios. Se rompe en los casos que realmente requieren una tarde de definición de alcance: una fintech por debajo del umbral de entidad significativa, un grupo hospitalario con una filial de pagos, o una agencia que nunca ha firmado nada con la palabra “NIS2” pero descubre una cláusula de cadena de suministro enterrada en un anexo. El diagrama de flujo siguiente es el recorrido que usamos en una llamada de incorporación con un cliente nuevo, antes de que empiece cualquier revisión del contrato.
flowchart TD
A["¿El cliente es una entidad financiera según el artículo 2 de DORA?"] -->|"Sí"| B["¿Es un banco, empresa de inversión, entidad de pago, aseguradora, gestor de activos, o TPP de PSD2?"]
A -->|"No"| C["¿El cliente está en un sector del Anexo I o II de NIS2: energía, transporte, salud, agua, infraestructura digital, administración pública, correos, residuos, o manufactura?"]
B -->|"Sí"| D["DORA principal: construir Registro de Información, preparación para TLPT, análisis de riesgo de concentración"]
B -->|"No - por debajo del umbral o exento"| C
C -->|"Sí"| E["NIS2 principal: construir registro de riesgos del artículo 21, rastro de evidencia del Anexo II, delta de transposición nacional"]
C -->|"No"| F["¿Está la agencia contratada por una entidad que a su vez está dentro del alcance, es decir, la agencia es proveedor TIC de terceros?"]
F -->|"Sí - el cliente es alcance DORA"| G["Incorporación por cadena de suministro según el artículo 28 de DORA: las cláusulas contractuales del cliente trasladan obligaciones de nivel DORA"]
F -->|"Sí - el cliente es alcance NIS2"| H["Incorporación por cadena de suministro según el artículo 21(2)(d) de NIS2: las cláusulas contractuales del cliente trasladan obligaciones de nivel NIS2"]
F -->|"No"| I["Ningún régimen se aplica directa ni indirectamente: vigilar el crecimiento del cliente y la reclasificación sectorial cada año"]
D --> J["¿Tiene el grupo filiales no financieras que también usan la agencia?"]
E --> J
J -->|"Sí"| K["Holding de régimen mixto: mantener la evidencia de nivel DORA como techo y mapear las filiales individualmente"]
J -->|"No"| L["Un rastro de evidencia de un solo nivel es suficiente"]
Hay dos ramas donde las agencias suelen equivocarse más al responder. Primero, la rama “No - por debajo del umbral o exento” que sale de B: un cliente puede ser una entidad financiera según el artículo 2 de DORA y aún así no ser un banco o una aseguradora en el sentido cotidiano; los proveedores de servicios de financiación participativa y algunas entidades de pago caen aquí, y no dejan de ser entidades DORA solo por ser pequeñas. Segundo, la rama F: una agencia sin ningún cliente regulado sobre el papel puede seguir siendo arrastrada a obligaciones de DORA si uno de sus subcontratos de alojamiento o mantenimiento se encuentra bajo la cadena de suministro de una entidad regulada, varios niveles más abajo.
Matriz de aplicabilidad
Seis arquetipos de cliente que una agencia probablemente encontrará, mapeados frente al régimen principal, cómo llega la obligación a la agencia, y el nivel de rastro de evidencia con el que debería terminar esa llamada de definición de alcance.
| Tipo de cliente | Régimen principal | Incorporación por cadena de suministro | Nivel del rastro de evidencia |
|---|---|---|---|
| Banco | DORA (alcance directo) | No aplica - el propio banco es la entidad regulada | DORA completo: Registro de Información, preparación para TLPT, análisis de riesgo de concentración |
| Entidad de pago | DORA (alcance directo) | No aplica - la propia entidad es la regulada | DORA completo: Registro de Información, TLPT proporcional según el tamaño |
| Hospital | NIS2 (alcance directo, sector salud, Anexo I) | No aplica - el propio hospital es la entidad regulada | Base NIS2: registro de riesgos del artículo 21, rastro de evidencia del Anexo II |
| Distribuidor de energía | NIS2 (alcance directo, sector energía, Anexo I) | No aplica - el propio distribuidor es la entidad regulada | Base NIS2, a menudo elevada a la profundidad de entidad esencial dada la criticidad |
| Agencia WordPress como proveedor TIC | Ninguno directamente | Artículo 28 de DORA o artículo 21(2)(d) de NIS2, según el cliente que contrate a la agencia | Refleja el régimen del cliente; el nivel DORA se convierte en el mínimo en cuanto un cliente está en alcance DORA |
| Grupo con filiales mixtas | Dividido por filial (algunas DORA, algunas NIS2) | Directo para las filiales reguladas, incorporación contractual para el resto mediante la lista de proveedores compartida del grupo | Techo de nivel DORA aplicado a todo el grupo, reducido por filial una vez confirmado su propio régimen |
El patrón que sorprende en las llamadas de definición de alcance nuevas: en cuanto una relación con un cliente en cualquier parte de la cartera de la agencia es alcance DORA, es operativamente más económico construir cada rastro de evidencia al nivel DORA y reducirlo para los clientes solo-NIS2 que mantener dos sistemas de documentación en paralelo.
Dos casos de definición de alcance anonimizados
Los detalles siguientes están compuestos y despojados de datos identificativos; ningún nombre de cliente aparece en esta sección.
Caso A: cooperativa de crédito regional. Una cooperativa de crédito con unas 40 sucursales en una sola región subcontrató su sitio web corporativo y una intranet interna para el personal, ambos basados en WordPress, a una agencia externa. La cooperativa es una entidad financiera según el artículo 2 de DORA sin matices; la estructura “cooperativa” no cambia eso. La llamada de definición de alcance confirmó que la agencia debía aparecer en el Registro de Información de la cooperativa como proveedor de servicios TIC de terceros, en concreto en las tablas B.02.01 (acuerdos contractuales) y B.05.01 (funciones respaldadas), aunque el tamaño de la cooperativa la mantenía por debajo del umbral de pruebas de penetración avanzadas basadas en amenazas. La agencia aún tuvo que responder a la pregunta de riesgo de concentración del artículo 29 (“quién más podría hacerse cargo del alojamiento y el mantenimiento en ocho semanas”) porque el responsable de cumplimiento de la cooperativa necesitaba esa respuesta por escrito independientemente del estatus TLPT. La estructura de carpetas del rastro de evidencia resultante reflejaba el diseño 05_dora_register/ descrito más adelante en este artículo, poblada desde el primer día del contrato en lugar de completarse a última hora antes de una auditoría.
Caso B: grupo hospitalario municipal. Un grupo de hospitales municipales que gestiona un portal de información para pacientes compartido y una intranet para el personal, ambos basados en WordPress, contrató el mismo enfoque de rastro de evidencia, pero aterrizó en el lado opuesto del árbol. Los hospitales están en el Anexo I de NIS2 (sector salud) y el grupo no tenía estatus de entidad financiera en ninguna parte de su estructura, así que DORA nunca entró en juego. No se construyó ningún esquema de Registro de Información; hubiera sido un esfuerzo desperdiciado, ya que el formato RoI de quince tablas es un requisito específico de DORA sin equivalente en NIS2. En su lugar, la agencia construyó un registro de proveedores más simple más un cuestionario de diligencia debida y una cláusula de SLA de notificación de incidentes vinculada a la transposición nacional de NIS2 del hospital (que establecía sus propios plazos de notificación y autoridad competente, distintos del ritmo de 24h/72h/1 mes usado en el resto de este pilar). La lección práctica al comparar ambos casos lado a lado: el cliente de alcance DORA costó aproximadamente el doble de esfuerzo de documentación inicial que el cliente de alcance NIS2, casi enteramente por el esquema del Registro de Información, y esa diferencia de coste es el mejor predictor de qué nivel de rastro de evidencia cotizar para un nuevo contrato.
Qué se solapa
Cinco grandes áreas de solapamiento donde un único artefacto sirve a ambos regímenes:
Gestión de riesgos. El artículo 21 de NIS2 enumera diez medidas; los artículos 5-15 de DORA cubren el mismo terreno conceptual con más detalle. Un registro de riesgos que nombre activos, amenazas, probabilidad, impacto y tratamiento satisface ambos. El nivel de detalle difiere: DORA espera más granularidad para funciones críticas o importantes; NIS2 espera proporcionalidad.
Gestión de incidentes. Los artículos 22-23 de NIS2 y los artículos 17-23 de DORA exigen ambos clasificación, respuesta, recuperación, análisis posterior y notificación. Los plazos de notificación difieren ligeramente (NIS2: alerta temprana 24h, notificación 72h, informe final 1 mes; DORA: similar, con plantillas sectoriales). El manual interno de respuesta a incidentes puede compartirse.
Continuidad de negocio. El artículo 21(2)(c) de NIS2 y el artículo 11 de DORA exigen ambos copia de seguridad, restauración probada, fuera del sitio, con RPO y RTO documentados. Un plan de continuidad y recuperación con un registro anual de pruebas de restauración satisface ambos.
Controles de la cadena de suministro. El artículo 21(2)(d) de NIS2 y el artículo 28 de DORA exigen ambos registro de proveedores, diligencia debida, cláusulas contractuales, plan de salida. El Registro de Información de DORA es un esquema más estricto; construir para DORA otorga el cumplimiento de la cadena de suministro de NIS2 de forma gratuita.
Notificación. Ambos exigen notificación a la autoridad competente. NIS2 designa el CSIRT nacional y la autoridad competente; DORA notifica al regulador financiero (nacional más las autoridades europeas de supervisión). La preparación interna de la evidencia es la misma; el destinatario es diferente.
Lo que DORA añade encima
Tres diferencias donde DORA va más allá de NIS2 y la agencia WordPress debe añadir evidencia específica:
Esquema del Registro de Información. El Reglamento de Ejecución 2024/2956 de la Comisión especifica quince tablas con columnas nombradas. Detallado en la guía de campos del Registro de Información. NIS2 no tiene equivalente; la agencia bajo obligaciones solo-NIS2 no necesita este esquema.
Pruebas de penetración basadas en amenazas. El artículo 26 de DORA exige TLPT avanzadas para entidades financieras clasificadas como significativas. La agencia que opera infraestructura crítica para una entidad de este tipo puede estar dentro del alcance como sistema sometido a prueba. NIS2 menciona la gestión de vulnerabilidades de forma amplia, pero no el TLPT.
Riesgo de concentración y sustituibilidad. El artículo 29 de DORA exige un análisis explícito de concentración: cuántas funciones críticas respalda este tercero, y con qué facilidad puede ser sustituido. La agencia debe poder responder “quién más podría hacer este trabajo en ocho semanas si desaparecemos”. NIS2 no tiene una exigencia prescriptiva comparable.
Lo que NIS2 añade encima
Dos diferencias donde NIS2 llega más lejos que DORA en contextos no financieros:
Amplitud sectorial. Hospitales, ISP, operadores de telecomunicaciones, servicios postales, producción de alimentos, administración pública, organizaciones de investigación están en NIS2. La mayoría no están en DORA. La agencia que trabaja en estos sectores de clientes mantiene un rastro conforme a NIS2 por sector.
Variantes de transposición nacional. Como NIS2 es una directiva, cada Estado miembro implementa los detalles con matices locales. La implementación alemana (KRITIS-DachG / NIS2UmsuCG) difiere de la polaca (KSC), que a su vez difiere de la noruega. La agencia que opera de forma transfronteriza mantiene un pequeño documento de diferencias por jurisdicción.
Un rastro de evidencia, ambos regímenes
Un diseño práctico del rastro de evidencia que cubre ambos:
00_governance/- registro de riesgos, aprobación del órgano de dirección, ritmo de revisión.01_gestion_riesgos/- mapeo del artículo 21 / artículo 5, controles, archivos de evidencia.02_respuesta_incidentes/- manual, simulacros de sobremesa, análisis posteriores, plantillas 24/72/30.03_continuidad_negocio/- política de copias de seguridad, registros de pruebas de restauración, plan de continuidad.04_cadena_suministro/- registro de proveedores, lista de subcontratistas, archivos de diligencia debida.05_dora_register/- entradas al Registro de Información (15 tablas) para clientes DORA.06_notificacion/- informes previos, registro de destinatarios, registro de plazos.07_jurisdicciones/- diferencias de transposición de NIS2 por Estado miembro.08_tlpt/- para entidades DORA significativas, informes de TLPT y remediación.
Constrúyalo una vez, iterelo cada trimestre, y la siguiente revisión de proveedores tomará horas, no semanas.
Referencias cruzadas
- NIS2 Anexo II para agencias WordPress: rastro de evidencia
- DORA artículo 28: riesgo de terceros TIC para WordPress
- Registro de Información de DORA para proveedores WordPress: campos requeridos
- Línea de tiempo de notificación de incidentes NIS2 24h/72h/1M
- Pilar de NIS2 y DORA en WordPress
- Auditoría de cumplimiento UE para WordPress




