PCI DSS 4.0: qué es, a quién aplica y cuáles son sus 12 requisitos

Si tu empresa acepta pagos con tarjeta, tarde o temprano tu banco adquirente o tu pasarela de pago te pedirá demostrar que cumples PCI DSS. No es una ley ni una norma ISO, sino un estándar contractual de la industria de tarjetas, y su versión 4.0.1 es la vigente. Esta guía explica qué exige, cómo se valida y qué suelen pasar por alto comercios y empresas de software en España.

PCI DSS Pagos con tarjeta Ciberseguridad Publicado: 8 min de lectura

Qué es PCI DSS y quién lo gestiona

PCI DSS, Payment Card Industry Data Security Standard, es un conjunto de requisitos técnicos y organizativos para proteger los datos de cuentas de tarjetas de pago. Lo publica el PCI Security Standards Council, fundado por las grandes marcas de tarjetas. El Council mantiene el estándar, pero no impone sanciones: son las marcas de tarjetas y los bancos adquirentes quienes exigen el cumplimiento a través de los contratos con comercios y proveedores.

La versión 4.0 se publicó en 2022 y la 4.0.1, una revisión limitada que aclara textos y corrige erratas, en junio de 2024. La versión 3.2.1 se retiró en marzo de 2024 y la 4.0 a finales de 2024, de modo que hoy las evaluaciones se hacen con la 4.0.1. Además, los requisitos marcados como de fecha futura, que eran buenas prácticas hasta entonces, son obligatorios desde el 31 de marzo de 2025.

A quién se aplica

PCI DSS se aplica a cualquier entidad que almacene, procese o transmita datos de titulares de tarjeta o datos sensibles de autenticación, y también a quien pueda afectar a la seguridad de ese entorno. No depende del tamaño de la empresa: un pequeño comercio electrónico también está sujeto, aunque su forma de demostrarlo sea más sencilla.

  • Comercios físicos y online que aceptan tarjetas, incluso si externalizan el pago.
  • Proveedores de servicios: pasarelas de pago, procesadores, plataformas de comercio electrónico, alojamiento o servicios gestionados que afectan al entorno de tarjetas.
  • Empresas de software y SaaS que alojan páginas de pago o integran formularios de captura de datos.
  • Centros de atención telefónica que toman datos de tarjeta por teléfono.

Los 12 requisitos de PCI DSS 4.0.1

Los requisitos se agrupan en seis objetivos y se desglosan en cientos de subrequisitos con procedimientos de prueba. Estos son los doce principales:

  • 1. Instalar y mantener controles de seguridad de red.
  • 2. Aplicar configuraciones seguras a todos los componentes del sistema.
  • 3. Proteger los datos de cuenta almacenados.
  • 4. Proteger los datos de titulares con criptografía robusta durante la transmisión por redes abiertas y públicas.
  • 5. Proteger todos los sistemas y redes frente a software malicioso.
  • 6. Desarrollar y mantener sistemas y software seguros.
  • 7. Restringir el acceso a componentes del sistema y datos de titulares según la necesidad de conocer.
  • 8. Identificar a los usuarios y autenticar el acceso a los componentes del sistema.
  • 9. Restringir el acceso físico a los datos de titulares.
  • 10. Registrar y supervisar todo acceso a componentes del sistema y datos de titulares.
  • 11. Probar periódicamente la seguridad de sistemas y redes.
  • 12. Respaldar la seguridad de la información con políticas y programas organizativos.

Compruebe su preparación gratis

10–15 minutos, sin registro: puntuación de preparación, informe de brechas y recomendaciones de IA.

Qué cambió en marzo de 2025

Muchas empresas validaron la versión 4.0 antes de que los requisitos de fecha futura fueran obligatorios, y ahora descubren en su siguiente evaluación que les faltan controles. Estos son algunos de los más relevantes:

  • Autenticación multifactor para todo acceso al entorno de datos de titulares, no solo para el acceso remoto (requisito 8.4.2).
  • Contraseñas de al menos 12 caracteres cuando se usan como factor de autenticación, salvo limitaciones técnicas del sistema (requisito 8.3.6).
  • Inventario y autorización de los scripts que se ejecutan en las páginas de pago (requisito 6.4.3).
  • Mecanismo de detección de cambios y manipulaciones en páginas de pago (requisito 11.6.1).
  • Revisión automatizada de registros de auditoría (requisito 10.4.1.1).
  • Protección contra phishing para el personal (requisito 5.4.1).
  • Análisis de riesgos específicos para justificar la frecuencia de ciertos controles (requisito 12.3.1).

