Un evaluador no lee el informe de una prueba de penetración como lo hace un ingeniero. Busca el alcance y si coincide con el entorno auditado, el método, las fechas, la cualificación y la independencia de quienes hicieron las pruebas y la demostración de que los hallazgos se corrigieron y se volvieron a comprobar.
Definimos el alcance de la prueba en función del requisito que debe cumplir y estructuramos el informe para que esas respuestas sean fáciles de encontrar. Las pruebas en sí no se reducen: una prueba diseñada solo para superar una auditoría no protege nada, y los evaluadores la reconocen cada vez más cuando la ven.
01Alcance
Qué ponemos a prueba
PCI DSS v4.0.1: pruebas de penetración externas e internas según el requisito 11.4
PCI DSS: pruebas de segmentación del entorno de datos del titular de la tarjeta
SOC 2: pruebas como evidencia para los criterios de monitorización y de vulnerabilidades
ISO/IEC 27001:2022: controles de gestión de vulnerabilidades técnicas y de pruebas de seguridad
DORA: pruebas de resiliencia operativa digital de los sistemas de TIC
NIS2: evaluación de la eficacia de las medidas de gestión de riesgos
Artículo 32 del RGPD: verificación periódica de las medidas técnicas y organizativas
Cuestionarios de seguridad de clientes y socios que exigen una prueba reciente
02Enfoque
Cómo se realiza el trabajo
01
Correspondencia con los requisitos
Establecemos a qué requisito sirve la prueba, qué exige en cuanto a alcance, frecuencia y método, y qué espera ver su evaluador.
02
Alineación del alcance
El alcance de la prueba se ajusta a los límites del entorno auditado. Las diferencias se documentan y se justifican.
03
Pruebas
La prueba sigue nuestra metodología estándar para el tipo de sistema. No se omite nada porque el marco no lo mencione.
04
Evidencias
El informe indica el método, las fechas, la cualificación y la independencia de quienes hicieron las pruebas. Después del retest, una carta resume el resultado para terceros, sin detalles técnicos.
No. El cumplimiento lo determina su evaluador sobre la base de todos los controles. La prueba aporta las evidencias para los requisitos relativos a las pruebas de seguridad y le indica qué corregir antes de que llegue el evaluador.
¿Exigen SOC 2, ISO/IEC 27001, NIS2 o el RGPD una prueba de penetración?
Ninguno la menciona con esas palabras como control obligatorio. Exigen que se identifiquen las vulnerabilidades y que se pruebe con regularidad la eficacia de las medidas. Una prueba de penetración es la evidencia que los auditores esperan con más frecuencia para esos requisitos. PCI DSS y DORA lo dicen expresamente.
¿Con qué frecuencia hay que repetir la prueba?
PCI DSS exige pruebas de penetración al menos una vez cada doce meses y después de cambios significativos, y pruebas de segmentación al menos una vez cada doce meses (cada seis meses para los proveedores de servicios). DORA exige probar los sistemas críticos al menos una vez al año. Para otros marcos, la frecuencia se deriva de su propia evaluación de riesgos; lo habitual es que se esperen pruebas anuales.
Pruebas de penetración externas e internas de redes y Active Directory: desde un servicio expuesto o un único puesto de trabajo hasta el control del dominio.