Si eres responsable de seguridad en una empresa que procesa, almacena o transmite datos de tarjeta, el requisito 11.4 es donde muchos programas de cumplimiento PCI-DSS se atascan. No porque el texto sea ambiguo, sino porque exige demostrar con evidencias que tu entorno de datos de titular (CDE) está realmente aislado y que has buscado activamente vulnerabilidades explotables, no solo escaneado con una herramienta y archivado el PDF. El QSA no acepta un informe genérico: quiere metodología documentada, alcance justificado, corrección verificada y, en el caso de la segmentación, una prueba explícita de que los controles que sacan sistemas fuera de alcance funcionan.
Este artículo desglosa qué pide exactamente el requisito, cómo se interpreta en una auditoría real y qué evidencias tienes que tener preparadas antes de que llegue el assessor.
Qué exige el requisito 11.4 de PCI-DSS
El requisito 11.4 de PCI-DSS (en la versión 4.0) obliga a que las pruebas de penetración externas e internas se definan, documenten y ejecuten con una metodología formal, y que sus resultados se corrijan y reevalúen. Sustituye y amplía lo que en la 3.2.1 era el 11.3. La estructura del requisito se articula en varios subpuntos que conviene conocer por separado:
- 11.4.1 — Existe una metodología de pentesting definida y documentada. Debe basarse en enfoques reconocidos del sector (por ejemplo NIST SP 800-115, OWASP o PTES), cubrir todo el perímetro del CDE y los sistemas críticos, incluir pruebas a nivel de red y de aplicación, y contemplar las amenazas de los últimos 12 meses.
- 11.4.2 — Pentesting interno al menos una vez al año y tras cualquier cambio o actualización significativa de infraestructura o aplicaciones.
- 11.4.3 — Pentesting externo con la misma frecuencia: anual y tras cambios significativos.
- 11.4.4 — Las vulnerabilidades explotables y las debilidades de seguridad encontradas se corrigen conforme a la evaluación de riesgo del requisito 6.3.1, y se repite la prueba para verificar la corrección.
- 11.4.5, 11.4.6 y 11.4.7 — Pruebas específicas de los controles de segmentación, con matices para proveedores de servicios y para entidades multiinquilino.
La palabra clave en todo el requisito es explotable. PCI-DSS distingue el análisis de vulnerabilidades (requisito 11.3, automatizado, trimestral) del pentesting (11.4, manual y dirigido). No puedes cubrir el 11.4 con un escáner: hace falta un profesional que valide, encadene y explote debilidades para demostrar impacto real.
Pentesting interno y externo: alcance y diferencias
El error más común es tratar ambos como el mismo ejercicio con distinto punto de partida. No lo son.
Pentesting externo
Evalúa el perímetro accesible desde Internet: direcciones IP públicas, servicios expuestos, aplicaciones web de comercio, APIs de pago, portales de administración expuestos y cualquier punto de entrada que un atacante remoto usaría. El objetivo es determinar si desde fuera se puede alcanzar el CDE o comprometer un sistema que sirva de pivote hacia él. Aquí es donde cobra sentido revisar la superficie real, no la teórica: subdominios olvidados, entornos de preproducción accesibles y servicios que TI creía apagados.
Pentesting interno
Simula a un atacante que ya tiene un punto de apoyo dentro de la red —un empleado malicioso, un equipo comprometido por phishing o un proveedor con acceso—. Aquí se evalúa el movimiento lateral, la escalada de privilegios, la segregación de VLANs y, sobre todo, si desde un segmento fuera de alcance se puede llegar al CDE. Es la prueba que más incomoda a las organizaciones porque suele revelar que la red plana que se documentó como segmentada no lo está tanto.
En ambos casos, el requisito 11.4.1 exige cubrir tanto la capa de red como la de aplicación. Una API que gestiona tokens de pago necesita pruebas de lógica de negocio, autenticación y autorización, no solo un escaneo de puertos del host que la aloja.
Pruebas de segmentación del CDE: el punto que más suspenden
Si tu estrategia de reducción de alcance se basa en segmentar la red para dejar la mayor parte de sistemas fuera del CDE, el requisito 11.4.6 (o 11.4.5 para el resto de entidades) te obliga a demostrar que esa segmentación funciona. No basta con enseñar reglas de firewall: hay que probar activamente que desde los segmentos fuera de alcance no existe conectividad hacia el CDE.
Esto implica lanzar pruebas de conectividad desde cada red out-of-scope contra el entorno de tarjeta, verificar que los controles bloquean el tráfico y documentar tanto los intentos permitidos como los denegados. Las frecuencias difieren según el perfil:
- Entidades estándar (comercios): pruebas de segmentación al menos cada 12 meses y tras cualquier cambio en los controles de segmentación.
- Proveedores de servicios: al menos cada 6 meses y tras cambios significativos.
El fallo típico es demostrar la segmentación en una dirección pero no cubrir todos los orígenes posibles, o no volver a probar tras un cambio de arquitectura. Un cambio de reglas en un firewall, una nueva conexión VPN de un proveedor o una migración a cloud son eventos que reinician el reloj.
Cómo demostrar el cumplimiento ante el QSA
El QSA no evalúa que tengas un pentest; evalúa la calidad y trazabilidad de ese pentest. Antes de la auditoría deberías poder presentar, sin improvisar:
- La metodología documentada y la justificación del alcance (qué se incluyó, qué se excluyó y por qué).
- Los informes con hallazgos, severidad, evidencia de explotación y recomendaciones.
- La evidencia de retest: la prueba de que las vulnerabilidades explotables se corrigieron y se reverificaron, no solo que se abrió un ticket.
- Las pruebas de segmentación con resultados por cada segmento evaluado.
- Las credenciales y experiencia del equipo que ejecutó las pruebas, con independencia respecto a quien construyó los sistemas.
En CISEC ejecutamos estos ejercicios con equipo certificado OSCP y metodología alineada con OWASP, PTES y MITRE ATT&CK, precisamente para que la trazabilidad de cada hallazgo resista la revisión del assessor. Si necesitas cerrar el 11.4 con evidencias que aguanten la auditoría, nuestro servicio de pentesting para cumplimiento PCI-DSS cubre el ciclo completo: alcance, ejecución interna y externa, pruebas de segmentación y retest documentado.
Un punto que ayuda a no llegar al año con sorpresas: el requisito exige repetir pruebas tras cambios significativos. Depender de un único ejercicio anual convierte el cumplimiento en una foto que envejece mal. Un enfoque de pentesting continuo —como el que soporta nuestra plataforma ORDAL— permite revalidar la superficie externa y los controles críticos de forma recurrente, de modo que el pentest formal anual confirma un estado ya conocido en lugar de destapar problemas de última hora.
Preguntas frecuentes sobre el requisito 11.4
¿Un escaneo de vulnerabilidades trimestral cumple el requisito 11.4?
No. Los escaneos trimestrales corresponden al requisito 11.3. El 11.4 exige pentesting manual que explote las vulnerabilidades para demostrar impacto real. Son controles complementarios y ambos son obligatorios; uno no sustituye al otro.
¿Con qué frecuencia hay que hacer las pruebas de segmentación del CDE?
Como mínimo cada 12 meses para la mayoría de entidades y cada 6 meses para proveedores de servicios, además de tras cualquier cambio significativo en los controles de segmentación. Cada modificación de firewall o de arquitectura de red que afecte al aislamiento del CDE obliga a reevaluar.
¿Puede el pentest lo hacer el mismo equipo que administra los sistemas?
PCI-DSS exige independencia organizativa entre quien ejecuta las pruebas y quien gestiona los sistemas evaluados. Puede ser un equipo interno cualificado y separado, pero en la práctica la mayoría de organizaciones recurren a un proveedor externo para garantizar esa independencia y aportar la experiencia técnica que el QSA espera ver.