Resumen: qué es PCI DSS
- Doce requisitos de seguridad del PCI Security Standards Council para cualquiera que almacena, procesa o transmite datos de titulares de tarjeta.
- La versión actual es 4.0.1. Los requisitos 6.4.3 (inventario de scripts) y 11.6.1 (detección de manipulación en página de pago) aplicados desde el 31 de marzo de 2025.
- El no cumplimiento significa multas, posible pérdida de aceptación de marcas de tarjeta, y responsabilidad completa por costos de brecha.
Qué es PCI DSS y quién lo gestiona
El estándar lo publica el PCI Security Standards Council, una entidad fundada en 2006 por American Express, Discover, JCB, Mastercard y Visa para estandarizar la seguridad de los datos de tarjetas en todo el ecosistema de pagos. Antes del consejo, cada marca de tarjetas tenía su propio programa de seguridad. Consolidarlos en PCI DSS significó que los comercios y los proveedores de servicios podían apuntar a un solo marco en lugar de cinco.
PCI DSS no es una ley, pero lo exigen por contrato todas las marcas de tarjetas y los adquirentes que te permiten aceptar tarjetas. El incumplimiento puede acarrear multas, tarifas de procesamiento más altas, costes de investigación forense tras una brecha y la pérdida total de la capacidad de procesar pagos con tarjeta.
Quién tiene que cumplir
Cualquier empresa que acepte, almacene, procese o transmita datos de tarjetas de pago. La obligación aplica en distintos niveles según el volumen de transacciones:
| Nivel de comercio | Volumen de transacciones | Validación |
|---|---|---|
| 1 | Más de 6M/año (Visa/Mastercard) | RoC anual firmado por un QSA |
| 2 | 1M-6M/año | SAQ anual (normalmente SAQ D) + escaneos ASV |
| 3 | 20K-1M de e-commerce/año | SAQ anual + escaneos ASV |
| 4 | Menos de 20K de e-commerce o 1M en total | SAQ anual, escaneos ASV según se requiera |
| Proveedor de servicios | Cualquier entidad que maneje datos de tarjetas para terceros | RoC anual firmado por un QSA |
La variante específica de SAQ depende de cómo manejes los datos de tarjetas. Para conocer las diferencias, consulta nuestra guía de SAQ D y nuestra guía del Report on Compliance de PCI DSS.
Los 12 requisitos
PCI DSS 4.0.1 organiza sus controles en seis objetivos que contienen 12 requisitos:
Objetivo 1: Construir y mantener una red y unos sistemas seguros
- Requisito 1: Instalar y mantener controles de seguridad de red
- Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema
Objetivo 2: Proteger los datos de las cuentas
- Requisito 3: Proteger los datos de las cuentas almacenados
- Requisito 4: Proteger los datos de los titulares de tarjetas con criptografía robusta durante la transmisión
Objetivo 3: Mantener un programa de gestión de vulnerabilidades
- Requisito 5: Proteger todos los sistemas y redes frente al software malicioso
- Requisito 6: Desarrollar y mantener sistemas y software seguros
Objetivo 4: Implementar medidas robustas de control de acceso
- Requisito 7: Restringir el acceso según la necesidad de conocer del negocio
- Requisito 8: Identificar a los usuarios y autenticar el acceso
- Requisito 9: Restringir el acceso físico a los datos de los titulares de tarjetas
Objetivo 5: Monitorizar y probar las redes con regularidad
- Requisito 10: Registrar y monitorizar todos los accesos
- Requisito 11: Probar la seguridad de los sistemas y las redes con regularidad
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
Cada requisito tiene varios subrequisitos. El estándar completo abarca cientos de páginas.
Qué cambió en PCI DSS 4.0.1
La versión 4.0.1 reemplazó a PCI DSS 3.2.1 como estándar obligatorio el 2025-03-31. Las principales incorporaciones respecto a la 3.2.1 giran en torno a la seguridad del lado del cliente:
- Requisito 6.4.3: mantener un inventario de scripts en las páginas de pago, documentar la justificación de negocio, verificar la integridad y detectar cambios no autorizados
- Requisito 11.6.1: monitorizar las cabeceras HTTP en las páginas de pago, detectar cambios no autorizados y alertar sobre ellos
- Requisito 8.3.6: se reforzó la complejidad de las contraseñas
- Requisito 8.4.2: se exige MFA para todo acceso administrativo que no sea por consola al entorno de datos de titulares de tarjetas
- Requisito 12.3.3: inventario de cifrados y protocolos criptográficos
- Requisito 10.7.2/3: registro y monitorización ampliados
Las incorporaciones del lado del cliente son las que más importan porque cierran una brecha que las herramientas de seguridad tradicionales no cubren. Ataques como el skimming de scripts al estilo Magecart ocurren por completo en el navegador y, hasta la 4.0.1, no existía ningún requisito explícito de PCI DSS para detectarlos.
Para un recorrido más detallado, consulta nuestra guía completa de PCI DSS 4.0 y el resumen del webinar de implementación de la 4.0.1.
Errores comunes de cumplimiento de PCI DSS
Trabajando con comercios que pasan por su primera evaluación de la 4.0.1, aparecen una y otra vez las mismas carencias:
- Sin inventario de scripts en las páginas de pago: lo exige el 6.4.3, ausente en la mayoría de los entornos antes de 2025
- Sin monitorización de cabeceras HTTP: lo exige el 11.6.1
- Subestimar el alcance: dar por hecho que aplica el SAQ A cuando en realidad se requiere el SAQ A-EP o el SAQ D
- Recopilación manual de evidencia: los QSA necesitan evidencia continua, no capturas de pantalla tomadas durante la evaluación
- Controles compensatorios sin documentación formal: los QSA no aceptarán controles compensatorios sin documentar
- Tratar las certificaciones de proveedores como tu propio cumplimiento: que tu procesador de pagos cumpla con PCI no te convierte a ti en cumplidor de PCI
Dónde encaja cside
Los requisitos 6.4.3 y 11.6.1 son las dos áreas peor preparadas en la mayoría de las evaluaciones de PCI DSS. cside genera un inventario de scripts continuo, monitorización de integridad, monitorización de cabeceras HTTP e historial de alertas de cambios, exactamente la evidencia que un QSA necesita para dar el visto bueno a esos requisitos.
Para la guía práctica de implementación, consulta cómo cumplir con PCI 6.4.3 y la guía para QSA sobre 6.4.3 y 11.6.1.
Cómo empezar
Si acabas de empezar con PCI DSS, la secuencia es así:
- Identifica tu nivel de comercio y qué SAQ (o RoC) aplica
- Elabora un diagrama de alcance que abarque todos los sistemas que almacenan, procesan o transmiten datos de tarjetas
- Realiza una evaluación de carencias frente a los requisitos aplicables
- Subsana las carencias, priorizando todo lo que bloquee el procesamiento de transacciones
- Completa el SAQ o contrata a un QSA para el RoC
- Mantén evidencia continua de cara al próximo ciclo anual
El cumplimiento es un programa continuo, no un proyecto puntual. Los comercios que lo tratan como algo continuo terminan gastando menos tiempo y dinero por ciclo que los que reconstruyen la evidencia cada año.
