Si tu empresa acepta pagos con tarjeta, es muy probable que en algún momento recibas un correo del banco, de tu adquirente o de un cliente corporativo preguntando por tu cumplimiento de PCI DSS. La reacción más común entre las MiPyMEs mexicanas es la misma: pensar que se trata de un requisito para grandes corporativos, o asumir que usar Stripe, PayPal, Mercado Pago u Openpay ya resuelve el tema por completo.
Ninguna de las dos suposiciones es del todo correcta, y partir de ellas suele terminar en una carrera contrarreloj cuando el requerimiento llega con fecha límite.
Este artículo resuelve las dudas más frecuentes sobre PCI DSS para empresas que procesan pagos con tarjeta en México. Es también el contexto base del webinar del jueves 27 de agosto, donde Guillermo Salinas y Eduardo Calvillo profundizarán en cada uno de estos puntos con casos reales.
Por qué tu empresa está recibiendo solicitudes de PCI DSS
PCI DSS (Payment Card Industry Data Security Standard) no es una ley mexicana ni una regulación gubernamental. Es un estándar creado por el PCI Security Standards Council, el organismo formado por las principales marcas de tarjeta: Visa, Mastercard, American Express, Discover y JCB.
Eso explica por qué la solicitud casi nunca llega de una autoridad. Llega de tres lugares:
Del banco adquirente o del procesador de pagos, porque las marcas de tarjeta les exigen validar el cumplimiento de los comercios que tienen en su portafolio.
De un cliente corporativo, cuando tu empresa forma parte de su cadena de suministro y tocas de alguna manera datos de tarjetahabientes. Aquí el cumplimiento suele venir escrito en el contrato o en el proceso de onboarding de proveedores.
De un socio de negocio o marketplace, que traslada su propia obligación de cumplimiento hacia quienes se integran a su plataforma.
En los tres casos la naturaleza del requerimiento es contractual, no regulatoria. Y esa diferencia importa, porque las consecuencias de no cumplir no llegan por la vía de una multa administrativa, sino por la vía comercial: penalizaciones, incremento de comisiones o pérdida de la capacidad de aceptar tarjetas.
¿PCI DSS aplica según el tamaño de mi empresa?
Aquí está uno de los malentendidos más frecuentes. PCI DSS aplica a cualquier organización que almacene, procese o transmita datos de tarjetahabientes, sin importar si factura tres millones o trescientos millones de pesos al año. Una tienda en línea con veinte pedidos al mes está dentro del alcance igual que una cadena nacional.
Lo que sí cambia con el tamaño es la forma de demostrar ese cumplimiento.
Los cuatro niveles de comercio
Las marcas de tarjeta clasifican a los comercios en cuatro niveles determinados principalmente por el volumen anual de transacciones. A grandes rasgos:
Nivel 1 corresponde a los comercios de mayor volumen, típicamente arriba de seis millones de transacciones anuales por marca, y también a cualquier empresa que haya sufrido una brecha de datos de tarjeta, sin importar su tamaño.
Nivel 2 agrupa a comercios en un rango intermedio, del orden de uno a seis millones de transacciones anuales.
Nivel 3 se enfoca en comercio electrónico de volumen medio.
Nivel 4 es donde caen la mayoría de las MiPyMEs mexicanas: volúmenes menores, tanto en comercio electrónico como en punto de venta.
Los umbrales exactos varían ligeramente entre Visa y Mastercard, y quien define en qué nivel estás no eres tú, sino tu adquirente. Vale la pena preguntarlo de forma explícita antes de iniciar cualquier proyecto de cumplimiento, porque de esa clasificación depende todo lo demás.
El mito del proveedor de pagos
Este es probablemente el punto que más conversaciones destraba. Sí, usar un proveedor como Stripe, PayPal, Mercado Pago u Openpay reduce de manera significativa tu alcance, o scope, dentro de PCI DSS. No, no elimina tu responsabilidad de cumplimiento.
La distinción real no está en qué proveedor usas, sino en cómo lo integraste.
Si el cliente sale por completo de tu sitio hacia una página de pago alojada por el proveedor, o si el formulario de captura vive dentro de un iframe controlado íntegramente por el proveedor, tu alcance se reduce al mínimo. En ese escenario tu empresa nunca toca el número de tarjeta.
Si en cambio el formulario de pago vive en tu sitio, aunque los campos sensibles los inyecte una biblioteca de JavaScript del proveedor, tu página forma parte del flujo de pago. Tu alcance crece, y con él la validación que se te va a pedir.
Y si en algún punto del proceso alguien de tu equipo captura, recibe por correo, anota en un sistema o guarda un número de tarjeta, incluso de forma temporal o en un CRM, el alcance se amplía de manera considerable sin importar qué pasarela uses.
Un punto adicional que muchas MiPyMEs pasan por alto: incluso en las integraciones más ligeras, la versión 4.0.1 del estándar incorporó requisitos específicos para el manejo de scripts en páginas de pago. La justificación de “nosotros no tocamos tarjetas” ya no exime automáticamente de todo control técnico.
Qué pasa si no cumples
Conviene separar dos escenarios distintos.
El primero es el escenario contractual, cuando simplemente no entregas la validación que te piden. Las consecuencias típicas incluyen incremento en las comisiones de procesamiento, penalizaciones mensuales que el adquirente traslada al comercio, retención de fondos, pérdida del contrato con el cliente corporativo que lo exigía y, en el extremo, la suspensión de tu capacidad para aceptar tarjetas.
El segundo escenario es una brecha de datos de tarjeta sin estar en cumplimiento, y es donde el costo se dispara. A las multas de las marcas de tarjeta se suman los costos de la investigación forense obligatoria, la reposición de tarjetas afectadas, la responsabilidad legal frente a los titulares bajo la legislación mexicana de protección de datos personales, y un daño reputacional que para una MiPyME suele ser más caro que la multa misma.
Hay un detalle que rara vez se menciona: sufrir una brecha te reclasifica automáticamente a Nivel 1, con todo lo que eso implica en costo y esfuerzo de validación hacia adelante.
Qué evalúa PCI DSS en la práctica
El estándar se organiza en doce requisitos, que se pueden agrupar en cinco grandes áreas de evaluación:
Seguridad de red e infraestructura, incluyendo segmentación, firewalls y la eliminación de configuraciones por defecto en sistemas y dispositivos.
Protección de los datos del tarjetahabiente, tanto cuando están almacenados como cuando viajan por redes públicas, con cifrado y con políticas claras de retención.
Gestión de vulnerabilidades, que abarca desde el software antimalware hasta el desarrollo seguro de aplicaciones y la aplicación oportuna de parches.
Control de acceso, bajo el principio de mínimo privilegio, con identificadores únicos por usuario, autenticación multifactor y control del acceso físico a los medios que contienen datos.
Monitoreo, pruebas y políticas, es decir, registro y revisión de la actividad en los sistemas, pruebas periódicas de seguridad y una política de seguridad de la información formalmente documentada y comunicada.
En el webinar del 27 de agosto veremos cómo se traduce cada área en controles concretos, con ejemplos de colocation y de medios de pago.
SAQ o auditoría con QSA: ¿cuál te toca?
No todas las empresas necesitan el proceso más robusto, y confundir estos dos caminos es una de las razones por las que muchas MiPyMEs sobredimensionan el proyecto antes de empezar.
El cuestionario de autoevaluación (SAQ)
El Self-Assessment Questionnaire es un cuestionario de validación que la propia empresa completa y firma. Existen varios tipos, y el que te corresponde depende de cómo procesas los pagos: comercio electrónico totalmente externalizado, terminal punto de venta, sistema con conexión a internet, entre otros. La diferencia entre un tipo y otro es enorme: unos contienen alrededor de veinte preguntas y otros superan las trescientas.
En la mayoría de los casos el SAQ se acompaña de escaneos trimestrales de vulnerabilidades realizados por un ASV, un proveedor autorizado de escaneo, cuando tienes direcciones IP expuestas a internet.
La auditoría con QSA
Un Qualified Security Assessor es un evaluador certificado por el PCI Security Standards Council que realiza una revisión formal y emite un Report on Compliance. Es el camino obligatorio para comercios de Nivel 1 y para ciertos proveedores de servicio, y también es una opción que algunas empresas de nivel menor eligen de forma voluntaria cuando un cliente corporativo lo exige o cuando su modelo de negocio lo justifica.
Existe además un punto intermedio que suele ser el más útil para una MiPyME: acompañarse de un QSA para hacer un análisis de brechas antes de completar el SAQ. Así llegas al cuestionario sabiendo qué contestar, en lugar de firmar un documento cuyas implicaciones no terminas de dimensionar.
El primer paso no es certificarte
Antes de decidir entre SAQ y QSA, o de invertir en controles técnicos, hay tres preguntas que cualquier empresa debería poder responder: qué datos de tarjeta tocan realmente mis sistemas y mis procesos, en qué nivel me clasifica mi adquirente, y qué tan lejos estoy hoy de los controles que me van a pedir.
Una evaluación de postura de seguridad responde esas tres preguntas y convierte un requerimiento que parece abrumador en un plan de trabajo con prioridades y tiempos definidos.
En OCD Tech México acompañamos a empresas mexicanas a identificar su alcance real bajo PCI DSS y a construir esa ruta de cumplimiento. Si estás recibiendo solicitudes de tu banco o de un cliente y no sabes por dónde empezar, escríbenos para agendar una evaluación de postura de seguridad.
Acompáñanos el 27 de agosto
Todos estos temas los abordaremos a detalle en el webinar en vivo del jueves 27 de agosto, con Guillermo Salinas y Eduardo Calvillo, incluyendo casos reales de aplicación en entornos de colocation y medios de pago, y un espacio de preguntas y respuestas.
Regístrate y trae tus dudas. Si tu empresa acepta pagos con tarjeta, esta conversación es necesaria. Regístrate: https://us06web.zoom.us/meeting/register/hLjssmQcRJCiHhrwroC1GQ
https://ocd-tech.com.mx/contacto/