Una guía completa para lograr y mantener el cumplimiento de PCI DSS

Publicado: 16 de diciembre de 2024. Actualizado: agosto de 2026. Revisado por el equipo de Asesoría en Cumplimiento Normativo de Encryption Consulting.

Cuando un cliente entrega su tarjeta, confía en sus sistemas, no solo en su empresa, para que mantengan esos datos seguros. Solo en 2024, las filtraciones de datos expusieron más de 26 mil millones de registros a nivel mundial , y los datos de tarjetas de pago siguen siendo uno de los objetivos más valiosos para los atacantes, ya que se convierten directamente en fraude. PCI DSS existe para cerrar esa brecha entre "procesamos tarjetas" y "podemos demostrar que nuestros sistemas son lo suficientemente seguros como para generar confianza".

Esta guía explica en detalle los requisitos de PCI DSS, con especial atención a los controles criptográficos que suelen generar dificultades en la mayoría de las organizaciones: cómo elegir entre cifrado y tokenización, qué versión de TLS utilizar, cómo cambiaron los requisitos de MFA en 2025 y cómo crear un programa de gestión de claves que supere las pruebas de un auditor. Finaliza con una ruta concreta y numerada para la certificación y las limitaciones que debe conocer antes de comenzar.

¿Qué es el cumplimiento de la norma PCI DSS y a quién se aplica?

El cumplimiento de la norma PCI DSS implica que una organización ha implementado y puede demostrar los controles técnicos y operativos requeridos por el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) para proteger los datos de los titulares de tarjetas a lo largo de su ciclo de vida: captura, transmisión, almacenamiento y eliminación. El Consejo de Estándares de Seguridad PCI (PCI SSC) es un organismo creado en 2006 por Visa, Mastercard, American Express, Discover y JCB para reemplazar el conjunto de programas de seguridad específicos de cada marca de tarjeta que existían anteriormente.

La norma PCI DSS se aplica a cualquier entidad que almacene, procese o transmita datos de titulares de tarjetas o datos de autenticación confidenciales, o que pueda afectar la seguridad de dichos datos, independientemente del volumen de transacciones o el tamaño de la empresa. Tanto una cafetería con un único terminal de pago como una plataforma de comercio electrónico multinacional están sujetas a la normativa; la diferencia radica en la cantidad de trabajo de validación que cada una debe realizar, no en si la norma se aplica o no.

Algunos términos aparecen a lo largo de esta guía y en todas las evaluaciones PCI DSS, por lo que vale la pena definirlos una vez, de forma clara:

• CDE (Entorno de Datos del Titular de la Tarjeta)Las personas, los procesos y la tecnología que almacenan, procesan o transmiten datos de titulares de tarjetas o datos de autenticación confidenciales, además de cualquier sistema conectado que pueda afectar la seguridad de esos datos. Reducir la huella del CDE mediante la segmentación de la red es la principal herramienta para reducir el alcance y el costo de la evaluación.
• QSA (Evaluador de Seguridad Calificado): una persona certificada por el PCI SSC para realizar evaluaciones PCI DSS in situ para organizaciones, normalmente comercios y proveedores de servicios de Nivel 1.
• SAQ (Cuestionario de Autoevaluación): una herramienta de validación que los comercios utilizan para autoinformar sobre el cumplimiento normativo en lugar de someterse a una auditoría completa dirigida por un QSA. El tipo de SAQ aplicable depende de cómo el comercio acepte y gestione los datos de las tarjetas.
• ROC (Informe de Cumplimiento)Informe detallado elaborado por un QSA tras una evaluación in situ, que documenta cómo se probó y validó cada requisito. Obligatorio para comercios de Nivel 1 y la mayoría de los proveedores de servicios.
• AOC (Certificado de Cumplimiento): un resumen firmado que declara el resultado de la evaluación, presentado al banco adquirente o a la marca de pago como prueba formal del estado de cumplimiento. Todos los comercios y proveedores de servicios presentan un AOC, ya sea después de un ROC o un SAQ.

Cumplir con la norma PCI DSS no es una mera formalidad regulatoria. Es una obligación contractual impuesta por el banco adquirente y las marcas de tarjetas a través del acuerdo comercial, y el incumplimiento descubierto tras una infracción suele conllevar multas, un aumento de las comisiones por transacción y, en casos graves, la pérdida total de la capacidad para aceptar pagos con tarjeta.

¿Cuáles son los 12 requisitos de PCI DSS?

La norma PCI DSS v4.0.1 organiza sus controles en 12 requisitos agrupados bajo seis objetivos de control: construir y mantener una red segura, proteger los datos de las cuentas, mantener un programa de gestión de vulnerabilidades, implementar un control de acceso sólido, supervisar y probar las redes periódicamente y mantener una política de seguridad de la información. Cada evaluación, ya sea un cuestionario de autoevaluación (SAQ) o una auditoría QSA completa, se califica según estos 12 requisitos.

