Pentesting para la certificación ISO 27001
La ISO/IEC 27001:2022 plantea evaluar y tratar el riesgo de seguridad de la información, y el pentesting es la evidencia técnica que el auditor espera detrás de controles del Anexo A como 8.8, 8.25 y 8.29. Conviene precisar algo que casi ninguna página aclara: el Anexo A es un conjunto de referencia, no una lista de requisitos. Strike ejecuta pentesting continuo con IA y validación humana experta antes de la entrega al cliente, y entrega reportes que apoyan programas de auditoría y cumplimiento. Strike apoya el proceso; el certificado lo emite el organismo de certificación. Fuente: ISO, fecha de acceso: 29 de julio de 2026.
Pensado para el ciclo de certificación ISO 27001 de tres años
Equipos que van hacia una auditoría de Etapa 2 y necesitan llegar con los hallazgos cerrados y reevaluados, no con items abiertos para explicar.
Organizaciones ya certificadas, cuyas auditorías de vigilancia del año uno y del año dos siguen muestreando si los controles todavía funcionan.
Responsables de seguridad que necesitan evidencia de testing que mapee limpio al Anexo A y se adjunte al plan de tratamiento de riesgos y a la Declaración de Aplicabilidad.
Pentesting ISO 27001: qué establece la norma y dónde entra el testing
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: se identifica el riesgo, se lo trata y se demuestra que los 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. Fuente: ISO/IEC 27001:2022 (fecha de acceso: 29 de julio de 2026).
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: hay que obtener información sobre las vulnerabilidades de los sistemas en uso, evaluar la exposición y actuar sobre ella. El pentesting saca a la luz las exposiciones que ningún feed de vulnerabilidades va a informar nunca, porque viven en la lógica de negocio propia. Fuente: ISO/IEC 27001:2022 (fecha de acceso: 29 de julio de 2026).
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 con validación humana experta antes de la entrega al cliente, retesting cuya disponibilidad depende del alcance suscrito, y reportes que se pueden entregar al auditor y adjuntar a la Declaración de Aplicabilidad.
Métricas reportadas por Strike en esta página: 97% de precisión / 3% de falsos positivos, y más de 6.000 vulnerabilidades críticas reportadas. Son cifras que Strike reporta sobre su propia plataforma, no benchmarks de terceros; el alcance, las definiciones y las fechas de medición de cada una están en cómo medimos los resultados.
Pentesting ISO 27001 y el Anexo A: un conjunto de referencia, no una lista de requisitos
Esta es la distinción que casi todas las páginas de cumplimiento aplanan, y es la que define cómo se le responde al auditor. En la ISO/IEC 27001:2022, las cláusulas numeradas 4 a 10 son la parte obligatoria de la norma y no pueden excluirse de un SGSI conforme. El Anexo A es otra cosa: según el texto de la norma, es un conjunto de referencia de controles de seguridad de la información, del cual cada organización selecciona sobre la base de su propia evaluación de riesgos. Cuando la organización determina que un control no es aplicable, esa determinación y su justificación quedan registradas en la Declaración de Aplicabilidad.
La consecuencia, dicha sin vueltas: la ISO 27001 no obliga a hacer pentesting. Ninguna cláusula y ningún control del Anexo A nombra al pentest como una actividad que la organización tenga que ejecutar. Quien afirme que la norma obliga a contratar uno está describiendo la práctica habitual de auditoría, no el texto de la norma.
¿Por qué, entonces, el auditor pide un pentest? Porque está muestreando si los controles que la organización seleccionó operan de forma efectiva, y la evidencia de testing es una de las formas de prueba que un auditor reconoce de inmediato. El pedido es real. Su base es la propia Declaración de Aplicabilidad y el plan de tratamiento de riesgos, no una línea del Anexo A que obligue a nadie.
Qué cambia esto al momento de responder: si se seleccionaron los controles 8.8, 8.25 u 8.29 del Anexo A, también se eligieron los métodos que los demuestran. El pentesting es un método; la revisión de código y las pruebas automatizadas son otros, e ISO no los jerarquiza. Si un control fue excluido, lo que el auditor lee en lugar de un reporte de testing es la justificación en la Declaración de Aplicabilidad. En cualquier caso, la evidencia tiene que poder trazarse hasta el riesgo que trata.
Dónde deja esto a un pentest ISO 27001 en la práctica: la mayoría de las organizaciones certificadas hace uno, porque es la forma más rápida de mostrar un control resistiendo o cayendo en condiciones de ataque real, y no en papel. Es una decisión sobre calidad de la evidencia, no sobre obligación, y conviene tomarla de manera deliberada y no porque un proveedor haya dicho que la norma forzó la mano.
Fuentes: ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements (ISO), fecha de acceso: 29 de julio de 2026, incluida la enmienda ISO/IEC 27001:2022/Amd 1:2024. La numeración de controles del Anexo A sigue la revisión de 2022. El texto completo de la norma es de acceso pago en ISO; la página de catálogo citada aquí es de acceso público. Strike apoya programas de auditoría y cumplimiento; no emite certificados ISO, y la certificación la otorga un organismo de certificación acreditado después de su propia auditoría.
Pentesting ISO 27001, en preguntas
¿Un pentest ISO 27001 es lo mismo que el pentesting para ISO 27001?
Sí. Pentest ISO 27001 es simplemente la forma corta de nombrar lo mismo, y ninguna de las dos expresiones aparece en la norma. La ISO/IEC 27001:2022 establece que las cláusulas 4 a 10 son la parte obligatoria, y, según el texto de la norma, el Anexo A es un conjunto de referencia de controles del cual la organización selecciona sobre la base de su propia evaluación de riesgos, registrando cualquier exclusión y su justificación en la Declaración de Aplicabilidad. Así que la expresión describe una contratación de testing orientada a apoyar un programa ISO 27001, no un control que se pueda señalar en el texto. Fuente: ISO/IEC 27001:2022 (ISO), fecha de acceso: 29 de julio de 2026.
¿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 el plan de tratamiento de riesgos y la 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.
¿Qué papel cumple Strike frente a ISO 27001?
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 que apoyan programas de auditoría y cumplimiento 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 la superficie de ataque, no como un proyecto puntual de precio cerrado, así que el costo depende del alcance y de los activos. El setup toma menos de 5 minutos una vez que están listos los datos del objetivo y los accesos, para alcances soportados. Aparte, una vez que el testing está corriendo, los hallazgos llegan en 1–2 horas. Solicite una cotización con alcance.
Algo así. La ISO/IEC 27001:2022 establece que las cláusulas 4 a 10 son la parte obligatoria de la norma, y, según el texto de la norma, el Anexo A es un conjunto de referencia de controles del cual la organización selecciona sobre la base de su propia evaluación de riesgos, registrando cualquier exclusión y su justificación en la Declaración de Aplicabilidad. Lo que la ISO 27001 pide es una evaluación de riesgos, un plan de tratamiento y evidencia de que los controles seleccionados son efectivos. El pentesting es la evidencia que el auditor reconoce más rápido detrás de los controles 8.8, 8.25 y 8.29 del Anexo A, y la mayoría de las organizaciones certificadas hace uno. La norma deja el método abierto; la auditoría rara vez. Fuente: ISO/IEC 27001:2022 (fecha de acceso: 29 de julio de 2026).
Con la confianza de los equipos de seguridad que lideran la industria.
Experiencia humana.
Poder de la IA.
Seguridad superior.
Ya sea que su empresa esté creciendo rápido, cerrando acuerdos con grandes compañías o simplemente cansada de reportes sin valor, la ayudamos a construir una estrategia de seguridad que avance más rápido que las amenazas.
