PCI DSS 4.0: todo lo que su empresa necesita saber para proteger los datos de tarjeta

Qué es el PCI DSS y quién debe cumplirlo

El PCI DSS — Payment Card Industry Data Security Standard — es un estándar técnico creado en 2004 y mantenido por el PCI Security Standards Council (PCI SSC), un consorcio formado por Visa, Mastercard, American Express, Discover y JCB. Su objetivo es establecer un nivel mínimo de protección para el ecosistema de pagos con tarjeta a escala global.

La obligación de cumplir el PCI DSS no depende del tamaño de la empresa ni de un acto regulatorio específico: nace del contrato con el adquirente (como Cielo, Rede o Stone) y de las reglas de las propias marcas. Cualquier organización que almacene datos de titulares de tarjeta (número PAN, fecha de vencimiento, nombre del titular), que procese transacciones de pago o que transmita esos datos por sus redes está dentro del alcance — ya sea una startup de pagos, un e-commerce, una fintech regulada por el Banco Central, una empresa de SaaS que gestiona cobros o un prestador de servicios que aloja sistemas de terceros.

En la práctica, esto incluye: adquirentes, gateways de pago, facilitadores de pago (PayFacs), prestadores de servicio que manejan datos de tarjeta, operadores de e-commerce con checkout propio y aplicaciones móviles que capturan datos de tarjeta directamente. Tercerizar el procesamiento a una PSP o usar un gateway certificado reduce el alcance, pero no elimina la responsabilidad — la empresa aún debe demostrar cumplimiento sobre el tramo del recorrido que permanece bajo su control.

Los 12 requisitos del PCI DSS explicados

El PCI DSS organiza sus controles en 12 requisitos agrupados en seis objetivos de control. El primer objetivo — construir y mantener una red y sistemas seguros — abarca los requisitos 1 y 2: instalar y mantener controles de seguridad de red (firewall, listas de acceso, segmentación) y aplicar configuraciones seguras a todos los componentes del sistema, eliminando las credenciales predeterminadas de fábrica y las funcionalidades innecesarias.

El segundo objetivo trata de la protección de los datos de cuenta (requisitos 3 y 4). El requisito 3 exige que los datos del titular almacenados se minimicen y, cuando sea necesario, se protejan con cifrado fuerte, hash o truncamiento — estando expresamente prohibido almacenar el código de seguridad (CVV/CVC) tras la autorización. El requisito 4 determina el cifrado en tránsito con protocolos modernos (TLS 1.2 como mínimo, preferentemente TLS 1.3) en toda transmisión de datos de tarjeta por redes públicas.

El tercer objetivo aborda el mantenimiento de un programa de gestión de vulnerabilidades (requisitos 5 y 6): protección de todos los sistemas contra malware con soluciones actualizadas, y desarrollo y mantenimiento de sistemas y software seguros, incluyendo la corrección de vulnerabilidades identificadas en plazos definidos por criticidad y la verificación del código de las aplicaciones orientadas a internet.

El cuarto objetivo cubre los controles de acceso (requisitos 7, 8 y 9). El requisito 7 limita el acceso a los datos de cuenta al principio de menor privilegio. El requisito 8 — profundamente reformulado en la v4.0 — exige identificación única por usuario, autenticación multifactor (MFA) obligatoria para todos los accesos al CDE y contraseñas con complejidad y rotación definidas. El requisito 9 controla el acceso físico a los sistemas que almacenan o procesan datos de tarjeta, incluyendo cámaras, registros de visitantes y protección de medios.

El quinto objetivo trata del monitoreo y las pruebas (requisitos 10 y 11): registro (logging) de todos los accesos a recursos de red y datos de tarjeta con retención mínima de 12 meses, y pruebas regulares de seguridad, incluyendo escaneo de vulnerabilidades trimestral por un ASV aprobado y pruebas de penetración anuales (internas y externas) que cubran la segmentación de red. El sexto objetivo, requisito 12, exige una política de seguridad de la información documentada, mantenida y comunicada a todos los stakeholders, además de un programa formal de gestión de riesgo, gestión de proveedores y respuesta a incidentes.

Niveles de comercio y tipo de validación exigida

Las marcas clasifican a los comercios en cuatro niveles según el volumen anual de transacciones procesadas. El nivel 1 comprende empresas que procesan más de 6 millones de transacciones al año con Visa o Mastercard, o aquellas que ya sufrieron una violación de datos de tarjeta — independientemente del volumen. Para ese grupo, el cumplimiento debe validarse anualmente por un Qualified Security Assessor (QSA), un auditor externo certificado por el PCI SSC, que realiza un Report on Compliance (RoC) presencial y detallado.

