NIS2 anexo II para agencias WordPress: alcance, plazos y rastro de evidencias
El artículo 21 de la Directiva 2022/2555 es la disposición operativa que determina cómo es una auditoría. El anexo I y el anexo II determinan quién tiene que pasarla. Este texto asigna las diez medidas del artículo 21, apartado 2, a controles concretos en una agencia WordPress y a los archivos de evidencia que espero cuando un cliente regulado inicia una evaluación de proveedores.
Es un artículo de apoyo al pilar sobre NIS2 y DORA en WordPress, con referencia a la guía de notificación de incidentes en 24 h, 72 h y un mes.
TL;DR
- El artículo 21, apartado 2, enumera diez medidas de gestión de riesgos. Ninguna es opcional.
- Los anexos I y II enumeran sectores; el artículo 3 decide quién es entidad esencial y quién importante. Las mismas medidas, distinta supervisión.
- El auditor busca cuatro artefactos por medida: política, responsable, registro de implantación, ritmo de revisión.
- Las multas del artículo 34 recaen en la entidad, no en el proveedor WordPress, pero las cláusulas de la cadena de suministro trasladan las obligaciones hacia abajo.
- En cada encargo regulado mantengo una carpeta por cada letra del artículo 21.
Qué entidades entran en el anexo I y el anexo II de NIS2
El anexo I enumera los sectores de alta criticidad: energía, transporte, banca, infraestructuras de los mercados financieros, sanidad, agua potable y aguas residuales, infraestructura digital, gestión de servicios TIC (B2B), administración pública, espacio. El anexo II enumera otros sectores críticos: servicios postales y de mensajería, gestión de residuos, sustancias químicas, alimentación, fabricación de productos sanitarios, ordenadores y electrónica, maquinaria y vehículos de motor, proveedores de servicios digitales, organizaciones de investigación.
Ambos anexos se aplican a entidades medianas y de mayor tamaño (50 o más empleados, o un volumen de negocios anual y un balance general ambos superiores a 10 millones de EUR). Las microempresas y pequeñas empresas quedan fuera del ámbito directo, con las excepciones del artículo 2, apartado 2: prestadores de servicios de confianza, registros de TLD, algunos proveedores de DNS, administración pública, proveedores de redes públicas de comunicaciones electrónicas.
Filtro práctico para una agencia WordPress: hospital, banco, planta química, operador de centro de datos, registro de TLD. Si el cliente es uno de ellos, empieza la delimitación del ámbito. Si el cliente es un hotel, una startup SaaS o un comercio regional, la delimitación suele terminar con “fuera del ámbito, las buenas prácticas de seguridad siguen aplicándose”.
Medidas del artículo 21 de NIS2 en una agencia WordPress
El texto de la directiva se lee como diez letras, de la a) a la j). Cada letra se convierte en una carpeta en mi repositorio de proyecto.
a) Políticas de análisis de riesgos y de seguridad de los sistemas de información. Un registro de riesgos firmado, con activos, amenazas, probabilidad, impacto y tratamiento. Para WordPress: servidor de producción, servidor de staging, conjunto de plugins, APIs externas (pagos, correo electrónico, analítica, IA), cuentas de administración, base de datos de contenidos. Amenazas: RCE en un plugin, credential stuffing, ransomware sobre las copias de seguridad, brecha del RGPD a través de una exportación. Tratamiento: calendario de actualizaciones, MFA, copia de seguridad cifrada fuera de las instalaciones, conjunto de reglas WAF.
b) Gestión de incidentes. Detección, clasificación, respuesta, recuperación, balance. Evidencia: runbook de respuesta a incidentes con responsables con nombre, herramienta de monitorización que dispara alertas (Wordfence, Sucuri, IDS del hosting, alertas de Cloudflare), canal de Slack o PagerDuty, plantilla de post-mortem.
c) Continuidad de las actividades, como la gestión de copias de seguridad y la recuperación en caso de catástrofe, y gestión de crisis. Copia de seguridad con almacenamiento externo, RPO y RTO definidos, restauración probada. Plan de comunicación de crisis con una persona para los medios y otra para el regulador. Simulacro anual de restauración con informe.
d) Seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos. Aquí es donde aterriza la agencia WordPress. La entidad regulada mantiene un registro de proveedores, los clasifica por criticidad, realiza la due diligence e incluye cláusulas de seguridad en los contratos. El artículo 28 de DORA aplica la misma lógica, con más rigor para el sector financiero.
e) Seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades. Un ciclo de desarrollo seguro documentado. Para WordPress: revisión de código de los plugins y temas propios, análisis de dependencias (Snyk, Dependabot), Plugin Check (PCP) de WordPress.org para los plugins propios, una dirección de correo para notificar vulnerabilidades, una política de gestión de parches.
f) Políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad. Auditoría interna, externa o prueba de penetración. Evidencia: descripción del alcance, informe de la prueba, registro de acciones correctivas, acta de la repetición de la prueba.
g) Prácticas básicas de ciberhigiene y formación. Formación anual para toda la plantilla, formación por rol para los administradores. Evidencia: registro de formación con nombres, fechas y contenidos.
h) Políticas y procedimientos relativos a la utilización de criptografía y, en su caso, de cifrado. TLS 1.3 en el borde, cifrado de las copias de seguridad, cifrado en reposo de las copias de la base de datos. Política de algoritmos de hash (sin MD5 ni SHA-1). Inventario de claves criptográficas.
i) Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos. Proceso de altas, cambios y bajas de personal. Cuentas de administración nominativas, sin credenciales compartidas. Inventario de activos que abarque todas las instalaciones WordPress, entornos de staging, accesos a repositorios y accesos a consolas de hosting. Revisión trimestral de permisos.
j) Uso de soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras y sistemas seguros de comunicación de emergencia. MFA en cada inicio de sesión de administración de WordPress, cada consola de hosting, cada consola de CDN, cada repositorio de código, cada buzón de correo. Sin excepciones para “cuentas internas de confianza”.
Entidad esencial o entidad importante según el artículo 3 de NIS2
El anexo en el que figura un sector no decide por sí solo la categoría. El artículo 3, apartado 1, letra a), considera esenciales las entidades de los tipos del anexo I que superan los límites máximos de mediana empresa de la Recomendación 2003/361/CE, es decir, las grandes empresas: 250 o más empleados, o un volumen de negocios anual superior a 50 millones de EUR junto con un balance general superior a 43 millones de EUR. El artículo 3, apartado 2, considera entidades importantes a las demás entidades de los tipos de los anexos I y II que no son esenciales. Un hospital mediano del anexo I es, por tanto, una entidad importante, igual que un fabricante grande del anexo II.
Hay casos que no dependen del tamaño. El artículo 3, apartado 1, letra b), declara esenciales a los prestadores cualificados de servicios de confianza, a los registros de nombres de dominio de primer nivel y a los proveedores de servicios de DNS, sea cual sea su tamaño. Los Estados miembros pueden además identificar entidades concretas con arreglo al artículo 2, apartado 2, letras b) a e).
La consecuencia práctica para la agencia es que el cliente debe conocer su categoría antes de enviar el cuestionario. El artículo 3, apartado 3, obligaba a los Estados miembros a elaborar antes del 17 de abril de 2025 una lista de entidades esenciales e importantes y a revisarla al menos cada dos años. Si el cliente no sabe indicar su categoría, la evaluación del proveedor empieza con una pregunta abierta, y esa pregunta corresponde a su asesoría jurídica, no a la agencia.
Una agencia de mantenimiento WordPress como proveedor de servicios gestionados en NIS2
El artículo 6, punto 39, define el proveedor de servicios gestionados como la entidad que presta servicios relacionados con la instalación, la gestión, la explotación o el mantenimiento de productos, redes, infraestructuras o aplicaciones de TIC o cualesquiera otros sistemas de redes y de información, mediante asistencia o administración activa en las instalaciones del cliente o a distancia. El anexo I, punto 9, incluye a estos proveedores en el sector de gestión de servicios de TIC (de empresa a empresa). Un contrato de mantenimiento WordPress con acceso de administración, actualizaciones y supervisión de servidores encaja en la redacción de esa definición. Si una agencia concreta queda incluida es una valoración jurídica, y no la hago por nadie.
El tamaño sigue mandando. Una agencia con menos de 50 personas y un volumen de negocios o un balance de hasta 10 millones de EUR queda fuera del artículo 2, apartado 1. Una agencia mediana que preste servicios gestionados sería una entidad importante; una grande, esencial. Para estos proveedores, el artículo 26, apartado 1, letra b), sitúa la jurisdicción en el Estado miembro de su establecimiento principal en la Unión.
Hay una segunda consecuencia. El Reglamento de Ejecución (UE) 2024/2690 de la Comisión, adoptado con arreglo al artículo 21, apartado 5, desarrolla los requisitos técnicos y metodológicos de las medidas del artículo 21, apartado 2, para los proveedores de servicios gestionados, entre otros. Su artículo 3 considera significativo, por ejemplo, un incidente que cause o pueda causar una pérdida financiera directa superior a 500 000 EUR o al 5 % del volumen de negocios anual total del ejercicio anterior, si esta cifra es menor. Una agencia incluida en el ámbito aplica ese reglamento directamente, no a través del contrato del cliente.
Qué evidencias exige un auditor de NIS2 para cada medida
Para cada una de las diez letras espero cuatro artefactos cuando llega el auditor:
| Artefacto | Aspecto | Significado |
|---|---|---|
| Documento de política | Aprobado por la dirección, fechado, con control de versiones | El artículo 20 exige la aprobación y supervisión del órgano de dirección |
| Responsable del proceso | Rol con nombre (CISO, responsable de ingeniería, director de la agencia) | El auditor no acepta “el equipo” como responsable |
| Registro de implantación | Logs, capturas de pantalla, números de ticket, informes de análisis, cláusulas contractuales | Demuestra que la política funciona de verdad |
| Ritmo de revisión | Revisión anual o trimestral, entrada en el calendario, acta | Una política en el cajón sin revisión es un hallazgo de auditoría |
Mantengo esta tabla de cuatro columnas para cada letra del artículo 21, apartado 2. Diez letras, cuarenta artefactos. Así es el dosier de auditoría en 2026.
Plazos de notificación de incidentes del artículo 23 de NIS2
El artículo 21 regula el funcionamiento ordinario. Cuando se produce un incidente, se aplica el artículo 23:
- 24 horas desde que se tiene conocimiento: alerta temprana al CSIRT o a la autoridad competente.
- 72 horas desde que se tiene conocimiento: notificación con evaluación inicial e indicadores de compromiso.
- 1 mes después de la notificación del incidente: informe final con la descripción detallada, la causa raíz probable, las medidas de mitigación aplicadas y en curso y, en su caso, el impacto transfronterizo.
- Si el incidente sigue abierto en ese momento: un informe de situación y el informe final en el plazo de un mes desde la gestión del incidente (artículo 23, apartado 4, letra e).
- Informe intermedio siempre que lo solicite el regulador.
Multas de NIS2 y responsabilidad de la dirección
El artículo 34 fija umbrales que las transposiciones nacionales no pueden rebajar:
- Entidades esenciales: al menos 10 millones de EUR o el 2 % del volumen de negocios anual mundial total, según cuál sea mayor.
- Entidades importantes: al menos 7 millones de EUR o el 1,4 % del volumen de negocios anual mundial total, según cuál sea mayor.
El artículo 20, apartado 1, atribuye la responsabilidad a los órganos de dirección, incluida la obligación de supervisar la aplicación. El artículo 20, apartado 2, exige que los miembros del órgano reciban formación. Las transposiciones nacionales pueden añadir sanciones personales contra la persona responsable. En España todavía no hay ley de transposición: el anteproyecto aprobado por el Consejo de Ministros el 14 de enero de 2025 no se aprobó antes de que el Real Decreto 806/2026 disolviera las Cortes. Antes de la auditoría, revisa con el cliente sus obligaciones vigentes según el Real Decreto-ley 12/2018.
Cláusulas de cadena de suministro NIS2 en el contrato con la agencia WordPress
El artículo 21, apartado 3, obliga a la entidad a tener en cuenta, al elegir las medidas de la letra d), las vulnerabilidades específicas de cada proveedor directo, la calidad general de sus productos y sus prácticas de ciberseguridad, incluidos sus procedimientos de desarrollo seguro. El artículo 21, apartado 4, exige medidas correctoras sin demora indebida cuando la entidad detecta que no cumple. En una agencia WordPress esto se traduce en preguntas sobre revisión de código, gestión de dependencias y plazos de parcheo.
El texto oficial más detallado sobre el contenido del contrato es el punto 5.1.4 del anexo del Reglamento de Ejecución 2024/2690. Enumera lo que, cuando proceda, deben especificar los contratos con proveedores: requisitos de ciberseguridad; sensibilización, capacidades, formación y certificados del personal del proveedor; control de antecedentes de ese personal; notificación sin demora indebida de los incidentes que supongan un riesgo; derecho de auditoría o a recibir informes de auditoría; obligación de hacerse cargo de las vulnerabilidades; reglas de subcontratación; obligaciones al terminar el contrato, como la recuperación y eliminación de la información.
El reglamento obliga solo a las entidades de su artículo 1: proveedores de DNS, registros de TLD, proveedores de nube, de centros de datos y de CDN, proveedores de servicios gestionados y de seguridad gestionada, mercados en línea, motores de búsqueda, redes sociales y prestadores de servicios de confianza. Un hospital o un fabricante no está obligado por él, pero los ocho elementos sirven como lista de comprobación para el borrador de contrato. Si falta alguno, la agencia pregunta al cliente cómo lo cubre antes de firmar.
Cómo delimitar los servicios de la agencia en una evaluación NIS2
El paquete de la agencia empieza por describir la frontera. Hay que indicar las partes del contrato, el servicio del cliente, los sitios de producción, los repositorios, los entornos, las integraciones y los proveedores que la agencia gestiona realmente. La responsabilidad sobre el código WordPress, el hosting, el DNS, la CDN, la identidad, los pagos y el acceso editorial se detalla por separado. Que una herramienta esté presente en la arquitectura no convierte automáticamente a la agencia en propietaria del control.
En el mismo documento se registran exclusiones y supuestos. Si el cliente mantiene su propio proveedor de identidad o gestiona la base de datos, hay que decirlo. Si la agencia despliega código pero no aprueba los cambios en producción, ese reparto también debe ser visible. El cliente regulado responde de su calificación NIS2 y del derecho nacional; la agencia aporta evidencias sobre su propio servicio.
Matriz RACI de NIS2 para cliente, agencia y hosting
Una matriz de tipo RACI cubre la aprobación de cambios, los despliegues de emergencia, la clasificación de vulnerabilidades, el acceso privilegiado, la ejecución de copias de seguridad, la autorización de restauraciones, la escalada de incidentes, la revisión de logs y la salida del proveedor. Cada fila indica el rol del cliente, el rol de la agencia, quién aprueba, dónde está la evidencia y el canal de escalada.
Los controles compartidos exigen precisión. El hosting puede hacer la copia, la agencia supervisar su ejecución y el cliente fijar el objetivo de restauración. Una entrada del tipo “responde el hosting” oculta las obligaciones de control y decisión de las demás partes. La matriz se actualiza cuando cambian el alcance, la arquitectura o las personas.
Evidencias de NIS2 para cambios, vulnerabilidades y accesos
Para un cambio se conservan la solicitud, la evaluación de riesgos, la revisión por una segunda persona, la prueba, la aprobación, el registro del despliegue y el resultado del rollback. Un cambio de emergencia tiene un camino más corto, pero no un camino sin documentación: se registran la autoridad de quien decide, el motivo y el plazo de la revisión posterior. Una release debe enlazar el ticket, el commit y la hora en producción.
Para una vulnerabilidad se registran el origen de la alerta, el activo y la versión, la justificación de la prioridad, la exposición, la decisión, el plazo y la repetición de la prueba. Una exportación del escáner, por sí sola, no dice si el problema afectaba a producción ni si se aceptó una excepción. Cuando un plugin no tiene un parche con soporte, hacen falta controles compensatorios y una decisión de sustitución.
Para un acceso se registran la identidad nominativa, el rol, la justificación, quién aprueba, el MFA, la fecha de concesión y la última revisión. La retirada del acceso de una persona que se marcha o de una cuenta de soporte caducada también tiene que dejar rastro. Las contraseñas y los códigos de recuperación no van en el dosier de evidencias.
Cómo probar la restauración de copias de seguridad para NIS2
Un estado verde en la tarea de copia de seguridad confirma que se creó el archivo, no que sea recuperable. La evidencia describe el alcance, el ritmo, el cifrado, la ubicación, la retención, la alerta de fallo y las personas autorizadas a restaurar. Después se realiza la restauración en un entorno aislado, registrando el inicio, el final, la comprobación de integridad, la prueba de la aplicación y las desviaciones respecto al RPO y al RTO.
Hay que contemplar las dependencias que quedan fuera de la base de datos: medios, configuración, secretos, DNS, reglas en el borde, tareas programadas y definiciones de despliegue. Restaurar solo la base de datos puede dar un sitio que se abre, pero que no envía mensajes ni acepta pagos. El acta de aceptación precisa qué servicio se recuperó, qué se simuló y qué se excluyó.
Con qué frecuencia revisar y aceptar las evidencias de NIS2
Cada evidencia tiene un responsable y un disparador de actualización. Los accesos pueden revisarse cada trimestre, los simulacros de restauración y de incidentes cada año o tras un cambio relevante, y las vulnerabilidades y parches de forma continua. Un cambio de contrato, arquitectura, proveedor o de un plugin crítico activa una revisión específica.
Un artefacto queda aceptado cuando está actualizado, tiene responsable, está vinculado a un control dentro del alcance, está guardado en el lugar correcto y lo ha comprobado el rol responsable. Las carencias se registran aparte, con riesgo, responsable y plazo. No se debe crear un registro histórico que falta como si hubiera existido antes.
El paquete muestra controles seleccionados del proveedor en un periodo determinado. No es un certificado NIS2, ni un dictamen jurídico, ni una prueba de cumplimiento total del cliente. Tampoco garantiza la ausencia de incidentes. Las limitaciones deben figurar en la portada.
Presupuesto de un paquete de proveedor NIS2 para WordPress
Para pedir presupuesto, envíe las partes del contrato, la descripción del servicio, la arquitectura, los entornos, las integraciones críticas, el cuestionario de proveedor, la fecha de la auditoría y la lista de evidencias disponibles. No envíe secretos en el primer mensaje. Nuestro trabajo de preparación para NIS2 y DORA puede abarcar el paquete de proveedor WordPress, la matriz de responsabilidades, las carencias de evidencia y la aceptación. No sustituye la valoración jurídica del cliente.
Qué incluye el paquete de seguridad del proveedor
Una agencia WordPress que quiera conservar clientes regulados en 2026 entrega dos artefactos en cada encargo:
- Una autodeclaración respecto al artículo 21, apartado 2, letra d, que describe las medidas de seguridad aplicadas en la propia agencia.
- Un documento de referencia que el cliente incorpora a su propio dosier del artículo 21 y que muestra cómo el encargo WordPress se corresponde con cada una de las diez medidas.
Reúno ambos en un “paquete de seguridad del proveedor” y lo adjunto a la propuesta. Así se elimina una ronda con el departamento de compras y se demuestra que entendemos el contexto regulatorio. El presupuesto de los encargos de compliance engineering es individual; es el alcance del dosier lo que marca las horas, no una tarifa.
