¿Qué es PCI DSS v4.0.1?

PCI DSS v4.0.1 es la versión de errata de junio de 2024 sobre PCI DSS v4.0. No es una nueva versión del estándar —son los mismos 12 requisitos de alto nivel y la misma estructura general que v4.0— pero el PCI Security Standards Council hizo suficientes cambios de redacción como para que v4.0 y v4.0.1 sean documentos formalmente separados. Después del 31 de marzo de 2025, v4.0 queda retirada y cada evaluación, cada Self-Assessment Questionnaire y cada Report on Compliance debe hacerse contra v4.0.1. El gran impacto práctico es que los requisitos con fecha futura de v4.0 —incluidos 6.4.3 (inventario de scripts y monitorización de integridad) y 11.6.1 (detección de cambios en la página)— son ahora obligatorios y se están evaluando al mismo tiempo que se usa la redacción de v4.0.1.

Si es nuevo en la familia v4, empiece por el explicador más amplio de PCI DSS v4.0. Esta página es para comercios y proveedores de servicios que ya aprobaron v4.0 y necesitan saber qué cambió realmente v4.0.1, y para cualquiera a quien su QSA le acabe de decir que la evaluación que está a punto de empezar será sobre v4.0.1.

¿Por qué una v4.0.1 en absoluto?

PCI DSS v4.0 se publicó en marzo de 2022 con una larga ventana de transición. La primera oleada de requisitos obligatorios entró en vigor el 31 de marzo de 2024 (cuando se retiró v3.2.1). Una segunda oleada —los requisitos "con fecha futura"— se aplazó hasta el 31 de marzo de 2025 para dar a comercios y proveedores de servicios tiempo para construir los nuevos controles (gestión de scripts, detección de cambios en la página, revisión automatizada de logs, MFA más fuerte).

Entre marzo de 2022 y junio de 2024, el PCI Council recogió comentarios de QSAs, ISAs y organizaciones participantes sobre puntos donde la redacción de v4.0 era ambigua, internamente inconsistente o tenía consecuencias no deseadas. La limpieza se publicó como v4.0.1 en junio de 2024, con una ventana de solapamiento de nueve meses (junio de 2024 al 31 de marzo de 2025) en la que se podía usar v4.0 o v4.0.1 para una evaluación. Después de la fecha límite, solo v4.0.1.

El Consejo fue explícito: v4.0.1 no introduce nuevos requisitos. Cada requisito de v4.0.1 ya estaba en v4.0. Lo que cambió es cómo están escritos algunos de ellos.

Qué cambió realmente entre v4.0 y v4.0.1

Hay aproximadamente 60 ediciones individuales en el documento v4.0.1 respecto a v4.0, que van desde correcciones de erratas hasta aclaraciones de fondo. Las que más importan en la práctica:

Autenticación multifactor (Requisito 8)

Varios requisitos de MFA tenían una redacción que se leía como una prohibición absoluta de ciertos factores de autenticación, cuando la intención del Consejo era "no puede ser el único factor". v4.0.1 reescribió esos puntos para dejar claro que, por ejemplo, los factores basados en conocimiento siguen permitidos como un factor dentro de una combinación de MFA: simplemente no se pueden usar dos factores de conocimiento para satisfacer el requisito de MFA. Las notas de aplicabilidad sobre MFA para el acceso administrativo (8.4.2) y MFA al entrar en el entorno de datos del titular de la tarjeta (8.4.3) también se afinaron.

Requisito 6.4.3: gestión de scripts

El 6.4.3 es la regla que dice que cada script cargado en una página de pago expuesta al público (la página en la que el titular de la tarjeta introduce los datos de la tarjeta) tiene que estar en un inventario con una razón de negocio documentada, debe estar autorizado antes de cargarse y debe tener su integridad asegurada. v4.0.1 aclaró dos cosas: qué páginas cuentan como "páginas de pago" (la página que captura o transmite datos del titular de la tarjeta, incluido el contenido en iframe que lo hace) y qué significa "integridad asegurada" en la práctica (un mecanismo documentado que detecta cambios no autorizados: hashes de Subresource Integrity, una lista blanca del gestor de etiquetas, o la aplicación de un content-security-policy script-src más un control de monitorización).

