Pentest para PCI DSS: qué dice el Requisito 11.4

Qué pide PCI DSS y dónde entra el pentest

Tienes que correr pentests regularmente. El Requisito 11.4 está dentro del Requisito 11, Test Security of Systems and Networks Regularly. El encabezado de la sección dice: «External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected» — se ejecutan pruebas de penetración externas e internas de forma regular, y las vulnerabilidades explotables y las debilidades de seguridad se corrigen. Se divide en siete subrequisitos, del 11.4.1 al 11.4.7.

Antes de la frecuencia, el estándar pide un enfoque documentado. El 11.4.1 indica que «A penetration testing methodology is defined, documented, and implemented by the entity» y enumera qué incluye: entre otros puntos, «Coverage for the entire CDE perimeter and critical systems», «Testing from both inside and outside the network», «Testing to validate any segmentation and scope-reduction controls», «Review and consideration of threats and vulnerabilities experienced in the last 12 months» y «Retention of penetration testing results and remediation activities results for at least 12 months».

Las pruebas internas y externas se tratan por separado, con una redacción casi idéntica. Ambas indican que la prueba se ejecuta «Per the entity's defined methodology», «At least once every 12 months» —al menos una vez cada 12 meses— y «After any significant infrastructure or application upgrade or change» —después de cualquier actualización o cambio relevante de infraestructura o de aplicaciones.

Conviene leer dos cosas con atención. La frecuencia es «al menos una vez cada 12 meses»: un piso, en las palabras del propio estándar, que no equivale a un evento anual. Y el cambio es un disparador separado que convive con ese piso, no una nota al pie. Un entorno que despliega cada semana cumple la segunda condición mucho más seguido que la primera.

Acá es donde PCI DSS se lee mal con más frecuencia. El 11.4.2 y el 11.4.3 indican que la prueba se ejecuta «By a qualified internal resource or qualified external third-party» —por un recurso interno calificado o un tercero externo calificado— y que «Organizational independence of the tester exists (not required to be a QSA or ASV)».

Ese paréntesis está en el estándar y aparece siete veces a lo largo del Requisito 11.4. PCI DSS no pide que la prueba de penetración la ejecute un QSA ni un ASV. Pide una persona calificada, con independencia organizacional respecto de los sistemas que se prueban. Los QSA evalúan cumplimiento; los ASV se nombran para el requisito de escaneo de vulnerabilidades, no para pruebas de penetración. Sobre calificaciones, la guía del estándar menciona «Specific penetration testing certifications» y «Prior experience conducting penetration testing» como consideraciones, no como un umbral definido.

El 11.4.4 indica que las vulnerabilidades explotables y las debilidades de seguridad encontradas durante la prueba se corrigen «In accordance with the entity's assessment of the risk posed by the security issue», y agrega una línea que cambia la forma de todo el requisito: «Penetration testing is repeated to verify the corrections» — la prueba de penetración se repite para verificar las correcciones.

El entregable no es la prueba. Es la corrección verificada. Un programa que produce un informe y se detiene cubrió una parte del 11.4, y no la parte que lo cierra.

Donde la segmentación aísla el CDE, los controles de segmentación también se prueban. Para todas las entidades, el 11.4.5 indica «At least once every 12 months and after any changes to segmentation controls/methods». Para proveedores de servicios, el 11.4.6 indica «At least once every six months and after any changes to segmentation controls/methods» —al menos una vez cada seis meses y después de cualquier cambio en los controles o métodos de segmentación—. Ambos piden confirmar que los controles están «operational and effective, and isolate the CDE from all out-of-scope systems».

Los proveedores de servicios multicliente acompañan las pruebas de penetración externas de sus clientes según el 11.4.3 y el 11.4.4. Es el único subrequisito del 11.4 que tuvo fecha futura: su nota de aplicabilidad decía «This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment». Esa fecha ya pasó. Del 11.4.1 al 11.4.6 no llevaban esa nota y entraron en vigencia de inmediato.

Strike es una plataforma de Validación Híbrida Continua: Threat Emulations impulsadas por IA con validación humana experta antes de la entrega al cliente. Frente a la forma del Requisito 11.4, hay tres puntos que coinciden.

