¿Necesitas un pentesting para certificarte en ISO 27001?

Por Kike Gandia · Co-Fundador y CEO, OSCP · Última actualización: noviembre de 2026

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 pide probar la seguridad durante el desarrollo y antes de aceptar un sistema, y el A.8.8 pide conocer y tratar las vulnerabilidades técnicas de los sistemas que ya están en producción. El pentesting es, en la práctica, la forma estándar de aportar evidencia de ambos 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.

Qué debe tener el informe para que el auditor lo acepte como evidencia

El auditor no evalúa el pentest en sí, sino si demuestra que el control funciona. Estos son los elementos que revisa:

Elemento del informe	Por qué lo mira el auditor
Alcance y fechas	Tiene que coincidir con los activos del SGSI y de la Declaración de Aplicabilidad
Quién lo ha hecho	La norma pide revisiones independientes de la seguridad (A.5.35): un tercero, o un equipo sin relación con quien opera los sistemas
Metodología declarada	OWASP, OSSTMM o PTES: la norma no impone una, pero tiene que ser reconocible y repetible
Hallazgos con criticidad y evidencias	CVSS, prueba reproducible y recomendación de corrección para cada uno
Resumen ejecutivo	Es lo que se presenta en la auditoría y lo que lee la dirección
Plan de remediación	Responsable y plazo de cada hallazgo, enlazado con tu tratamiento de riesgos
Informe de retest	Demuestra que lo crítico se corrigió y cierra el ciclo

Un informe sin alcance claro o sin retest es la causa más habitual de que el auditor lo acepte solo a medias.

Si además te certificas en el ENS categoría ALTA

Ahí el pentest deja de ser una decisión de riesgo y pasa a ser obligatorio: el refuerzo R6 de la medida de vigilancia [op.mon.3] del Real Decreto 311/2022 exige pruebas de penetración periódicas en los sistemas de categoría ALTA. Un mismo pentest puede servir para las dos auditorías si su alcance cubre a la vez los sistemas del SGSI y los del ENS, y si el informe identifica con claridad qué activos de cada marco se han probado. Planificarlo una sola vez evita pagar dos ejercicios sobre los mismos sistemas.

Pentest externo de pocas IP antes de la auditoría: cuándo basta

Un pentest externo de caja negra sobre unas pocas direcciones IP públicas, con las aplicaciones web que exponen, responde a una pregunta concreta: qué puede hacer un atacante desde Internet sin credenciales. Es suficiente si eso es lo que tu análisis de riesgos marca como crítico. No cubre la red interna, el directorio activo ni lo que hay detrás del login de una aplicación: si alguno de esos activos aparece como crítico en tu análisis de riesgos, el auditor esperará verlo probado, con un pentest interno o con pruebas autenticadas.

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.

¿Tiene que hacer el pentest una empresa externa?

La norma no lo exige literalmente, pero sí pide revisiones independientes de la seguridad (A.5.35). Un equipo interno puede hacerlo si no depende de quien administra los sistemas probados; en la práctica, la mayoría de las organizaciones recurre a un tercero porque su informe no deja dudas de autoevaluación ante el auditor.

¿Con cuánta antelación a la auditoría conviene hacerlo?

Con el margen suficiente para corregir y repetir las pruebas. Un pentest de alcance acotado (unas pocas IP o una aplicación) se ejecuta e informa en 5 a 10 días laborables; después hay que corregir y hacer el retest. Llegar a la auditoría con el informe de retest es mucho mejor evidencia que llegar con hallazgos críticos abiertos.

¿Qué metodología acepta el auditor: OWASP, OSSTMM...?

Cualquier metodología reconocida y documentada. ISO 27001 no prescribe ninguna: OWASP (WSTG y ASVS) para aplicaciones web y APIs, OSSTMM o PTES para infraestructura, y CVSS para clasificar la criticidad son las referencias habituales. Lo que importa es que el informe diga cuál se ha seguido y que las pruebas sean repetibles.