Este es el requisito que encendió la mecha entre los minoristas con pilas pesadas de analítica y widgets de chat en sus páginas de checkout, porque cada script de Google Tag Manager, cada widget de chat, cada fragmento de A/B testing está dentro del alcance.

Requisito 11.6.1: detección de cambios y manipulación

El 11.6.1 es el compañero del 6.4.3. Exige a los comercios detectar cambios no autorizados en las cabeceras HTTP y en el contenido de script de sus páginas de pago, con alertas ante cualquier cambio, a una frecuencia definida por un análisis de riesgos focalizado (pero como mínimo una vez cada siete días). v4.0.1 aclaró qué significa "cabeceras HTTP" dentro del alcance (las cabeceras que afectan a la seguridad: CSP, X-Frame-Options, HSTS, etc., no Content-Length) y confirmó que una revisión periódica manual no satisface el 11.6.1: tiene que ser un mecanismo que detecte cambios y genere una alerta.

Aclaraciones menores

• El requisito 3.5.1 (hacer el PAN ilegible) afinó su lista de métodos aceptables.
• El requisito 12.5.2 (confirmación anual del alcance) ganó una referencia explícita a qué cuenta como "cambio significativo" y dispara una revisión interina del alcance.
• El apéndice de Customised Approach Objectives se editó para varios requisitos para eliminar redacciones circulares.
• Se corrigieron múltiples notas al pie y notas de aplicabilidad para referirse a los requisitos cruzados correctos.

Si aprobó v4.0, ¿necesita volver a atestiguar bajo v4.0.1?

Sí. Las atestaciones de PCI DSS están fechadas contra una versión específica del estándar. Una atestación que dice "PCI DSS v4.0" es válida para el período de evaluación que cubre, pero la siguiente evaluación anual después del 31 de marzo de 2025 tiene que hacerse contra v4.0.1. Los SAQs (los cuestionarios de autoevaluación para los comercios que no necesitan una evaluación completa dirigida por un QSA) se han actualizado todos a versiones v4.0.1.

Para la mayoría de los comercios, la reatestación es directa porque v4.0.1 no añadió nada: se contestan las mismas preguntas de control con una redacción ligeramente distinta. El trabajo real, donde existe, está en implementar realmente el 6.4.3 y el 11.6.1 (que pasaron a ser obligatorios en la misma fecha límite de marzo de 2025 independientemente de la transición de versión) y poder evidenciar esos controles durante la nueva evaluación.

Plazos de adquirentes y marcas

Las marcas de tarjeta y los adquirentes fijan sus propios plazos por encima de los del PCI Council. Visa, Mastercard y Amex se alinearon todos con la fecha del 31 de marzo de 2025 para la adopción de v4.0.1. Algunos adquirentes dieron a sus comercios un breve período de gracia adicional durante 2025 para presentar el nuevo documento de atestación, pero los controles subyacentes tenían que estar en marcha desde el 31 de marzo de 2025 con independencia de cuándo se presentara la documentación.

Si su adquirente o QSA sigue pidiéndole documentos v4.0 en 2026, es una laguna de proceso por su parte: replique y pida los SAQs y AOCs de v4.0.1.

Qué no cambió v4.0.1

Los 12 requisitos de alto nivel no han cambiado. El enfoque definido (defined approach) y el enfoque personalizado (customised approach) no han cambiado. Los tipos de Self-Assessment Questionnaire (A, A-EP, B, B-IP, C, C-VT, D-MER, D-SP, SPoC, P2PE) no han cambiado. Los requisitos de validación según el nivel del comercio (del 1 al 4) no han cambiado. La lista de approved scanning vendors, qualified security assessors y aplicaciones de pago listadas por PCI no ha cambiado. Si entendió v4.0, entiende v4.0.1: las diferencias están en el documento, no en la estructura del estándar.