Resumen: PCI DSS 4.0 amplió significativamente los requisitos de pentesting en comparación con la versión 3.2.1. Los requisitos con fecha futura se volvieron obligatorios el 31 de marzo de 2025, lo que significa que toda organización que procese, almacene o transmita datos de tarjetahabientes debe cumplir ahora con las reglas más estrictas. Los cambios clave incluyen metodología documentada obligatoria, requisitos explícitos de pruebas internas y externas, verificación de segmentación ampliada, pruebas de capa de aplicación alineadas con el OWASP Top 10, y la nueva opción de validación de enfoque personalizado que requiere pruebas aún más rigurosas. Los proveedores de servicios enfrentan obligaciones adicionales que incluyen pruebas de segmentación semestrales y verificación de aislamiento multi-inquilino. Esta guía mapea cada requisito, explica qué cambió y proporciona una lista de verificación práctica de preparación para las evaluaciones de 2026.
PCI DSS 4.0 representa la revisión más significativa del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago desde su creación. Publicado en marzo de 2022 con un período de transición que finalizó el 31 de marzo de 2025, el estándar actualizado introdujo cambios sustanciales en los requisitos de pentesting que muchas organizaciones aún están trabajando para comprender e implementar. Con las evaluaciones de 2026 acercándose, la ventana de preparación se está reduciendo.
Si procesas, almacenas o transmites datos de tarjetahabientes -- o si proporcionas servicios a organizaciones que lo hacen -- comprender los requisitos de pentesting en PCI DSS 4.0 no es opcional. A diferencia de algunos marcos de cumplimiento donde el pentesting está implícito o recomendado, PCI DSS lo exige explícitamente con requisitos específicos de alcance, metodología y frecuencia que tu Evaluador de Seguridad Calificado (QSA) evaluará en detalle.
Qué Cambió de PCI DSS 3.2.1 a 4.0
PCI DSS 3.2.1 abordaba el pentesting principalmente en el Requisito 11.3, con un lenguaje relativamente amplio que daba a las organizaciones una latitud significativa en cómo realizaban y documentaban sus pruebas. La versión 4.0 renumeró, expandió y endureció estos requisitos considerablemente. Estos son los cambios más significativos.
Requisitos Renumerados
PCI DSS 4.0 reorganizó la estructura de requisitos. El pentesting pasó del Requisito 11.3 al Requisito 11.4, con sub-requisitos del 11.4.1 al 11.4.7. Esto no es solo cosmético -- la renumeración refleja contenido ampliado y sub-requisitos adicionales que no existían en la versión 3.2.1.
Metodología Documentada Obligatoria
El Requisito 11.4.1 ahora exige explícitamente que se defina, documente e implemente una metodología de pentesting. La metodología debe:
- Basarse en un enfoque aceptado por la industria (PTES, OSSTMM, Guía de Pruebas OWASP o NIST SP 800-115)
- Cubrir todo el perímetro del entorno de datos de tarjetahabientes (CDE) y sistemas críticos
- Incluir pruebas tanto internas como externas
- Incluir pruebas desde dentro y fuera de la red
- Incluir pruebas de capa de aplicación que aborden, como mínimo, las vulnerabilidades listadas en el Requisito 6.2.4 (que se alinea estrechamente con el OWASP Top 10)
- Incluir pruebas de penetración de capa de red que cubran todas las funciones de red y sistemas operativos
Bajo la versión 3.2.1, las organizaciones podían conformarse con una metodología que referenciara estándares de la industria en términos generales. Bajo la versión 4.0, el QSA evaluará si tu metodología documentada aborda específicamente cada uno de estos elementos y si tus pruebas reales siguieron la metodología documentada. Una referencia vaga a "mejores prácticas de la industria" no será suficiente.
Alcance y Criticidad Ampliados
El Requisito 11.4.2 especifica que las pruebas de penetración internas deben realizarse en todos los sistemas dentro del alcance. La definición de "dentro del alcance" bajo PCI DSS 4.0 incluye cualquier sistema que almacene, procese o transmita datos de tarjetahabientes, cualquier sistema que esté en el mismo segmento de red que los sistemas CDE, y cualquier sistema que pueda afectar la seguridad del CDE. Esto es más amplio de lo que muchas organizaciones creen, y subestimar el alcance del pentesting es uno de los hallazgos más comunes que reportan los QSA.
El Requisito 11.4.3 cubre las pruebas de penetración externas, requiriendo pruebas del perímetro externamente accesible del CDE y cualquier sistema crítico accesible desde fuera de la red de la organización.
Pruebas de Segmentación: Ahora Más Rigurosas
El Requisito 11.4.5 aborda la verificación de segmentación de red -- pruebas que confirman que los controles de segmentación de red aíslan efectivamente el CDE de los sistemas fuera del alcance. Bajo la versión 3.2.1, las pruebas de segmentación eran requeridas pero la metodología estaba definida de manera laxa. Bajo la versión 4.0:
- Las pruebas de segmentación deben confirmar que los métodos de segmentación son operativos y efectivos
- Las pruebas deben verificar que los sistemas fuera del alcance no pueden comunicarse con los sistemas en el CDE
- Para proveedores de servicios, las pruebas de segmentación deben realizarse cada seis meses (no solo anualmente)
- Las pruebas deben ocurrir después de cualquier cambio en los controles o métodos de segmentación
El requisito semestral para proveedores de servicios es particularmente significativo. Las organizaciones que realizaban verificación de segmentación anual bajo la versión 3.2.1 ahora necesitan duplicar su frecuencia de pruebas, lo que tiene implicaciones significativas de costo y operativas.
Requisitos con Fecha Futura (Ahora Obligatorios)
Varios requisitos de pentesting fueron designados como "con fecha futura" cuando se publicó PCI DSS 4.0, lo que significa que eran mejores prácticas hasta el 31 de marzo de 2025, después de lo cual se volvieron obligatorios. Ahora son completamente exigibles:
- 11.4.1: El requisito de metodología documentada descrito anteriormente.
- 11.4.6: Para proveedores de servicios, el pentesting debe confirmar específicamente que el enfoque personalizado resulta en los controles de seguridad esperados. Este es un territorio nuevo -- el enfoque personalizado es un concepto de PCI DSS 4.0 que permite a las organizaciones cumplir objetivos de seguridad a través de controles alternativos, pero esos controles alternativos deben ser validados mediante pruebas.
- 11.4.7: Los proveedores de servicios multi-inquilino deben permitir el pentesting por parte de sus clientes. Esto significa que si proporcionas infraestructura compartida a comerciantes, debes tener procesos y políticas que permitan a tus inquilinos realizar (o que se realicen en su nombre) pruebas de penetración de sus entornos dentro de tu infraestructura.
La Distinción entre Escaneo y Pentesting: Crítica para el Cumplimiento
PCI DSS 4.0 es excepcionalmente claro sobre la diferencia entre escaneo de vulnerabilidades y pentesting, y confundir los dos es una de las formas más rápidas de reprobar una evaluación.
Los escaneos de vulnerabilidades (Requisitos 11.3.1 y 11.3.2) son evaluaciones automatizadas que identifican vulnerabilidades conocidas, configuraciones incorrectas y parches faltantes en los sistemas. PCI DSS requiere:
- Escaneos de vulnerabilidades internos al menos trimestralmente
- Escaneos de vulnerabilidades externos al menos trimestralmente por un Proveedor de Escaneo Aprobado (ASV)
- Escaneos después de cualquier cambio significativo
Las pruebas de penetración (Requisito 11.4) van más allá del escaneo para incluir explotación activa. El estándar establece explícitamente que el pentesting involucra "intentar explotar vulnerabilidades" para "determinar si el acceso no autorizado u otra actividad maliciosa es posible." Un pentesting que solo identifica vulnerabilidades sin intentar la explotación no satisface el Requisito 11.4.
Esta distinción importa porque algunos proveedores comercializan el escaneo de vulnerabilidades como pentesting. Un informe de escaneo automatizado, independientemente de cuán completo sea, no satisface el requisito de pentesting. Tu QSA examinará la metodología del informe y la evidencia para determinar si se intentó la explotación real. Si la evidencia muestra solo resultados de escáner sin intentos de explotación, el requisito se marcará como no cumplido.
La implicación para las plataformas de pruebas automatizadas con IA es importante: la plataforma debe demostrar validación de explotación, no solo detección de vulnerabilidades, para satisfacer los requisitos de pentesting de PCI DSS. Las pruebas automatizadas de ThreatExploit incluyen intentos de explotación activa con captura de evidencia, lo cual está específicamente diseñado para cumplir con este requisito.
Desglose Requisito por Requisito
Aquí hay un mapeo detallado de cada requisito de pentesting bajo PCI DSS 4.0, lo que evalúa el QSA y cómo satisfacerlo.
Requisito 11.4.1: Metodología y Alcance
Lo que dice: Se define, documenta e implementa una metodología de pentesting que incluye enfoques de pentesting aceptados por la industria, cobertura de todo el perímetro del CDE y sistemas críticos, pruebas desde dentro y fuera de la red, y pruebas para validar los controles de segmentación y reducción de alcance.
Lo que evalúa el QSA:
- ¿Existe un documento de metodología escrito?
- ¿Hace referencia a un estándar reconocido (PTES, OSSTMM, OWASP, NIST)?
- ¿El alcance cubre todos los sistemas dentro del alcance?
- ¿Hay evidencia de que las pruebas siguieron la metodología documentada?
Cómo satisfacerlo: Mantén un documento de política de pentesting que especifique la metodología, el proceso de definición de alcance, la frecuencia de pruebas y los requisitos de informes. Asegúrate de que tu proveedor de pruebas (ya sea interno, externo o automatizado) siga y documente el cumplimiento de esta metodología.
Requisito 11.4.2: Pentesting Interno
Lo que dice: El pentesting interno se realiza según la metodología definida al menos una vez cada 12 meses y después de cualquier cambio significativo en la infraestructura o aplicación.
Lo que evalúa el QSA:
- ¿Se realizaron pruebas internas en los últimos 12 meses?
- ¿El informe de pruebas cubre todos los sistemas internos dentro del alcance?
- ¿Se repitieron las pruebas después de cambios significativos?
- ¿Se corrigieron y volvieron a probar las vulnerabilidades identificadas?
Cómo satisfacerlo: Realiza pentesting interno anualmente como mínimo. Documenta lo que constituye un "cambio significativo" en tu metodología. Mantén evidencia de que se realizaron nuevas pruebas después de cambios importantes en la infraestructura, implementaciones de aplicaciones o modificaciones de red.
Requisito 11.4.3: Pentesting Externo
Lo que dice: El pentesting externo se realiza según la metodología definida al menos una vez cada 12 meses y después de cualquier cambio significativo en la infraestructura o aplicación.
Lo que evalúa el QSA:
- Los mismos criterios que el 11.4.2, aplicados a pruebas externas
- ¿Se probó todo el perímetro externo?
- ¿Se incluyeron todos los sistemas accesibles externamente?
Cómo satisfacerlo: Realiza pentesting externo anualmente como mínimo. Asegúrate de que el alcance incluya todos los sistemas orientados a internet en el CDE: aplicaciones web, API, endpoints VPN, puertas de enlace de correo electrónico y cualquier otro servicio accesible externamente.
Requisito 11.4.4: Remediación y Repetición de Pruebas
Lo que dice: Las vulnerabilidades explotables y debilidades de seguridad encontradas durante el pentesting se corrigen, y se repiten las pruebas para verificar las correcciones.
Lo que evalúa el QSA:
- ¿Existe un plan de remediación para cada hallazgo?
- ¿Se remediaron los hallazgos críticos y altos?
- ¿Hay evidencia de repetición de pruebas después de la remediación?
- ¿La evidencia de la repetición de pruebas está documentada en el informe?
Cómo satisfacerlo: Establece un flujo de trabajo de remediación con SLA definidos por severidad (ej., crítico: 15 días, alto: 30 días, medio: 90 días). Después de la remediación, realiza nuevas pruebas y documenta los resultados. Las pruebas automatizadas con IA hacen que la repetición de pruebas sea eficiente e inmediata -- puedes validar una corrección en horas después del despliegue en lugar de programar un compromiso de seguimiento.
Requisito 11.4.5: Verificación de Segmentación
Lo que dice: Si se utiliza segmentación para aislar el CDE, se realizan pentesting para verificar que los controles de segmentación son operativos y efectivos -- al menos cada 12 meses, y cada seis meses para proveedores de servicios.
Lo que evalúa el QSA:
- ¿Existe segmentación entre el CDE y las redes fuera del alcance?
- ¿Se probaron los controles de segmentación intentando penetrar desde segmentos fuera del alcance hacia los que están dentro del alcance?
- Para proveedores de servicios: ¿se realizaron dos pruebas de segmentación en los últimos 12 meses?
- ¿Se repitieron las pruebas después de cambios en los métodos de segmentación?
Cómo satisfacerlo: Programa pruebas específicas de segmentación con la frecuencia requerida. Las pruebas deben incluir intentos de cruzar los límites de los segmentos utilizando análisis de enrutamiento, pruebas de reglas de firewall, intentos de salto de VLAN y explotación de cualquier servicio que abarque segmentos. Las pruebas automatizadas pueden realizar verificación de segmentación de manera continua, detectando la deriva de configuración entre los ciclos formales de evaluación.
Requisito 11.4.6: Validación de Enfoque Personalizado (Proveedores de Servicios)
Lo que dice: Si se utiliza el enfoque personalizado para cualquier requisito de PCI DSS, el enfoque personalizado de la entidad se confirma mediante pentesting.
Lo que evalúa el QSA:
- ¿La organización ha adoptado el enfoque personalizado para algún requisito?
- Si es así, ¿el pentesting valida específicamente los controles alternativos?
- ¿Hay evidencia documentada de que los controles alternativos logran el objetivo de seguridad previsto?
Cómo satisfacerlo: Si utilizas el enfoque personalizado, trabaja con tu QSA para definir escenarios específicos de pentesting que validen tus controles alternativos. Documenta el enfoque de pruebas, los resultados esperados y los resultados reales. Esto requiere una coordinación estrecha entre tu programa de pruebas y tu equipo de cumplimiento.
Requisito 11.4.7: Soporte de Pruebas para Proveedores de Servicios Multi-Inquilino
Lo que dice: Los proveedores de servicios multi-inquilino apoyan las solicitudes de pentesting de sus clientes de acuerdo con los métodos especificados.
Lo que evalúa el QSA:
- ¿El proveedor de servicios tiene una política para apoyar el pentesting de clientes?
- ¿Existen procedimientos definidos para que los clientes soliciten y realicen pruebas?
- ¿Se especifican plazos y métodos razonables?
Cómo satisfacerlo: Desarrolla una política de pentesting para clientes que defina: cómo los clientes solicitan pruebas, qué métodos están permitidos (solo externo, interno con coordinación, escaneo automatizado), procedimientos de programación y cualquier restricción necesaria para proteger a otros inquilinos. Comunica esta política a todos los clientes.
Pruebas de Capa de Aplicación: La Alineación con OWASP
El Requisito 6.2.4 de PCI DSS 4.0 define el conjunto mínimo de vulnerabilidades de aplicación que deben abordarse en el desarrollo, y el Requisito 11.4 vincula el pentesting a estas mismas categorías de vulnerabilidades. Aunque el estándar no usa la frase "OWASP Top 10" directamente, las categorías de vulnerabilidades se alinean estrechamente:
- Ataques de inyección (SQL, LDAP, XPath, inyección de comandos)
- Desbordamientos de búfer
- Almacenamiento criptográfico inseguro
- Comunicaciones inseguras
- Manejo inadecuado de errores
- Cross-site scripting (XSS)
- Control de acceso inadecuado (incluyendo IDOR, navegación forzada, escalamiento de privilegios)
- Cross-site request forgery (CSRF)
- Autenticación y gestión de sesiones rotas
- Todas las demás vulnerabilidades identificadas en el Requisito 6.2.4
Tu pentesting debe demostrar que cada una de estas categorías de vulnerabilidades fue probada. El QSA revisará el informe de pruebas para confirmar la cobertura. Si tu informe muestra pruebas de inyección SQL pero no hay evidencia de pruebas de autenticación, el requisito se considerará parcialmente cumplido en el mejor de los casos.
Esta es un área donde las plataformas de pruebas automatizadas proporcionan una ventaja significativa. Las pruebas impulsadas por IA verifican sistemáticamente cada categoría de vulnerabilidad en la metodología con total consistencia, asegurando que ninguna categoría se omita debido a presión de tiempo o descuido humano. Los testers manuales, bajo las restricciones de tiempo de un compromiso de alcance fijo, pueden priorizar ciertas categorías y dar a otras una atención superficial.
Cómo las Pruebas Automatizadas con IA Satisfacen PCI DSS 4.0
Mapeo de las pruebas de penetración automatizadas con IA a cada requisito de PCI DSS 4.0:
| Requisito | Lo Que Exige | Cómo la Automatización lo Satisface |
|---|---|---|
| 11.4.1 | Metodología documentada | Documentación de metodología de plataforma basada en OWASP/PTES |
| 11.4.2 | Pruebas internas anuales + después de cambios | Pruebas internas bajo demanda, activadas por CI/CD o programación |
| 11.4.3 | Pruebas externas anuales + después de cambios | Pruebas externas bajo demanda con disponibilidad el mismo día |
| 11.4.4 | Remediación y repetición de pruebas | Repetición inmediata de pruebas después de correcciones con evidencia de antes y después |
| 11.4.5 | Verificación de segmentación (semestral para PS) | Pruebas de segmentación automatizadas en programación configurable |
| 11.4.6 | Validación de enfoque personalizado | Escenarios de prueba configurables para controles personalizados |
| 11.4.7 | Soporte de pruebas multi-inquilino | Capacidad de pruebas de autoservicio para inquilinos |
La ventaja clave es la frecuencia. PCI DSS 4.0 establece frecuencias mínimas de pruebas (anualmente para la mayoría, semestralmente para la segmentación de proveedores de servicios), pero el estándar también requiere pruebas después de "cambios significativos." En entornos de desarrollo modernos donde el código se despliega semanal o diariamente, definir y rastrear cambios significativos es operativamente desafiante. Las pruebas automatizadas continuas eliminan este problema por completo: si pruebas continuamente, cada cambio se prueba, y el disparador de "cambio significativo" se vuelve irrelevante.
Lista de Verificación de Preparación para Evaluaciones de 2026
Usa esta lista de verificación para evaluar tu preparación para los requisitos de pentesting de PCI DSS 4.0 en tu próxima evaluación.
Documentación
- Metodología de pentesting escrita que referencia PTES, OSSTMM, OWASP o NIST SP 800-115
- Alcance definido que mapea el límite actual del CDE y todos los sistemas dentro del alcance
- Definición de "cambio significativo" que activa nuevas pruebas
- SLA de remediación por severidad de vulnerabilidad
- Programa de pruebas que cumple con los requisitos mínimos de frecuencia
Cobertura de Pruebas
- Pentesting interno completado en los últimos 12 meses
- Pentesting externo completado en los últimos 12 meses
- Verificación de segmentación completada (dentro de 12 meses para comerciantes, 6 meses para proveedores de servicios)
- Pruebas de capa de aplicación cubriendo todas las categorías de vulnerabilidades del Requisito 6.2.4
- Pruebas de capa de red cubriendo todos los sistemas operativos y funciones de red dentro del alcance
- Repetición de pruebas realizada después de todos los cambios significativos de infraestructura o aplicación desde la última evaluación
Calidad de la Evidencia
- Los informes de pruebas incluyen evidencia de explotación, no solo identificación de vulnerabilidades
- Puntuaciones CVSS asignadas a todos los hallazgos
- Evidencia de remediación documentada para todos los hallazgos críticos y altos
- Resultados de repetición de pruebas confirmando la efectividad de la remediación
- Resumen ejecutivo y secciones de metodología adecuados para revisión del QSA
- Declaración de alcance clara en cada informe que coincide con el límite del CDE
Específico para Proveedores de Servicios
- Pruebas de segmentación semestrales completadas (dos pruebas en los últimos 12 meses)
- Controles de enfoque personalizado validados mediante pentesting (si aplica)
- Política de soporte de pentesting para clientes documentada y comunicada (si es multi-inquilino)
Mejoras de Proceso para 2026
- Evaluar pruebas automatizadas con IA para aumentar la frecuencia de pruebas más allá de los mínimos
- Implementar pruebas continuas para abordar los requisitos de pruebas por "cambio significativo"
- Integrar pentesting en el pipeline de gestión de cambios y despliegue
- Establecer flujo de trabajo automatizado de repetición de pruebas para una validación más rápida de la remediación
- Revisar y actualizar el documento de metodología de pruebas al menos anualmente
El Piso de Cumplimiento vs el Techo de Seguridad
PCI DSS 4.0 establece un piso para el pentesting -- requisitos mínimos que deben cumplirse para lograr el cumplimiento. Cumplir con ese piso es necesario. Pero como discutimos en detalle en nuestro artículo sobre pentesting de cumplimiento vs pruebas de seguridad reales, los mínimos de cumplimiento están diseñados para establecer una línea base, no para proporcionar seguridad integral.
Las organizaciones que tratan los requisitos de pentesting de PCI DSS como el techo en lugar del piso dejan un riesgo significativo sin abordar. Los requisitos no cubren las pruebas de sistemas adyacentes a los pagos que están fuera del alcance pero que podrían servir como pivotes de ataque. No requieren pruebas de fallos de lógica de negocio específicos de los flujos de pago. No exigen pruebas de ingeniería social ni evaluaciones de seguridad física.
Las organizaciones de pago más seguras utilizan los requisitos de PCI DSS como punto de partida y extienden las pruebas para cubrir su perfil de riesgo real. Las pruebas automatizadas con IA hacen esto económicamente factible porque el costo marginal de probar más allá del mínimo de cumplimiento es insignificante cuando las pruebas están automatizadas. Ejecutar un pentesting contra sistemas fuera del alcance junto con la prueba mandatada dentro del alcance cuesta poco esfuerzo adicional cuando la plataforma maneja ambos simultáneamente.
PCI DSS 4.0 elevó significativamente el piso de pentesting en comparación con la versión 3.2.1. Cumplir con el nuevo piso requiere mejor documentación, alcance más amplio, pruebas más frecuentes y evidencia más rigurosa. Las organizaciones que se preparen ahora -- con metodologías documentadas, capacidades de pruebas automatizadas y flujos de trabajo de remediación -- navegarán sus evaluaciones de 2026 sin problemas. Las que esperen encontrarán la brecha entre sus prácticas actuales y los nuevos requisitos más amplia de lo esperado.
Preguntas Frecuentes
¿Cuáles son los requisitos de pentesting de PCI DSS 4.0?
PCI DSS 4.0 requiere: metodología de pentesting documentada (OSSTMM, OWASP o NIST SP 800-115), pruebas tanto internas como externas, verificación de segmentación de red, pruebas de capa de aplicación que cubran el OWASP Top 10, y pruebas de todos los sistemas dentro del alcance. Los nuevos requisitos incluyen validación de enfoque personalizado y obligaciones de pruebas para proveedores de servicios multi-inquilino.
¿Con qué frecuencia requiere PCI DSS el pentesting?
PCI DSS requiere pentesting al menos anualmente y después de cualquier cambio significativo en la infraestructura o aplicación. Los controles de segmentación deben probarse cada seis meses para proveedores de servicios. Los requisitos con fecha futura de la versión 4.0 (ahora obligatorios desde el 31 de marzo de 2025) agregan documentación de metodología más estricta y requisitos de alcance de pruebas.
¿Cuál es la diferencia entre un escaneo de vulnerabilidades y un pentesting bajo PCI DSS?
PCI DSS distingue explícitamente entre ambos. Los escaneos de vulnerabilidades (Requisito 11.3.1-11.3.2) son evaluaciones automatizadas basadas en herramientas que identifican vulnerabilidades conocidas. Los pentesting (Requisito 11.4) involucran intentos activos de explotación para determinar si las vulnerabilidades pueden ser aprovechadas para comprometer sistemas. Usar solo un escáner de vulnerabilidades no satisfará el requisito de pentesting y resultará en una falla de auditoría.