Pentesting para ISO 27001 y ENS: qué exige la norma y cómo se acredita

ISO 27001 y el ENS son normas de gestión, no catálogos de pruebas. No dicen "haz un pentesting en marzo": dicen que debes identificar tus riesgos, tratarlos y poder demostrarlo. El problema aparece en la auditoría: cuando declaras que tratas el riesgo tecnológico, el auditor pregunta cómo lo compruebas.

Ahí es donde entra la prueba técnica. Una política de gestión de vulnerabilidades sin ningún análisis real es una intención, no un control. Un informe de pentesting con alcance, fecha, hallazgos puntuados, plan de acción y retest es un control funcionando. Por eso, en la práctica, ambos marcos terminan traduciéndose en pruebas periódicas aunque su texto no las nombre con ese detalle.

La consecuencia práctica es la misma para todas las normas: lo que importa no es solo encontrar vulnerabilidades, es poder demostrar que el proceso existe y se repite. Un pentest aislado de hace tres años, sin plan de acción, no acredita un sistema de gestión. Tres ciclos con hallazgos, corrección y verificación, sí.

En ISO/IEC 27001:2022 los controles relevantes están en los controles tecnológicos del Anexo A:

Ninguno de los dos fija una frecuencia. La fijas tú en tu Declaración de Aplicabilidad y en el análisis de riesgos, y a partir de ese momento se convierte en un compromiso auditable. El criterio habitual y defendible es: al menos una vez al año, y siempre tras cambios significativos en la superficie expuesta.

Hay además tres controles de red que se auditan en la misma visita y que suelen llegar sin evidencia: A.8.20 (seguridad de redes), A.8.21 (seguridad de los servicios de red) y A.8.22 (segregación de redes). Si tu alcance incluye red interna o perímetro, la evidencia que se pide es la auditoría técnica del firewall junto con el registro de revisiones de reglas. Lo desarrollamos en la guía de cumplimiento de firewall perimetral y auditoría de red interna.

Si tu organización está preparando la certificación, revisa también la checklist de seguridad para empresas para no dejar fuera controles que se auditan en la misma visita.

El ENS (Real Decreto 311/2022) es de obligado cumplimiento para el sector público español y sus proveedores, y estructura las exigencias en tres categorías de seguridad: básica, media y alta. La categoría no se elige a gusto: se deriva de la evaluación del sistema según el impacto de un incidente sobre la información y los servicios.

La consecuencia práctica: el alcance y la periodicidad salen de tu categoría y de tu declaración de conformidad, no de un catálogo cerrado. Si tu sistema es de categoría media o alta y tu última prueba técnica tiene más de un año, esa es la primera pregunta que va a hacer tu auditor.

Si tu empresa responde a varios marcos a la vez —lo habitual en proveedores del sector público que también facturan a clientes financieros—, diseña un solo alcance que cubra el marco más exigente y reutiliza el informe para el resto. Encargar una prueba distinta por norma multiplica el coste sin mejorar la seguridad.

Si el marco que te aprieta es el financiero, DORA tiene sus propias reglas: las pruebas del artículo 25 obligan a todas las entidades del ámbito con periodicidad mínima anual, y el TLPT del artículo 26 solo a las designadas como significativas. Lo detallamos en pruebas técnicas de resiliencia operativa para DORA. Y si tu obligación viene de la Directiva NIS2 —entidades esenciales e importantes y sus proveedores—, la prueba técnica es la forma de evidenciar el artículo 21: lo explicamos en pruebas técnicas para NIS2.

• Presentar una salida de escáner como pentesting. El auditor distingue una exportación de Nessus o Burp Scanner de un informe con explotación validada. En categorías medias y altas no cuela, y deja en mal lugar al resto del SGSI.
• No declarar el alcance. Un informe excelente que audita "la web" sin decir qué URLs, qué APIs y qué fechas no acredita nada frente al sistema que certificas.
• Olvidar el plan de acción. Demuestra que detectas, no que corriges. Es la diferencia entre A.8.8 existiendo sobre el papel y funcionando.
• No hacer retest. Sin verificación, el ciclo queda abierto y el hallazgo crítico de hace 14 meses sigue siendo una pregunta abierta en auditoría.
• Comprar el pentest después de la auditoría. Si la prueba se hace una semana antes de la visita y los hallazgos críticos siguen abiertos, el auditor los verá como riesgo no tratado, no como evidencia de control.
• Alcance diseñado para una sola norma. Si respondes a ISO 27001 y a un cuestionario de ciberseguro, un alcance pensado para ambos cuesta casi lo mismo que uno pensado para uno solo.

Puesto en contexto: repetir una auditoría de certificación por falta de evidencias cuesta más que el propio pentesting, y no digamos un incidente. El Instituto Nacional de Ciberseguridad cifra en 75.000€ el coste medio de un incidente de seguridad en una empresa española.

Si quieres una estimación ajustada a tu caso antes de hablar con nadie, usa la calculadora de presupuesto de pentesting y obtén un rango en menos de un minuto.