1. Instalar y mantener controles de seguridad de redLos cortafuegos y los controles equivalentes segmentan el CDE de las redes no confiables y restringen el tráfico a lo que requieren los procesos de negocio.
2. Aplique configuraciones seguras a todos los componentes del sistema.Las contraseñas, cuentas y configuraciones predeterminadas del proveedor se modifican antes de que cualquier sistema acceda al CDE.
3. Proteger los datos de la cuenta almacenadosLos datos del titular de la tarjeta almacenados se vuelven ilegibles mediante criptografía robusta o tokenización, y su retención se limita a lo que esté justificado por las necesidades del negocio. Se explica en detalle a continuación.
4. Proteja los datos del titular de la tarjeta con criptografía sólida durante la transmisión a través de redes públicas abiertasTLS 1.2 o superior protege todas las transmisiones de datos del titular de la tarjeta a través de Internet u otras redes no confiables. Se explica en detalle a continuación.
5. Proteja todos los sistemas y redes contra software malicioso: Se implementan controles antimalware, se mantienen actualizados y se supervisan activamente en todos los sistemas aplicables.
6. Desarrollar y mantener sistemas y software segurosLa frecuencia de las actualizaciones, las prácticas de desarrollo seguras y el control de cambios evitan que las vulnerabilidades conocidas persistan en producción.
7. Restringir el acceso a los componentes del sistema y a los datos de los titulares de tarjetas según la necesidad de conocerlos por parte de la empresa.Los modelos de acceso con privilegios mínimos limitan quién puede acceder a los datos del titular de la tarjeta únicamente a los roles que lo requieren.
8. Identificar usuarios y autenticar el acceso a los componentes del sistemaCada usuario y administrador está identificado de forma única, y se aplica la autenticación multifactor para acceder al CDE. Esto se explica en detalle a continuación.
9. Restringir el acceso físico a los datos del titular de la tarjeta: Las instalaciones, los medios y los dispositivos que almacenan datos de los titulares de tarjetas están protegidos físicamente y se registra el acceso.
10. Registrar y supervisar todos los accesos a los componentes del sistema y a los datos del titular de la tarjeta.Los registros de auditoría capturan quién accedió a qué y cuándo, y los registros se revisan periódicamente en busca de anomalías.
11. Pruebe periódicamente la seguridad de los sistemas y las redes.Los análisis trimestrales de vulnerabilidades de ASV, las pruebas de penetración anuales y la validación continua del alcance confirman que los controles son realmente efectivos.
12. Apoyar la seguridad de la información con políticas y programas organizacionalesUna política de seguridad de la información documentada y comunicada, junto con un plan de respuesta a incidentes, proporcionan una base de gobernanza a los otros 11 requisitos.

Los requisitos 3, 4 y 8 son donde residen las decisiones de ingeniería criptográfica y de autenticación, y también donde la mayoría de las organizaciones gastan de más en controles inadecuados o dejan una brecha importante sin resolver. El resto de esta guía se centra en estos puntos.

¿Cuáles son los requisitos criptográficos de PCI DSS?

Los requisitos criptográficos de PCI DSS abarcan tres problemas distintos: hacer ilegibles los datos almacenados del titular de la tarjeta (Requisito 3), proteger los datos del titular de la tarjeta durante la transmisión (Requisito 4) y gestionar las claves que garantizan la fiabilidad de ambos controles (Requisitos 3.6 y 3.7). Cada uno tiene su propio modelo de amenazas, y tratarlos como una simple casilla de verificación genérica para "cifrarlo todo" es la forma en que las organizaciones terminan con controles que superan una auditoría pero fallan en la práctica.

Requisito 3: Cifrado frente a tokenización para datos de titulares de tarjetas almacenados

El requisito 3 exige que el número de cuenta principal (PAN) sea ilegible en cualquier lugar donde se almacene, mediante criptografía robusta, truncamiento, tokens de índice con un cifrado seguro o hash unidireccional del PAN completo. En la práctica, esto se reduce a elegir entre cifrar el PAN directamente o reemplazarlo con un token y almacenar el valor real en un lugar completamente fuera del alcance de la normativa.

Modelo de amenazas. Los datos de los titulares de tarjetas almacenados son objetivo de ataques mediante la vulneración de la base de datos, el uso indebido por parte de personal interno, la exposición de copias de seguridad y registros, y el movimiento lateral desde un sistema menos sensible hacia el almacén de datos. El control debe resistir a un atacante que ya tenga acceso de lectura a la capa de almacenamiento, razón por la cual la afirmación de que "la base de datos cuenta con controles de acceso" nunca se considera suficiente por sí sola.

Selección de algoritmos. Cuando se utiliza cifrado, AES-256 es el estándar de facto para entornos PCI DSS; es rápido en hardware, no presenta debilidades criptoanalíticas prácticas conocidas con ese tamaño de clave y el PCI SSC lo reconoce explícitamente como criptografía robusta. Generalmente, se prefiere AES-256-GCM al modo CBC para nuevas implementaciones, ya que proporciona cifrado autenticado, detectando manipulaciones y ocultando los datos, con un rendimiento comparable en las CPU modernas con aceleración AES-NI.

