Cumplimiento de PCI DSS para Banca Cloud-Native en 2026
Guía práctica sobre PCI DSS v4.0 para fintechs y bancos cloud-native en España y Latinoamérica: quién debe cumplirlo, los 12 requisitos resumidos, entornos Kubernetes y contenedores, reducción de alcance mediante tokenización y segmentación, SAQ vs ROC, y la interacción con el Banco de España, CNMV y el RGPD.
Qué es PCI DSS y quién debe cumplirlo
PCI DSS - el Payment Card Industry Data Security Standard - es un conjunto global de controles técnicos y operativos para cualquier organización que almacene, procese o transmita datos de tarjetas de pago. Lo mantiene el PCI Security Standards Council, fundado por Visa, Mastercard, American Express, Discover y JCB.
Si tu producto toca un número de cuenta primario (PAN) de cualquier forma, PCI DSS te aplica. Esto incluye emisores de tarjetas, procesadores de pago, bancos adquirentes, plataformas fintech que gestionan transacciones con tarjeta, y cualquier servicio SaaS que esté en el flujo de datos entre el titular de la tarjeta y una red de pago.
Emisores de tarjetas
Cualquier plataforma que emita tarjetas virtuales o físicas y almacene números de tarjeta debe cumplir los requisitos PCI DSS para almacenamiento y transmisión de PAN.
Procesadores de pago
Cualquier intermediario que enrute transacciones con tarjeta entre un comercio y una red de tarjetas - incluidos proveedores BaaS y pasarelas de pago - está en alcance.
Proveedores de servicios
Plataformas cloud, proveedores de servicios gestionados y vendedores SaaS que puedan afectar a la seguridad del entorno de datos de tarjetas de un cliente también están en alcance.
Desde el 31 de marzo de 2025, PCI DSS v4.0.1 es la única versión activa. Los 64 requisitos nuevos o actualizados introducidos en v4.0 son ya obligatorios: el período de transición ha finalizado. En España, los fintechs supervisados por el Banco de España o la CNMV encontrarán que muchos controles PCI DSS se solapan con las expectativas de seguridad IT de sus supervisores y con el RGPD, lo que hace que una estrategia de cumplimiento integrada sea la más eficiente.
El incumplimiento acarrea consecuencias reales: los bancos adquirentes pueden imponer cuotas mensuales de 5.000 a 100.000 EUR por violaciones no resueltas, y una brecha de datos en un entorno no conforme puede desencadenar multas de los esquemas de tarjetas, investigaciones forenses obligatorias y pérdida de derechos de procesamiento de tarjetas.
Hablemos de tu proyecto y veamos cómo podemos lanzar tu Producto bancario digital Juntos
Solicita una demoLos 12 requisitos resumidos para banca
PCI DSS v4.0.1 organiza sus controles en 12 familias de requisitos agrupadas bajo seis objetivos. La siguiente tabla mapea cada requisito con los controles más relevantes para un fintech o banco cloud-native.
| # | Requisito | Qué significa en la práctica |
|---|---|---|
| 1 | Controles de seguridad de red | Firewalls, grupos de seguridad y reglas VPC que aíslan el entorno de datos de titulares de tarjetas (CDE) de otras redes. |
| 2 | Configuraciones seguras | Sin contraseñas predeterminadas; imágenes de SO y contenedores reforzadas; sin puertos o servicios no utilizados. |
| 3 | Proteger los datos de cuenta almacenados | Cifrar los PAN en reposo con AES-256 o equivalente. Hacerlos ilegibles en todo almacenamiento: bases de datos, copias de seguridad, registros. |
| 4 | Proteger los datos del titular en tránsito | TLS 1.2+ para todas las transmisiones; sin protocolos no cifrados dentro del CDE. |
| 5 | Proteger contra software malicioso | Antimalware para sistemas aplicables; escaneo de imágenes de contenedores en pipelines CI/CD. |
| 6 | Desarrollar y mantener sistemas y software seguros | Gestión de parches, SDLC seguro, firewall de aplicaciones web, integridad de scripts de páginas de pago (nuevo en v4.0). |
| 7 | Restringir el acceso según necesidad de negocio | Control de acceso basado en roles (RBAC); principios de mínimo privilegio aplicados a cuentas de servicio y personas. |
| 8 | Identificar usuarios y autenticar accesos | MFA requerida para todos los accesos al CDE, incluidos usuarios no administrativos (nuevo mandato en v4.0). |
| 9 | Restringir el acceso físico a los datos del titular | Controles de medios físicos; registros de visitantes; procedimientos de destrucción. En cloud: atestación de seguridad del CSP. |
| 10 | Registrar y supervisar todos los accesos | Pistas de auditoría para toda actividad del CDE; integración SIEM; almacenamiento de logs a prueba de manipulaciones; retención mínima de 12 meses. |
| 11 | Probar la seguridad regularmente | Escaneos ASV trimestrales, pruebas de penetración anuales, escaneos internos de vulnerabilidades; IDS/IPS donde aplique. |
| 12 | Apoyar la seguridad con políticas organizativas | Política de seguridad documentada, evaluaciones de riesgos, formación en concienciación de seguridad, gestión de proveedores terceros. |
Uno de los cambios conceptuales más significativos en v4.0 es el paso de eventos de cumplimiento anuales a monitorización continua. Los controles que antes se verificaban una vez al año durante una auditoría deben ser ahora demostrablemente continuos. Esto afecta cómo se diseñan el registro de actividad, el escaneo automatizado y las revisiones de acceso.
PCI DSS en entornos cloud-native y de contenedores
La guía tradicional de PCI DSS fue escrita para salas de servidores con rangos de IP fijos. Los entornos cloud-native - clústeres Kubernetes, funciones serverless, contenedores efímeros, configuraciones multi-cuenta - requieren un enfoque diferente para la mayoría de los 12 requisitos. El estándar acomoda esto a través del "Customized Approach" que permite cumplir los objetivos de seguridad mediante controles adecuados a la arquitectura propia.
El modelo de responsabilidad compartida. Cuando se opera en una nube pública, el proveedor cloud (CSP) posee la capa física e hipervisor. Tú posees todo lo que está por encima. Mapear esto claramente es el primer paso del scoping de PCI en cloud.
| Capa | Propietario | Controles PCI |
|---|---|---|
| Infraestructura física e hipervisor | Proveedor cloud (CSP) | Seguridad física, aislamiento de hardware. El CSP proporciona una Attestation of Compliance (AoC). |
| VPCs, grupos de seguridad, políticas IAM | Tu equipo | Segmentación de red, IAM de mínimo privilegio, cifrado en tránsito entre servicios. |
| Clúster Kubernetes, plano de control | Tu equipo | Endurecimiento del clúster, RBAC, estándares de seguridad de pods, escaneo de imágenes, controladores de admisión. |
| Capa de aplicación y lógica de negocio | Tu equipo | mTLS entre servicios, validación de entradas, SDLC seguro, WAF para páginas de pago. |
| Datos en reposo (bases de datos, almacenamiento de objetos) | Tu equipo | Cifrado respaldado por KMS, rotación de claves, registro de accesos, cifrado de copias de seguridad. |
Zero-trust y service mesh. En una arquitectura de microservicios, el perímetro de "castillo y foso" no existe. Cada pod y servicio necesita su propia identidad. Un service mesh como Istio o Linkerd impone TLS mutuo entre todos los servicios, proporciona observabilidad por petición y limita el radio de explosión: si un contenedor se ve comprometido, mTLS impide el movimiento lateral hacia servicios adyacentes. Esto mapea directamente al Requisito 4 (cifrado en tránsito) y apoya el mandato de monitorización continua del Requisito 10.
Policy as Code. Herramientas como Open Policy Agent (OPA) o Kyverno permiten definir controles PCI como código y aplicarlos en el momento de admisión: impedir contenedores con privilegios de root, bloquear balanceadores de carga públicos para servicios internos, exigir procedencia de imágenes desde un registro firmado, detectar deriva de configuración. En entornos bajo RGPD, como ocurre en España, la política como código también puede imponer restricciones de residencia de datos, asegurando que los datos de titulares de tarjetas permanezcan dentro de centros de datos europeos.
Reducción de alcance mediante tokenización y segmentación de red
La forma más efectiva de reducir el coste y la complejidad del cumplimiento PCI es minimizar el tamaño del entorno de datos de titulares de tarjetas. Menos sistemas en alcance significa una auditoría más pequeña, menos evidencias que recopilar y una superficie de ataque menor. Dos técnicas impulsan la reducción de alcance: tokenización y segmentación de red.
Tokenización. Un sistema de tokenización reemplaza el PAN bruto por un valor sustituto (el token) que no tiene relación criptográfica con el original. Los sistemas que solo ven el token - tu CRM, portal de clientes, pipeline de análisis - están fuera del alcance. Los únicos componentes en alcance son el vault de tokenización, el sistema de gestión de claves y cualquier aplicación que llame a la API de detokenización.
Para que un token elimine un sistema del alcance, deben cumplirse dos condiciones: el sistema token-only no debe tener acceso al vault, las claves ni al endpoint de detokenización; y el token debe ser irreversible por el sistema receptor sin una llamada a la API del vault. Si ambas condiciones se cumplen, las directrices de tokenización del PCI Security Standards Council confirman que esos sistemas caen fuera del CDE.
Segmentación de red. La segmentación separa los sistemas que contienen o tocan PANs de los que no lo hacen. En un entorno Kubernetes, esto significa namespaces o node pools dedicados para cargas de trabajo CDE, políticas de red que bloqueen todo el tráfico de namespaces no CDE hacia namespaces CDE (excepto rutas explícitamente permitidas), y VPCs o cuentas separadas para el procesamiento de datos de tarjetas.
Ventajas de la tokenización
- Elimina tiers de aplicación enteros del alcance PCI
- Protege datos incluso si se ve comprometido un sistema no CDE
- Funciona junto al cifrado (complementario, no alternativo)
- Los controles de acceso requeridos son más fáciles de auditar
Ventajas de la segmentación
- Limita el radio de explosión de un incidente de seguridad
- Reduce el número de sistemas sujetos a controles PCI completos
- Permite posturas de seguridad distintas para CDE y no CDE
- Proporciona un límite de auditoría claro para QSA o SAQ
Los errores de scoping son el fallo más común y costoso en las evaluaciones PCI. Un error frecuente es asumir que el cifrado por sí solo elimina un sistema del alcance. El cifrado protege los datos dentro del CDE, pero no contrae el límite del CDE. Solo la tokenización (cuando se implementa correctamente) y la segmentación demostrada eliminan sistemas del alcance. En España, donde los datos de titulares de tarjetas también pueden ser datos personales bajo el RGPD, una brecha desencadena tanto obligaciones de notificación PCI DSS como notificaciones a la Agencia Española de Protección de Datos (AEPD).
SAQ vs ROC, niveles de comercio y el proceso de evaluación
Los requisitos de validación PCI DSS dependen de tu nivel de comercio o proveedor de servicios, que fijan los esquemas de tarjetas (Visa, Mastercard, etc.) según el volumen anual de transacciones y el perfil de riesgo.
| Nivel | Umbral de transacciones | Método de validación |
|---|---|---|
| Nivel 1 | Más de 6 millones de transacciones con tarjeta/año (comercios); más de 300.000/año (proveedores de servicios o tras una brecha) | Report on Compliance (ROC) anual por un Qualified Security Assessor (QSA); escaneos ASV trimestrales |
| Nivel 2 | 1 a 6 millones de transacciones/año | SAQ anual o evaluación liderada por QSA; escaneos ASV trimestrales |
| Nivel 3 | 20.000 a 1 millón de transacciones e-commerce/año | SAQ anual; escaneos ASV trimestrales |
| Nivel 4 | Menos de 20.000 transacciones e-commerce o menos de 1 millón de transacciones totales/año | SAQ anual recomendado; escaneos ASV según lo requiera el adquirente |
SAQ (Self-Assessment Questionnaire). El SAQ es una autodeclaración. Existen varios tipos de SAQ (A, A-EP, B, B-IP, C, C-VT, D, P2PE-HW) que se aplican según cómo se gestionen los datos de tarjetas. SAQ-A cubre comercios que externalizan completamente la gestión de datos de tarjetas. SAQ-D - el más completo - aplica cuando se almacenan, procesan o transmiten datos de tarjetas internamente, y refleja casi el conjunto completo de controles PCI DSS. Completar SAQ-D típicamente lleva seis a doce meses para un fintech desde cero.
ROC (Report on Compliance). El ROC es una auditoría independiente realizada por un QSA o un Internal Security Assessor (ISA) certificado. Es obligatorio para entidades de Nivel 1 y habitual en proveedores de servicios y fintechs de alto volumen. Muchos fintechs persiguen voluntariamente una evaluación ROC antes de que sea técnicamente necesario, porque clientes enterprise y socios de esquemas de tarjetas lo exigen como condición de colaboración. En Latinoamérica, los esquemas de tarjetas locales pueden tener sus propios umbrales de nivel, por lo que siempre conviene verificar con el adquirente local.
Cómo la plataforma de Crassula apoya la reducción de alcance PCI
La plataforma bancaria white-label de Crassula está diseñada para gestionar las partes más sensibles del entorno de datos de tarjetas, permitiendo a los clientes construir productos de tarjetas y pagos sin asumir la carga total de la propiedad del CDE.
Datos de tarjetas tokenizados
Los PAN emitidos en la plataforma Crassula se almacenan y transmiten en forma tokenizada. Las aplicaciones cliente trabajan con tokens, no con números de tarjeta brutos, manteniendo la mayoría de los sistemas cliente fuera del alcance PCI.
Datos cifrados en reposo y en tránsito
Todos los datos de titulares de tarjetas almacenados en la infraestructura de Crassula están cifrados con AES-256. Toda la comunicación entre servicios usa TLS 1.3. La rotación de claves gestionada por KMS es automática.
Segmentación de red
Las cargas de trabajo CDE se ejecutan en namespaces dedicados y reforzados con políticas estrictas de egreso/ingreso. Los tiers de aplicación no CDE están separados a nivel de red y no pueden acceder a los almacenes de datos de tarjetas.
Registro listo para auditoría
Todo acceso a los entornos de datos de titulares de tarjetas se registra con trazas a prueba de manipulaciones, retenidas durante al menos 12 meses. Los clientes reciben exportaciones de logs para sus propios informes de cumplimiento.
Cuando construyes un producto de emisión de tarjetas o de pagos sobre Crassula, heredas los controles de seguridad ya incorporados en la plataforma, en lugar de implementarlos desde cero. Esto reduce el alcance de tu propia evaluación PCI a los puntos de integración entre tu aplicación y las APIs de Crassula. Para equipos que lanzan un primer programa de tarjetas en España o Latinoamérica, este enfoque puede comprimir el tiempo hasta la primera evaluación PCI de 12-18 meses (construyendo tu propio CDE) a 3-6 meses. Contacta al equipo de Crassula para una descripción técnica del límite de responsabilidad compartida y la documentación que necesitará tu QSA.
Preguntas frecuentes
PCI DSS (Payment Card Industry Data Security Standard) es un conjunto de controles de seguridad que aplica a cualquier organización que almacene, procese o transmita datos de tarjetas de pago, incluidos PAN, CVV, PIN y datos de banda magnética. Si tu fintech emite tarjetas, procesa transacciones con tarjeta, o está en el camino de datos entre el titular de la tarjeta y una red de tarjetas, PCI DSS te aplica. Esto incluye emisores de tarjetas, procesadores de pago, facilitadores de pago y proveedores de servicios que hospedan o gestionan datos de tarjetas en nombre de clientes. Si solo pasas datos de tarjeta a un tercero completamente conforme a PCI DSS y no tienes acceso a los números de tarjeta brutos, puedes caer en una categoría SAQ de alcance reducido.
PCI DSS v4.0 (actualmente en v4.0.1, la versión activa) introdujo varios cambios significativos respecto a v3.2.1. Los más importantes para fintechs cloud-native son: la MFA es ahora obligatoria para todos los accesos al CDE, no solo para accesos administrativos; los scripts de páginas de pago deben tener controles de integridad para prevenir el skimming en el lado del cliente (Requisito 6.4); el "Customized Approach" permite a las organizaciones cumplir los objetivos de seguridad mediante controles adecuados a su propia arquitectura; la monitorización continua es explícitamente requerida en lugar de verificaciones puntuales anuales; y los 64 nuevos requisitos introducidos en v4.0 se volvieron obligatorios el 31 de marzo de 2025. No hay grandfathering: desde 2026, todas las evaluaciones usan v4.0.1 como línea base.
El cumplimiento PCI DSS en cloud comienza con entender el modelo de responsabilidad compartida: tu proveedor cloud gestiona la seguridad física (y proporciona un AoC que lo demuestra), mientras que tú posees todo desde la capa de virtualización hacia arriba. Los pasos clave son: definir el límite del CDE con precisión; implementar segmentación de red para aislar el CDE; aplicar cifrado en tránsito con TLS 1.3 y mTLS entre microservicios; gestionar claves de cifrado en un KMS cloud con rotación automática; aplicar RBAC de mínimo privilegio y MFA para todos los accesos al CDE; desplegar policy-as-code (OPA, Kyverno) para evitar configuraciones no conformes en producción; configurar SIEM y registro centralizado con retención de 12 meses; y ejecutar escaneos ASV trimestrales y pruebas de penetración anuales. En España, la superposición con el RGPD significa que las brechas de datos de tarjetas también desencadenan obligaciones de notificación a la AEPD en un plazo de 72 horas.
La tokenización reemplaza un PAN bruto por un token sustituto sin relación matemática con el original. Cualquier sistema que solo vea el token - tu CRM, plataforma de análisis o portal de clientes - está fuera del alcance PCI, siempre que no pueda llamar a la API de detokenización ni acceder al vault de claves. La segmentación de red separa los sistemas CDE de los sistemas no CDE a nivel de red mediante firewalls, límites VPC, políticas de red de Kubernetes y namespaces o cuentas dedicados. Los sistemas del lado no CDE no pueden iniciar conexiones al CDE y quedan por tanto excluidos de la auditoría. Las dos técnicas son complementarias: la tokenización elimina elementos de datos individuales del alcance; la segmentación elimina tiers de red enteros.
Un SAQ (Self-Assessment Questionnaire) es una autodeclaración de que tu entorno cumple PCI DSS. Aplica a comercios de menor volumen y algunos proveedores de servicios, y se completa internamente (aunque las evidencias deben conservarse para respaldar la declaración). Un ROC (Report on Compliance) es una auditoría independiente realizada por un QSA externo o un ISA certificado. Es obligatorio para entidades de Nivel 1 y lo esperan cada vez más los clientes enterprise y los socios de esquemas de tarjetas como condición para hacer negocios. El resultado de una evaluación ROC es un informe técnico detallado más una Attestation of Compliance (AoC). Para la mayoría de los fintechs que gestionan datos de tarjetas directamente, el camino hacia un ROC de proveedor de servicios Nivel 1 es el destino final, aunque muchos empiezan con un SAQ mientras acumulan volumen.
Otras guías
Crea un banco digital en cuestión de días
Solicita una demo