Gateways, proveedores de pago (PSP) y procesadoras
El PCI DSS, el estándar de seguridad de datos de tarjetas, tiene una lista de exigencias que solo aplica a quien presta servicios a otras empresas, y además un apéndice entero para quien aloja a varios clientes en el mismo entorno. DM11 lleva a tu empresa por el camino correcto, sin esa sorpresa de descubrir el tamaño real del trabajo a mitad de la evaluación.
DM11 prepara a tu empresa. No somos QSA, el evaluador acreditado, y no emitimos el informe de cumplimiento (RoC), la atestación (AOC) ni ningún certificado. Cuando se exige la evaluación formal, quien la conduce es un QSA aliado, acreditado por el PCI SSC, el consejo que mantiene el estándar.
Quién conduce la preparación
La pregunta que lo define todo
La respuesta lo cambia todo: qué requisitos aplican, cómo los compruebas y con qué frecuencia repites cada rutina. El estándar llama proveedor de servicios a quien procesa, guarda o transmite datos de tarjeta en nombre de otra empresa, o a quien puede afectar la seguridad de esos datos. Gateway, subadquirente, facilitador y procesadora entran en esa cuenta. Y quien vende directo y además procesa para terceros acumula los dos roles a la vez.
El propio estándar lo prevé: cuando la empresa es comercio y proveedor a la vez, los requisitos que solo aplican a proveedor se aplican a la parte del negocio que presta el servicio. En la práctica, son dos alcances dentro de la misma evaluación. Tratar ambos como uno solo es un error que sale caro.
Quien te contrata necesita dar seguimiento a tu cumplimiento al menos una vez cada doce meses y saber qué requisitos son tuyos, cuáles son suyos y cuáles comparten. No es curiosidad: es una obligación suya. Y la respuesta que le des decide si el contrato avanza o se traba.
Aparecer en la lista de proveedores conformes de una marca ayuda a tu cliente a cumplir el seguimiento anual. Pero el estándar es claro: para demostrar los requisitos que cumples en su nombre, la lista sola no sirve como prueba. Se espera que entregues el AOC cuando lo pidan.
Lo que cambia para el proveedor
El PCI DSS marca varios requisitos como válidos solo para proveedor de servicios y además duplica la frecuencia de rutinas que el comercio hace una vez al año. Quien arma el programa pensando en comercio solo lo nota demasiado tarde.
La versión vigente es PCI DSS v4.0.1, publicada en junio de 2024. La v4.0 se retiró en diciembre de 2024, así que esta es la única versión activa. La plantilla del informe de cumplimiento (Report on Compliance) está en la revisión 3, de enero de 2025.
Buena parte de los requisitos nuevos de la versión 4 era solo recomendación hasta el 31 de marzo de 2025 y se volvió obligatoria en esa fecha. Varios de ellos pesan más para el proveedor, sobre todo los de confirmación de alcance cada seis meses y los del apéndice de entorno compartido.
El SAQ D-Service Provider es el único cuestionario de autoevaluación (SAQ) para proveedor, y aplica solo a quien la marca considera elegible. Incluye todos los requisitos exclusivos de proveedor y el apéndice de entorno compartido, que no aparecen en el SAQ de comercio.
El comercio confirma el alcance una vez al año. El proveedor lo confirma cada seis meses, y también después de cualquier cambio importante. El propio estándar explica por qué: la red de un proveedor suele ser más grande, más compleja y cambiar más.
Donde el comercio prueba la segmentación una vez al año, el proveedor la prueba cada seis meses y después de cualquier cambio en los controles de segmentación. Y quien aloja a varios clientes tiene además una segunda prueba, sumada a esa.
El estándar da dos opciones al proveedor: hacer una evaluación al año y entregar la prueba a los clientes, o ser evaluado bajo demanda por cada cliente y participar en la evaluación de cada uno. En la segunda, cambias un proyecto al año por una fila de ellos.
Cuál es tu camino
Tu ruta depende de cómo circulan los datos, de a quién atiendes y del volumen que procesas en nombre de terceros. Quien define el límite y la forma de validar son las marcas de tarjeta y el adquirente, no el PCI Security Standards Council.
| Tu perfil | Ruta de validación | Lo que exige |
|---|---|---|
| El dato nunca toca tu entorno | SAQ A | El conjunto más corto de controles. No aplica a proveedor de servicios: es ruta de comercio. |
| El dato pasa por ti, pero vendes a tus propios clientes finales | SAQ D Comercio | La norma completa desde la perspectiva de comercio, sin los requisitos exclusivos de proveedor. |
| Procesas, almacenas o transmites en nombre de otras empresas, dentro del umbral de la marca | SAQ D Proveedor | La norma completa, más los requisitos exclusivos de proveedor, más el apéndice de entorno compartido si alojas a varios clientes. Aquí necesitas describir el resultado de cada prueba, requisito por requisito, y no solo marcar sí o no. |
| Por encima del umbral de la marca, o cuando el adquirente lo exige | Report on Compliance | Evaluación formal conducida por un QSA, en el modelo oficial, con el evaluador confirmando el alcance por su cuenta. Es también el camino para entrar en las listas de proveedores conformes de las marcas. |
Visa publica el límite de 300 mil transacciones al año para separar al proveedor Nivel 1 del Nivel 2: en el Nivel 1 corresponde Report on Compliance por QSA, y en el Nivel 2, autoevaluación. El escaneo externo trimestral, hecho por una empresa aprobada, aplica a los dos niveles. Mastercard usa otro criterio, por categoría de servicio y volumen anual, en programa propio. Confirma tu categoría con el adquirente antes de elegir la ruta.
Lo que solo aplica a ti
El estándar marca estos requisitos como válidos solo para proveedor de servicios. Quien arma el programa a partir de material genérico de PCI DSS simplemente no los ve, y descubre la falta cuando el evaluador pregunta.
Una descripción de todos los algoritmos, protocolos y claves que protegen el dato almacenado, con fortaleza y fecha de vencimiento, más el inventario de los módulos de cifrado, con tipo y ubicación. Y una clave usada en producción no puede reutilizarse en el entorno de pruebas.
Si compartes claves de cifrado con quienes atiendes, necesitas documentar y dar instrucciones sobre cómo transmitir, guardar y actualizar esas claves de forma segura.
Si accedes de forma remota al entorno de quien atiendes, el factor de autenticación debe ser único para cada cliente. La credencial usada en un cliente no puede servir para otro.
Cuando la contraseña es la única forma en que el usuario de tu cliente llega al dato de tarjeta, tienes dos salidas: o cambia cada noventa días, o analizas la situación de la cuenta en tiempo real y decides el acceso en el momento.
Cada seis meses, y después de cualquier cambio en los controles de segmentación, para confirmar que el entorno de tarjeta está aislado de todos los sistemas fuera de alcance. Quien la ejecuta necesita independencia dentro de la empresa, pero no necesita ser QSA.
La detección de intrusiones necesita encontrar, alertar y tratar los canales de comunicación ocultos que usa el malware. Y el plan de respuesta a incidentes necesita prever qué hacer cuando esto se detecte.
La alta dirección asume formalmente la responsabilidad por el programa, con una carta que deja esto registrado y comunicado a ella. Y cada tres meses alguien confirma que las tareas se están haciendo conforme a la política, siempre una persona distinta de quien ejecuta la tarea.
Confirmación de alcance cada seis meses, y una revisión documentada de impacto siempre que la empresa cambie de forma relevante, como fusión, adquisición o cambio de quien responde por los controles, con el resultado comunicado a la dirección.
Un acuerdo por escrito que reconozca que eres responsable de la seguridad del dato que guardas en nombre del cliente. Y responder, cuando lo pidan, a las preguntas sobre tu estado de cumplimiento y sobre quién responde por cada requisito.
Entorno compartido
El estándar trata por separado a quien ofrece servicio compartido a varios clientes, con sistema, infraestructura, aplicación o base de datos en común. El texto menciona por nombre los servicios de gateway y de procesamiento en entorno compartido. Quien solo ofrece centro de datos compartido, el modelo de colocation, queda fuera de este apéndice.
El proveedor no entra al entorno del cliente sin autorización, y el cliente no entra al entorno del proveedor sin autorización. Cada cliente alcanza solo su propio dato de tarjeta y usa solo los recursos reservados para él, sin afectar a los demás.
Cada seis meses, una prueba de penetración confirma que la separación entre los entornos de los clientes está funcionando. El estándar es claro: esta prueba se suma a la de segmentación, no la sustituye. Son dos ejercicios distintos en el mismo semestre.
El registro (log) queda activado por defecto para el entorno de cada cliente y solo el cliente dueño de ese entorno puede consultarlo, con la ubicación del registro comunicada con claridad.
Capacidad de apoyar de inmediato la investigación forense en un incidente de cualquier cliente, y un canal seguro para que los clientes reporten incidentes y vulnerabilidades, con tratamiento y corrección.
Quien opera un entorno compartido necesita apoyar la prueba de penetración externa de los clientes. Y el estándar dice por qué, sin rodeos: prohibirla dejaría los sistemas de ellos abiertos a ataques.
Vale la pena registrar lo que el propio estándar observa: aunque el proveedor cumpla estos requisitos, cada cliente sigue siendo responsable de cumplir y validar los requisitos de su propio entorno. Tu cumplimiento no transfiere cumplimiento a quien atiendes, y prometer eso en la venta se vuelve un problema después.
Lo que entregas a tu cartera
Aquí hay una ventaja competitiva que pocos aprovechan. La forma en que entregas la página de pago decide qué autoevaluación podrá usar tu cliente comercio, y la diferencia entre la más corta y la siguiente es grande. Esto es argumento de venta para tu cartera, y se puede comprobar en el material del PCI Security Standards Council.
| Cómo integras | Autoevaluación de tu cliente | Condición |
|---|---|---|
| Tercerización total, como enlace de pago enviado al tarjetahabiente | SAQ A | La exigencia de proteger la página contra scripts no aplica a este modelo. |
| Redirección del sitio del cliente a tu entorno | SAQ A | La exigencia de scripts tampoco aplica en la redirección, siempre que se cumplan los demás criterios. |
| Página o formulario embebido, típicamente por iframe | SAQ A | Solo si el cliente protege la página por su cuenta, o si le das una confirmación por escrito de que tu solución, instalada según tus instrucciones, protege la página contra ataques de scripts. |
| El sitio del cliente controla el flujo y afecta la integridad de la página | SAQ A-EP | Bastante más extenso. Si alojas el sitio y operas un entorno compartido, cumplir el apéndice de multicliente es prerrequisito para que tu cliente sea elegible. |
| El dato de tarjeta llega al propio sitio del cliente | SAQ D Comercio | El entorno del cliente entra completo en el alcance. |
La tercera línea es la oportunidad. El proveedor que integra la gestión de scripts y la detección de alteraciones dentro de su propia solución de iframe, y emite la confirmación por escrito, mantiene a su cartera en la autoevaluación más corta en vez de empujarla a la siguiente. Quien no lo hace, empuja. La decisión final sobre qué autoevaluación aplica siempre es del adquirente o de la marca del cliente.
Quién hace qué
En un mercado donde se promete un certificado que no se puede emitir, preferimos dejar claro desde ya quién firma qué. Esto cambia lo que debes exigirnos a nosotros y lo que necesitas resolver con otros.
Autodiagnóstico
Las primeras preguntas clasifican tu caso y señalan la ruta de validación. Las demás recorren los capítulos de la norma y muestran dónde están las brechas. El resultado aparece completo en pantalla, con la ruta, la nota de cada capítulo y qué cierra cada brecha. Y no pedimos correo electrónico para mostrarlo.
Cómo trabajamos
Cada fase termina con un entregable. Sabes qué recibes antes de empezar.
Mapeamos el flujo del dato, los sistemas conectados y los que afectan la seguridad del entorno. Separamos la vía de comercio de la de proveedor cuando la empresa acumula ambos roles, porque tratar las dos como una sola distorsiona todo lo demás.
Lo que recibes
Antes de instalar controles, quitamos del camino lo que no necesita estar dentro de alcance. Segmentación, fin del almacenamiento innecesario y revisión de integración reducen el programa entero de una sola vez.
Lo que recibes
Ejecutamos junto con tu equipo lo que falta en cada capítulo, con atención especial a los requisitos exclusivos de proveedor y al apéndice de entorno compartido, que suelen quedar fuera.
Lo que recibes
El cumplimiento de proveedor es calendario, no proyecto. Estructuramos las revisiones trimestrales, la confirmación de alcance cada seis meses, las pruebas de penetración con la frecuencia correcta y el escaneo trimestral.
Lo que recibes
Armamos lo que la debida diligencia de tus clientes va a pedir: matriz de responsabilidades por requisito, acuerdo por escrito de responsabilidad y el proceso de respuesta a las solicitudes de estado.
Lo que recibes
Organizamos la prueba en el formato que espera el evaluador y hacemos un ensayo antes de la evaluación real. Cuando la ruta es Report on Compliance, nos alineamos con el QSA aliado, manteniendo los roles separados.
Lo que recibes
Historias
Cambiamos los nombres de los clientes por el mismo sigilo que va a proteger a tu empresa después. Los nombres cambian, y el patrón de los problemas se repite.
Preguntas frecuentes
Respuestas basadas en el estándar del PCI Security Standards Council y en los programas de las marcas. Donde no existe un dato oficial, decimos que no existe.
No. DM11 no es QSA y no emite el Report on Compliance, la atestación ni ningún certificado. Nosotros preparamos: diseñamos y reducimos el alcance, instalamos los controles, armamos las rutinas recurrentes, hacemos la prueba de penetración de segmentación y organizamos la prueba. Cuando tu ruta exige evaluación formal, quien la conduce es un QSA aliado acreditado, con los roles separados entre quien preparó y quien evalúa.
¿Más dudas? Habla con DM11
Una conversación de treinta minutos suele bastar para separar lo que es obligación de proveedor, lo que es de comercio y qué ruta de validación aplica a tu caso. Sin compromiso.