Compromisos entre rendimiento e interoperabilidad. El cifrado mantiene el formato del PAN reversible y en su lugar, lo cual es útil cuando los sistemas posteriores (programas de fidelización, contracargos, facturación recurrente) aún necesitan reconstruir el valor original. La tokenización elimina por completo el PAN real de su entorno, lo que reduce el alcance de PCI DSS, pero depende de que haya una bóveda de tokenización de terceros o centralizada disponible y accesible para cada sistema que necesite destokenizar. La tokenización que preserva el formato evita cambios en las aplicaciones posteriores, pero agrega un viaje de ida y vuelta de red para cada llamada de destokenización, lo cual es importante con un alto volumen de transacciones.

Ejemplos de implementación. Una pasarela de pago normalmente tokeniza el PAN en el momento de la captura y almacena únicamente el token en su propia base de datos, manteniendo la bóveda de tokens como el único sistema dentro del alcance completo de PCI DSS. Un sistema de facturación local heredado que debe conservar el PAN real para los cargos recurrentes suele recurrir al cifrado de datos transparente (TDE) a nivel de columna con AES-256, respaldado por una clave protegida por HSM, ya que reemplazar el PAN con un token alteraría su lógica de facturación.

Dependencia de la gestión de claves. Ninguno de los enfoques es seguro sin los controles de gestión de claves descritos en los requisitos 3.6 y 3.7, que se detallan a continuación. Una columna de base de datos cifrada con AES-256 y con una clave almacenada en un archivo de configuración contiguo no ofrece prácticamente ninguna protección real, y es un hallazgo común en las evaluaciones fallidas.

Factor de decisión	Seleccione el cifrado (AES-256)	Elija tokenización
Los sistemas posteriores necesitan el PAN real (facturación recurrente, contracargos).	Sí, el cifrado permite recuperar el valor.	No, a menos que todos los sistemas puedan llamar al servicio de destokenización.
El objetivo es reducir el alcance de la evaluación PCI DSS.	Los sistemas de almacenamiento de datos cifrados normalmente se mantienen dentro del alcance.	Sí, quitar el PAN real puede dejar los sistemas fuera de alcance.
Alto volumen de transacciones con sensibilidad a la latencia	Descifrado local, mínima latencia añadida.	Se agregó un viaje de ida y vuelta de red por cada llamada de destokenización.
Aplicaciones heredadas que no se pueden rediseñar	Más fácil de adaptar en la capa de almacenamiento.	A menudo requiere cambios en la aplicación para llamar a la bóveda.
Varias unidades de negocio o terceros necesitan acceso	Requiere distribución de claves y control de acceso por consumidor.	Centraliza el control en una sola bóveda, lo que facilita la auditoría.

Requisito 4: TLS para datos del titular de la tarjeta en tránsito

El requisito 4 exige que los datos del titular de la tarjeta estén protegidos con criptografía robusta siempre que se transmitan a través de redes públicas abiertas. Si bien la norma PCI DSS no especifica una versión de protocolo obligatoria en su texto, tanto su propia guía como el boletín " Migración desde SSL y TLS antiguo" del PCI SSC dejan claro que SSL y las versiones antiguas de TLS (TLS 1.0 y 1.1) no cumplen con la definición de criptografía robusta. En la práctica, esto significa que TLS 1.2 es el mínimo exigido, y se recomienda TLS 1.3 para cualquier implementación nueva.

Modelo de amenazas. Los datos en tránsito están expuestos a la interceptación mediante ataques de intermediario (man-in-the-middle), ataques de degradación de protocolo y vulnerabilidades conocidas a nivel de cifrado, como POODLE y BEAST, que atacan específicamente a SSL y las primeras versiones de TLS. Un evaluador que pruebe este control buscará cualquier receptor que aún acepte una versión de protocolo obsoleta, en lugar de simplemente verificar que TLS esté activado.

Guía para la selección de protocolos. Desactive SSL 2.0, SSL 3.0, TLS 1.0 y TLS 1.1 en todos los componentes del sistema que interactúen con el CDE, incluidos los balanceadores de carga internos y las integraciones con sistemas de punto de venta heredados. Configure la preferencia de conjuntos de cifrado para priorizar los conjuntos de confidencialidad directa (basados ​​en ECDHE) sobre el intercambio de claves RSA estático y evite los cifrados simétricos con tamaños de bloque inferiores a 128 bits. El PCI SSC recomienda la norma NIST SP 800-52 como referencia para el endurecimiento de la configuración de TLS.

