Si ya sabes que es PCI DSS, esta guía no va a repetírtelo. Vamos a ir directo al punto que la mayoría de los artículos evitan: el cumplimiento PCI DSS en ecommerce no es un formulario que llenas una vez al año. Es una decisión de arquitectura que tomas desde el primer dia que integras un método de pago en tu plataforma.
La forma en que tu tienda procesa pagos determina tu nivel de compliance, el tipo de validación que necesitas, el alcance de tu entorno de datos de tarjeta (CDE) y la cantidad de controles que tu equipo tiene que operar. Un CTO que entiende esto no solo evita multas. Construye una operación que aguanta auditorias sin crisis.
Este artículo cubre como lograr y mantener el cumplimiento PCI DSS en un contexto de ecommerce. No explica que es PCI DSS. Si necesitas esa base, revisa primero esta información.
- 01 Por qué tu arquitectura de pagos define tu carga de compliance
- 02 Tu nivel de comerciante: lo que determina el volumen de transacciones
- 03 SAQ A vs SAQ A-EP vs SAQ D
- 04 Como reducir el alcance de tu CDE
- 05 Responsabilidad compartida: lo que tu pasarela de pago no asume por ti
- 06 PCI DSS v4.0 para Ecommerce
- 07 6 errores más frecuentes al implementar PCI DSS en ecommerce
- 08 Preguntas que todo CTO de ecommerce hace sobre PCI DSS
Por qué tu arquitectura de pagos define tu carga de compliance
El primer error que cometen la mayoría de los equipos de tecnología en ecommerce es pensar en PCI DSS como un proceso administrativo. La realidad es que la carga de compliance, el SAQ (Self-Assessment Questionnaire) que debes completar y la cantidad de controles que necesitas operar los decide tu arquitectura, no tu equipo de cumplimiento.
La pregunta central es esta: cuando un comprador ingresa sus datos de tarjeta en tu tienda, esos datos tocan tu servidor o van directo al servidor del procesador de pagos.
Si la respuesta es que van directo al procesador sin pasar por tu infraestructura, tu alcance es mínimo. Si tu servidor participa en cualquier parte del flujo de datos de tarjeta, tu alcance se expande y con el, tu responsabilidad.
El CDE: el perímetro que define todo
El Cardholder Data Environment (CDE) es el conjunto de sistemas, procesos y personas que almacenan, procesan o transmiten datos del titular de la tarjeta, o que pueden afectar la seguridad de esos datos.
En un ecommerce, el CDE puede incluir tu servidor web, tu base de datos, tu sistema de backoffice, tu plataforma de hosting, tus herramientas de analítica y cualquier script de tercero que se ejecute en tus páginas de pago.
Un solo script de terceros que se ejecuta en tu página de checkout puede expandir tu CDE si no está debidamente inventariado y controlado. Esto es lo que los Requisitos 6.4.3 y 11.6.1 de PCI DSS v4.0 abordan directamente.
Reducir el CDE es la estrategia más efectiva para reducir la carga de compliance. No se trata de evadir controles, sino de diseñar la arquitectura para que los datos de tarjeta nunca toquen sistemas que no necesitan verlos.
Tu nivel de comerciante: Lo que determina el volumen de transacciones
PCI DSS clasifica a los comercios en cuatro niveles según el volumen de transacciones con tarjeta que procesan al año. El nivel determina el método de validación requerido, la periodicidad de los escaneos y si necesitas un QSA (Qualified Security Assessor) externo o puedes completar una autoevaluación.
Que significa esto en la práctica para un Ecommerce en México, Colombia o Chile
La mayoría de los ecommerce de la región operan en Nivel 3 o Nivel 4. Esto significa que pueden validar su compliance mediante un SAQ anual, sin necesidad de contratar un QSA externo para una auditoria completa.
Sin embargo, el nivel no exime de los controles técnicos. Un ecommerce de Nivel 4 que usa un iframe del PSP (proveedores de servicios de pago) mal configurado puede tener el mismo riesgo que uno de Nivel 1 con mala arquitectura. El nivel define quien te audita, no que controles necesitas.
Nota importante: las marcas de tarjeta (Visa, Mastercard, American Express) pueden tener umbrales ligeramente distintos. Los bancos adquirentes locales, como los que operan con Conekta, PayU o dLocal en LATAM, aplican estos criterios según los requerimientos de cada marca.
Artículo relacionado: ¿Quién debe cumplir con PCI DSS en México?
SAQ A vs SAQ A-EP vs SAQ D: Cómo elegir el correcto para tu integración
El SAQ (Self-Assessment Questionnaire) es el cuestionario de autoevaluación que los comercios completan para validar su compliance. Existen nueve tipos de SAQ, pero para ecommerce los tres relevantes son A, A-EP y D.
Elegir el SAQ incorrecto no solo es un error administrativo: puede invalidar tu compliance ante un adquirente o ante una marca de tarjeta. La siguiente tabla resume las diferencias clave.
Cómo determinar cuál aplica a tu tienda
Plataformas comunes en LATAM y su implicación de SAQ
Si tu ecommerce usa una plataforma gestionada con checkout alojado completamente en el PSP, como Conekta Hosted Checkout, Mercado Pago Checkout Pro, PayU con redirección o Stripe Checkout con redirect, en principio calificas para SAQ A, siempre que no existan scripts propios que participen en el flujo de pago.
Si usas Stripe Elements, Conekta Card Elements, MercadoPago SDK con iframe embebido en tu página, o cualquier integración donde el JS del PSP se carga en tu dominio, necesitas evaluar si corresponde SAQ A-EP.
Si tienes una integración vía API directa donde tu servidor recibe y transmite datos de tarjeta antes de enviarlos al PSP, estas en SAQ D sin excepción.
Cómo reducir el alcance de tu CDE sin perder funcionalidad
Reducir el CDE no significa sacrificar la experiencia de pago. Significa diseñar la arquitectura para que los datos de tarjeta solo existan donde es estrictamente necesario. Estas son las estrategias principales:
Tokenización: ¿Qué es y cómo funciona?
La tokenización sustituye los datos reales de la tarjeta (el PAN o número de tarjeta) por un token sin valor fuera del sistema que lo genera. Cuando el PSP tokeniza los datos en el momento del pago, tu sistema solo almacena el token, no el número de tarjeta.
El impacto en el CDE es directo: si tu sistema nunca ve ni almacena el PAN real, esos sistemas quedan fuera del alcance de PCI DSS para los controles de almacenamiento seguro de datos de tarjeta.
La tokenización no es lo mismo que el cifrado. El cifrado protege datos que siguen existiendo en tu entorno, solo que en formato inaccesible sin la clave. La tokenización elimina los datos de tu entorno por completo y los reemplaza por un referente sin valor propio.
Hosted Payment Pages y redirect
La forma más efectiva de reducir el CDE es no recibir datos de tarjeta en ningún momento. Los modelos de redirect completo o hosted payment pages del PSP logran esto: el comprador completa el pago en el entorno certificado del PSP y tu sistema solo recibe la confirmación de la transacción.
Este modelo es el que habilita SAQ A y es la arquitectura más eficiente en términos de compliance. El costo es una menor flexibilidad en la experiencia de pago, aunque los PSPs modernos en LATAM ofrecen opciones de personalización de marca en sus hosted pages.
Segmentación de red
Para ecommerce con integraciones más complejas donde el servidor participa en el flujo, la segmentación de red permite aislar los sistemas que forman parte del CDE del resto de la infraestructura. Esto no elimina los controles, pero los limita a los sistemas relevantes y reduce el perímetro de auditoría.
La segmentación de red debe estar documentada, probada y validada periódicamente. Un firewall mal configurado que no aísle correctamente el CDE no cuenta como segmentación válida para PCI DSS.
Responsabilidad compartida: Lo que tu pasarela de pago no asume por ti
Este es el punto donde más equipos de TI cometen errores de interpretación. Usar un PSP certificado PCI DSS Nivel 1 no transfiere tu responsabilidad de compliance. Lo que el PSP cubre es su propia infraestructura. Lo que ocurre en tu ecommerce sigue siendo tu responsabilidad.
PCI DSS v4.0 refuerza esto con los Requisitos 12.8 y 12.9, que exigen gestión activa y documentada de proveedores de servicio terceros.
Cómo gestionar la responsabilidad compartida con tu PSP
El Requisito 12.8 de PCI DSS establece que debes mantener y monitorear la lista de todos los proveedores de servicio terceros (TPSP) con acceso a tu CDE o que puedan afectar su seguridad. Esto incluye tu PSP, tu plataforma de hosting, tu CDN y cualquier proveedor de scripts de analítica o marketing que se carguen en tus páginas de pago.
Para cada TPSP en scope, debes obtener y revisar anualmente su AOC (Attestation of Compliance), que es el documento que certifica que el proveedor está en compliance con PCI DSS. Si tu PSP no puede proveer un AOC vigente, tu propio compliance está en riesgo.
En LATAM, algunos PSPs medianos no publican o no actualizan su AOC con regularidad. Verificar este documento no es un formalismo: es un requisito que los adquirentes y las marcas de tarjeta pueden solicitar en cualquier momento.
Podría interesarte leer: ¿Cómo saber si mi empresa está lista para una auditoría de seguridad?
PCI DSS v4.0 para Ecommerce: Req. 6.4.3 y 11.6.1 ya son obligatorios
PCI DSS v4.0 entro en vigor en marzo de 2024. Los requisitos denominados future-dated, diseñados específicamente para ecommerce, se volvieron obligatorios el 31 de marzo de 2025. En 2026, si tu ecommerce aún no tiene estos controles operando, no estas atrasado en implementarlos. Estas operando fuera de estándar. La pregunta ya no es si aplican. La pregunta es si puedes demostrarlo ante una auditoria hoy.
Requisito 6.4.3: Gestión de scripts en páginas de pago
Este requisito establece que debes mantener un inventario de todos los scripts que se ejecutan en tus páginas de pago al consumidor. Para cada script en ese inventario debes poder demostrar que:
- Existe un método para confirmar que cada script está autorizado por la organización
- Existe un método para asegurar la integridad de cada script
- Existe un inventario escrito de todos los scripts con justificación escrita de por qué cada uno es necesario
En términos prácticos, esto significa que no puedes tener scripts de Google Analytics, Meta Pixel, chatbots, A/B testing o cualquier otro script de tercero en tus páginas de pago sin inventario, autorización documentada y mecanismo de verificación de integridad (como Subresource Integrity o Content Security Policy).
Requisito 11.6.1: Detección de cambios en páginas de pago
Este requisito exige que implementes un mecanismo para detectar cambios no autorizados en las páginas de pago al consumidor. El objetivo es prevenir ataques de tipo Magecart o e-skimming, donde actores maliciosos inyectan código en tu página para capturar datos de tarjeta antes de que lleguen al PSP.
El mecanismo de detección debe ejecutarse al menos una vez cada siete días o con la frecuencia que tu Targeted Risk Analysis justifique como suficiente. Debe cubrir los HTTP headers de la página y el contenido del script en la página de pago.
Dato importante: El e-skimming es el vector de ataque más común en ecommerce. Los ataques Magecart han comprometido miles de tiendas online en los últimos años, incluyendo plataformas de talla global como British Airways y Ticketmaster. Según inteligencia de amenazas de Recorded Future, este tipo de ataque creció 103% en solo seis meses durante 2024-2025. PCI DSS v4.0 los aborda directamente porque el sector lo exigía. (Fuentes: Recorded Future / Visualping)
Implicaciones para tu stack tecnológico
Cumplir con 6.4.3 y 11.6.1 requiere una combinación de controles técnicos y procesos operativos. En el lado técnico, implementar Content Security Policy (CSP) estricto en tus páginas de pago, Subresource Integrity (SRI) en scripts externos y monitoreo de integridad de página.
En el lado operativo, requiere un proceso de aprobación para cualquier nuevo script en páginas de pago, un registro de cambios y revisiones periódicas. Este proceso debe estar documentado y la evidencia debe estar disponible para una eventual auditoria.
Los seis errores más frecuentes al implementar PCI DSS en ecommerce
Estos errores no son teóricos. Son los que aparecen con mayor frecuencia en diagnósticos de compliance en ecommerce en Mexico, Colombia y Chile.
El común denominador de estos errores es la misma concepción: PCI DSS como un check administrativo en lugar de un marco de control operativo. Los equipos que entienden la diferencia estructuran sus decisiones de arquitectura y operación en torno al compliance desde el diseño, no después de la auditoria.
Monitoreo Continuo: De compliance anual a operación trazable
Uno de los requisitos que más se subestima en ecommerce es el Requisito 10 de PCI DSS: el registro y monitoreo de todos los accesos a los recursos del sistema y a los datos del titular de la tarjeta. No es solo guardar logs. Es demostrar que alguien está leyendo esos logs, correlacionando eventos y respondiendo a anomalías en tiempo.
El compliance anual dice que tu entorno estaba en orden en el momento de la evaluación. El monitoreo continuo dice que tu entorno está en orden ahora y que tienes evidencia de ello.
Qué debe cubrir el monitoreo continuo en un ecommerce
- Accesos a sistemas del CDE: quienes acceden, desde donde y en que horario
- Cambios en configuraciones de seguridad: firewalls, reglas de acceso, configuraciones de plataforma
- Intentos de autenticación fallidos y accesos privilegiados
- Actividad en las páginas de pago: cambios en scripts, headers HTTP y contenido
- Alertas de vulnerabilidades en dependencias de plataforma y plugins
- Resultados de escaneos ASV trimestrales y su seguimiento a remediación
Como TecnetSOC soporta el cumplimiento continuo de PCI DSS
TecnetSOC es nuestro Centro de Operaciones de Ciberseguridad (SOC), con cobertura operativa continua.
Lo que diferencia a TecnetSOC en contextos de PCI DSS es la evidencia operativa que produce: logs estructurados, alertas correlacionadas y reportes trazables que un QSA puede revisar sin que tu equipo tenga que reconstruir la historia desde cero. Desde TecnetSOC, el monitoreo de tu entorno produce evidencia directamente alineada con los requisitos del estándar:
- 10.2 y 10.3: generación y retención de logs de eventos críticos en sistemas del CDE
- 10.4: revisión de logs al menos diariamente por personal operativo
- 10.7: detección y respuesta a fallas en los mecanismos de control de seguridad
- 11.5: detección de intrusiones y cambios no autorizados en archivos críticos del CDE
- 6.3: gestión de vulnerabilidades identificadas en el entorno del CDE
El resultado es un entorno del que puedes producir evidencia trazable, con reportes estructurados, tickets de incidentes documentados y un historial de alertas que un QSA puede revisar sin que tu equipo tenga que reconstruir la historia desde cero.