Durante casi tres años, PCI DSS v4.0 vivió con un asterisco. El Payment Card Industry Security Standards Council publicó la versión 4.0 en marzo de 2022, pero dejó 51 requisitos marcados como “de fecha futura”, una especie de periodo de gracia para que las empresas se prepararan sin la presión de una auditoría inmediata. Esa fecha límite era el 31 de marzo de 2025. Ya pasó.

Desde entonces, cualquier evaluación de PCI DSS, en cualquier parte del mundo, incluida México, se realiza contra el estándar completo, sin excepciones ni requisitos opcionales. Si tu empresa procesa, transmite o almacena datos de tarjetas de pago y todavía opera con los controles que le bastaban en 2023 o 2024, hay una probabilidad real de que tu próxima evaluación no pase.

Qué cambió realmente con la v4.0.1

Aquí conviene aclarar algo que genera confusión constante: v4.0.1 no es una versión nueva del estándar con requisitos distintos. Es una revisión de erratas publicada en junio de 2024, con correcciones de redacción y aclaraciones, pero sin añadir ni eliminar requisitos frente a v4.0. Los doce requisitos de alto nivel siguen siendo los mismos, los tipos de cuestionario de autoevaluación (SAQ A, A-EP, B, B-IP, C, C-VT, D-MER, D-SP) no cambiaron, y los niveles de validación según el volumen de transacciones tampoco.

Lo que sí importa es que v4.0 quedó retirada formalmente, y desde entonces toda evaluación, todo SAQ y todo Report on Compliance debe hacerse contra v4.0.1 (PCI Hispano). Si tu adquirente o tu QSA te sigue pidiendo documentos con membrete de v4.0 en 2026, es un descuido de proceso de su parte, no un estándar vigente.

El periodo de gracia ya terminó

El cambio de fondo, más que cualquier requisito individual, es filosófico. PCI DSS v3.2.1 se manejaba como un evento anual: se hacía la evaluación, se corregían los hallazgos, se presentaba el reporte, y la empresa volvía a su operación normal hasta el siguiente ciclo. La v4.0 rechaza explícitamente ese modelo. El estándar ahora exige que la seguridad sea un proceso continuo, de negocio, no una obligación de una vez al año (SecurityWall).

Esto se traduce en controles muy concretos que ya son obligatorios y que muchas empresas mexicanas todavía no han implementado del todo.

Autenticación multifactor para todos, no solo para administradores

Antes, la autenticación multifactor solo era obligatoria para accesos administrativos y accesos remotos al entorno de datos de tarjetas. Bajo v4.0.1, la MFA es obligatoria para cualquier acceso a ese entorno, incluidos usuarios que no son administradores. Si tu equipo de soporte, ventas o atención a clientes toca sistemas dentro del alcance de PCI, y no todos tienen un segundo factor de autenticación configurado, ahí hay una brecha que un evaluador va a encontrar.

Gestión de scripts en la página de pago

Este es, probablemente, el cambio más ignorado y el más relevante frente a cómo realmente se roban datos de tarjetas hoy. Durante años, el modelo mental de PCI era del lado del servidor: proteger los sistemas que almacenan y procesan los datos. Pero buena parte del robo de datos ya no ocurre ahí, ocurre en el navegador del cliente, a través de ataques de tipo e-skimming (también llamados Magecart o formjacking), donde un atacante inyecta o compromete un script de JavaScript en la página de pago para copiar los datos de la tarjeta mientras el cliente los escribe, antes de que se cifren, completamente fuera de los sistemas internos del comercio (ComplianceHub).

Los requisitos 6.4.3 y 11.6.1 obligan a mantener un inventario de cada script que se carga y ejecuta en la página de pago, confirmar que cada uno está autorizado y justificado por un motivo de negocio, y detectar cambios no autorizados en esa página. Esto incluye herramientas de analítica, widgets de chat, autocompletado de direcciones, y cualquier otro elemento de terceros, incluido lo que el área de marketing agrega sin pasar por una revisión de seguridad. Este último punto, la falta de gobernanza sobre los scripts de terceros que entran a la página de pago sin control de TI, es hoy el vacío más grande que se está encontrando en las evaluaciones de 2026.