Compromisos entre rendimiento e interoperabilidad. TLS 1.3 elimina varios intercambios de claves heredados y deja de ser compatible con conjuntos de cifrado conocidos por su debilidad, lo que reduce tanto la latencia de la conexión como el riesgo de errores de configuración. La desventaja es que algunos terminales de punto de venta, SDK de pago y dispositivos integrados más antiguos aún solo negocian TLS 1.2, razón por la cual TLS 1.2 sigue siendo el mínimo práctico en lugar de migrar directamente a TLS 1.3; una actualización gradual que retire el hardware compatible con TLS 1.2 según un cronograma definido es un plan más realista que una transición inmediata.

Ejemplo de implementación. Un patrón común es la terminación TLS en un balanceador de carga o puerta de enlace API configurado para TLS 1.2 como mínimo y TLS 1.3 como preferido, con recifrado (no en texto plano) en el segmento interno entre la puerta de enlace y la capa de aplicación, de modo que los datos del titular de la tarjeta nunca se transmitan sin cifrar, ni siquiera dentro de la propia red de la organización.

Requisitos 3.6 y 3.7: El ciclo de vida de la gestión de claves

La seguridad del cifrado depende de la solidez de las claves que lo respaldan, por lo que la norma PCI DSS dedica dos familias completas de requisitos a la protección de claves y la gestión de su ciclo de vida. El requisito 3.6 describe cómo se protegen las claves durante su uso, y el requisito 3.7 define el ciclo de vida que debe seguir una clave desde su creación hasta su destrucción.

El requisito 3.6 exige que las claves criptográficas utilizadas para proteger los datos de las cuentas almacenadas estén protegidas, ya sea cifradas con una clave de cifrado independiente, almacenadas en un dispositivo criptográfico seguro como un HSM o divididas en componentes gestionados bajo control dual. El acceso a los componentes de la clave en texto plano se restringe al mínimo número de custodios necesarios, y se minimizan las ubicaciones de almacenamiento de claves.

El requisito 3.7 exige procedimientos documentados para todo el ciclo de vida de las claves: generación de claves seguras, distribución segura, almacenamiento seguro, rotación al final de un criptoperiodo definido y retiro, reemplazo o destrucción de las claves comprometidas, retiradas o próximas al final de su criptoperiodo. Asimismo, exige conocimiento compartido y control dual para cualquier operación manual de gestión de claves, prevención de la sustitución no autorizada de claves y una confirmación formal y firmada por los custodios de claves de que comprenden y aceptan sus responsabilidades.

En la práctica, este es el requisito que con mayor frecuencia se subestima. Una política de rotación de claves que existe como documento pero que no se aplica mediante herramientas, o un criptoperiodo que nunca se definió formalmente, es un hallazgo común en las evaluaciones QSA. Centralizar la gestión del ciclo de vida de las claves a través de una plataforma dedicada a certificados y claves como CertSecure Manager proporciona a la organización calendarios de rotación obligatorios, responsabilidad del custodio e informes listos para auditoría, en lugar de una hoja de cálculo para el seguimiento manual de la antigüedad de las claves.

Implementación de HSM para almacenamiento de claves

Un módulo de seguridad de hardware (HSM) es la solución práctica que la mayoría de las organizaciones que cumplen con la normativa satisfacen con el requisito 3.6 sobre "dispositivos criptográficos seguros": un dispositivo dedicado y a prueba de manipulaciones que genera, almacena y utiliza claves criptográficas sin exponerlas en texto plano a la aplicación o al sistema operativo. FIPS 140-3 es el estándar de validación actual con el que se evalúan los HSM, y las QSA exigen cada vez más el almacenamiento de claves validado por FIPS en lugar de bóvedas de claves basadas en software para entornos de alto valor.

Generalmente, las organizaciones eligen entre HSM locales, que ofrecen el máximo control y son comunes donde los requisitos normativos o contractuales lo exigen, y HSM como servicio alojado en la nube , que elimina el costo de capital y la sobrecarga de la ceremonia de claves físicas, al tiempo que proporciona almacenamiento de claves validado por FIPS. Un ejemplo típico de implementación: la bóveda de tokenización de un procesador de pagos almacena su clave maestra de cifrado dentro de un clúster de HSM, y cada llamada de generación o destokenización de tokens se firma o descifra dentro del perímetro del HSM, por lo que la clave en sí nunca sale del hardware validado.

¿Qué requisitos exige la norma PCI DSS para la autenticación multifactor?

La norma PCI DSS v4.0.1 amplió significativamente los requisitos de MFA en el Requisito 8.4, y el cambio más importante, la MFA para cada usuario que accede al entorno de datos del titular de la tarjeta, se ha aplicado completamente desde el 31 de marzo de 2025. Vale la pena distinguir tres subrequisitos relacionados, ya que a menudo se confunden en resúmenes informales:

