Pentest para PCI DSS 4.0: lo que el auditor espera realmente de tu informe
Contratar un pentest "para cumplir" y suspender la auditoría igualmente es más común de lo que parece. Qué cambia en PCI DSS 4.0 y qué necesita un informe para pasar sin observaciones.
El problema: un pentest que no sobrevive a la auditoría
Cada semana hablamos con equipos de seguridad que contrataron un pentest, recibieron un PDF de 40 páginas y, en la auditoría, el QSA o el auditor interno les dijo que aquello "no cumple". No porque la prueba fuera mala, sino porque el informe no demuestra lo que exige la norma.
Con PCI DSS 4.0 (y con ISO 27001, ENS o las expectativas de los reguladores financieros) el pentest dejó de ser una formalidad anual. Necesita un alcance definido por metodología, evidencia de explotación, y corrección y retest documentados. Sin eso, la empresa paga dos veces.
Qué pide PCI DSS 4.0 (requisito 11.4)
El requisito 11.4 es explícito en puntos que muchos equipos pasan por alto:
- Metodología documentada y aceptada por la industria (NIST SP 800-115, PTES u OWASP WSTG son las referencias habituales). El informe debe indicar cuál se usó, no solo listar hallazgos.
- Cobertura de toda la superficie del CDE: perímetro y componentes críticos, capa de aplicación y de red. Un escaneo externo con Nessus no es un pentest.
- Pruebas de segmentación: si aíslas el entorno de tarjetas con VLANs y firewalls, el pentest debe demostrar que la segmentación funciona. Es uno de los puntos que más se suspenden.
- Periodicidad: al menos anual y tras cualquier cambio significativo en infraestructura o aplicaciones.
- Corrección y retest: las vulnerabilidades explotables deben corregirse y el retest documentarse. Un informe sin sección de retest deja el requisito abierto.
La versión 4.0 también exige que quien ejecuta la prueba tenga independencia organizativa y cualificación demostrable, otra razón para que el informe identifique al equipo y sus certificaciones.
Qué buscan los auditores de ISO 27001 y ENS
Ninguno prescribe una metodología, pero ambos hacen las mismas tres preguntas: con qué frecuencia pruebas, cómo tratas lo que encuentras y cómo lo demuestras. Las empresas aprueban cuando tienen un calendario de pentest por criticidad, informes con PoC y clasificación de riesgo, un plan de tratamiento con plazos y evidencia de retest. El mismo paquete sirve para la due diligence de clientes y los cuestionarios de seguridad de proveedores.
Anatomía de un informe que aprueba
- Resumen ejecutivo de una página: alcance, fechas, metodología, riesgo general, hallazgos por severidad, estado tras el retest.
- Alcance y reglas de engagement: URLs, IPs, credenciales usadas (black/grey/white-box), exclusiones y ventanas.
- Metodología nombrada con las fases ejecutadas.
- Hallazgos con: descripción, CVSS y riesgo de negocio, evidencia reproducible (request/response, capturas, pasos), recomendación de corrección con referencias (OWASP, CWE).
- Pruebas de segmentación (cuando aplique) con resultado explícito.
- Retest con fecha, hallazgos corregidos, pendientes y aceptados.
- Certificado firmado que identifique al equipo y sus certificaciones.
Errores que suspenden
- Salida de escáner con logo de consultora.
- Hallazgos sin evidencia ("posible SQL injection").
- Alcance que no coincide con el diagrama de red entregado al auditor.
- Retest realizado pero no documentado.
- Un pentest de 2023 presentado en 2026 tras dos migraciones a la nube.
Cómo lo prueba Pentest Machine
Nuestros informes siguen la estructura anterior por defecto, con metodología nombrada (OWASP WSTG, PTES, NIST 800-115), PoC para cada hallazgo, pruebas de segmentación cuando el alcance es PCI y retest incluido en el precio. Si tu auditoría está en el calendario, el momento de alinear el alcance es antes de la prueba, no después del informe.