Los niveles 2, 3 y 4 atienden a empresas con volúmenes menores — entre 1 y 6 millones, entre 20 mil y 1 millón, y por debajo de 20 mil transacciones anuales, respectivamente. Estos niveles permiten la autoevaluación mediante Cuestionarios de Autoevaluación (SAQ), documentos segmentados por tipo de entorno: el SAQ A cubre a los merchants que tercerizan completamente el procesamiento; el SAQ A-EP incluye e-commerces con redirect; el SAQ D, el más amplio, se aplica a cualquier comercio que no se encuadre en los demás perfiles. Todos los niveles exigen un escaneo trimestral de vulnerabilidades externas por un Approved Scanning Vendor (ASV) y la presentación de un Attestation of Compliance (AoC) al adquirente.

Los prestadores de servicio — empresas que procesan, almacenan o transmiten datos de tarjeta en nombre de terceros — siguen una tabla propia de niveles y, en general, tienen exigencias más rígidas. Un prestador de nivel 1 que atienda más de 300 mil transacciones al año de tarjeta necesita un RoC completo por un QSA. La correcta identificación del nivel y del SAQ adecuado es el primer paso de cualquier programa de cumplimiento.

Novedades del PCI DSS 4.0 y 4.0.1

Publicada en marzo de 2022, la versión 4.0 del PCI DSS fue la mayor revisión desde la creación del estándar. El principal cambio conceptual es la introducción del 'Customized Approach': en lugar de seguir al pie de la letra la implementación prescriptiva de cada control, la organización puede demostrar al QSA que alcanzó el objetivo de seguridad mediante controles alternativos, siempre que documente el enfoque, realice un análisis de riesgo y valide su eficacia. Esto abre espacio para que las empresas con arquitecturas modernas (cloud-native, zero trust, serverless) se adecúen sin forzar controles concebidos para entornos on-premises tradicionales.

En el área de autenticación, el requisito 8 recibió actualizaciones sustanciales: la MFA pasó a ser obligatoria para todos los accesos interactivos al CDE — no solo para los administradores remotos, como preveía la v3.2.1 — y las exigencias de contraseña se endurecieron. El requisito 6 incorporó controles específicos para ataques del lado del cliente (client-side): los scripts de las páginas de pago deben inventariarse, tener su integridad verificada y ser monitoreados para detectar modificaciones no autorizadas — una medida directa contra los ataques de skimming de JavaScript (Magecart).

La versión 4.0.1, lanzada en junio de 2024, trajo correcciones de lenguaje, aclaraciones de alcance y ajustes en requisitos marcados como 'best practice until 31 March 2025'. A partir del 31 de marzo de 2025, todos los requisitos de la v4.0 se volvieron obligatorios. Los plazos de transición de la v3.2.1 a la 4.0 ya expiraron — las empresas que aún validan con base en la versión anterior están técnicamente fuera de cumplimiento.

Alcance, segmentación y relación con la LGPD y el Banco Central

El concepto de alcance (scope) define qué sistemas, redes y procesos deben ser cubiertos por los controles del PCI DSS. El alcance primario es el Cardholder Data Environment (CDE) — los componentes que almacenan, procesan o transmiten datos de cuenta. Además, cualquier sistema que pueda impactar la seguridad del CDE (connected-to o security-impacting) también entra en el alcance, aunque no manipule directamente datos de tarjeta.

La segmentación de red es la principal estrategia para reducir el alcance. Cuando se implementa debidamente — mediante firewalls, VLAN o microsegmentación — aísla el CDE del resto de la infraestructura corporativa, limitando la superficie de ataque y el número de sistemas sujetos a la auditoría. La segmentación debe probarse al menos anualmente y siempre que ocurran cambios significativos en la infraestructura. Una segmentación mal implementada es uno de los hallazgos más comunes en las pruebas de penetración de entornos PCI y puede resultar en la expansión inesperada del alcance durante la auditoría.

En Brasil, el PCI DSS convive con la LGPD (Ley 13.709/2018) y con las regulaciones del Banco Central, especialmente la Resolución CMN 4.893/2021 sobre política de seguridad cibernética para instituciones financieras. Los tres marcos son complementarios: los datos de tarjeta son datos personales financieros, y los controles PCI — minimización, cifrado, control de acceso, notificación de incidentes — atienden simultáneamente las exigencias de la LGPD. Para las fintechs reguladas, el cumplimiento del PCI también contribuye a demostrar al Banco Central la madurez del programa de seguridad cibernética exigido. Un programa integrado que trate los tres marcos de forma unificada es más eficiente y menos oneroso que tres iniciativas paralelas.

Penalidades, riesgos y cómo Decripte apoya su adecuación

El incumplimiento del PCI DSS no genera multas de un órgano gubernamental directamente, pero las consecuencias son igualmente severas. Las marcas pueden aplicar multas mensuales al adquirente — que las traslada al comercio — que varían de US$ 5.000 a US$ 100.000 por mes mientras persista el incumplimiento. En caso de una violación de datos confirmada, la empresa puede perder el derecho de aceptar tarjetas de la marca afectada, asumir los costos de una investigación forense PFI (PCI Forensic Investigator), pagar la reemisión de las tarjetas comprometidas y responder por fraudes en un proceso de contracargo masivo.

