Cada vez que un cliente introduce el número de su tarjeta de credito en tu tienda online, en tu app móvil o en tu terminal físico, se inicia una cadena de responsabilidades de seguridad que afecta a todos los eslabones del proceso: el comercio, la pasarela de pago, el procesador y el banco. Si alguno de esos eslabones fallá, los datos del titular de la tarjeta quedan expuestos y las consecuencias van desde multas millonarias hasta la perdida total de la confianza del cliente.
El estándar que define como proteger esos datos en cada fase del proceso es PCI-DSS (Payment Card Industry Data Security Standard). No es una recomendacion ni una buena práctica opcional: es un requisito contractual impuesto por las marcas de tarjetas que, si no se cumple, puede resultar en sanciones económicas, la prohibicion de aceptar pagos con tarjeta e incluso responsabilidad legal en caso de brecha de datos.
En este artículo explicamos que es PCI-DSS, a quien aplica, cuales son los 12 requisitos de la versión 4.0, que niveles de cumplimiento existen, que medidas de infraestructura necesitas implementar y como EasyDataHost puede ayudarte a cumplir la normativa con una infraestructura preparada para ello.
Que es PCI-DSS
PCI-DSS es el estándar de seguridad de datos de la industria de tarjetas de pago. Fue creado en 2004 por el PCI Security Standards Council (PCI SSC), un organismo fundado conjuntamente por Visa, Mastercard, American Express, Discover y JCB. Su objetivo es establecer un marco comun de requisitos de seguridad que toda entidad que almacene, procese o transmita datos de titulares de tarjetas debe cumplir.
La versión actual es PCI-DSS v4.0, públicada en marzo de 2022, que introduce cambios significativos respecto a la v3.2.1: un enfoque personalizado (customized approach), MFA obligatorio en todos los accesos al entorno de datos de tarjetas, análisis de riesgo dirigido y monitorización de integridad de scripts en paginas de pago. Desde el 31 de marzo de 2025, la v4.0 es la única versión vigente y todos los requisitos futuros deben cumplirse según esta versión.
PCI-DSS no es una ley gubernamental, sino un estándar contractual. Sin embargo, su incumplimiento tiene consecuencias reales: las marcas de tarjetas imponen multas que van desde los 5.000 hasta los 100.000 dolares mensuales, y en caso de brecha de datos, el comercio puede ser responsable de los costes de fraude, la emisión de nuevas tarjetas y la notificacion a los afectados. En muchas jurisdicciones, incluida la Union Europea, el incumplimiento de PCI-DSS puede constituir también una infracción del GDPR.
A Quien Aplica PCI-DSS
PCI-DSS aplica a cualquier entidad que almacene, procese o transmita datos de titulares de tarjetas (cardholder data) o datos sensibles de autenticación. Esto incluye:
- store Comercios (merchants): cualquier negocio que acepte pagos con tarjeta, ya sea online, presencial o por telefono. Desde una pequena tienda online hasta una gran cadena de retail.
- account_balance Proveedores de servicios (service providers): empresas que procesan, almacenan o transmiten datos de tarjetas en nombre de otros. Incluye procesadores de pago, pasarelas, proveedores de hosting, empresas de tokenizacion y cualquier tercero con acceso al entorno de datos de tarjetas.
- sync_alt Procesadores de pago: entidades que gestionan la autorización, liquidacion y compensacion de transacciones con tarjeta entre el comercio y las redes de tarjetas.
- dns Proveedores de infraestructura: empresas de hosting, cloud y colocation que alojan sistemas donde se procesan datos de tarjetas, incluso si no acceden directamente a los datos.
Un error comun es pensar que si usas una pasarela de pago externa (como Stripe o Redsys) ya no necesitas cumplir PCI-DSS. La realidad es que siempre necesitas algun nivel de cumplimiento. Lo que cambia es el alcance (scope): al externalizar el procesamiento de datos de tarjetas reduces significativamente el número de requisitos que te aplican, pero no los eliminas por completo. Como mínimo, deberas completar un cuestionario de autoevaluación (SAQ) y mantener medidas básicas de seguridad en tu entorno.
Los 12 Requisitos de PCI-DSS v4.0
PCI-DSS v4.0 organiza sus 12 requisitos en 6 objetivos de control. Cada requisito se desglosa en subrequisitos detalládos con procedimientos de prueba específicos:
Objetivo 1: Construir y mantener una red segura
- looks_one Requisito 1: Instalar y mantener controles de seguridad de red. Firewalls, segmentacion de red, reglas de acceso entre zonas. Toda conexión entre el entorno de datos de tarjetas (CDE) y redes externas debe estar controlada y documentada.
- looks_two Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema. Eliminar cuentas y contrasenas por defecto, deshabilitar servicios innecesarios, hardening de sistemas operativos y aplicaciones.
Objetivo 2: Proteger los datos del titular de la tarjeta
- looks_3 Requisito 3: Proteger los datos almacenados del titular. Cifrado de datos en reposo, truncamiento del PAN (numero de tarjeta), políticas de retención mínima. Nunca almacenar CVV, PIN ni datos de la banda magnetica.
- looks_4 Requisito 4: Cifrar la transmisión de datos del titular en redes abiertas. TLS 1.2 como mínimo (TLS 1.3 recomendado), certificados válidos, eliminación de protocolos obsoletos como SSL y TLS 1.0/1.1. Lee más sobre cifrado de datos y privacidad.
Objetivo 3: Mantener un programa de gestión de vulnerabilidades
- looks_5 Requisito 5: Proteger todos los sistemas y redes contra software malicioso. Antivirus/antimalware actualizado, detección de amenazas, protección de endpoints.
- looks_6 Requisito 6: Desarrollar y mantener sistemas y software seguros. Parcheo de vulnerabilidades, desarrollo seguro (SDLC), revisión de código, protección de aplicaciones web con WAF.
Objetivo 4: Implementar medidas solidas de control de acceso
- filter_7 Requisito 7: Restringir el acceso a datos del titular según la necesidad de negocio. Principio de mínimo privilegio, control de acceso basado en roles (RBAC).
- filter_8 Requisito 8: Identificar usuarios y autenticar el acceso a componentes del sistema. Cuentas individuales, MFA obligatorio para todo acceso al CDE, políticas de contrasenas robustas. En v4.0, MFA es obligatorio para todos los accesos administrativos, no solo los remotos.
- filter_9 Requisito 9: Restringir el acceso físico a los datos del titular. Control de acceso a centros de datos, camaras, registros de visitantes, destruccion segura de medios.
Objetivo 5: Monitorizar y probar las redes regularmente
- format_list_numbered Requisito 10: Registrar y monitorizar todos los accesos a los recursos de la red y los datos del titular. Logging centralizado, retención de logs durante al menos 12 meses, revisión periódica de logs, alertas en tiempo real.
- format_list_numbered Requisito 11: Probar regularmente los sistemas y procesos de seguridad. Escaneos de vulnerabilidades trimestrales (ASV), tests de penetracion anuales, monitorización de integridad de ficheros, detección de puntos de acceso wireless no autorizados.
Objetivo 6: Mantener una política de seguridad de la información
- format_list_numbered Requisito 12: Soportar la seguridad de la información con políticas y programas organizacionales. Política de seguridad documentada, formacion del personal, gestión de incidentes, evaluación de riesgos anual, gestión de proveedores de servicios.
Niveles de Cumplimiento
Las marcas de tarjetas clasífican a los comercios en cuatro niveles según su volumen anual de transacciones con tarjeta. Cada nivel tiene requisitos de válidación diferentes:
| Nivel | Transacciones anuales | Válidación requerida |
|---|---|---|
| Nivel 1 | > 6 millones | Auditoria anual por QSA (Qualified Security Assessor) + escaneo ASV trimestral |
| Nivel 2 | 1 - 6 millones | SAQ (Self-Assessment Questionnaire) anual + escaneo ASV trimestral |
| Nivel 3 | 20.000 - 1 millon (e-commerce) | SAQ anual + escaneo ASV trimestral |
| Nivel 4 | < 20.000 (e-commerce) o < 1 millon (otros) | SAQ anual + escaneo ASV trimestral (recomendado) |
Cualquier comercio que haya sufrido una brecha de datos es automáticamente reclasíficado a Nivel 1, independientemente de su volumen de transacciones. Los proveedores de servicios tienen su propia clasíficacion: Nivel 1 (más de 300.000 transacciones anuales) y Nivel 2 (menos de 300.000).
Requisitos Clave y Como Cumplirlos
La siguiente tabla resume los requisitos con mayor impacto en la infraestructura y las medidas concretas para cumplirlos:
| Requisito | Descripción | Medida de infraestructura |
|---|---|---|
| Segmentacion de red | Aislar el CDE del resto de la red | VLANs dedicadas, firewalls entre zonas, microsegmentacion |
| Cifrado en tránsito | Proteger datos en redes abiertas | TLS 1.2+ en todas las conexiones, certificados gestionados, HSTS |
| Cifrado en reposo | Proteger datos almacenados | AES-256, gestión de claves con HSM, cifrado de volumen completo |
| Tokenizacion | Sustituir datos reales por tokens | Pasarela de tokenizacion, reduccion del scope PCI |
| WAF | Proteger aplicaciones web | Web Application Firewall con reglas OWASP, protección contra inyeccion y XSS |
| IDS/IPS | Detectar y prevenir intrusiones | Sistemas de detección/prevencion de intrusiones en el perimetro del CDE |
| Logging centralizado | Registrar y monitorizar accesos | SIEM, retención 12 meses, alertas en tiempo real, logs inmutables |
Infraestructura para PCI-DSS
Cumplir PCI-DSS no es solo cuestion de políticas y procedimientos: requiere una infraestructura técnica que soporte los controles de seguridad exigidos. Los pilares fundamentales de una infraestructura PCI-compliant son:
- lan Segmentacion de red: el entorno de datos de tarjetas (CDE) debe estar completamente aislado del resto de la red. Esto reduce el alcance de la auditoria PCI y limita la exposicion en caso de brecha. Se implementa con VLANs dedicadas, firewalls stateful entre zonas y reglas de acceso estrictas.
- shield Firewalls y WAF: firewalls de red para controlar el trafico entre el CDE y las redes externas, y un Web Application Firewall (WAF) para proteger las aplicaciones de pago contra ataques OWASP Top 10 (inyeccion SQL, XSS, CSRF).
- lock Cifrado: TLS 1.2 o superior para todas las comunicaciones que atraviesen redes públicas. Cifrado AES-256 para datos en reposo. Gestión de claves criptográficas con HSM o soluciones equivalentes. Más detalles en nuestro artículo sobre cifrado de datos y privacidad.
- token Tokenizacion: sustituir los datos reales de la tarjeta por tokens sin valor fuera del sistema de pago. La tokenizacion es la estrategia más efectiva para reducir el scope PCI, ya que los sistemas que solo manejan tokens quedan fuera del alcance de la auditoria.
- monitoring IDS/IPS y logging: sistemas de detección y prevencion de intrusiones en el perimetro del CDE, combinados con logging centralizado con retención mínima de 12 meses, alertas en tiempo real y revisión periódica de logs.
Concepto clave:
La segmentacion de red es la medida con mayor impacto en el cumplimiento PCI-DSS. Al aislar el CDE, reduces drasticamente el número de sistemas que entran en el alcance de la auditoria, lo que simplifica el cumplimiento y reduce costes.
PCI-DSS en la Nube
Cumplir PCI-DSS en entornos cloud introduce el concepto de responsabilidad compartida. El proveedor de cloud es responsable de la seguridad de la infraestructura física (centro de datos, red, hipervisor), mientras que el cliente es responsable de la seguridad de sus sistemas, aplicaciones y datos dentro del cloud.
Para que el cumplimiento PCI en la nube sea viable, es fundamental elegir un proveedor que ya cumpla con los requisitos de infraestructura PCI-DSS y que pueda proporcionar un Attestation of Compliance (AOC) o documentación equivalente. Esto no exime al comercio de su responsabilidad, pero reduce significativamente el esfuerzo necesario al heredar los controles del proveedor.
La combinacion de tokenizacion con un proveedor de cloud PCI-compliant es la estrategia más efectiva para minimizar el scope. Si los datos reales de la tarjeta nunca tocan tu infraestructura cloud (porque la pasarela de pago los tokeniza antes), el alcance de tu auditoria PCI se reduce al SAQ más básico.
Novedades de PCI-DSS v4.0
La versión 4.0 introduce cambios significativos respecto a la v3.2.1. Las organizaciones deben adaptarse a estos nuevos requisitos:
- tune Enfoque personalizado (Customized Approach): permite a las organizaciones cumplir los objetivos de seguridad mediante controles alternativos, siempre que demuestren que cumplen la intencion del requisito. Esto ofrece mayor flexibilidad a empresas con arquitecturas innovadoras.
- passkey MFA en todas partes: la autenticación multifactor es ahora obligatoria para todos los accesos al CDE, no solo para accesos remotos. Esto incluye accesos desde la red interna y accesos administrativos a cualquier componente del entorno.
- target Análisis de riesgo dirigido (Targeted Risk Analysis): sustituye la frecuencia fija de algunos controles por un análisis de riesgo que determina la frecuencia adecuada para cada organización. Por ejemplo, la frecuencia de revisión de logs o de escaneos de vulnerabilidades puede ajustarse según el nivel de riesgo.
- code Integridad de scripts en paginas de pago: nuevo requisito que exige monitorizar la integridad de todos los scripts que se ejecutan en paginas de pago del navegador. Esto responde al aumento de ataques de tipo Magecart/web skimming que inyectan scripts maliciosos en paginas de checkout.
Errores Comunes en el Cumplimiento PCI-DSS
Estos son los errores que con más frecuencia detectan los auditores QSA y que pueden resultar en incumplimiento o, peor aun, en una brecha de datos:
- dangerous Almacenar el CVV/CVC: los datos sensibles de autenticación (CVV, PIN, datos de banda magnetica) nunca deben almacenarse después de la autorización, ni siquiera cifrados. Es la violacion más grave y la que acarrea las multas más altas.
- dangerous Red plana sin segmentacion: tener el CDE en la misma red que el resto de sistemas de la empresa. Sin segmentacion, toda la red entra en el alcance de la auditoria PCI y cualquier sistema comprometido puede acceder a los datos de tarjetas.
- dangerous Ausencia de logging: no registrar los accesos al CDE o no retener los logs el tiempo suficiente. Sin logs, es imposible detectar una brecha a tiempo y reconstruir que paso.
- dangerous TLS obsoleto: seguir usando TLS 1.0 o 1.1, que tienen vulnerabilidades conocidas. PCI-DSS exige TLS 1.2 como mínimo desde hace años.
- dangerous Cuentas de administrador compartidas: usar una única cuenta root o admin compartida entre varios miembros del equipo. PCI-DSS exige que cada persona tenga su propia cuenta individual con MFA.
EasyDataHost para PCI-DSS
EasyDataHost ofrece infraestructura preparada para cumplir los requisitos técnicos de PCI-DSS. Nuestro centro de datos en Madrid cumple con los requisitos de seguridad física (Requisito 9), y nuestra infraestructura de red, cloud, colocation y servicios gestionados fácilita el cumplimiento de los requisitos de red, cifrado, acceso y monitorización.
- check_circle Segmentacion de red: VLANs dedicadas, firewalls gestionados y microsegmentacion para aislar tu CDE.
- check_circle Cifrado de almacenamiento: discos cifrados con AES-256, gestión de claves segura.
- check_circle WAF e IDS/IPS: protección perimetral gestionada contra amenazas OWASP y ataques de red.
- check_circle Logging y monitorización: logging centralizado con retención de 12+ meses y alertas en tiempo real.
- check_circle Marco de compliance: infraestructura alineada con ISO 27001, ENS Alto y GDPR, fácilitando el cumplimiento PCI-DSS.
- check_circle Datos en España: centro de datos Tier III+ en Madrid, soberania de datos en la UE. Ideal para el sector financiero.
Conclusión
PCI-DSS no es opcional para ninguna entidad que participe en el ecosistema de pagos con tarjeta. La versión 4.0 refuerza los requisitos con MFA universal, análisis de riesgo dirigido e integridad de scripts, y exige que las organizaciones adopten un enfoque proactivo y continuo de la seguridad, no una mera lista de controles que se revisan una vez al ano.
- arrow_right PCI-DSS aplica a toda entidad que almacene, procese o transmita datos de tarjetas de pago.
- arrow_right Los 12 requisitos cubren red, datos, vulnerabilidades, acceso, monitorización y políticas.
- arrow_right La segmentacion de red y la tokenizacion son las estrategias más efectivas para reducir el scope.
- arrow_right PCI-DSS v4.0 exige MFA universal, análisis de riesgo dirigido e integridad de scripts en paginas de pago.
- arrow_right EasyDataHost ofrece infraestructura PCI-ready con segmentacion, cifrado, WAF y monitorización.
Si necesitas infraestructura preparada para cumplir PCI-DSS, contacta con nuestro equipo para disenar la arquitectura que mejor se adapte a tus requisitos de cumplimiento.