Por Hackanary — Ethical Hackers
Si estás certificado en **ISO/IEC 27001:2022** o te estás preparando, seguro te han preguntado: *¿tienen un pentest vigente?* La respuesta corta es que la norma **no menciona la palabra pentest ni fija una frecuencia**, pero sí exige que gestiones las vulnerabilidades técnicas y que pruebes la seguridad de tus sistemas. En la práctica, un **pentest independiente** es la evidencia que los auditores reconocen de inmediato. Aquí te explicamos qué controles respalda y cómo prepararlo. Si ya sabes lo que necesitas, revisa nuestro pentest para ISO 27001.
¿Es obligatorio hacer un pentest para ISO 27001?
No existe una cláusula que diga "realiza un pentest cada año". ISO 27001 es una norma **basada en riesgo**: tú defines en tu análisis de riesgos y en la **Declaración de Aplicabilidad (SoA)** qué controles del Anexo A aplican y cómo demuestras que funcionan. El auditor no te exige una técnica específica; te exige **evidencia de que el control opera**.
El problema es que, para controles técnicos como la gestión de vulnerabilidades, casi no hay evidencia más directa que una prueba de intrusión realizada por un tercero. Por eso, aunque no sea obligatorio por texto, **es lo que los auditores esperan ver** y lo que tus clientes corporativos suelen pedir en sus cuestionarios de proveedores.
Los controles del Anexo A que respalda un pentest
La versión 2022 reorganizó el Anexo A en 93 controles. Estos son los que un pentest bien definido ayuda a demostrar:
- »**A.8.8 Gestión de vulnerabilidades técnicas:** el pentest identifica vulnerabilidades explotables y, con el retest, demuestra que las corregiste. Equivale al antiguo A.12.6.1 de la versión 2013.
- »**A.8.29 Pruebas de seguridad en desarrollo y aceptación:** las pruebas de seguridad de tus aplicaciones antes y después de salir a producción.
- »**A.5.35 Revisión independiente de la seguridad de la información:** un pentest ejecutado por un tercero aporta independencia.
- »**A.8.9 Gestión de la configuración:** malas configuraciones de servidores, servicios y nube que el pentest suele encontrar.
- »**A.8.20 Seguridad de redes y A.8.22 segregación de redes:** si un atacante puede moverse desde un segmento a otro.
- »**A.8.5 Autenticación segura y A.8.2 Derechos de acceso privilegiado:** contraseñas débiles, MFA ausente, cuentas con permisos de más.
- »**A.8.15 Registro y A.8.16 Actividades de monitoreo:** en un Red Team, si tu equipo detectó el ataque.
Un solo pentest con alcance bien definido aporta evidencia a varios de estos controles a la vez. Para que le sirva al auditor, el informe debería **mapear cada hallazgo al control correspondiente** de tu SoA.
Qué mira realmente el auditor
El auditor de certificación toma una muestra y pregunta, en esencia, cuatro cosas sobre tu pentest:
- »**¿Cubre el alcance del SGSI?** Si certificaste un producto SaaS y el pentest fue solo a tu sitio web corporativo, no sirve de evidencia.
- »**¿Es vigente?** Un pentest de hace tres años no demuestra que hoy gestionas las vulnerabilidades.
- »**¿Lo hizo alguien competente e independiente?** Metodología, certificaciones del equipo y que no sea quien administra el sistema.
- »**¿Qué pasó con los hallazgos?** Plan de corrección, responsables, fechas y verificación de cierre o aceptación formal del riesgo.
Esto último es lo que más pesa: el auditor no espera que no tengas hallazgos; espera que los **gestiones**. Un informe con hallazgos corregidos y verificados es mejor evidencia que uno "limpio" sin retest.
Pentest, escaneo de vulnerabilidades y auditoría: no es lo mismo
Un **escáner automático** detecta versiones y configuraciones conocidas, pero no encadena fallos ni prueba lógica de negocio. Un **pentest manual** simula a un atacante real. Si tu auditor pide evidencia de pruebas de penetración, un escaneo automatizado puede quedarse corto. Más detalle en pentest manual vs automático.
Cuándo hacerlo dentro del ciclo de certificación
Una certificación ISO 27001 dura tres años: auditoría inicial, **auditorías de vigilancia anuales** y recertificación. Lo recomendable es hacer el pentest **2 a 3 meses antes** de cada auditoría, para ejecutar, corregir y hacer el retest con tiempo. También conviene repetirlo ante cambios importantes: nueva aplicación, migración a la nube o cambios de arquitectura. Si renuevas cada año, un plan anual con tarifa preferente para clientes recurrentes te evita llegar justo de fechas.
Qué sistemas incluir
Los que están dentro del alcance de tu certificación: aplicaciones web y APIs, infraestructura en la nube, infraestructura expuesta a internet y, si aplica, apps móviles o redes internas. Acotar bien el alcance te ahorra costo y evita que el auditor pregunte por algo que no probaste.
Preguntas frecuentes
¿ISO 27001 exige un pentest anual?
No lo exige de forma explícita. Pero como las auditorías de vigilancia son anuales y los controles A.8.8 y A.8.29 requieren evidencia, lo habitual es contar con un pentest vigente cada año o ante cambios importantes.
¿Sirve un escáner de vulnerabilidades como evidencia?
Sirve como complemento para la gestión continua de vulnerabilidades, pero muchos auditores esperan una prueba de penetración manual realizada por un tercero para controles como A.8.29 y A.5.35.
¿Cuánto antes de la auditoría debo hacer el pentest?
Idealmente 2 a 3 meses antes, para tener tiempo de corregir los hallazgos y hacer el retest.
¿Puede hacer el pentest mi propio equipo de TI?
Puede hacer pruebas internas, pero para demostrar independencia (A.5.35) lo más aceptado es que lo ejecute un tercero que no administra los sistemas evaluados.
¿El pentest reemplaza a mi consultor ISO 27001?
No. El consultor te ayuda a implementar y mantener el SGSI; el pentest entrega la evidencia técnica de que los controles funcionan.
¿Necesitas el pentest para tu próxima auditoría? Escríbenos por WhatsApp con tu alcance y la fecha de tu auditoría y te enviamos una propuesta. Desde **25 UF + IVA**, con informe ejecutivo y técnico y 2 retests incluidos.