Auditoría ENS: qué exige la revisión de cada dos años

La auditoría ENS se pasa al menos cada dos años. Y otra vez, fuera de calendario, siempre que el sistema cambie de forma sustancial. Lo fija el artículo 31 del Real Decreto 311/2022.

No todas las categorías acreditan igual. Los sistemas de categoría básica se quedan en una autoevaluación documentada; los de media y alta necesitan una auditoría de certificación firmada por una entidad acreditada. Si todavía no sabes en cuál cae el tuyo, empieza por qué es el ENS y a quién obliga y vuelve luego.

¿Cada cuánto hay que pasar la auditoría ENS?

Cada dos años como mínimo. El artículo 31 habla de una auditoría regular ordinaria «al menos cada dos años», y de una extraordinaria «siempre que se produzcan modificaciones sustanciales en los sistemas de información, que puedan repercutir en las medidas de seguridad requeridas». Las dos cuentan igual. La segunda es la que pilla a todo el mundo.

«Modificación sustancial» no viene tasado en la norma, así que conviene decidir por escrito qué lo es antes de que llegue el auditor. Publicar un servicio nuevo en internet lo es. Mover el correo o el directorio a la nube lo es. Absorber una filial con su propia red, también. Cuando la respuesta es que sí, la prueba técnica anterior ya no cubre lo que hay.

Qué mira el auditor, punto por punto

El Anexo III enumera lo que la auditoría tiene que constatar, y la lista es más corta de lo que parece desde fuera. Leerla entera antes de preparar nada ahorra reuniones: dice qué documentos hay que tener encima de la mesa y, de paso, cuáles no.

• › Que la política de seguridad define los roles y funciones de los responsables del sistema, de la información, de los servicios y de la seguridad.
• › Que existen procedimientos para resolver los conflictos entre esos responsables.
• › Que se ha realizado un análisis de riesgos, con revisión y aprobación anual.
• › Que se cumplen las medidas del Anexo II que apliquen en cada caso.
• › Que hay un sistema de gestión de la seguridad documentado, aprobado por la dirección y apoyado en la Declaración de Aplicabilidad del artículo 28.

Y pide evidencias, no declaraciones. El propio Anexo III las nombra: documentación de los procedimientos, registro de incidentes y productos certificados, entre otras. Un informe técnico con sus hallazgos y sus capturas entra por la primera puerta.

Qué medidas del Anexo II se demuestran con una prueba técnica

Cuatro, y conviene saber cuáles porque son las que justifican el gasto ante dirección. El Anexo II no pide una auditoría técnica en abstracto: la pide dentro de medidas concretas, cada una con su aplicabilidad por categoría.

Aplicaciones web: la medida que casi nadie mira

A mp.s.2 se le pasa por encima porque suena a cosa de desarrollo. Su refuerzo R1 pide auditorías de seguridad sobre las aplicaciones web antes de producción, y aplica ya en categoría básica. En alta sube al R2, que exige metodologías definidas y herramientas automáticas, con los resultados analizados y las vulnerabilidades resueltas por el procedimiento de gestión de cambios.

Vigilancia: el refuerzo que solo aparece en categoría alta

op.mon.3 empieza siendo un recolector automático de eventos y va sumando refuerzos hasta el R6, «Inspecciones de seguridad», exigible solo en categoría alta. Ahí es donde encaja una prueba de intrusión periódica. La norma la dispara también tras un incidente que haya revelado vulnerabilidades nuevas o subestimadas, que es la parte que nadie planifica.

Dónde dice el ENS «pruebas de penetración»

En un solo sitio. La expresión aparece una vez en todo el Real Decreto 311/2022, dentro de op.nub.1.2, entre los requisitos que debe cumplir un servicio en la nube contratado a un tercero. En ninguna parte del texto se lee que la categoría alta obligue a un test de intrusión.

Lo decimos porque circula lo contrario en bastantes webs del sector. Quien cita mal la norma tampoco te va a leer bien el Anexo II. Lo que el ENS sí exige, desde categoría básica, son auditorías de seguridad sobre las aplicaciones web, y esa es la conversación que hay que tener con el auditor.

