PCI DSS 4 México requisitos es una búsqueda común cuando una organización procesa, almacena o transmite datos de tarjeta y necesita confirmar qué cambió frente a PCI DSS 3.2.1, cuáles son los 12 dominios y qué fechas aplican para su ruta de cumplimiento. En esta guía resumimos los cambios clave y cómo reducir el alcance del CDE usando un enfoque Zero Trust.
Desde el 31 de marzo de 2024, PCI DSS versión 4.0 es el estándar vigente. La versión 3.2.1 quedó retirada y toda organización que procese, almacene o transmita datos de tarjetas de pago debe demostrar cumplimiento ante esta versión. En México, esto aplica a bancos, retailers, aseguradoras, e-commerce y cualquier entidad con un entorno de datos de tarjetahabiente (CDE) activo.
¿Qué cambia con PCI DSS 4.0?
La versión 4.0 introduce tres cambios de fondo respecto a 3.2.1:
Enfoque en outcomes
PCI DSS 4.0 permite demostrar cumplimiento mediante “enfoques personalizados” siempre que el resultado de seguridad sea equivalente, no solo checklists prescriptivos.
Autenticación reforzada
MFA es ahora obligatorio para todo acceso al CDE, no solo para accesos remotos. Los requerimientos 8.4 y 8.5 son los más impactados en implementaciones existentes.
Seguridad en e-commerce
El requerimiento 6.4 ahora exige gestión explícita de scripts en páginas de pago para mitigar ataques tipo Magecart/skimming. Afecta directamente a tiendas en línea.
Los 12 dominios de PCI DSS 4.0: qué exige cada uno
Dominio 1 y 2 — Controles de red y configuraciones seguras
Toda organización debe instalar y mantener controles de seguridad de red que protejan el CDE del tráfico no autorizado. Esto incluye firewalls, segmentación de red, y configuraciones documentadas y revisadas al menos cada seis meses. Un firewall administrado con política de revisión periódica cubre estos dominios operativamente.
Dominio 3 — Proteger los datos almacenados
El número primario de cuenta (PAN) debe almacenarse de forma cifrada o tokenizada. Este dominio es responsabilidad directa del equipo de desarrollo y arquitectura del cliente. Un MSSP puede asesorar en el diseño pero no sustituye la implementación de cifrado en la capa de aplicación.
Dominio 4 — Proteger datos en tránsito
TLS 1.2 o superior es obligatorio para toda transmisión de datos de tarjeta sobre redes públicas. La inspección de tráfico SSL por parte de una plataforma Zero Trust permite verificar que ningún enlace transmita datos sin cifrado adecuado, y detectar exfiltración encubierta en canales HTTPS.
Dominio 5 — Protección contra malware
Todos los sistemas del CDE deben contar con mecanismos de detección y prevención de malware actualizados. Un EDR/XDR de generación actual con respuesta automatizada cubre este dominio; la actualización periódica de firmas y comportamientos ya no es suficiente por sí sola.
Dominio 6 — Sistemas y software seguros
Parches críticos de seguridad deben aplicarse en un plazo máximo de un mes desde su publicación. Las aplicaciones de pago deben evaluarse contra vulnerabilidades conocidas (OWASP Top 10) al menos anualmente o tras cambios significativos. La gestión continua de vulnerabilidades y el escaneo de aplicaciones web son controles específicos de este dominio.
Dominio 7 y 8 — Control de acceso e identidad
El acceso al CDE debe basarse en necesidad de negocio (“need to know”). PCI DSS 4.0 exige MFA para todo acceso al entorno de datos de tarjeta, cuentas individuales (sin cuentas compartidas), y revisión periódica de cuentas activas. Zero Trust Network Access reduce el perímetro del CDE al verificar identidad y contexto antes de cada conexión.
Dominio 9 — Acceso físico
Controles de acceso físico a servidores, lectores de tarjeta y áreas donde se procesen datos. Este dominio queda dentro del alcance operativo del cliente; QMA puede asesorar en su diseño pero no opera controles físicos.
Dominio 10 — Registro y monitoreo de accesos
Todos los accesos a recursos del CDE deben registrarse y los logs deben conservarse durante doce meses (tres meses disponibles de forma inmediata). El monitoreo de eventos de seguridad 24/7 con correlación SIEM cubre este dominio y genera la evidencia auditable que el QSA verificará.
Dominio 11 — Pruebas periódicas de seguridad
Escaneos de vulnerabilidades trimestrales (por un ASV aprobado para los externos), pruebas de penetración anuales, y detección de puntos de acceso inalámbricos no autorizados. La gestión continua de vulnerabilidades automatiza el ciclo de detección-priorización-remediación requerido en este dominio.
Dominio 12 — Políticas y programa de seguridad de la información
La organización debe mantener una política de seguridad de la información documentada, revisada anualmente, con un programa de concientización para todo el personal que accede al CDE. GRC operativo e ISO 27001 son marcos complementarios que estructuran este dominio.
Fechas clave para su organización en México
| Fecha | Evento | Impacto |
|---|---|---|
| Marzo 2022 | Publicación de PCI DSS 4.0 | Período de transición de dos años |
| 31 marzo 2024 | Retiro de PCI DSS 3.2.1 | PCI DSS 4.0 es el único estándar válido |
| 31 marzo 2025 | Vencimiento de requirements “best practice” | 64 requerimientos marcados como futuros pasaron a ser obligatorios |
| Hoy | Auditorías QSA activas | Toda evaluación se realiza contra v4.0 completa, incluyendo los 64 requerimientos antes opcionales |
Si su organización todavía opera con los controles de la versión 3.2.1, hay requerimientos sin cubrir que su próxima auditoría detectará.
Cómo reducir el alcance del CDE con Zero Trust
Una de las estrategias más efectivas para reducir el costo de cumplimiento PCI DSS es acotar el tamaño del entorno de datos de tarjetahabiente. Mientras menos sistemas estén “dentro del alcance”, menos controles deben auditarse.
Zero Trust Network Access segmenta el CDE a nivel de identidad y contexto, no solo por VLAN. Esto permite aislar los sistemas de pago del resto de la infraestructura de manera verificable, lo que los QSA reconocen como reducción legítima de alcance cuando está correctamente documentada.
Segmentación sin Zero Trust
El CDE se define por VLAN o segmento de red. Todo sistema que tenga conectividad al segmento queda “en alcance” aunque no procese datos de tarjeta directamente. Perímetro amplio, auditoría extensa.
Segmentación con Zero Trust
El acceso al CDE requiere verificación de identidad, estado del dispositivo y contexto en cada conexión. Los sistemas sin necesidad de acceso no tienen conectividad, lo que los excluye del alcance de forma documentada y verificable.
CAPACIDAD RELACIONADA
GRC operativo: controles PCI documentados y auditables
QMA opera los controles técnicos requeridos por PCI DSS 4.0 bajo su modelo MSSP y genera evidencia continua para las auditorías QSA. Conozca qué requerimientos cubre el servicio y cómo se estructuran los entregables.
Preguntas frecuentes sobre PCI DSS 4.0 en México
¿PCI DSS aplica a mi empresa si proceso pagos a través de una pasarela externa como Stripe o Conekta?
Sí, aunque el alcance es reducido. Si redirige al cliente a la pasarela y nunca almacena ni transmite el PAN en sus propios sistemas, cae en el SAQ A (más simple). Sin embargo, si tiene scripts de pago en su sitio web o registra datos de transacción, el alcance se amplía. Un análisis de alcance formal (scoping) es el primer paso recomendado.
¿Cuál es la diferencia entre un ROC y un SAQ?
El Reporte de Cumplimiento (ROC) lo genera un QSA acreditado y es obligatorio para los niveles 1 y 2 de comerciantes. El Cuestionario de Autoevaluación (SAQ) es una herramienta de autoevaluación para niveles 3 y 4. El nivel depende del volumen anual de transacciones con tarjeta de cada marca (Visa, Mastercard, etc.).
¿Qué es un QSA y QMA puede actuar como tal?
Un QSA (Qualified Security Assessor) es un auditor certificado por el PCI SSC para validar el cumplimiento. QMA no actúa como QSA; implementa y opera los controles técnicos que el QSA evaluará. Este modelo es el más común: el MSSP prepara la organización y el QSA realiza la evaluación independiente.
¿Con qué frecuencia debo escanear vulnerabilidades para cumplir PCI DSS?
PCI DSS 4.0 requiere escaneos trimestrales de vulnerabilidades externas realizados por un ASV (Approved Scanning Vendor) aprobado, y escaneos internos también trimestrales. Además, cualquier cambio significativo en la infraestructura activa un escaneo adicional. Un programa de gestión continua de vulnerabilidades cubre estos requisitos de forma automatizada.
¿MFA es obligatorio para todos los usuarios del CDE en PCI DSS 4.0?
Sí. A diferencia de la versión 3.2.1, que exigía MFA solo para accesos remotos, la versión 4.0 requiere MFA para todo acceso al entorno de datos de tarjetahabiente, incluyendo accesos internos desde la red corporativa. Este es uno de los cambios más impactantes de la nueva versión para organizaciones con accesos locales al CDE.
¿Cuánto tiempo toma preparar una auditoría PCI DSS desde cero?
Depende del tamaño del CDE y del estado actual de los controles. En organizaciones con infraestructura de seguridad establecida (SIEM, firewall gestionado, EDR), el proceso de preparación suele tomar entre 3 y 6 meses. Si los controles técnicos no están implementados, el plazo se extiende. Un diagnóstico de brechas (gap assessment) al inicio permite estimar el esfuerzo con precisión.
¿Qué evidencia debe generar mi equipo para la auditoría PCI DSS?
El QSA solicitará: políticas y procedimientos documentados, logs de acceso al CDE (mínimo 3 meses inmediatos), reportes de escaneos de vulnerabilidades trimestrales, resultados de pruebas de penetración anuales, registros de revisión de cuentas, y configuraciones de firewalls y sistemas. Un servicio MSSP genera buena parte de esta evidencia de forma continua como parte de su operación normal.
Evalúe el estado de sus controles PCI DSS 4.0
Un diagnóstico de brechas permite identificar qué requerimientos están cubiertos, cuáles requieren trabajo urgente, y cuál es el alcance real de su CDE. QMA realiza esta evaluación inicial como punto de partida para un plan de remediación estructurado.
