Pentest PCI DSS 11.4 en la práctica: interno, externo, segmentación y retest

Por qué el 11.4 reprueba auditorías que "tenían pentest"

Casi toda empresa que maneja datos de tarjeta sabe que necesita un pentest. La sorpresa llega en la auditoría: el QSA abre el requisito 11.4 de PCI DSS 4.0.1 y no pregunta "¿hicieron un pentest?". Recorre una lista de subrequisitos, cada uno con su propia evidencia: metodología, prueba interna, prueba externa, corrección y repetición, segmentación. Es habitual que un informe cubra cuatro y deje dos abiertos, y la empresa acaba pagando dos veces.

Esta guía complementa el artículo sobre lo que el auditor espera realmente de tu informe. Aquí el foco es el requisito en sí: qué dice cada subrequisito, qué evidencia suele pedir el QSA, cómo definir el alcance y dónde tropiezan las empresas.

El 11.4 de un vistazo

Ítem	Qué exige	Evidencia que suele pedir el QSA
11.4.1	Metodología de pentest definida, documentada e implementada	Documento de metodología, referencia a NIST SP 800-115, PTES u OWASP WSTG, registro de cómo se aplicó
11.4.2	Pentest interno al menos cada 12 meses y tras cambios significativos, por un evaluador calificado e independiente	Informe con fechas, alcance, credenciales usadas y calificación del equipo
11.4.3	Pentest externo con la misma frecuencia y los mismos disparadores	Informe separado del interno, que cubra el perímetro y los sistemas expuestos
11.4.4	Vulnerabilidades explotables corregidas según el riesgo y prueba repetida para confirmarlo	Estado por hallazgo tras el retest, con fecha y evidencia
11.4.5	Controles de segmentación probados al menos cada 12 meses y tras cambios en esos controles	Sección explícita con todos los segmentos probados y el resultado
11.4.6	Solo proveedores de servicios: segmentación probada cada 6 meses y tras cambios	Dos ciclos al año, cada uno con evidencia
11.4.7	Solo proveedores de servicios multiinquilino: apoyar a los clientes en la prueba externa (11.4.3 y 11.4.4)	Evidencia (aunque sea redactada) de que se probó la infraestructura del cliente, o acceso para que el cliente la pruebe

Verifica siempre el texto en la versión vigente publicada por el PCI SSC. La numeración sigue PCI DSS 4.0.1, y el 11.4.7 pasó de buena práctica a obligatorio después del 31 de marzo de 2025.

11.4.1: la metodología tiene que estar escrita

El estándar pide un enfoque aceptado por la industria. En la práctica, el informe cita NIST SP 800-115, PTES u OWASP WSTG y explica cómo se aplicó. Debe cubrir:

• todo el perímetro del CDE y los sistemas críticos;
• pruebas desde dentro y desde fuera de la red;
• validación de los controles de segmentación y reducción de alcance;
• pruebas en la capa de aplicación (como mínimo las vulnerabilidades del requisito 6.2.4) y en la capa de red;
• la revisión de amenazas y vulnerabilidades de los últimos 12 meses;
• un enfoque documentado para tratar el riesgo de lo encontrado;
• conservación de los resultados y de la remediación durante al menos 12 meses.

Guarda la metodología como documento de la empresa, no solo como una página del informe del proveedor. El QSA puede pedir el procedimiento aunque el PDF ya cite el estándar.

Alcance: el CDE y todo lo que se conecta con él

La mayor causa de reprobación no es técnica, es de alcance. El CDE incluye los sistemas que almacenan, procesan o transmiten datos de tarjeta y también los que se conectan a ellos o pueden afectar su seguridad. Normalmente:

• aplicaciones de pago, APIs y paneles de administración;
• bases de datos y colas con PAN;
• servidores de salto, VPN y cuentas de administración que llegan al CDE;
• entornos en la nube (VPC, security groups, cuentas) conectados al CDE;
• integraciones con adquirentes, pasarelas y antifraude.

El alcance del pentest debe coincidir con el diagrama de red y el flujo de datos que entregas al QSA. Si el diagrama muestra cinco subredes y el informe probó dos, el requisito queda abierto.

Ejemplo de alcance: un e-commerce con checkout propio

