Pentesting ISO 27001: qué acepta el auditor como evidencia
Cuando alguien pregunta si un pentesting ISO 27001 es obligatorio, la respuesta es no: la norma no lo nombra en ninguna cláusula. Lo que sí exige es demostrar que gestionas las vulnerabilidades técnicas.
Y ahí empieza el problema real, que no es normativo sino de prueba. El auditor no discute tu política. Te pide el registro que demuestra que la política se aplicó, y esa es una conversación distinta. Si vienes de cero, la ruta completa está en certificarse en ISO 27001; aquí hablamos de la evidencia.
¿Es obligatorio el pentesting ISO 27001?
No, y conviene decirlo claro porque medio sector vende lo contrario. La ISO/IEC 27001:2022 es una norma de gestión basada en riesgos: fija qué hay que conseguir y deja a cada organización decidir cómo. Ninguno de sus requisitos ni de los 93 controles del Anexo A nombra las pruebas de intrusión.
Donde sí aparecen es un escalón más abajo. La ISO/IEC 27002:2022, que es la guía de implantación publicada por el mismo comité, recomienda pruebas de penetración en la orientación de dos controles: A.8.8, gestión de vulnerabilidades técnicas, y A.8.29, pruebas de seguridad en desarrollo y aceptación. La guía no es certificable. El auditor la usa igual como vara de medir.
La consecuencia práctica es que puedes certificarte sin un pentest si justificas otra forma de detectar y tratar vulnerabilidades. Casi nadie lo consigue. Un escáner programado responde a la mitad de A.8.8 y a nada de A.8.29.
Qué controles del Anexo A responde un informe técnico
Cinco, y no todos con el mismo peso. Mirarlo control a control ayuda a decidir el alcance de la prueba antes de pedir presupuesto, en vez de encargar «un pentest» y ver luego qué tapa.
| Control | Qué pide | Qué aporta el informe |
|---|---|---|
| `A.8.8` Gestión de vulnerabilidades técnicas | Obtener información sobre las vulnerabilidades, evaluar la exposición y tomar medidas | El hallazgo, su criticidad razonada y la constancia de que se corrigió |
| `A.8.29` Pruebas de seguridad en desarrollo y aceptación | Definir y ejecutar pruebas de seguridad durante el ciclo de desarrollo | La prueba sobre la aplicación antes de que entre en producción |
| `A.8.25` Ciclo de vida de desarrollo seguro | Reglas de desarrollo seguro aplicadas de verdad | Los fallos de diseño que el código no enseña y una revisión encuentra |
| `A.8.16` Actividades de supervisión | Vigilar redes y sistemas para detectar comportamiento anómalo | Si tu SIEM vio la intrusión simulada, y en cuánto tiempo |
| `A.5.35` Revisión independiente de la seguridad | Revisar el enfoque de seguridad a intervalos planificados o ante cambios | La revisión hecha por alguien ajeno a quien implantó el control |
A.8.16 es el que más se desaprovecha. La prueba genera tráfico real de ataque, así que el mismo encargo sirve para comprobar si la monitorización se entera. Basta con pedir al auditado que anote qué alertas saltaron y cuándo, y contrastarlo después con nuestro registro de actividad.
La diferencia entre tener el control y poder demostrarlo
Un control implantado sin registro, para el auditor, no existe. Suena duro y es literal: la auditoría de certificación se basa en evidencia objetiva, y una afirmación del responsable no lo es. Aquí es donde se pierden las certificaciones que llegaban bien preparadas.
El caso típico de A.8.8: la empresa tiene un escáner corriendo cada semana sobre su red interna y nadie duda de que las vulnerabilidades se detectan. El auditor pregunta por la evaluación de exposición y por el tratamiento. No hay acta que diga por qué esas doce críticas se aceptaron como riesgo, ni quién lo aprobó. La detección estaba resuelta y las otras dos partes del control, no.
Un informe de pentesting con retest cubre las tres de una vez, porque las lleva escritas por construcción. Lo que debe contener está en qué debe incluir un informe de pentesting.
El ciclo de tres años, visita a visita
El certificado dura tres años y en ese tiempo el auditor viene cuatro veces, no una. La primera vigilancia llega como muy tarde a los doce meses de la decisión de certificación, según la norma de acreditación que aplica a las certificadoras. Saberlo cambia cuándo se encarga la prueba técnica.
| Visita | Qué mira | Qué prueba técnica llega a tiempo |
|---|---|---|
| Etapa 1 | Documentación: alcance, análisis de riesgos y Declaración de Aplicabilidad | Ninguna todavía, pero el alcance del pentest se decide aquí |
| Etapa 2 | Implantación real, con registros de operación | El informe completo y el plan de tratamiento en marcha |
| Seguimiento, año 1 | Muestra de controles, incidencias y acciones correctivas | El retest de lo detectado en la etapa 2 |
| Seguimiento, año 2 | Otra muestra de controles y la evolución del sistema | Prueba nueva si cambió la infraestructura o el alcance |
| Recertificación, año 3 | El sistema entero y si de verdad consigue lo que pretende | Prueba completa, con la serie de los tres años detrás |
Cuándo se encarga para que llegue a tiempo
Con cuatro meses de margen sobre la visita. Dos semanas de ejecución en una infraestructura interna, unos días para el informe, y después lo que de verdad tarda: corregir. Si la prueba se hace el mes anterior, lo que enseñas al auditor es una lista de fallos abiertos, que resulta peor que no enseñar nada.
Nuestro retest cae a los seis meses de la entrega, así que encaja solo con el seguimiento anual. La prueba de la etapa 2 se verifica justo cuando toca la primera vigilancia.
Qué convierte un informe en evidencia de auditoría
No todo informe vale. Estos son los seis elementos por los que preguntamos cuando alguien nos enseña el que le entregó otro proveedor.
- › El alcance por escrito, con los sistemas y las direcciones incluidas, y lo que quedó fuera.
- › La metodología nombrada, no aludida. OWASP WSTG para una aplicación web dice bastante más que «metodología propia».
- › Cada hallazgo con su evidencia y los pasos para reproducirlo sin llamar a quien lo encontró.
- › La criticidad razonada, con el impacto sobre este sistema y no una etiqueta genérica.
- › El plan de tratamiento con responsable y fecha, que es lo que enlaza con el proceso de mejora del sistema de gestión.
- › El retest firmado, que es la única prueba de que el hallazgo está cerrado.
Los seis se dejan ver en un vistazo. Un informe que sale de una herramienta y se entrega tal cual falla en el tercero y en el sexto, que son justo los dos que el auditor mira.
Los cuatro hallazgos que se repiten en la vigilancia anual
- 01El alcance del pentest no coincide con el alcance del sistema certificado. Sobra media empresa o falta un servicio publicado después.
- 02Vulnerabilidades aceptadas como riesgo sin que nadie con autoridad lo haya firmado.
- 03El informe es del año pasado y entre medias hubo una migración. La evidencia envejeció antes que el certificado.
- 04El pentest lo hizo el mismo proveedor que administra la infraestructura, y el auditor pregunta por
A.5.35.
El cuarto sorprende a mucha gente. Vamos con él.
Quién puede firmar la prueba
A.5.35 pide que el enfoque de la organización para gestionar la seguridad se revise de forma independiente, a intervalos planificados o cuando haya cambios importantes. Quien configuró el cortafuegos no puede dictaminar sobre el cortafuegos: no es mala fe, es que no va a encontrar lo que no se le ocurrió.
Eso no obliga a cambiar de proveedor de sistemas. Obliga a que la revisión venga de fuera de esa cadena. Nosotros auditamos y no administramos, y esa separación es la que hace que el informe valga como evidencia de este control.
Qué auditamos para la ISO 27001 y desde cuánto
Depende de qué controles necesites cubrir. La auditoría de SGSI parte de 980 € y revisa el sistema de gestión frente a la norma, incluida la Declaración de Aplicabilidad. Es la que dice qué falta antes de que lo diga el auditor.
Para la parte técnica, 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. Una externa cabe en pocos días; una interna o una web llevan de una a tres semanas.
En todas entregamos lo mismo: informe técnico con evidencia de cada hallazgo, presentación a dirección con el PowerPoint que usamos y retest a los seis meses. Quien además tiene que responder ante el sector público encontrará que el trabajo se aprovecha casi entero para el ENS.
Si te certificas este año, encarga la prueba antes de la etapa 2 y no después. El informe que enseñas en esa visita marca el tono de las tres siguientes.
Fuentes
Cómo lo abordamos
Los servicios con los que resolvemos lo que cuenta este artículo:
- ›Auditoría SGSI (ISO 27001 / ENS) · Auditoría de tu SGSI frente a ISO 27001 y ENS: qué controles funcionan de verdad, cuáles están solo sobre el papel y qué falta para certificarte.
- ›Auditoría de infraestructura interna · Pentesting desde dentro de tu red, como quien ya ha entrado: movimiento lateral, escalada de privilegios y hasta dónde se llega en el dominio.
- ›Auditoría de superficie externa · Auditoría de todo lo que expones a Internet: subdominios que nadie recuerda, servicios abiertos y credenciales filtradas en brechas ajenas.
- ›Pentesting de aplicaciones web · Pentesting manual de tu aplicación web contra OWASP WSTG: la lógica de negocio rota y los accesos que no deberían existir.