• Requisito 8.4.1Se requiere la autenticación multifactor (MFA) para todo acceso administrativo al CDE que no sea mediante consola. Este requisito se mantiene desde la versión 3.2.1 de PCI DSS y ha estado vigente durante años.
• Requisito 8.4.2: Se requiere MFA para todo acceso al CDE, no solo para el acceso administrativo. Este es el nuevo control principal en la versión 4.0, que extiende MFA a todos los usuarios en lugar de solo a los administradores, y se volvió obligatorio en Marzo 31, 2025.
• Requisito 8.4.3Se requiere la autenticación multifactor (MFA) para todo acceso remoto a la red que se origine fuera de la red de la entidad y que pueda acceder al CDE o afectarlo, lo que incluye tanto el acceso remoto del personal como el de terceros o proveedores. Este requisito existía antes de la versión 4.0 y se aclaró en lugar de introducirse por primera vez.

El requisito 8.5.1 funciona en conjunto con el 8.4.2 y también se volvió obligatorio el 31 de marzo de 2025: exige que los sistemas de autenticación multifactor (MFA) se implementen de manera que no puedan eludirse excepto mediante un proceso de excepción documentado y con evaluación de riesgos, que se utilicen al menos dos factores de autenticación independientes, que todos los factores deban ser exitosos antes de otorgar el acceso y que la implementación resista los ataques de repetición. Un despliegue de MFA que técnicamente solicite un segundo factor, pero que permita eludirlo mediante la opción "recordar este dispositivo durante 30 días" sin ningún control compensatorio, no cumple con el requisito 8.5.1.

Para la mayoría de las organizaciones, el trabajo práctico consiste en extender la autenticación multifactor (MFA) del grupo de administradores que ya cubría en virtud del apartado 8.4.1 a todos los usuarios de aplicaciones, contratistas e integraciones de terceros que interactúen con el entorno de datos común (CDE), y luego documentar los controles anti-omisión de los que un evaluador solicitará específicamente ver pruebas.

¿Cuál es el camino para lograr el cumplimiento y la certificación PCI DSS?

Para lograr el cumplimiento de la norma PCI DSS, se sigue una secuencia consistente independientemente del nivel del comercio, aunque la profundidad de la validación en cada etapa difiere. A continuación, se describe el proceso paso a paso:

1. Confirme el alcance de su CDE. Mapee cada sistema, proceso y segmento de red que almacene, procese o transmita datos de titulares de tarjetas, o que pueda afectar su seguridad. La segmentación de la red es la forma más eficaz de reducir el alcance y disminuir el costo de la evaluación.
2. Determina tu nivel de comerciante e identifica la ruta de validación correcta. El volumen de transacciones determina si deberá completar un cuestionario de autoevaluación o si se requiere una evaluación presencial dirigida por un QSA, así como el tipo de SAQ aplicable. Consulte la tabla de niveles de cumplimiento a continuación.
3. Realiza una evaluación de brechas con respecto a los 12 requisitos. Pruebe los controles actuales, especialmente el cifrado, la tokenización, la configuración TLS, la cobertura de la autenticación multifactor (MFA) y la gestión de claves, comparándolos con lo que realmente exige la norma PCI DSS, no solo con lo que "parece seguro".
4. Corregir las deficiencias detectadas. Primero, subsane las deficiencias criptográficas (PAN almacenado sin cifrar, versiones obsoletas de TLS, falta de MFA en el acceso a CDE), ya que estos son los hallazgos de mayor gravedad en la mayoría de las evaluaciones, y luego aborde las deficiencias relacionadas con el registro de eventos, el control de acceso y la documentación.
5. Validación formal completa: evaluación SAQ o QSA. Los comerciantes con menor volumen de transacciones completan el SAQ correspondiente; los comerciantes de Nivel 1 y la mayoría de los proveedores de servicios se someten a una evaluación in situ dirigida por un QSA que genera un Informe de Cumplimiento (ROC).
6. Presente la Declaración de Cumplimiento (AOC). El AOC firmado, respaldado por el SAQ o el ROC, se envía a su banco adquirente y, cuando sea necesario, a las marcas de tarjetas, como constancia formal de su estado de cumplimiento.
7. Mantener el cumplimiento continuo. Los análisis trimestrales de vulnerabilidades de ASV, las pruebas de penetración anuales, la revisión continua de registros y un ejercicio anual de confirmación del alcance (Requisito 12.5.2) evitan que los controles se desvíen silenciosamente del cumplimiento entre las evaluaciones formales.

Ese último paso es en el que las organizaciones suelen invertir menos. Un ROC o AOC es una certificación puntual. El cumplimiento de PCI DSS es una disciplina operativa que se mantiene durante todo el año, no un evento anual.

¿Qué nivel de cumplimiento y tipo de SAQ se aplican a su empresa?

La norma PCI DSS clasifica a los comercios en cuatro niveles según el volumen anual de transacciones con tarjeta. El nivel determina cómo se valida el cumplimiento, no si se aplican los 12 requisitos. Todo comercio que maneje datos de tarjetas debe cumplir con los 12 requisitos, independientemente de su nivel.

