Qué exige NIS2 en pentesting según el artículo 21
Si eres CISO o Security Manager de una empresa que cae dentro del ámbito de NIS2, probablemente ya te has enfrentado a la misma pregunta que casi todo el sector: la directiva habla de "gestión de riesgos", "medidas técnicas" y "evaluación de la eficacia", pero no publica una checklist con ensayos obligatorios. Esa ambigüedad es incómoda. Te obliga a interpretar el texto y a decidir qué evidencias vas a presentar cuando la autoridad competente —en España, dependiente del marco que desarrolla la transposición— o un auditor te pida demostrar que tus controles funcionan de verdad y no solo sobre el papel.
En este artículo desglosamos qué exige NIS2 en pentesting, qué dice literalmente el artículo 21, dónde encaja una prueba de intrusión dentro de esas obligaciones y por qué el pentesting es, hoy, la vía más defendible para demostrar la eficacia de las medidas.
Qué dice realmente el artículo 21 de NIS2
El artículo 21 de la Directiva (UE) 2022/2555 establece que las entidades esenciales e importantes deben adoptar "medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos" que afectan a sus redes y sistemas de información. El enfoque es de gestión de riesgos "all-hazards": tienes que cubrir todo el espectro de amenazas, no solo un catálogo cerrado.
El apartado 2 concreta un mínimo de áreas que las medidas deben abarcar. Entre ellas destacan, por su relación directa con el pentesting:
- Análisis de riesgos y políticas de seguridad de los sistemas de información.
- Gestión de incidentes (detección, respuesta y recuperación).
- Seguridad en la adquisición, desarrollo y mantenimiento de sistemas, incluida la gestión y divulgación de vulnerabilidades.
- Políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad.
- Prácticas básicas de ciberhigiene y formación.
- Seguridad de la cadena de suministro.
La clave está en la cuarta: NIS2 no te pide solo tener controles, te pide evaluar si funcionan. Y esa evaluación tiene que ser periódica, documentada y capaz de sostener un escrutinio externo. Ahí es donde una autoevaluación de escritorio deja de ser suficiente.
"Evaluar la eficacia" no es lo mismo que "tener el control"
Muchas organizaciones confunden ambos planos. Tener un WAF, un EDR o una política de gestión de parches acredita que existe el control. Pero el artículo 21 exige demostrar que ese control resiste un ataque real. La diferencia es sustancial: un firewall mal configurado, una regla de detección con un hueco o un proceso de parcheo con SLAs incumplidos son controles que existen y que fallan. Solo una prueba adversaria lo revela.
Además, el artículo 21 se apoya en el principio de proporcionalidad: el grado de exigencia debe ser acorde al riesgo, al tamaño de la entidad y a la probabilidad e impacto de los incidentes. Esto significa que una prueba genérica y descontextualizada no basta; la evaluación debe alinearse con tu superficie de exposición real.
Por qué el pentesting es la evidencia que NIS2 espera
NIS2 no menciona la palabra "pentesting" de forma literal, y conviene ser honestos con ello. Pero cuando la directiva exige "políticas y procedimientos para evaluar la eficacia de las medidas" y "gestión y divulgación de vulnerabilidades", el test de intrusión es la técnica que materializa ambas obligaciones de forma verificable.
Un escaneo automatizado de vulnerabilidades te da un inventario de fallos conocidos, pero no valida explotabilidad ni cadenas de ataque, ni evalúa la respuesta de tu equipo de detección. El pentesting, por el contrario, aporta tres cosas que un auditor de NIS2 valora:
- Evidencia de explotabilidad real. Un hallazgo con prueba de concepto demuestra impacto de negocio, no una simple etiqueta CVSS.
- Validación de la cadena de defensa. El ejercicio pone a prueba prevención, detección y respuesta de forma encadenada, exactamente el planteamiento "all-hazards".
- Trazabilidad documental. Un informe metodológico, con alcance, vectores probados y remediación priorizada, constituye la evidencia que sostiene la obligación de "evaluar la eficacia".
La metodología importa tanto como el resultado
Para que un pentest sea defendible ante NIS2, la ejecución debe apoyarse en marcos reconocidos. En CISEC trabajamos con OWASP (WSTG y ASVS para aplicaciones y API), PTES para la estructura del ejercicio y MITRE ATT&CK para mapear técnicas adversarias contra tus capacidades de detección. Este mapeo es especialmente útil porque conecta directamente los hallazgos con la obligación de gestión de incidentes del artículo 21: no solo dices qué falla, sino qué técnicas de un adversario real pasarían desapercibidas.
El equipo que ejecuta también es parte de la evidencia. Certificaciones ofensivas como la OSCP acreditan capacidad de explotación manual real, no dependencia exclusiva de herramientas automatizadas. Para un auditor, la cualificación del equipo forma parte del argumento de proporcionalidad y diligencia debida.
De la foto puntual al pentesting continuo
El artículo 21 introduce un matiz que cambia el enfoque tradicional: la evaluación de la eficacia debe ser un proceso, no un evento anual. Una arquitectura que cambia cada sprint, despliegues continuos y nuevas API expuestas cada trimestre hacen que un pentest de una vez al año genere una brecha temporal enorme entre lo que se probó y lo que está realmente en producción.
Aquí es donde el modelo de pentesting continuo tiene sentido para el cumplimiento. En CISEC lo abordamos con AISAC, nuestra plataforma de pentesting continuo, que mantiene una evaluación viva de la superficie de exposición y genera evidencia recurrente en lugar de una foto que caduca. Para NIS2 esto se traduce en algo concreto: cuando la autoridad pregunte por la periodicidad de tus evaluaciones, puedes demostrar continuidad en vez de justificar un único informe con doce meses de antigüedad.
Si quieres alinear tus pruebas con las obligaciones de la directiva de forma estructurada, nuestro servicio de pentesting para cumplimiento NIS2 define el alcance, la periodicidad y el formato de evidencia que necesitas para sostener una auditoría.
Cómo enfocar el alcance para que sea defendible
Un error frecuente es limitar el pentest al perímetro clásico. Bajo el enfoque all-hazards de NIS2, el alcance debería cubrir de forma priorizada por riesgo:
- Aplicaciones y API expuestas que soportan servicios esenciales o importantes.
- Infraestructura externa e interna, incluyendo movimiento lateral y escalada.
- Identidad y accesos, especialmente entornos cloud e híbridos.
- Cadena de suministro digital, cuando integras servicios de terceros críticos.
Documentar por qué has elegido ese alcance —vinculándolo a tu análisis de riesgos— es lo que convierte el ejercicio en evidencia de proporcionalidad y no en una prueba arbitraria.
Preguntas frecuentes
¿NIS2 obliga literalmente a hacer pentesting?
No con esa palabra. El artículo 21 exige "evaluar la eficacia" de las medidas de gestión de riesgos y gestionar vulnerabilidades. El pentesting es la técnica que materializa esas obligaciones de forma verificable y documentable, motivo por el que se ha convertido en el estándar de facto para demostrar cumplimiento ante auditores.
¿Con qué frecuencia debo realizar las pruebas para cumplir NIS2?
La directiva no fija un número, sino un principio de proporcionalidad y evaluación continua. Como mínimo, se recomienda un pentest anual completo y pruebas adicionales tras cambios significativos en la arquitectura. Los entornos con despliegue continuo se benefician de un modelo de pentesting continuo que mantiene la evidencia siempre actualizada.
¿Sirve un escaneo de vulnerabilidades en lugar de un pentest?
No como sustituto. El escaneo automatizado es un complemento útil para la ciberhigiene, pero no valida explotabilidad, encadenamiento de ataques ni la respuesta de tu equipo de detección. Para acreditar la eficacia real que espera el artículo 21, necesitas la explotación manual y la contextualización que aporta una prueba de intrusión.