Además del impacto financiero inmediato, una violación de datos de tarjeta genera un daño reputacional de larga duración, responsabilidad civil frente a los titulares de los datos (bajo la LGPD) y potencial responsabilidad regulatoria frente al Banco Central para las fintechs. Para los e-commerces, la pérdida de la afiliación equivale a la interrupción total de las ventas en línea.

Decripte ofrece soporte completo al ciclo de adecuación PCI DSS: evaluación de alcance y segmentación, análisis de brechas (gap assessment) frente a los requisitos de la v4.0, pruebas de penetración del entorno de datos de tarjeta realizadas por profesionales certificados, apoyo en la construcción de políticas y evidencias para el QSA, y acompañamiento continuo de la postura de cumplimiento. Atendemos a empresas de todos los tamaños — desde el e-commerce que recién comienza hasta el prestador de servicios de nivel 1 — con planes que se adaptan al volumen de transacciones y a la complejidad del entorno. Para empezar, acceda al plan gratuito de gestión de amenazas o conozca los planes completos de cumplimiento.

Cómo cumplir

1. 1

   1. Determine su alcance y nivel de comercio

   Mapee todos los flujos de datos de tarjeta en su organización — dónde se capturan, cómo circulan, dónde se almacenan o procesan — e identifique todos los sistemas que manejan o pueden influir en el CDE. Con base en el volumen anual de transacciones, determine su nivel (1 a 4) y el tipo de validación exigida (RoC por QSA o SAQ específico). Ese mapeo es la base de todo el programa de cumplimiento.

2. 2

   2. Implemente la segmentación de red para aislar el CDE

   Separe los sistemas del CDE del resto de la red corporativa con firewalls, VLAN o microsegmentación bien documentada. Reduzca al mínimo los flujos autorizados entre el CDE y otras redes, y documente cada regla de firewall con una justificación de negocio. La segmentación correcta puede reducir el alcance del PCI DSS de decenas de sistemas a solo aquellos estrictamente necesarios para el procesamiento de pagos.

3. 3

   3. Aplique configuraciones seguras y gestione las vulnerabilidades

   Elimine las credenciales predeterminadas, deshabilite los servicios innecesarios y aplique un hardening baseline documentado en todos los componentes del CDE. Establezca un proceso formal de gestión de parches con plazos de remediación basados en la criticidad de la vulnerabilidad — las críticas en un máximo de 30 días. Contrate un ASV aprobado para realizar escaneos externos trimestrales y corrija todos los hallazgos antes de presentar los resultados al adquirente.

4. 4

   4. Fortalezca la autenticación y el control de acceso

   Implemente MFA para todos los accesos interactivos al CDE — administradores, desarrolladores, analistas de soporte y cualquier cuenta con acceso remoto. Adopte el principio de menor privilegio: cada usuario o servicio debe tener solo los permisos estrictamente necesarios. Garantice IDs únicos por usuario (nunca cuentas compartidas), políticas de contraseña robustas y un proceso formal de revisión y revocación de accesos.

5. 5

   5. Proteja los datos en reposo y en tránsito

   Evalúe qué datos de tarjeta es realmente necesario almacenar — el CVV nunca debe retenerse tras la autorización. Los datos que deben almacenarse han de protegerse con cifrado fuerte (AES-256) o tokenización. Todas las transmisiones de datos de tarjeta por redes públicas deben usar TLS 1.2 o superior. Inventaríe todos los certificados y monitoree su validez para evitar una expiración inadvertida.

6. 6

   6. Active el logging, el monitoreo y realice pruebas de penetración

   Configure el logging centralizado de todos los accesos, eventos de autenticación y cambios de configuración en el CDE, con una retención mínima de 12 meses. Implemente alertas para eventos sospechosos y revise los registros regularmente. Realice pruebas de penetración anuales que cubran la red externa, la red interna del CDE y — obligatoriamente — la eficacia de la segmentación. Contrate a profesionales que utilicen metodologías reconocidas (PTES, OWASP) y produzcan informes rastreables para la auditoría.

7. 7

   7. Documente, capacite y valide con QSA o SAQ

   Produzca y mantenga actualizadas las políticas de seguridad de la información, los procedimientos operativos y los análisis de riesgo exigidos por el requisito 12. Capacite al menos anualmente a todos los colaboradores que interactúan con datos de tarjeta. Con toda la documentación y las evidencias en mano, complete el SAQ correspondiente a su perfil o sométase a la auditoría por el QSA. Envíe el AoC firmado al adquirente dentro del plazo definido en el contrato.

Preguntas frecuentes