Resumen: referencia de los 12 requisitos de PCI DSS 4.0.1
- Más allá de los 12: PCI DSS tiene 12 requisitos de alto nivel. Todos citan ese número y se detienen. El dato interesante es que 4.0.1 ahora tiene más de 400 subrequisitos, y los dos que más gente falla son los más nuevos, para los que nadie tenía evidencia antes de 2025.
- Los dos que más se fallan: PCI DSS 4.0.1 se volvió obligatorio en marzo de 2025. Los requisitos 6.4.3 (inventario de scripts, justificación de negocio, verificación de integridad, detección de cambios) y 11.6.1 (monitoreo de cabeceras HTTP en páginas de pago) son los dos menos preparados en las evaluaciones actuales. cside produce ambos artefactos de forma continua.
- Por dónde empezar: Si estás definiendo el alcance de una evaluación 4.0.1 y no tienes inventario de scripts ni monitoreo de cabeceras, comienza ahí antes de tocar los Requisitos 3 o 12. Si tu evidencia 6.4.3 y 11.6.1 ya fluye, enfoca luego la revisión de scope creep y el despliegue de MFA bajo 8.4.2.
¿Poco tiempo? Consulta cside PCI Shield. Cubre todo lo de abajo en un solo despliegue.
Los 12 requisitos de PCI DSS son el núcleo del estándar de seguridad de datos del sector de las tarjetas de pago (Payment Card Industry Data Security Standard). Toda entidad que almacena, procesa o transmite datos de tarjeta tiene que cumplirlos. Esta es la referencia práctica de lo que cubre cada requisito en PCI DSS 4.0.1, qué cambió respecto a la 3.2.1 y dónde tienen carencias la mayoría de los entornos.
La estructura: 6 objetivos, 12 requisitos
PCI DSS organiza sus controles en seis objetivos de seguridad. Cada objetivo contiene uno o más de los 12 requisitos principales. Cada requisito contiene varios subrequisitos, y el total de subrequisitos en la 4.0.1 supera los 400.
Objetivo 1: crear y mantener una red y unos sistemas seguros
Requisito 1: instalar y mantener controles de seguridad de red. Los firewalls, las configuraciones de los routers y la segmentación de red deben aislar el entorno de datos del titular de la tarjeta de las redes no confiables. Cada regla necesita una justificación de negocio documentada.
Requisito 2: aplicar configuraciones seguras a todos los componentes del sistema. Sin contraseñas por defecto, sin cuentas por defecto, sin servicios innecesarios. Las líneas base de fortalecimiento deben documentarse y aplicarse a todos los sistemas.
Objetivo 2: proteger los datos de cuenta
Requisito 3: proteger los datos de cuenta almacenados. Los datos del titular de la tarjeta deben cifrarse con criptografía robusta en reposo. Los datos de autenticación sensibles (CVV, PIN, pista completa) no deben almacenarse después de la autorización. Si no necesitas almacenar datos del titular de la tarjeta, no lo hagas. La vía más rápida para cumplir el Requisito 3 es no tener los datos.
Requisito 4: proteger los datos del titular de la tarjeta con criptografía robusta durante la transmisión. TLS 1.2 o superior en las redes públicas. Los protocolos obsoletos y los cifrados débiles deben inventariarse y eliminarse.
Objetivo 3: mantener un programa de gestión de vulnerabilidades
Requisito 5: proteger todos los sistemas y redes frente al software malicioso. Controles antimalware en todos los sistemas del CDE. Escaneos periódicos y actualizaciones de definiciones.
Requisito 6: desarrollar y mantener sistemas y software seguros. Gestión de parches, prácticas de código seguro, gestión de cambios. Aquí es donde vive el Requisito 6.4.3: el inventario de scripts del lado del cliente y el control de integridad que eran nuevos en la 4.0. Consulta nuestra guía práctica para cumplir con PCI 6.4.3 y 11.6.1 para la implementación concreta.
Objetivo 4: implementar medidas sólidas de control de acceso
Requisito 7: restringir el acceso a los componentes del sistema y a los datos del titular de la tarjeta según la necesidad de conocer del negocio. Controles de acceso basados en roles, mínimo privilegio, aprobación de accesos documentada.
Requisito 8: identificar a los usuarios y autenticar el acceso a los componentes del sistema. Identificadores únicos para cada usuario, requisitos de contraseñas robustas, MFA en todos los accesos administrativos al CDE (reforzado en la 4.0.1 en el 8.4.2).
Requisito 9: restringir el acceso físico a los datos del titular de la tarjeta. Controles físicos en las instalaciones que almacenan datos del titular de la tarjeta o alojan sistemas del CDE.
Objetivo 5: monitorizar y probar las redes con regularidad
Requisito 10: registrar y monitorizar todos los accesos a los componentes del sistema y a los datos del titular de la tarjeta. Registro exhaustivo, integridad de los registros, revisión de registros y sincronización horaria entre sistemas.
Requisito 11: probar la seguridad de los sistemas y las redes con regularidad. Escaneos de vulnerabilidades (internos y externos, trimestrales), pruebas de penetración (anuales + después de un cambio significativo) y, algo crítico para la 4.0.1, el Requisito 11.6.1, que cubre la monitorización de cabeceras HTTP en las páginas de pago.
Objetivo 6: mantener una política de seguridad de la información
Requisito 12: respaldar la seguridad de la información con políticas y programas organizativos. Política de seguridad, evaluación de riesgos, formación de concienciación en seguridad, respuesta a incidentes, gestión de proveedores. El Requisito 12 es el requisito marco que conecta todos los demás controles con un compromiso organizativo.
Qué hay de nuevo en la 4.0.1 frente a la 3.2.1
PCI DSS 4.0.1 pasó a ser obligatorio en marzo de 2025. Los cambios más importantes desde la 3.2.1:
| Cambio | Requisito | Impacto |
|---|---|---|
| Inventario de scripts + integridad en las páginas de pago | 6.4.3 | La mayoría de los entornos no tenían ninguna cobertura antes de 2025 |
| Monitorización de cabeceras HTTP en las páginas de pago | 11.6.1 | Lo mismo, se requiere un artefacto nuevo |
| Reglas de contraseñas reforzadas | 8.3.6 | Mínimo de 12 caracteres |
| MFA en el acceso administrativo al CDE | 8.4.2 | Se aplica a la administración fuera de consola, no solo remota |
| Inventario criptográfico | 12.3.3 | Documentación de cifrados y protocolos |
| Retención y revisión de registros | 10.7.2/3 | Requisitos de revisión de registros ampliados |
| Enfoque personalizado | Varios | Nueva alternativa al enfoque definido para los controles |
El enfoque personalizado permite a las organizaciones cumplir la intención de un requisito con un control distinto del que prescribe el estándar, siempre que documenten formalmente el análisis de riesgos y los controles. Es potente para los programas de seguridad maduros y peligroso para las organizaciones que lo usan para justificar controles más débiles.
Dónde se atascan las auditorías
Al trabajar con comercios que pasan por evaluaciones de 4.0.1, aparecen tres patrones de forma repetida:
- Requisitos 6.4.3 y 11.6.1: sin inventario de scripts, sin monitorización de integridad, sin monitorización de cabeceras HTTP. Consulta la guía para QSA para saber qué buscan concretamente los auditores.
- Ampliación del alcance: el CDE incluye más sistemas de los que mostraba el diagrama de alcance inicial, normalmente porque la segmentación es más débil de lo que se suponía
- Evidencias manuales: los QSA necesitan evidencias continuas, no capturas de pantalla tomadas durante la semana de la evaluación
La lista completa de requisitos de PCI DSS
PCI DSS 4.0.1 se organiza en 6 objetivos y 12 requisitos. La lista completa de requisitos de PCI DSS es:
- Instalar y mantener controles de seguridad de red.
- Aplicar configuraciones seguras a todos los componentes del sistema.
- Proteger los datos de cuenta almacenados.
- Proteger los datos del titular de la tarjeta con criptografía robusta durante la transmisión por redes públicas abiertas.
- Proteger todos los sistemas y redes frente al software malicioso.
- Desarrollar y mantener sistemas y software seguros.
- Restringir el acceso a los componentes del sistema y a los datos del titular de la tarjeta según la necesidad de conocer del negocio.
- Identificar a los usuarios y autenticar el acceso a los componentes del sistema.
- Restringir el acceso físico a los datos del titular de la tarjeta.
- Registrar y monitorizar todos los accesos a los componentes del sistema y a los datos del titular de la tarjeta.
- Probar la seguridad de los sistemas y las redes con regularidad.
- Respaldar la seguridad de la información con políticas y programas organizativos.
Los requisitos 6.4.3 y 11.6.1, ambos incluidos en el requisito 6 y el requisito 11 anteriores, son donde reside la seguridad de los scripts del lado del cliente: el 6.4.3 rige el inventario y la autorización de los scripts de las páginas de pago, y el 11.6.1 exige la detección de cambios y manipulaciones en esos scripts y en las cabeceras HTTP críticas.
Dónde encaja cside
Los requisitos 6.4.3 y 11.6.1 son el terreno propio de cside. El inventario continuo de scripts, el etiquetado de justificación de negocio, la monitorización de integridad, la detección de cambios en las cabeceras HTTP y un historial de alertas listo para auditoría salen de la plataforma. La guía de cumplimiento de los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 recorre lo que produce el panel y cómo lo lee un QSA.
Para una visión más amplia de cómo prepararte para una evaluación completa, consulta la guía del Informe de Cumplimiento y la guía del SAQ D.