Nivel	Volumen anual de transacciones	Se requiere validación	Ejemplos típicos
Nivel 1	Más de 6 millón	Auditoría anual in situ de QSA/ISA, ROC, escaneos trimestrales de ASV, prueba de penetración anual, AOC	Grandes plataformas de comercio electrónico, grandes minoristas, procesadores de pagos
Nivel 2	1 a 6 millones	Auditoría anual SAQ (o auditoría QSA si lo requiere el adquirente), escaneos ASV trimestrales, prueba de penetración anual, AOC	Cadenas minoristas medianas, proveedores de servicios regionales
Nivel 3	20,000 a 1 millón (comercio electrónico)	SAQ anual, escaneos ASV trimestrales, AOC	Comerciantes de comercio electrónico en crecimiento, servicios de suscripción especializados
Nivel 4	Menos de 20,000 (comercio electrónico) o hasta 1 millón (todos los canales)	SAQ recomendado o requerido por el adquirente, escaneos según corresponda, AOC	Comercios locales, pequeños cafés, pequeños sitios web

Dentro de los niveles 2 al 4, el tipo específico de SAQ depende de cómo el comercio acepta y gestiona los datos del titular de la tarjeta, no solo de su volumen de transacciones:

• PAE A: para comerciantes que subcontratan completamente el manejo de datos de titulares de tarjetas a un tercero que cumple con la norma PCI DSS, como un sitio de comercio electrónico que redirige a una página de pago externa.
• SAQ B: para comercios que utilizan terminales de pago autónomas con conexión telefónica que no almacenan electrónicamente los datos del titular de la tarjeta.
• SAQC: para comercios que utilizan aplicaciones de pago conectadas a Internet, sin almacenamiento electrónico de datos del titular de la tarjeta.
• SAQD: para comerciantes y proveedores de servicios que almacenan, procesan o transmiten datos de titulares de tarjetas fuera de los escenarios más específicos mencionados anteriormente; este es el SAQ más completo y cubre el conjunto completo de 12 requisitos.

¿Cómo se relacionan los 12 requisitos con los controles prácticos?

La tabla que aparece a continuación relaciona cada requisito con el área de control que rige y una implementación representativa, lo que resulta útil como lista de verificación práctica al definir el alcance de un plan de remediación.

Requisito	Área de control	Implementación representativa
1	Controles de seguridad de la red	Cortafuegos, segmentación de red que aísla el CDE
2	Configuración segura	Líneas base reforzadas, sin credenciales predeterminadas del proveedor.
3	Proteger los datos de la cuenta almacenados	Cifrado o tokenización AES-256, claves respaldadas por HSM
4	Cifrar datos en tránsito	TLS 1.2 como mínimo, TLS 1.3 preferido, sin SSL/TLS antiguo
5	Anti-malware	Protección de endpoints con monitorización activa
6	Desarrollo y parcheo seguros	Control de cambios, SLA de parches definidos, SDLC seguro
7	Control de acceso (información necesaria)	Acceso basado en roles con privilegios mínimos
8	Identificación y autenticación	Identificadores únicos, autenticación multifactor para todo el acceso a CDE (8.4.2/8.5.1)
9	Seguridad física	Acceso controlado a las instalaciones y a los medios de comunicación.
10	Registro y seguimiento	Registros de auditoría centralizados, revisión periódica de registros
11	Prueba de seguridad	Escaneos ASV trimestrales, pruebas de penetración anuales
12	Política y gobernanza de la seguridad	Política documentada, plan de respuesta a incidentes, revisión anual del alcance.

Breve historia de PCI DSS

El estándar PCI DSS surgió a raíz del auge del fraude en el comercio electrónico a finales de la década de 1990. CyberSource informó que las ganancias derivadas del fraude en línea alcanzaron los 15 millones de dólares al final de esa década, y Visa y Mastercard reportaron pérdidas combinadas de más de 750 millones de dólares por robos en línea entre 1988 y 1999. Visa fue la primera en responder con el Programa de Seguridad de la Información del Titular de la Tarjeta (CISP) a principios de la década de 2000, pero la existencia de programas específicos de cada marca, a veces contradictorios, dificultó el cumplimiento normativo para los comercios. Las principales marcas de pago unificaron sus esfuerzos y lanzaron la versión 1.0 del PCI DSS el 1.5 de diciembre de 2004.

• PCI DSS v2.0 (octubre de 2010): Se aclararon las directrices de implementación y se redujo la ambigüedad en las implementaciones inconsistentes de los comerciantes.
• PCI DSS v3.0 (noviembre de 2013): Se ha reforzado la gestión de vulnerabilidades y los requisitos de contraseñas en respuesta a técnicas de piratería informática más sofisticadas.
• PCI DSS v4.0 (marzo de 2022): introdujo requisitos ampliados de autenticación multifactor, opciones de implementación personalizadas y protecciones más sólidas contra el comercio electrónico y el phishing.
• PCI DSS v4.0.1 (junio de 2024)Se trata de una revisión limitada que corrige el formato y aclara la intención de los requisitos existentes, sin añadir ni eliminar requisitos. Se convirtió en la única versión activa una vez que la versión 4.0 dejó de estar disponible el 31 de diciembre de 2024, y sigue siendo el estándar vigente a partir de esta actualización.