Cómo se valida el cumplimiento: SAQ, QSA y niveles

La forma de validación la decide tu banco adquirente o la marca de tarjeta, según el nivel de comerciante o de proveedor de servicios, que depende sobre todo del volumen anual de transacciones. Las organizaciones de mayor volumen necesitan un Informe de Cumplimiento (ROC) elaborado por un evaluador cualificado, QSA, o por un auditor interno certificado, ISA, cuando la marca lo permite. El resto suele presentar un cuestionario de autoevaluación, SAQ, junto con una Declaración de Cumplimiento, AOC.

Existen varios tipos de SAQ según cómo aceptas pagos. El SAQ A se aplica a comercios de comercio electrónico que externalizan por completo la página de pago, el SAQ A-EP cuando tu web controla parte del proceso, y el SAQ D es el más extenso, para quien almacena datos o no encaja en otros tipos. Elegir mal el SAQ es uno de los errores más comunes: confirma siempre con tu adquirente cuál te corresponde. Además, los sistemas expuestos a Internet suelen requerir escaneos trimestrales de vulnerabilidades por un proveedor aprobado, ASV.

Cómo reducir el alcance y el esfuerzo

La mejor estrategia de cumplimiento es tener la menor cantidad posible de datos de tarjeta en tus sistemas. Cada sistema que toca esos datos, o que se conecta a uno que lo hace, entra en el alcance.

  • Usa páginas de pago alojadas o iframes del proveedor de pagos para no recibir el número de tarjeta en tus servidores.
  • Tokeniza: guarda tokens del proveedor en lugar de números de tarjeta para pagos recurrentes.
  • Segmenta la red para aislar el entorno de tarjetas del resto de sistemas.
  • Nunca almacenes datos sensibles de autenticación, como el CVV, después de la autorización.
  • Pide a tus proveedores de servicios su AOC y documenta qué requisitos cubre cada uno en una matriz de responsabilidades.

Errores frecuentes y relación con otros marcos

Entre los fallos más habituales están no tener un inventario de dónde se encuentran los datos de tarjeta, grabaciones de llamadas que capturan números completos, scripts de marketing cargados en la página de pago sin control, y SAQ firmados sin evidencias que los respalden. Recuerda que firmar una AOC es una declaración formal ante tu adquirente.

PCI DSS no es una certificación ISO, pero se solapa con ISO/IEC 27001 en gestión de accesos, registros, gestión de vulnerabilidades y políticas. Una empresa con un SGSI maduro tiene buena parte del trabajo organizativo hecho, aunque PCI DSS es mucho más prescriptivo en lo técnico. Y si tratas datos personales, el RGPD sigue aplicándose en paralelo. Una autoevaluación gratuita en baltum.ai muestra la madurez general de tu seguridad de la información y qué brechas cerrar primero.

Preguntas frecuentes

¿PCI DSS es obligatorio por ley en España?

No es una ley. Es una obligación contractual que imponen las marcas de tarjetas y los bancos adquirentes a quienes aceptan o procesan pagos con tarjeta. Las consecuencias de no cumplir dependen de esos contratos y pueden incluir penalizaciones o la pérdida de la posibilidad de aceptar tarjetas.

¿Existe un certificado PCI DSS?

Formalmente no hay una certificación como en ISO. Se valida el cumplimiento mediante un SAQ con su AOC o un ROC elaborado por un QSA. Algunos proveedores hablan de estar certificados, pero lo que tienen es una evaluación de cumplimiento válida para un periodo.

Si uso una pasarela de pago, ¿ya no tengo que cumplir?

Reduces mucho el alcance, pero no desaparece. Sigues teniendo que cumplir los requisitos que aplican a tu forma de integración, normalmente mediante un SAQ, y asegurarte de que la página o el script que redirige al pago no puede ser manipulado.

¿Con qué frecuencia hay que validar PCI DSS?

La validación es anual, y los escaneos ASV, cuando se requieren, son trimestrales. Además, muchos controles deben ejecutarse de forma continua o con la frecuencia definida en el propio estándar o en tu análisis de riesgos específico.

¿Qué es el CVV y por qué no se puede guardar?

El código de verificación de la tarjeta forma parte de los datos sensibles de autenticación. PCI DSS prohíbe almacenarlos después de la autorización, incluso cifrados, porque permitirían realizar transacciones fraudulentas.

Compruebe su preparación gratis

10–15 minutos, sin registro: puntuación de preparación, informe de brechas y recomendaciones de IA.

Este artículo es informativo y no constituye asesoramiento jurídico. baltum.ai es un software independiente, no un organismo de certificación.