Imagina una tienda que recibe la tarjeta en su propio checkout. Tiene una red corporativa, una VPC de producción con la aplicación y una VPC aislada con la base que guarda el PAN cifrado, accesible solo mediante un servidor de salto. La empresa afirma que la red corporativa y la VPC de aplicación están "fuera" del CDE por segmentación.

Un alcance defendible para el pentest sería:

1. Externo (11.4.3): el sitio, las APIs, el panel de administración, la VPN, el DNS y cualquier servicio descubierto en el inventario de IP públicas.
2. Interno (11.4.2): desde la red corporativa con un usuario común, y desde dentro de la VPC de aplicación, intentando llegar a la base y al servidor de salto.
3. Segmentación (11.4.5): desde cada segmento declarado "fuera del CDE" (corporativo, aplicación, pruebas y redes de terceros) hacia el CDE, en todos los puertos y caminos.
4. Aplicación: pruebas autenticadas en el checkout y en el panel, con perfiles distintos.

Ten en cuenta que "fuera del CDE por segmentación" solo vale si la prueba de segmentación lo demuestra. Si un servidor de la VPC de aplicación alcanza la base, ese servidor entra en el alcance de PCI.

11.4.2 y 11.4.3: interno y externo son pruebas distintas

La prueba externa parte de internet contra lo que está expuesto: sitios, APIs, VPN, correo, DNS, servicios olvidados. La prueba interna parte desde dentro: la red corporativa, un segmento no confiable o el propio CDE, simulando a un atacante que ya superó el perímetro, un empleado malintencionado o un dispositivo comprometido.

Un escaneo de vulnerabilidades externo (ASV) no sustituye a ninguna. El ASV cubre el requisito 11.3.2; el pentest lo hace una persona, demuestra explotación y encadena fallos. Conviven los dos.

El cambio significativo es el disparador que muchas empresas olvidan. Una nueva aplicación de pago, una migración a la nube, un cambio de adquirente o de topología o de firewall dentro del alcance exigen una nueva prueba, aunque la anual se hiciera en marzo. Define internamente qué es un cambio significativo y registra la decisión con fecha.

11.4.4: el retest no es opcional

Las vulnerabilidades explotables deben corregirse según el riesgo asignado, y repetirse la prueba para confirmarlo. El informe final muestra, por hallazgo, el estado: corregido y validado, pendiente con plazo, o riesgo aceptado con justificación formal. Un PDF sin sección de retest deja el 11.4.4 sin evidencia.

Planifica el calendario con margen: pentest en octubre, corrección en noviembre y retest en diciembre caben en el año. Un pentest en diciembre, no.

11.4.5 y 11.4.6: segmentación, el punto más reprobado

Segmentar la red reduce el alcance de PCI, pero solo si alguien demuestra que la segmentación funciona. La prueba intenta, desde redes fuera del CDE, llegar al CDE por todos los puertos y caminos que los controles deberían bloquear: VLAN, firewalls, ACL, reglas de security group y políticas de red de Kubernetes.

• Prueba cada segmento fuera del CDE hacia el CDE, no una muestra.
• Cubre todos los controles de segmentación, incluidos los de nube y contenedores.
• Repite tras cualquier cambio en esos controles.
• Los proveedores de servicios repiten cada 6 meses (11.4.6), no una vez al año.
• El resultado debe ser explícito: "ningún camino encontrado", con evidencia, o los caminos encontrados.

Dónde tropiezan las empresas

1. Segmentación declarada, nunca probada. El diagrama muestra aislamiento pero nadie intentó cruzarlo. Es el hallazgo de auditoría más común en este requisito.
2. Solo pruebas sin autenticar. El pentest llega al login y se detiene. El riesgo real está detrás, con perfiles comunes y de administración.
3. Retest sin fecha o sin evidencia. El hallazgo "desapareció" del informe nuevo, pero no hay prueba de que se corrigió.
4. Alcance menor que el diagrama. El proveedor prueba las IP que informó el cliente y el entorno de pruebas con datos reales queda fuera.
5. Falta de independencia. Quien opera el entorno también lo prueba.
6. Cambio significativo ignorado. La migración a la nube ocurrió después del pentest anual y no generó una nueva prueba.
7. Herramienta en lugar de persona. Un informe que es la salida de un escáner no demuestra explotación ni metodología.

