Inglés
Alemán
Español
Francés
Turco
Volver a Guías
Cumplimiento PCI DSS v4.0.1 para Pasarelas de Pago: Guía 2026 para España
PCI DSS v4.0.1 es plenamente exigible desde el 31 de marzo de 2025. Si acepta pago con tarjeta en cualquier forma, está en alcance; la única pregunta es cuán profundo. El tipo de pasarela que use, mucho más que el tamaño de su negocio, decide si el cumplimiento cuesta un cuestionario de 10 minutos o una auditoría anual de 100.000 EUR.
Esta guía explica los 12 requisitos básicos, los cuatro niveles de comerciante, los ocho tipos de SAQ y las decisiones arquitectónicas que reducen su alcance. Con la óptica del mercado español (Redsys, PSD2/SCA, 3DS2) y cómo las pasarelas cripto eliminan el alcance PCI para la pata cripto.
Impulse su negocio aceptando pagos criptográficos
Qué es PCI DSS (y quién lo hace cumplir)
El Payment Card Industry Data Security Standard (PCI DSS) es un estándar contractual del PCI Security Standards Council, un organismo operado conjuntamente por Visa, Mastercard, American Express, Discover y JCB. No es una ley, pero todo comercio que acepte tarjeta está obligado contractualmente a cumplirlo vía su acuerdo con el adquiriente.
La versión vigente es PCI DSS v4.0.1, publicada en 2024 y plenamente exigible desde el 31 de marzo de 2025. Reemplaza la v3.2.1 y añade alrededor de 50 requisitos nuevos.
La ejecución es práctica, no gubernamental: los comercios no conformes afrontan multas de su adquiriente (5.000 a 100.000 EUR al mes), comisiones más altas y, en último término, pérdida del derecho a procesar tarjeta. Tras una brecha, la no conformidad multiplica el daño por demandas, costes forenses y reputacionales. En España, además, una brecha con datos personales implica AEPD y multas RGPD.
Los 12 requisitos básicos de PCI DSS
Organizados en seis objetivos:
| Objetivo | Requisito |
|---|---|
| Construir y mantener una red segura | 1. Controles de seguridad de red (firewalls) |
| 2. Configuraciones seguras en todos los componentes | |
| Proteger los datos del titular | 3. Proteger datos almacenados (cifrado, truncado, tokenización) |
| 4. Proteger datos en transmisión con criptografía fuerte | |
| Programa de gestión de vulnerabilidades | 5. Proteger sistemas contra malware, antivirus actualizado |
| 6. Desarrollar y mantener sistemas y aplicaciones seguras | |
| Control de acceso fuerte | 7. Restringir acceso a datos por necesidad de negocio |
| 8. Identificar y autenticar acceso (MFA obligatorio) | |
| 9. Restringir acceso físico a datos de titular | |
| Monitorizar y probar redes | 10. Registrar y monitorizar todo acceso a datos y recursos |
| 11. Probar seguridad regularmente (escaneos ASV, pentests) | |
| Política de seguridad de información | 12. Mantener política que cubra la seguridad de la información |
v4.0.1 añadió análisis de riesgo dirigido, enfoques personalizados, autenticación más estricta (MFA en todo acceso al CDE) y monitorización explícita de la integridad de scripts de cliente para contrarrestar ataques tipo Magecart.
Niveles de comerciante: de 1 a 4
Cada red de tarjeta fija los niveles PCI por volumen transaccional. Definición de Visa (el resto son similares):
| Nivel | Volumen | Validación |
|---|---|---|
| 1 | > 6M transacciones/año o cualquier comercio que haya sufrido brecha | Auditoría anual in situ por QSA, más escaneos ASV trimestrales |
| 2 | 1M a 6M | SAQ anual (o auditoría QSA), escaneos ASV trimestrales |
| 3 | 20.000 a 1M e-commerce | SAQ anual, escaneos ASV trimestrales |
| 4 | < 20.000 e-commerce o < 1M presencial | SAQ anual, escaneos según política del adquiriente |
Una brecha puede elevar a cualquier comercio a Nivel 1 con independencia del volumen. Los proveedores de servicios (la mayoría de pasarelas) tienen una clasificación de dos niveles propia según procesen, almacenen o transmitan más de 300.000 transacciones al año.
Tipos de SAQ: el documento que más importa
Para los niveles 2 a 4, el cumplimiento se documenta vía el Cuestionario de Autoevaluación (SAQ). Hay varios tipos y difieren enormemente en extensión y coste:
| SAQ | Aplicable a | Preguntas (aprox.) |
|---|---|---|
| A | E-commerce con externalización total a terceros PCI-conformes (redirección o hosted fields) | ~24 |
| A-EP | E-commerce donde su web impacta la seguridad pero no toca datos de tarjeta | ~191 |
| B | Comercios con solo impresoras mecánicas o terminales standalone dial-up | ~41 |
| B-IP | Comercios con terminales PTS standalone sobre IP | ~86 |
| C-VT | Comercios con entrada manual en terminal virtual | ~80 |
| C | Comercios con aplicaciones de pago conectadas a internet, sin e-commerce | ~152 |
| P2PE | Comercios con solución P2PE validada | ~35 |
| D | Todo lo demás - el cajón de sastre. La mayoría de almacenamiento de tarjeta va aquí. | ~329 |
La decisión arquitectónica consiste casi íntegramente en entrar en SAQ-A o A-EP y quedarse ahí. El salto de SAQ-A (24 preguntas) a SAQ-D (329 preguntas) multiplica el coste por 10.
Cómo el tipo de pasarela cambia su alcance PCI
Su alcance PCI lo determina por dónde fluyen los datos de tarjeta:
- Pasarela hospedada (redirección Redsys clásica): los datos de tarjeta nunca tocan sus sistemas. SAQ-A. El caso más sencillo.
- API con hosted fields o drop-in SDK (Stripe ES, Adyen): los datos viajan del navegador a la pasarela por TLS, sin pasar por su servidor. SAQ-A, porque su sitio queda "out of scope" para el dato en sí.
- API con captura en servidor: los datos fluyen por su servidor. SAQ-D completo. Raro en construcciones modernas; casi siempre un error.
- Autoalojada: los datos fluyen por su servidor y pueden almacenarse. SAQ-D completo. Caro de mantener.
- Pasarela cripto: ningún dato de titular. Sin alcance PCI.
Para la mayoría de construcciones modernas, la elección correcta es: API con hosted fields, para cumplir SAQ-A sin perder UX nativa. Cualquier otro camino cede órdenes de magnitud más en coste de cumplimiento de lo que aporta.
Trampas frecuentes que inflan el alcance
Los comercios españoles amplían su alcance PCI sin darse cuenta:
- Operaciones MOTO (mail-order/telephone-order). Personal tecleando PAN en el CRM mete al CRM en alcance.
- Tarjeta por email. Nunca. Use pay-by-link seguro.
- Hosted fields mal configurados. Si su sitio puede inyectar JS en el iframe del PSP, puede acabar en SAQ A-EP en lugar de SAQ-A.
- Scripts de cliente en la página de checkout. Bajo v4.0.1 debe monitorizar la integridad de cualquier script en páginas que toquen datos de pago. Incluye analítica, widgets de chat y tag managers.
- Almacenar los últimos 4 dígitos y caducidad. No está en alcance si se trunca siguiendo las reglas, pero equivocarse le mete dentro.
- Grabaciones de llamada con PAN. El audio almacenado está en alcance. Pause la grabación durante la entrada de tarjeta o use solución de descoping.
El requisito 6.4.3 de v4.0.1 (inventariar, autorizar y monitorizar scripts de cliente en páginas de pago) es el mayor cambio que la mayoría de comercios tiene que asimilar en 2026.
Pasarelas cripto y alcance PCI
Aquí el ángulo cripto se pone interesante desde el coste de cumplimiento. Una pasarela cripto no maneja datos de titular, nunca. No hay PAN, CVV, caducidad, emisor ni red. Por tanto:
- Un comercio que acepta solo cripto tiene alcance PCI DSS cero. Sin cuestionario, sin escaneos, sin QSA.
- Un comercio que acepta tarjeta y cripto mantiene el alcance de la parte tarjeta, pero la pata cripto no suma.
- Los flujos fiat-a-cripto (comprador que paga con tarjeta y la pasarela convierte a cripto) sí tienen alcance PCI en la pata fiat; la pasarela suele absorberlo vía SAQ A-EP o auditoría QSA propia.
Para un negocio cripto puro el ahorro es real: entre 20.000 y 200.000 EUR anuales de gasto PCI dejan de existir. Para un stack mixto, añadir cripto no incrementa el coste PCI.
Este es uno de los motivos silenciosos por los que los raíles cripto son atractivos para bienes digitales, iGaming, forex y otros verticales de alto volumen en España. Menos superficies auditables, menos área de ataque, menos gasto en papeleo. Y, a la vez, MiCA impone sus propios requisitos por el otro lado: PCI se va, pero aparece CNMV.
Checklist práctica de cumplimiento PCI 2026 para España
- Conozca su nivel de comerciante. Pregunte al adquiriente si no está seguro.
- Conozca su SAQ. Diseñe hacia SAQ-A o A-EP siempre que pueda.
- Use pasarela API con hosted fields. SAQ-A sin perder control de UX.
- Inventaríe scripts de cliente en páginas de pago. Documente cada script, monitorice cambios, elimine lo innecesario.
- Imponga MFA en cualquier acceso a sistemas que toquen datos de tarjeta. Obligatorio bajo v4.0.1.
- Ejecute escaneos ASV trimestrales. Escaneos externos por Approved Scanning Vendor.
- Realice pentests anuales. Obligatorios para Niveles 1 y 2, recomendados para todos.
- Mantenga plan de respuesta a incidentes. Pruébelo anualmente. Recuerde la obligación de notificación a AEPD en 72h si hay datos personales.
- Forme al personal anualmente. El requisito 12 es explícito.
- Vigile el alcance de proveedores. Los proveedores de servicios deben ser PCI-conformes; exija su AOC (Attestation of Compliance) por escrito.
- Considere la capa cripto. Añadir una pasarela cripto reduce dependencia de tarjeta y no amplía alcance PCI. Exija al proveedor autorización PSC por la CNMV bajo MiCA.
Impulse su negocio aceptando pagos criptográficos
Comenzar
Preguntas frecuentes
PCI DSS es el estándar de seguridad que todo comercio que acepta tarjeta debe seguir para proteger los datos del titular. Tiene 12 requisitos que cubren seguridad de red, cifrado, control de acceso, monitorización y política. No cumplir arriesga multas y pérdida del derecho a procesar tarjeta.
Sí, siempre, pero el alcance depende de cómo se integre la pasarela. Las hospedadas y las API con hosted fields le mantienen en SAQ-A (alcance mínimo). Las autoalojadas le llevan a SAQ-D (alcance máximo).
SAQ-A es el Cuestionario de Autoevaluación más corto (~24 preguntas). Aplica a comercios e-commerce que externalizan completamente el manejo de datos de titular a terceros PCI-conformes (redirección o hosted fields).
Sí. v4.0.1 es plenamente exigible desde el 31 de marzo de 2025, en sustitución de v3.2.1. Cualquier comercio que valide cumplimiento en 2026 lo hace contra v4.0.1.
Para comercios SAQ-A, de unos cientos a pocos miles de euros al año (SAQ más escaneos ASV). Para SAQ-D, entre 20.000 y 200.000 EUR al año o más según la complejidad, con honorarios QSA para Nivel 1.
No. Los pagos cripto no incorporan datos de titular, así que PCI DSS no aplica a la pata cripto. Los comercios que aceptan solo cripto tienen alcance PCI cero. Lo que sí aplica son las obligaciones MiCA para su PSC autorizado por la CNMV.
Multas del adquiriente (5.000 a 100.000 EUR al mes), mayores comisiones y pérdida del derecho a procesar tarjeta. Tras una brecha con datos personales, se añaden sanciones AEPD bajo RGPD y costes forenses.
Sí, de forma notable si se implementa bien. La tokenización sustituye el PAN por un token inútil fuera de la pasarela, manteniendo sus sistemas fuera del alcance de datos almacenados. Junto a hosted fields para captura, es el camino más corto a SAQ-A.