Las pruebas pueden dispararse por cambios según el alcance configurado, que es la condición de cambio del 11.4.2 y el 11.4.3 y no un calendario. Los hallazgos se reproducen y se confirman antes de llegar a sus manos, con 97% de precisión / 3% de falsos positivos (dato reportado por Strike — cómo medimos los resultados), porque un hallazgo que un QSA no puede seguir no es evidencia. Y el reteste —la línea del 11.4.4— forma parte del modelo de operación en lugar de ser un trabajo aparte, aunque la disponibilidad de reteste depende del alcance contratado.

Dos límites, dichos con claridad. La cobertura depende del alcance autorizado y del acceso: una prueba de segmentación bajo el 11.4.5 o el 11.4.6 se define de forma deliberada y es un ejercicio distinto del perímetro. Y Strike no determina su cumplimiento: Strike apoya programas de auditoría y cumplimiento, y no emite atestaciones de PCI DSS. La suficiencia frente al 11.4 la determina su evaluador.

La puesta en marcha toma menos de 5 minutos en alcances soportados, y los primeros hallazgos curados llegan en 1 a 2 horas (ambos datos reportados por Strike — cómo medimos los resultados). El alcance y la autorización se definen antes de eso y corren en un reloj distinto de esas dos cifras. Hasta hoy, US$4.5B+ en riesgo mitigado (dato reportado por Strike — cómo medimos los resultados).

PCI DSS y pentest, respondido

¿PCI DSS pide una prueba de penetración anual?

SI! El texto dice «At least once every 12 months» —al menos una vez cada 12 meses— en el 11.4.2 y el 11.4.3. Ambos nombran además «After any significant infrastructure or application upgrade or change» como condición separada, así que los doce meses son un piso y no un cronograma.

¿La prueba tiene que ejecutarla un QSA?

No. El 11.4.2, el 11.4.3, el 11.4.5 y el 11.4.6 indican que la prueba se ejecuta «By a qualified internal resource or qualified external third party» y que «Organizational independence of the tester exists (not required to be a QSA or ASV)».

¿Puede ejecutarla el equipo interno?

El estándar admite «a qualified internal resource», sujeto a independencia organizacional: quien prueba está separado de la gestión de los sistemas objetivo. No define un umbral de certificación; su guía trata las certificaciones y la experiencia previa como consideraciones.

¿Alcanza con un escaneo de vulnerabilidades?

No. PCI DSS trata el escaneo y las pruebas de penetración en requisitos distintos. El 11.4.1 pide que la metodología incluya «Application-layer penetration testing» y «Network-layer penetration tests», que un escaneo no ejecuta.

¿Cada cuánto prueban segmentación los proveedores de servicios?

El 11.4.6, que aplica solo a proveedores de servicios, indica «At least once every six months and after any changes to segmentation controls/methods». Para el resto de las entidades, el 11.4.5 fija doce meses.

¿Qué versión de PCI DSS está vigente?

PCI DSS v4.0.1, publicada en junio de 2024. El PCI SSC abrió en junio de 2026 un pedido de comentarios sobre la v4.0.1 como punto de partida de la próxima iteración, y la v4.0.1 sigue siendo la versión publicada. No se encontró fecha de retiro de la v4.0.1 ni fecha de publicación de una sucesora en los materiales públicos revisados el 29 de julio de 2026.

Fuentes consultadas; fecha de acceso: 29 de julio de 2026. El texto del requisito se cita de PCI DSS v4.0.1 (junio de 2024), Requisito 11.4, según se reproduce en la plantilla de Report on Compliance de PCI DSS v4.0.1 (PCI SSC). Versión vigente confirmada contra Request for Comments: PCI DSS v4.0.1 (PCI SSC, 3 de junio de 2026). El estándar se obtiene desde la biblioteca de documentos del PCI SSC y se entrega bajo un acuerdo de licencia de aceptación previa. Las citas se reproducen en su idioma original, inglés, porque es el texto autoritativo del estándar. Strike no emite atestaciones de PCI DSS y no es un QSA; esta página resume texto de requisitos de acceso público y no constituye asesoramiento legal ni de cumplimiento. La suficiencia frente al Requisito 11.4 la determina su evaluador.