El PCI SSC ha confirmado que la futura versión, PCI DSS v5.0 , se encuentra en fase de planificación inicial para 2026, pero aún no se ha fijado una fecha de publicación. Según informes del sector elaborados por la propia comunidad de evaluadores del Consejo, su lanzamiento está previsto para dentro de al menos un año. Las organizaciones deben considerar la versión 4.0.1 como el estándar vigente y estar atentas a la publicación de un borrador formal antes de realizar cambios arquitectónicos en previsión de la versión 5.0.

Limitaciones

El cumplimiento de la norma PCI DSS es necesario pero no suficiente para la seguridad de los pagos, y conviene ser claros sobre lo que no garantiza:

• Conforme no es lo mismo que seguro. Un ROC o AOC refleja los controles vigentes en el momento de la evaluación. Algunas organizaciones han sufrido infracciones poco después de superar una evaluación debido a una desviación en la configuración o a la incorporación de un nuevo sistema al CDE sin haber sido incluido en el alcance de la misma.
• La precisión del alcance depende de que la segmentación esté validada, no solo afirmada. Una de las causas principales más comunes de las filtraciones de datos de tarjetas en organizaciones que, por lo demás, cumplen con la normativa, es la suposición no validada de que un segmento de red está aislado del CDE (Entorno de Datos de Tarjetas).
• Los controles compensatorios requieren rigor, no conveniencia. La norma PCI DSS permite implementar controles compensatorios cuando un requisito no se puede cumplir exactamente como está escrito, pero cada uno necesita un análisis de riesgos documentado y la aprobación de un QSA; si se usan de forma laxa, se convierten en una manera de evitar solucionar la deficiencia subyacente.
• El estándar es específico de cada versión y está en constante evolución. Las directrices de este artículo reflejan la versión 4.0.1 de PCI DSS a fecha de agosto de 2026. Una futura revisión, la versión 5.0, podría modificar los requisitos específicos, los plazos o los umbrales, por lo que las organizaciones deben verificar la conformidad con la norma publicada vigente antes de tomar decisiones sobre su cumplimiento.
• La interpretación de QSA puede variar. Dos evaluadores pueden llegar razonablemente a conclusiones diferentes sobre cuestiones de alcance límite o control compensatorio; involucrar a su QSA desde el principio en una decisión de arquitectura evita tener que rehacer el trabajo más adelante.

¿Qué recomendaría Encryption Consulting?

Nuestra postura, tras realizar evaluaciones de cumplimiento de PCI DSS para organizaciones que van desde comercios regionales hasta bancos nacionales, es que la mayoría de los programas PCI DSS fallan no por la falta de un control, sino porque la capa criptográfica y de gestión de claves se implementó de forma improvisada en lugar de diseñarse desde cero. A continuación, detallamos lo que haríamos, en orden.

Comience con un inventario criptográfico real, no con suposiciones. No puede proteger lo que no ve. Antes de decidir entre cifrado y tokenización, o auditar las configuraciones TLS, cree un inventario preciso de cada conjunto de cifrado, protocolo, certificado y clave en su CDE. Esto coincide directamente con el requisito 12.3.3 sobre la lista de materiales criptográficos (CBOM) , que analizamos en detalle si este requisito específico es su prioridad inmediata.

Centralizamos la gestión del ciclo de vida de claves y certificados. Implementamos CertSecure Manager para brindar a las organizaciones cronogramas de rotación obligatorios, responsabilidad del custodio y visibilidad centralizada de todas las claves y certificados incluidos en el alcance, abordando directamente los hallazgos de los Requisito 3.6/3.7 que aparecen con mayor frecuencia en las evaluaciones fallidas. Para las claves maestras que protegen las bóvedas de tokenización o el cifrado masivo, generalmente recomendamos el almacenamiento validado según FIPS 140-3 a través de HSM locales o HSM como servicio , según la madurez operativa de la organización y la infraestructura existente.

Ampliar la autenticación multifactor (MFA) de forma deliberada, no solo técnica. Cumplir con la letra del requisito 8.4.2 es sencillo; cumplir con la intención de evitar la elusión del requisito 8.5.1 exige mayor rigor. Trabajamos con nuestros clientes para documentar cada excepción legítima a la MFA, vincularla a un control compensatorio y eliminar las elusiones informales que se acumulan con el tiempo.

Trate el cumplimiento normativo como un proceso continuo, no anual. Nuestros servicios de asesoramiento en materia de cumplimiento combinan el trabajo con PCI DSS con el panorama regulatorio más amplio al que se enfrentan muchos de nuestros clientes, incluidos DORA, NIS2 y NIST CSF, de modo que los controles criptográficos creados para PCI DSS se diseñan para cumplir con mandatos superpuestos en lugar de ser rediseñados para cada uno.