Análisis de riesgo focalizado, no frecuencias fijas

Varios requisitos que antes fijaban una frecuencia específica ahora piden que la empresa haga su propio análisis de riesgo y documente por qué eligió una cadencia determinada. La flexibilidad que ofrece v4.0 no es gratuita, está condicionada a que exista ese análisis documentado que justifique la decisión (ComplianceHub). Sin ese documento, la flexibilidad no cuenta como cumplimiento, cuenta como un hallazgo.

El error más común en 2026: tratar marzo de 2025 como la meta final

El error que vemos con más frecuencia entre empresas mexicanas es tratar la fecha límite de marzo de 2025 como una línea de meta que ya se cruzó y se puede olvidar. No es así. Los evaluadores en 2026 esperan evidencia de operación sostenida, registros, alertas, análisis de riesgo actualizados según su propia cadencia declarada, no una certificación de que el control se encendió en algún momento y nunca más se revisó. Una empresa que implementó un control en marzo de 2025 y jamás volvió a operarlo activamente va a tener dificultades reales para demostrar cumplimiento en su siguiente auditoría.

Esto es particularmente delicado para negocios en México que procesan pagos con tarjeta para clientes propios o para terceros, desde comercios electrónicos hasta plataformas de cobro telefónico o call centers que capturan datos de tarjeta directamente. Si tu empresa asumió que “ya cumplió con PCI” en 2025 y no ha vuelto a tocar el tema desde entonces, es momento de revisarlo, porque el estándar fue diseñado exactamente para exponer ese tipo de cumplimiento de un solo momento.

Qué significa esto para tu negocio en México

Si tu empresa acepta pagos con tarjeta, ya sea de forma directa, a través de una pasarela de pagos, o como proveedor de servicios que procesa datos de tarjeta en nombre de otro negocio, esto no es un tema que puedas delegar por completo a tu procesador de pagos o a tu banco adquirente. Tres puntos que conviene revisar cuanto antes:

Primero, confirma qué tipo de SAQ aplica a tu negocio y si tu documentación actual corresponde a v4.0.1, no a v4.0. Si tu último Attestation of Compliance sigue mencionando la versión anterior, tu siguiente ciclo de evaluación probablemente lo va a rechazar.

Segundo, audita tu página de pago como si fuera un sistema más, no solo tu backend. Haz un inventario real de cada script que corre ahí, quién lo agregó, para qué, y si alguien lo está monitoreando. Es común que este inventario no exista porque marketing, desarrollo y seguridad nunca se sentaron juntos a construirlo.

Tercero, revisa si tus controles de frecuencia variable, como escaneos de vulnerabilidades o revisiones de acceso, tienen un análisis de riesgo documentado que justifique la cadencia elegida. Si la cadencia existe solo como una práctica informal sin ese respaldo, no vas a poder demostrarla frente a un evaluador.

El punto que no debería sorprender a nadie

PCI DSS no tiene los titulares de una nueva ley de privacidad o de una regulación de inteligencia artificial, pero para cualquier empresa que maneje datos de tarjetas, sigue siendo uno de los marcos con consecuencias financieras más inmediatas, desde multas contractuales con tu procesador de pagos hasta la posible pérdida de la capacidad de aceptar tarjetas si el incumplimiento persiste. El periodo de transición que suavizó la llegada de v4.x durante tres años ya se terminó. En 2026, el estándar es, simplemente, el estándar.

En OCD Tech México ayudamos a empresas a pasar de un cumplimiento de un solo momento a un programa de PCI DSS que realmente opera de forma continua, desde el inventario de scripts en la página de pago hasta los análisis de riesgo que sostienen cada control. Si no estás seguro de si tu empresa sigue operando como si fuera 2024, es un buen momento para averiguarlo antes de que lo averigüe tu evaluador.

Contacto