Si tu empresa procesa, almacena o transmite datos de tarjetas de pago — ya sea a través de un e-commerce, un portal de clientes o una plataforma interna de cobros — el estándar PCI DSS 4.0 ya te aplica. La versión anterior (3.2.1) quedó oficialmente obsoleta el 31 de marzo de 2024, y la versión 4.0 entró en vigor pleno el 31 de marzo de 2025, con los requisitos más exigentes activos durante 2026. El desconocimiento no es una defensa válida ante los auditores ni ante los adquirentes que procesan tus transacciones.
¿Qué es PCI DSS y por qué importa a empresas en Chile?
PCI DSS (Payment Card Industry Data Security Standard) es el conjunto de controles de seguridad que los sistemas de pago con tarjeta — Visa, Mastercard, American Express, Discover — exigen a todas las entidades que procesan datos de portadores de tarjeta. No es una ley chilena, pero es contractualmente obligatorio si tu empresa acepta o procesa pagos con tarjeta a través de cualquier adquirente: Transbank, Stripe, MercadoPago, entre otros.
En la práctica, si tu plataforma digital tiene un formulario de pago, integra una pasarela, guarda tokens de tarjetas o registra datos de transacciones, estás dentro del alcance. El incumplimiento puede derivar en:
- Multas contractuales del adquirente entre US$5.000 y US$100.000 por mes de incumplimiento sostenido
- Pérdida del derecho a procesar pagos con tarjeta
- Responsabilidad civil ante filtraciones de datos de titulares
- Daño reputacional frente a clientes, proveedores y partners comerciales
Un error frecuente en empresas medianas chilenas es asumir que PCI DSS “es para grandes corporaciones”. Los datos dicen lo contrario: el 70% de las brechas de datos en entornos de pago ocurren en empresas con menos de 200 empleados, según el Informe Verizon Data Breach Investigations Report 2025. El tamaño de la empresa no define el riesgo; la presencia de datos de tarjeta sí lo hace.
De PCI DSS 3.2.1 a 4.0: los cambios más relevantes
La nueva versión no solo actualiza controles existentes; introduce un concepto nuevo en la industria: el enfoque basado en objetivos (Customized Approach), que permite a organizaciones con programas de seguridad maduros demostrar cumplimiento con controles alternativos que logran el mismo objetivo del control prescriptivo original. Esto da flexibilidad real a equipos técnicos avanzados, pero exige mayor documentación y evidencia formal.
Los cambios más relevantes respecto a la versión 3.2.1:
| Área | PCI DSS 3.2.1 | PCI DSS 4.0 |
|---|---|---|
| Autenticación multifactor | Solo para acceso remoto | Para todos los accesos al entorno de datos de tarjeta (CDE) |
| Scripts de terceros en checkout | Sin control explícito | Inventario, autorización y monitoreo obligatorios (Req. 6.4.3) |
| Criptografía | TLS 1.2 suficiente | TLS 1.2 mínimo; TLS 1.3 recomendado + rotación de claves documentada |
| Phishing y concientización | Genérica | Programa específico anti-phishing obligatorio |
| Skimming digital | No cubierto | Monitoreo de cambios en páginas de pago (Req. 11.6.1) |
| Evaluación de proveedores | Cuestionarios anuales | Evaluación continua de riesgo de terceros con acceso al CDE |
| Testing en el SDLC | Recomendado | SAST, DAST y SCA obligatorios en el ciclo de desarrollo |
El cambio con mayor impacto en proyectos de desarrollo de software a medida es el Requisito 6.4.3: todos los scripts JavaScript cargados en páginas de pago — incluyendo scripts de terceros como Google Tag Manager, píxeles de remarketing o chatbots — deben estar inventariados, autorizados y monitoreados. Un script no autorizado en el checkout es un vector de card skimming activamente auditado en PCI DSS 4.0.
Los 12 dominios: ¿qué nuevo exige cada uno?
PCI DSS mantiene su estructura de 12 dominios, pero cada uno incorpora controles nuevos en la versión 4.0. Los que generan más trabajo de implementación en plataformas digitales chilenas son los siguientes:
Dominio 1 — Red segura: las reglas de firewall deben revisarse con evidencia documentada cada seis meses (antes era anual). Para empresas en la nube — AWS, GCP, Azure o Cloudflare — esto implica auditorías formales de security groups, VPCs y listas de control de acceso a red.
Dominio 6 — Seguridad del software: se exige formalmente un proceso de gestión de vulnerabilidades en el ciclo de desarrollo (SDLC). Esto incluye revisión de código, escaneo de dependencias de terceros (SCA) y pruebas DAST sobre el entorno de producción al menos una vez al año o ante cambios significativos en el sistema.
Dominio 8 — Gestión de identidad: MFA para todos los accesos al CDE es el cambio de mayor impacto organizacional. Si tu equipo utiliza un panel de administración que toca datos de transacciones, todos deben tener MFA activo. No hay excepciones en PCI DSS 4.0.
Dominio 11 — Pruebas de seguridad: el penetration testing anual contra el CDE sigue siendo obligatorio. Lo nuevo es que debe incluir específicamente pruebas de control de segmentación de red — verificar que los sistemas fuera del CDE no puedan alcanzar los sistemas dentro del alcance.
Dominio 12 — Políticas de seguridad: el programa de concientización de seguridad debe incluir módulos específicos sobre amenazas actualizadas: phishing, smishing e ingeniería social con técnicas documentadas para 2024-2025.
Niveles de cumplimiento: ¿cuál le aplica a tu empresa?
PCI DSS clasifica a los comerciantes en cuatro niveles según el volumen anual de transacciones. Esto determina el tipo de validación requerida:
| Nivel | Transacciones anuales | Validación requerida |
|---|---|---|
| Nivel 1 | +6 millones | Auditoría QSA certificada + escaneo ASV trimestral |
| Nivel 2 | 1–6 millones | SAQ anual + escaneo ASV trimestral |
| Nivel 3 | 20.000–1 millón (e-commerce) | SAQ anual + escaneo ASV trimestral |
| Nivel 4 | Menos de 20.000 (e-commerce) o hasta 1M otros canales | SAQ anual; ASV a criterio del adquirente |
La mayoría de las pymes chilenas con e-commerce caen en Nivel 4. Esto no significa que los requisitos sean opcionales — significa que el método de validación es un SAQ (cuestionario de autoevaluación) en lugar de una auditoría presencial de un QSA certificado.
Existe un matiz importante: el tipo de SAQ varía según la arquitectura de integración de pagos. Si usas Stripe Checkout o Webpay Plus en modo redirect — el usuario sale de tu sitio hacia el checkout del proveedor — probablemente calificas para el SAQ A, con solo 22 controles. Si procesas o manejas datos de tarjeta directamente en tu servidor, el SAQ correspondiente puede tener hasta 330 controles. Elegir el SAQ equivocado es un error técnico que puede anular la validación.
Fechas críticas y estado actual en 2026
El calendario de implementación de PCI DSS 4.0 tiene tres momentos clave que muchas empresas chilenas confunden:
31 de marzo de 2024: PCI DSS 3.2.1 quedó retirado. Desde ese momento, toda validación nueva debe realizarse contra PCI DSS 4.0.
31 de marzo de 2025: todos los requisitos de PCI DSS 4.0 son obligatorios, incluyendo los que el PCI SSC había marcado como “best practices” con implementación diferida durante 2024.
2026 en adelante: los adquirentes y las marcas de tarjetas están aumentando la frecuencia de verificación de cumplimiento. Para empresas de Nivel 1 y 2, ya es un requisito activo verificado en cada ciclo de renovación. Para Nivel 3 y 4, los adquirentes están comenzando a incorporar PCI DSS 4.0 como condición contractual explícita para mantener los contratos de procesamiento.
En Chile, Transbank ha comenzado a actualizar sus términos para incorporar referencias explícitas a PCI DSS 4.0. Si tienes un contrato vigente y procesas más de 20.000 transacciones anuales de e-commerce, debes verificar si ya recibiste notificación de cumplimiento por parte de tu adquirente.
Implicancias prácticas para plataformas digitales en Chile
Los cambios de PCI DSS 4.0 que más trabajo generan en proyectos de desarrollo de aplicaciones en Chile son los siguientes:
Inventario de scripts en páginas de pago: si tu plataforma carga cualquier script de tercero en el checkout — analytics, chatbots, retargeting — debes tener un inventario actualizado, una justificación de negocio para cada uno y un mecanismo de alerta ante cambios no autorizados. El control técnico estándar para esto es una política CSP (Content Security Policy) estricta más monitoreo de integridad de scripts.
MFA forzado para administradores del CDE: cualquier panel de administración que permita ver o gestionar datos de transacciones necesita MFA activo sin excepción. Esto incluye dashboards internos desarrollados a medida, accesos a bases de datos de producción y herramientas de soporte con visibilidad sobre datos de pago.
Logging y monitoreo mejorado: los registros de acceso al CDE deben incluir el ID de usuario, tipo de evento, fecha, hora y resultado. El período de retención mínimo es 12 meses (tres meses accesibles en línea, el resto en almacenamiento recuperable). Plataformas que usaban logging básico necesitan actualizar su infraestructura de observabilidad.
Gestión de secrets y claves criptográficas: la rotación de claves de cifrado debe estar documentada y automatizada. Claves hardcodeadas en el código fuente son una falla crítica en cualquier auditoría PCI DSS 4.0 — sin importar el nivel de cumplimiento.
Testing de seguridad en el SDLC: si tu empresa desarrolla software propio que toca el CDE, PCI DSS 4.0 exige que el proceso de desarrollo incluya revisión de código orientada a seguridad, gestión formal de componentes de terceros (SBOM o equivalente) y pruebas DAST periódicas documentadas.
Cómo preparar tu empresa: hoja de ruta en seis pasos
Si estás comenzando la evaluación de cumplimiento con PCI DSS 4.0, el orden correcto de trabajo es el siguiente:
1. Definir el alcance (scoping): identificar qué sistemas, personas y procesos tocan datos de tarjeta. El objetivo es reducir el alcance al mínimo necesario, lo que reduce dramáticamente el trabajo de cumplimiento. Una arquitectura con checkout externalizado tiene un alcance significativamente menor que una que procesa datos en servidor propio.
2. Determinar el nivel y el SAQ correcto: según el volumen de transacciones y la arquitectura de integración de pagos, define qué SAQ debes completar. Para la mayoría de las plataformas con checkout externalizado (Stripe, Webpay Plus redirect), el SAQ A o SAQ A-EP son suficientes.
3. Auditoría de brechas (gap assessment): comparar el estado actual de tus controles técnicos y organizacionales contra los requisitos del SAQ o del RoC correspondiente. Esto produce la lista exacta de trabajo pendiente, con priorización por riesgo.
4. Implementar los controles faltantes: prioriza por exposición. Los controles de autenticación (MFA) y los de monitoreo de scripts en páginas de pago son generalmente los más urgentes, dado que su ausencia es detectada en los primeros escáneres automatizados.
5. Documentar todo: PCI DSS 4.0 exige evidencia documentada de cada control implementado. Políticas, procedimientos, logs, evidencia de testing y revisiones periódicas. Sin documentación, el control no existe para el auditor.
6. Validar y completar el SAQ: con los controles implementados y la evidencia documentada, completar el cuestionario de autoevaluación y obtener la firma de un QSA si el nivel de la empresa lo requiere.
Conclusión
PCI DSS 4.0 no es un trámite burocrático. Es la respuesta de la industria de pagos a un aumento real en ataques de card skimming, phishing avanzado y filtraciones de datos en plataformas de e-commerce. Para empresas chilenas con plataformas digitales que procesan pagos con tarjeta, cumplir ya no es opcional — es condición de operación con los adquirentes.
Si tu empresa necesita entender qué nivel de cumplimiento le aplica o quiere una evaluación técnica del estado actual de su plataforma frente a PCI DSS 4.0, en Codelan podemos ayudarte a diagnosticarlo y a planificar la implementación sin interrumpir la operación. Conversemos — el diagnóstico inicial es gratuito y sin compromiso.
Preguntas frecuentes
¿PCI DSS 4.0 es obligatorio si solo uso Webpay Plus de Transbank?
Sí. Cualquier empresa que acepte pagos con tarjeta está dentro del alcance de PCI DSS, independientemente de qué pasarela use. La diferencia es que si usas Webpay Plus en modo redirect — el usuario sale de tu sitio para pagar en el portal de Transbank — calificas para el SAQ A, que tiene el menor número de controles (22). Pero el cumplimiento sigue siendo contractualmente obligatorio.
¿Cuál es la diferencia entre SAQ A y SAQ D?
El SAQ A aplica cuando todos los elementos de pago son completamente externalizados a un procesador certificado PCI DSS y tu sitio solo contiene un redireccionamiento al checkout de terceros. Tiene 22 controles. El SAQ D aplica cuando tu empresa procesa, almacena o transmite datos de tarjeta directamente en sus propios servidores, y tiene hasta 330 controles. La elección del SAQ incorrecto puede invalidar el proceso de validación entero.
¿Qué pasa si mi empresa no cumple con PCI DSS 4.0?
Las consecuencias pueden ir desde multas contractuales del adquirente — entre US$5.000 y US$100.000 por mes de incumplimiento — hasta la revocación del derecho a procesar pagos con tarjeta. En caso de una brecha de datos, el costo se multiplica: responsabilidad por fraudes, costos forenses, notificaciones obligatorias a titulares afectados y posibles sanciones adicionales bajo la normativa de protección de datos vigente en Chile.
¿MFA es obligatorio para todos los usuarios de mi sistema?
MFA es obligatorio solo para los usuarios con acceso al entorno de datos de tarjeta (CDE), no para todos los usuarios del sistema. Si tienes un e-commerce con miles de clientes registrados, no necesitas MFA para el login de compradores. Pero todos los administradores, técnicos y personal de soporte con acceso a datos de transacciones o sistemas de pago deben tenerlo activo, sin excepción.
¿Cuánto tiempo toma implementar PCI DSS 4.0 desde cero?
Depende del estado actual y del alcance. Para una empresa pequeña con checkout externalizado que califica para SAQ A y no tiene brechas técnicas significativas, el proceso puede tomar entre cuatro y ocho semanas. Para una plataforma con procesamiento más complejo que requiere SAQ D, el proceso realista es de tres a seis meses. Lo más importante para dimensionarlo correctamente es comenzar con un gap assessment honesto del estado actual.
¿Los scripts de Google Analytics en el checkout nos ponen en incumplimiento?
No automáticamente, pero sí son un punto de atención auditado. El Requisito 6.4.3 de PCI DSS 4.0 exige que todos los scripts en páginas de pago estén inventariados, autorizados y monitoreados. Si tienes GTM, Google Analytics o cualquier otro script de terceros en tu checkout, debes documentarlos, tener una justificación de negocio y un mecanismo de alerta ante cambios no autorizados. Una Content Security Policy (CSP) bien configurada es el control técnico estándar para cumplir este requisito.
¿Qué es el Customized Approach en PCI DSS 4.0?
Es un enfoque nuevo que permite a organizaciones con programas de seguridad maduros demostrar cumplimiento a través de controles equivalentes que logran el mismo objetivo que el control prescriptivo estándar. Es más flexible, pero exige análisis de riesgo formal, documentación extensa y evidencia de efectividad. No es recomendable para empresas sin un equipo de seguridad dedicado. El Defined Approach — el equivalente al enfoque de la versión 3.2.1 — sigue siendo válido y más simple de implementar para la gran mayoría de empresas chilenas.