Si se encuentra en las primeras etapas de este proceso, el primer paso más efectivo suele ser una evaluación de brechas con respecto a los Requisitos 3, 4 y 8, ya que es ahí donde el costo de cometer errores es mayor y el costo de corregirlos tardíamente es aún peor. Contáctenos para definir el alcance de una.

Conclusión

El cumplimiento de PCI DSS es una disciplina continua de ingeniería y gobernanza basada en 12 requisitos, y los controles criptográficos de los Requisitos 3, 4 y 8 son donde reside la mayor parte del riesgo real y la mayor parte del trabajo. Elegir correctamente entre cifrado y tokenización, aplicar TLS 1.2 o superior en todos los lugares donde viajan los datos del titular de la tarjeta, extender la autenticación multifactor (MFA) a todos los usuarios de CDE según el Requisito 8.4.2 y ejecutar un ciclo de vida de gestión de claves disciplinado según los Requisitos 3.6 y 3.7 permitirá a una organización superar la gran mayoría de las pruebas que realiza un QSA.

Nada de esto reemplaza el trabajo continuo: análisis trimestrales, pruebas de penetración anuales, confirmación anual del alcance y el hábito genuino de considerar el cumplimiento como una postura permanente, no como un evento anual. Si desea una segunda opinión sobre la situación real de su organización con respecto a PCI DSS v4.0.1, nuestros servicios de asesoramiento en cifrado pueden ayudarle a identificar las brechas, priorizar las medidas correctivas y desarrollar un programa que resista evaluaciones y ataques.

Preguntas frecuentes

¿Cuál es la diferencia entre un SAQ y un ROC? Un SAQ (Cuestionario de Autoevaluación) es una herramienta de validación autoadministrada que la mayoría de los comercios de nivel inferior a 1 utilizan para confirmar el cumplimiento sin una auditoría in situ. Un ROC (Informe de Cumplimiento) es el informe detallado que elabora un Evaluador de Seguridad Calificado tras una evaluación formal in situ, requisito para los comercios de nivel 1 y la mayoría de los proveedores de servicios. Ambos documentos respaldan, en última instancia, el mismo documento: la Declaración de Cumplimiento (AOC), que se presenta al banco adquirente.

¿Es PCI DSS un requisito legal o contractual? PCI DSS no es una ley gubernamental; es un requisito contractual que se aplica mediante el acuerdo comercial entre una empresa y su banco adquirente, respaldado por las marcas de tarjetas. El incumplimiento puede acarrear multas, comisiones por transacción más altas y, tras una infracción, responsabilidad por pérdidas por fraude. Por lo tanto, las consecuencias prácticas funcionan de manera muy similar a una obligación legal, aunque el estándar en sí sea un mandato del sector.

¿El cifrado de los datos del titular de la tarjeta los excluye del alcance de PCI DSS? No por sí solo. Un sistema que almacena datos PAN cifrados generalmente permanece dentro del alcance, ya que sigue almacenando datos de la cuenta, incluso de forma protegida. La tokenización, donde el PAN real se reemplaza por completo y se almacena únicamente en una bóveda separada, es lo que normalmente excluye a un sistema del alcance, siempre que el token no pueda revertirse al PAN sin la bóveda.

¿Con qué frecuencia deben realizarse las pruebas de penetración y los análisis de vulnerabilidades? La norma PCI DSS exige análisis de vulnerabilidades externos trimestrales realizados por un proveedor de análisis autorizado (ASV) y, para la mayoría de los comercios, excepto los más pequeños, una prueba de penetración anual que abarque tanto la red como la aplicación. Se requieren análisis adicionales tras cualquier cambio significativo en el entorno de datos de clientes (CDE), como un nuevo sistema, un cambio de red o una actualización importante de la aplicación.

¿Qué sucede si mi organización incumple la normativa tras una brecha de seguridad? Las consecuencias suelen incluir multas impuestas por las marcas de tarjetas a través del banco adquirente, costes obligatorios de investigación forense, responsabilidad por pérdidas por transacciones fraudulentas, aumento de las comisiones por transacción y, en casos graves o reiterados, la revocación de la autorización para procesar pagos con tarjeta. Demostrar el cumplimiento en el momento de la brecha, en lugar de hacerlo posteriormente, influye significativamente en la aplicación de estas consecuencias.

Referencias

• Documento estándar PCI DSS v4.0.1, Consejo de Estándares de Seguridad PCI
• Recién publicado: PCI DSS v4.0.1, Blog de PCI SSC
• Ahora es el momento de adoptar los requisitos futuros de PCI DSS v4.x, Blog de PCI SSC
• Migración desde SSL y TLS temprano, suplemento informativo de PCI SSC
• ¿Define PCI DSS qué versiones de TLS deben usarse? Preguntas frecuentes de PCI SSC
• Biblioteca de documentos PCI SSC