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.
- Anexo I = entidades esenciales. Anexo II = entidades importantes. 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 las entidades esenciales: 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 las entidades importantes: 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 volumen de negocios anual superior a 10 millones de EUR, o balance total superior 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, gestora de OICVM. 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 Checker en WordPress.org), 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”.
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 anexo II describe 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 desde que se tiene conocimiento: informe final con la causa raíz y las medidas correctivas adoptadas.
- 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; el estado de la ley polaca del sistema nacional de ciberseguridad debe comprobarse en ISAP antes de la auditoría.
¿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.