En la práctica el resultado se parece bastante, y por eso la confusión dura. Para acreditar mp.s.2 y las inspecciones de op.mon.3 hace falta un informe con hallazgos, evidencia de cada uno y constancia de que se corrigieron. Un escaneo automático entrega una lista de avisos y ninguna de las tres cosas.

El pentest se acuerda antes de ejecutarlo

Está escrito en el Anexo III: «Se dispondrá de un programa o plan de auditorías documentado. Las actividades de auditoría que impliquen comprobaciones en los sistemas operativos deberán ser planificadas y acordadas previamente». La ventana de pruebas, los sistemas incluidos y los teléfonos de guardia se pactan por escrito. No es burocracia.

Nosotros lo cerramos en las dos primeras fases. En el kick-off se fijan alcance, calendario, recursos y reglas del juego; después va un plan de auditoría formal con fechas de inicio y fin, fases, pruebas previstas y equipo auditor. Ese plan es además la primera evidencia que el auditor del ENS acepta sin discutir.

Qué debe contener el informe para que valga como evidencia

La Instrucción Técnica de Seguridad de Auditoría fija el contenido mínimo del informe. Merece la pena contrastarla con el informe de pentesting que tengas encima de la mesa, porque los puntos se solapan casi uno a uno.

• › Las áreas, módulos o funciones del sistema cubiertas por la auditoría, y las metodologías empleadas.
• › Los hallazgos, tanto de conformidad como de no conformidad.
• › Las no conformidades justificadas mediante evidencias objetivas.
• › La categoría del sistema y el nivel de seguridad de cada dimensión.
• › La conclusión sobre si procede o no la certificación.

Nuestro informe entrega cada vulnerabilidad con su descripción, su impacto, su criticidad y sus evidencias, y cuando hubo explotación va el proceso completo para que tu equipo lo reproduzca sin llamarnos. El detalle de qué debe llevar está en qué debe incluir un informe de pentesting. A los seis meses volvemos y verificamos lo corregido.

Cinco errores que dejan la renovación en el aire

1. 01El alcance sigue siendo el de hace dos años. Se auditó lo que había, y entre medias se publicó un portal que nadie añadió a la lista.
2. 02Se presenta un escaneo automático como prueba técnica. No explota, no encadena fallos y no descarta el falso positivo.
3. 03Las correcciones se cierran por correo. Sin retest no hay evidencia objetiva de que el hallazgo esté resuelto.
4. 04Los hallazgos vienen sin evidencia. El Anexo III pide justificar cada no conformidad con evidencias objetivas, y una captura recortada no lo es.
5. 05La prueba se deja para el mes anterior a la visita. Si sale una crítica, no da tiempo a corregirla ni a verificarla.

Los cinco tienen el mismo origen: la prueba técnica se trata como un trámite del año de la auditoría y no como parte de la operación.

El calendario de veinticuatro meses

Repartir el trabajo en dos años sale más barato que concentrarlo en el trimestre anterior a la visita. Este es el reparto que proponemos cuando el sistema es de categoría media o alta y ya tiene la certificación.

Qué auditamos para el ENS y desde cuánto

Cuatro frentes cubren lo que el Anexo II pide probar. La superficie externa parte de 450 €, una aplicación web de 1.140 € y la infraestructura interna de 1.520 €. El precio final sale del número de activos y de roles de usuario.

Para la parte de gestión, la auditoría de SGSI parte de 980 € y cubre el alineamiento con el ENS y con ISO 27001, que se solapan más de lo que parece. Una auditoría de superficie externa cabe en pocos días; una de infraestructura interna o de aplicación web lleva de una a tres semanas. Entregamos el informe técnico, la presentación a dirección con el PowerPoint que usamos y el retest a los seis meses.

Si te toca renovar este año, el orden que menos duele es empezar por lo que expones a internet y dejar el papel para el final. Lo primero es lo que un atacante ve hoy. Lo segundo se escribe mucho mejor cuando ya sabes qué encontró la prueba.