Pentesting para tu certificación ISO 27001

Qué pide la ISO 27001 — y dónde entra el pentesting

La ISO/IEC 27001:2022 nunca nombra al pentest como una actividad obligatoria. Lo que exige es un sistema de gestión de seguridad de la información basado en riesgo: identificas el riesgo, lo tratas y demuestras que tus controles realmente funcionan. El pentesting es la evidencia que más peso tiene en esa demostración, porque muestra un control resistiendo o cayendo frente a un ataque real, y no en papel.

Un certificado ISO 27001 vale tres años. El año uno y el año dos traen auditorías de vigilancia — revisiones por muestreo que confirman que el SGSI sigue operando — y el año tres es una auditoría de recertificación completa que reinicia el ciclo. Un pentest contratado cuatro semanas antes de la auditoría de Etapa 2 documenta un solo momento de una historia de treinta y seis meses. Todo lo que se desplegó en los otros treinta y cinco meses queda sin evidencia detrás.

Anexo A 8.8 — Gestión de vulnerabilidades técnicas: tienes que obtener información sobre las vulnerabilidades de los sistemas que usas, evaluar tu exposición y actuar sobre ella. El pentesting saca a la luz las exposiciones que ningún feed de vulnerabilidades te va a informar nunca, porque viven en tu propia lógica de negocio.

Anexo A 8.25 — Ciclo de vida de desarrollo seguro: la seguridad tiene que diseñarse dentro del desarrollo, no agregarse después. El testing que corre con cada release es la prueba práctica de que ese ciclo de vida es real y no un documento.

Anexo A 8.29 — Pruebas de seguridad en desarrollo y aceptación: una estrategia de pruebas definida, ejecutada durante el desarrollo y antes de la aceptación, en ambientes debidamente separados y por testers competentes. El control no obliga a hacer un pentest — la revisión de código y las pruebas automatizadas también califican. La mayoría de las organizaciones igual lo hace, porque es el método que el auditor reconoce de inmediato.

Trazabilidad: qué estuvo en alcance, quién lo probó y con qué competencia, qué encontró, cómo se calificó cada hallazgo, cuándo se corrigió y la prueba de que la corrección funciona. Y el botón de freno: evidencia de que un release se detuvo de verdad porque una prueba de seguridad falló. El testing continuo genera ese rastro como subproducto; una contratación anual genera un reporte y después once meses de silencio.

Strike no certifica ISO 27001 y no puede hacerlo: el certificado lo emite un organismo de certificación acreditado después de su propia auditoría. Lo que Strike produce es la evidencia técnica que ese organismo pide — pentesting continuo ejecutado por IA y validado por hackers expertos, con 97% de precisión y menos de 3% de falsos positivos, un retest documentado atado a cada hallazgo, y reportes que puedes entregarle al auditor y adjuntar a tu Declaración de Aplicabilidad.

ISO 27001 y pentesting, en preguntas

¿La ISO 27001 exige un pentest?

No con esas palabras. La ISO/IEC 27001:2022 exige una evaluación de riesgos, un plan de tratamiento y evidencia de que tus controles son efectivos. El pentesting es la evidencia que el auditor espera detrás de los controles 8.8, 8.25 y 8.29 del Anexo A, y en la práctica casi toda organización certificada hace uno. La norma deja el método abierto; la auditoría rara vez.

¿Qué evidencia de testing pide realmente un auditor ISO 27001?

Alcance, metodología, la competencia de quienes probaron, los hallazgos con su severidad, las fechas de remediación, la prueba de que cada corrección fue reevaluada, y el vínculo con tu plan de tratamiento de riesgos y tu Declaración de Aplicabilidad. Un reporte sin retest y sin trazabilidad al registro de riesgos es evidencia débil.

¿En qué momento del proceso de certificación conviene testear?

Antes de la auditoría de Etapa 2 como máximo, para que los hallazgos lleguen cerrados y no abiertos. Lo ideal es que el testing sea continuo, porque las auditorías de vigilancia del año uno y del año dos también muestrean la efectividad de los controles, y la recertificación del año tres mira hacia atrás todo el ciclo.

¿El mismo testing sirve para SOC 2 y PCI DSS?

En gran medida sí. El trabajo técnico se superpone bastante entre marcos; lo que cambia es cómo se empaqueta la evidencia y a qué controles se mapea. Strike corre un solo programa de testing continuo y produce reportes que apoyan cada marco, en lugar de tres contrataciones desconectadas.

¿Strike certifica ISO 27001?

No. Strike apoya la ISO 27001 con evidencia de pentesting — solo un organismo de certificación acreditado puede emitir el certificado, después de su propia auditoría. Strike aporta la evidencia técnica, los registros de retest y los reportes listos para auditoría en los que esa auditoría se apoya.

¿Cuánto cuesta y cuánto tarda?

Strike funciona como una suscripción continua dimensionada según tu superficie de ataque, no como un proyecto puntual de precio cerrado, así que el costo depende del alcance y de los activos. El onboarding toma días, y los hallazgos críticos validados suelen llegar en horas o días desde que arranca el testing. Escríbenos para una cotización con alcance.