Pruebas de penetración en el ENS: qué evidencia espera el auditor en sistemas MEDIA y ALTA

Si gestionas un sistema de categoría MEDIA o ALTA, hay una fecha que pesa más que cualquier ley en tramitación: la de tu próxima auditoría del Esquema Nacional de Seguridad. Este artículo trata de esa fecha. En concreto, de qué papel juegan las pruebas de penetración en ella y por qué el informe en PDF que entrega el proveedor suele dejar huecos que el auditor acaba encontrando.

NIS2 puede esperar. El ENS, no¶

España tenía que haber transpuesto la Directiva NIS2 antes del 17 de octubre de 2024. El Consejo de Ministros aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025, y la ley no ha llegado a publicarse en el BOE. El 8 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por el retraso. Con la disolución de las Cortes el 6 de octubre y las elecciones del 29 de noviembre, el texto queda pendiente de la próxima legislatura.

Habrá ley, y traerá obligaciones nuevas para miles de entidades. Pero mientras tanto, para las administraciones públicas y para las empresas privadas que les prestan servicios, la obligación exigible hoy es el ENS (Real Decreto 311/2022). Tiene medidas concretas, categorías y auditorías con fecha. Es, con diferencia, el marco que antes vas a tener que demostrar.

Qué dice el ENS sobre las pruebas¶

El ENS no tiene una medida titulada "pentest". La exigencia de buscar y corregir vulnerabilidades está repartida por varias medidas del Anexo II, y cambia con la categoría. La categoría sale del impacto sobre las cinco dimensiones (disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad), y cada medida añade refuerzos según sube.

Las medidas que más pesan en las pruebas técnicas son estas:

Medida	Qué pide	MEDIA	ALTA
op.mon.3 R2	Vigilancia que determine la superficie de exposición a vulnerabilidades y deficiencias de configuración	Sí	Sí
op.mon.3 R6	Inspecciones periódicas, y tras incidentes que revelen vulnerabilidades: verificación de configuración, análisis de vulnerabilidades y pruebas de penetración	No	Sí
mp.s.2 R1 / R2	Auditorías de seguridad de las aplicaciones web: de caja negra (R1) o de caja blanca con herramientas automáticas de detección de vulnerabilidades (R2)	R1 o R2	R2
mp.sw.2 R1, op.exp.4 R1	Pruebas antes de pasar a producción, en un entorno aislado o de preproducción	Sí	Sí

Dos detalles merecen atención. El primero: la única mención literal a las pruebas de penetración como obligación de una categoría está en op.mon.3 R6, y solo aplica a ALTA. En MEDIA, la exigencia llega por la vigilancia de la superficie de exposición y por las auditorías de las aplicaciones web, no por la palabra "pentest". El RD 3/2010 sí pedía análisis de vulnerabilidades y pruebas de penetración en MEDIA antes de la entrada en servicio; el RD 311/2022 lo reorganizó, y algunos resúmenes siguen citando el texto antiguo.

El segundo: el Anexo II no fija la frecuencia. op.mon.3 R6 dice "periódicamente", y mp.s.2 deja la frecuencia de las auditorías al procedimiento de auditoría de la entidad. Esa frecuencia la decides tú, y el auditor comprobará que está definida y que se ha cumplido.

Nuestra recomendación es sencilla: lee las medidas aplicables con sus refuerzos para tu categoría, y apóyate en las guías CCN-STIC correspondientes. No te quedes con el resumen de un proveedor, incluido este.

Qué mira el auditor¶

Los sistemas MEDIA y ALTA necesitan una auditoría para certificar su conformidad (artículo 38). La auditoría ordinaria se repite al menos cada dos años, y una modificación sustancial del sistema obliga a una extraordinaria (artículo 31). Cuando el auditor llega a las pruebas técnicas, suele hacer cuatro preguntas:

1. ¿El alcance de las pruebas coincide con el sistema certificado? Es decir, con los activos que figuran en tu inventario y tu declaración de aplicabilidad.
2. ¿Cuándo se hicieron? Y si fue antes o después de los cambios relevantes del sistema.
3. ¿Qué se encontró y qué se hizo con ello? El hallazgo tiene que llevar a una corrección, y la corrección a una comprobación.
4. ¿Puedo comprobar algo de lo que pone aquí? No es habitual que lo pregunte en voz alta, pero es lo que intenta al muestrear.

Dónde falla el informe en PDF¶

No es un problema de calidad del pentester. Es un problema de formato. Estos son los huecos que más se repiten:

• Alcance genérico. "Infraestructura expuesta de la entidad" no se puede cruzar con un inventario de activos. El auditor quiere rangos, dominios y aplicaciones concretos.
• Fechas que no encajan. Un informe de marzo para un sistema que cambió de proveedor de nube en junio describe otro sistema.
• Hallazgos sin cierre. El informe lista lo encontrado, pero la corrección vive en un ticket y la verificación en un correo. Nadie las ha juntado.
• Capturas sin contexto. Una imagen de una respuesta no dice qué petición la produjo, contra qué máquina ni cuándo.

Cada uno de estos huecos se suele tapar con conversaciones durante la auditoría. Funciona, pero consume tiempo de las dos partes, y deja la conformidad apoyada en explicaciones en lugar de en evidencias.

Un registro en lugar de un informe¶

En Pentr, la evidencia de una prueba no es un documento redactado después, sino el registro de la propia ejecución. La primera entrada es el alcance declarado (rangos y dominios dentro y fuera de alcance) junto con la autorización. Después vienen, en orden, cada petición y respuesta, cada comando con su salida y cada captura, etiquetados con la fase y con la medida del ENS con la que se relacionan. Cada entrada está encadenada con la anterior mediante su huella SHA-256, y la cadena se firma al cerrar la ejecución.

Para el auditor, eso cambia dos cosas. El alcance deja de ser una afirmación en la primera página y pasa a ser la primera entrada de la cadena, sellada con todo lo demás. Y la verificación no depende de nosotros. Con el registro exportado y la clave pública, pentr-verify comprueba en su propio equipo, sin cuenta y sin conexión, que no se ha modificado nada.

Cuando se corrige un hallazgo, la nueva comprobación se añade al mismo registro. El hallazgo, la corrección y su verificación quedan juntos, que es justo lo que el auditor intenta reconstruir.

Lo que Pentr no sustituye¶

Un registro firmado de las pruebas es una evidencia más. No hace el resto del trabajo:

• La categorización del sistema y el análisis de riesgos son tuyos.
• La declaración de aplicabilidad y la política de seguridad, también.
• La auditoría la hace una entidad de certificación acreditada. Nosotros le damos material, no la conformidad.
• Lo que no es accesible por red queda fuera: revisión de código, hardware, procesos internos.

Antes de la próxima auditoría¶

Una lista corta, en el orden en que la haríamos:

1. Confirma la categoría de cada sistema y qué medidas y refuerzos te aplican.
2. Define por escrito la frecuencia de las pruebas, ya que el Anexo II no la fija.
3. Alinea el alcance de las pruebas con el inventario de activos, rango a rango.
4. Prueba después de los cambios relevantes, no solo en las semanas previas a la auditoría.
5. Une cada hallazgo con su corrección y con la prueba que la verifica.
6. Guarda la evidencia de forma exportable y verificable durante todo el ciclo de certificación.
7. Pregunta al auditor qué formato prefiere antes de la visita, no durante.

El texto consolidado del RD 311/2022 recoge todas las medidas del Anexo II con sus refuerzos. Si quieres ver cómo encaja un registro sellado con las medidas del ENS, la página del ENS lo explica con más detalle.