Quién puede probar: calificación e independencia

El estándar exige que el evaluador sea calificado y organizativamente independiente de quien gestiona el entorno probado. No necesita ser QSA ni ASV. El equipo de infraestructura que opera el CDE no debería ser quien lo prueba. Un equipo interno de seguridad separado puede cumplir si la independencia organizativa es real, y un proveedor externo suele simplificar la conversación con el QSA.

Pide al proveedor los currículos y las certificaciones de los evaluadores e incluye su identificación en el informe. Consulta también las 10 preguntas antes de contratar un pentest.

Cómo elegir proveedor para el 11.4

• Pide un informe de ejemplo anonimizado y comprueba que tenga metodología, evidencia reproducible, sección de segmentación y retest.
• Pregunta si el retest está incluido y cuántas rondas.
• Confirma que el mismo equipo cubre red y aplicación, o que se coordinan.
• Verifica que el proveedor probará segmento por segmento y entregará el resultado de segmentación por separado.
• Acuerda el formato de entrega con tu QSA antes de contratar, para evitar retrabajo.

Lista de verificación antes de contratar

• [ ] Diagrama de red y flujo de datos de tarjeta actualizados
• [ ] Lista de todos los segmentos "fuera del CDE" que dependen de segmentación
• [ ] Inventario de IP, dominios y APIs expuestos
• [ ] Cuentas de prueba para cada perfil (usuario común, administrador, socio)
• [ ] Definición interna de "cambio significativo" e historial del último año
• [ ] Ventanas de prueba acordadas con operaciones y con el NOC
• [ ] Contactos de emergencia durante la ejecución
• [ ] Fecha prevista del retest y responsable de las correcciones

Cómo ordenar el año

• Trimestre 1: alcance y diagrama de red actualizados; contratación.
• Trimestre 2: pentest externo, interno y de segmentación.
• Trimestre 3: correcciones y retest; archivo de evidencias.
• Continuo: disparador de cambio significativo y, para proveedores de servicios, segmentación cada 6 meses.

Para saber qué esperar en precio y plazo, consulta cuánto cuesta un pentest.

Preguntas frecuentes

¿Un escaneo de vulnerabilidades sustituye al pentest del 11.4?

No. El escaneo automatizado cubre otros requisitos, como el 11.3. El 11.4 exige una prueba hecha por una persona calificada, con metodología y prueba de explotación.

¿Con qué frecuencia hay que hacer el pentest PCI?

Como mínimo cada 12 meses, interno y externo, y también tras cualquier cambio significativo en la infraestructura o en las aplicaciones dentro del alcance.

¿Cuándo es obligatoria la prueba de segmentación?

Si usas segmentación para reducir el alcance de PCI, debe probarse al menos cada 12 meses y tras cambios en los controles. Los proveedores de servicios la prueban cada 6 meses.

¿Puede el equipo interno hacer el pentest?

Sí, siempre que esté calificado y sea organizativamente independiente de quien opera el entorno probado. Muchas empresas contratan un proveedor externo para simplificar la evaluación del QSA.

¿El retest debe estar en el informe?

Sí. El requisito pide corregir las vulnerabilidades explotables y repetir la prueba, y el informe debe mostrar el estado de cada hallazgo tras el retest.

¿El pentest debe hacerlo un QSA o un ASV?

No. El estándar exige un evaluador calificado e independiente, no que sea QSA o ASV. El QSA es quien valora la evidencia en la auditoría.

¿Hay que probar los entornos de pruebas?

Si se conectan al CDE o usan datos reales de tarjeta, sí, entran en el alcance. Los entornos aislados y sin datos reales pueden quedar fuera, siempre que se demuestre la segmentación.

Soy proveedor multiinquilino. ¿Qué cambia?

Además del 11.4.6, el 11.4.7 pide que apoyes a los clientes en la prueba externa, con evidencia de que se probó su infraestructura o con acceso para que prueben por su cuenta.

Siguiente paso

Si tu auditoría PCI está en el calendario, el mejor momento para alinear alcance y diagrama es antes de la prueba. Solicita un presupuesto y recibe una propuesta con alcance, segmentación y retest incluidos.