¿Necesitas un pentesting para certificarte en ISO 27001?
Por el equipo de QuantumSec
La respuesta corta es: la norma no lo exige literalmente, pero en la práctica es muy difícil pasar una auditoría de certificación sin él si tu organización tiene sistemas expuestos a internet o datos sensibles. La razón está en cómo está construida ISO 27001: no exige herramientas concretas, exige que demuestres que gestionas el riesgo de forma efectiva —y un pentesting es, para muchos riesgos técnicos, la única forma creíble de demostrarlo.
Qué dice literalmente la norma (y qué no dice)
ISO/IEC 27001:2022 no menciona la palabra "pentesting" en ningún control del Anexo A. Lo que sí exige es un control de gestión de vulnerabilidades técnicas (A.8.8) y controles de seguridad en el desarrollo (A.8.25 a A.8.29, que incluyen explícitamente "pruebas de seguridad"). El control A.8.29 habla de probar la seguridad durante el desarrollo y las operaciones —el pentesting es, en la práctica, la forma estándar de cumplir ese control cuando hay aplicaciones o infraestructura crítica en el alcance del SGSI.
Por qué el auditor lo pide aunque no esté nombrado explícitamente
El enfoque de ISO 27001 es basado en riesgo: si tu análisis de riesgos identifica que una aplicación web expuesta es un activo crítico, y el control elegido para mitigarlo es "pruebas de seguridad periódicas", el auditor va a pedir evidencia de que esas pruebas se han hecho y de qué encontraron. Un escaneo automático de vulnerabilidades puede no ser suficiente evidencia si el riesgo identificado es alto: ahí es donde un pentesting manual se convierte, en la práctica, en la evidencia que el auditor espera ver.
Cuándo es más probable que te lo exijan
Aplicaciones web o APIs expuestas a internet con datos de clientes. Infraestructura crítica dentro del alcance del SGSI (red interna, Active Directory). Sector regulado o con exigencias de terceros (fintech, salud, e-commerce). Alcance del SGSI que incluye desarrollo de software propio. En estos casos, la ausencia de cualquier evidencia de pentesting o análisis técnico de seguridad es uno de los hallazgos más habituales en auditorías de certificación.
Con qué frecuencia y qué alcance
No hay una cifra fija en la norma, pero la práctica habitual es un pentesting anual de los activos críticos identificados en el análisis de riesgos, más pruebas adicionales tras cambios significativos (nueva versión de una aplicación, cambio de infraestructura). El alcance debe ser coherente con lo que dice tu propio análisis de riesgos: si identificaste la aplicación web como activo crítico, el pentesting debe cubrirla explícitamente, no un análisis genérico de perímetro.
FAQ
¿Un análisis de vulnerabilidades automático es suficiente?
Para riesgos de severidad baja o media, puede serlo. Para activos que tu propio análisis de riesgos clasifica como críticos, un auditor experimentado espera evidencia de pruebas manuales que confirmen explotabilidad real, no solo un listado de CVEs sin verificar.
¿El informe del pentesting hay que entregarlo al auditor completo?
Normalmente se presenta como evidencia el informe ejecutivo y la confirmación de que las vulnerabilidades críticas fueron remediadas (o el plan de remediación en curso), no necesariamente el detalle técnico completo con PoC, que puede tratarse como información sensible.
¿Qué pasa si el pentesting encuentra vulnerabilidades críticas justo antes de la auditoría?
Es mejor que las encuentre tu pentesting que el auditor por otra vía. Lo que se evalúa no es "cero vulnerabilidades" sino que existe un proceso de gestión de riesgos que las detecta y las remedia con un plan y plazo razonables.