Las necesarias hacen funcionar el sitio. Las demás miden qué páginas ayudan y qué anuncios traen a quien necesita a DM11. Tú eliges, y puedes revisarlo desde el pie de página.
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.
Depende de tu nivel, que definen las marcas y administra el adquirente, no el PCI SSC. Visa publica el límite de 300 mil transacciones al año: por encima, proveedor Nivel 1, con Report on Compliance por QSA; por debajo, Nivel 2, con autoevaluación. Mastercard usa categoría de servicio y volumen anual en programa propio. El escaneo externo trimestral por empresa aprobada aplica a los dos niveles. Confirma tu categoría con tu adquirente antes de decidir.
Solo existe uno: el SAQ D para proveedores de servicios. Y aplica solo a quien la marca considera elegible para autoevaluación. Incluye todos los requisitos exclusivos de proveedor y el apéndice de entorno compartido, que no existen en el SAQ de comercio. Otra diferencia que sorprende a quien viene del mundo del comercio: la versión actual pide describir el resultado de la prueba de cada requisito, y no solo marcar si se cumple.
El estándar prevé exactamente esta situación: los requisitos marcados como exclusivos de proveedor aplican a la parte del negocio que presta el servicio. En la práctica, son dos vías de alcance dentro de la misma evaluación, y tratar las dos como una sola distorsiona el dimensionamiento. Es una de las primeras cosas que separamos al inicio del proyecto, porque todo lo que viene después depende de esto.
Además de una lista de requisitos que simplemente no existe para comercio, cambia la frecuencia de rutinas importantes. La confirmación de alcance pasa de anual a semestral. La prueba de penetración de segmentación pasa de anual a semestral, y también después de cualquier cambio en los controles de segmentación. Entran revisiones trimestrales de ejecución, hechas por quien no ejecuta la tarea, y la responsabilidad formal de la dirección por el programa. El propio estándar explica por qué: la red del proveedor es más grande, más compleja y cambia más.
Agrega un apéndice entero, que el estándar creó para este caso y en el cual menciona por nombre los servicios de gateway y de procesamiento en entorno compartido. Exige separación en ambos sentidos entre proveedor y cliente, garantía de que un cliente no llega al dato ni a los recursos de otro, registro por cliente visible solo para el dueño, canal para reportar incidentes y apoyo a la investigación forense. Y exige una prueba de penetración cada seis meses de la separación entre clientes, que el estándar dice de forma expresa que se suma a la prueba de segmentación. Son dos ejercicios distintos en el mismo semestre. Quien ofrece solo centro de datos compartido, en el modelo de colocation, queda fuera de este apéndice.
No, y prometer eso en la venta se vuelve un problema después. El estándar registra que, aunque el proveedor cumpla los requisitos del entorno compartido, cada cliente sigue siendo responsable de cumplir y validar los requisitos de su propio entorno. Lo que haces por el cliente es reducir su esfuerzo, entregar prueba y asumir la parte que te corresponde en la matriz de responsabilidades. Es bastante, y se puede vender, pero no es transferencia de cumplimiento.
Afecta bastante, y es una palanca comercial que pocos aprovechan. Si entregas por redirección o tercerización total, la exigencia de proteger la página contra scripts no recae sobre el cliente. Si entregas página embebida por iframe, el cliente solo sostiene la autoevaluación más corta si protege la página por su cuenta o si recibe de ti la confirmación por escrito de que tu solución, instalada según tus instrucciones, protege contra ataques de scripts. El proveedor que instala el inventario de scripts y la detección de alteraciones y emite esa confirmación mantiene a su cartera en la ruta más corta. Quien no lo hace, empuja al cliente a la siguiente ruta, que es bastante más extensa.
Vale la pena, con una salvedad. El estándar reconoce que estar en la lista de una marca puede ser prueba suficiente para que el cliente cumpla el seguimiento anual de estado, siempre que quede claro que los servicios que contrató estaban cubiertos por la evaluación. Pero para demostrar los requisitos que cumples en nombre del cliente, la lista no basta: se espera que entregues la atestación cuando la pidan. En las dos marcas principales, el camino para entrar en la lista pasa por evaluación formal con QSA y por un registro hecho por el adquirente o por la institución que te patrocina.
Se puede, y el estándar prevé esa opción, pero vale la pena entender lo que significa en la práctica. Las dos alternativas oficiales son: 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, entregando el resultado a cada uno. En la segunda, cambias un ejercicio al año por una fila de ellos, con equipos distintos, plazos distintos y alcances distintos. Para quien tiene una cartera relevante, suele salir más caro en dinero y en tiempo de equipo técnico.
Es la novedad de la versión 4 que permite cumplir el objetivo de un requisito con un control distinto del que describe el estándar. El texto es claro sobre a quién sirve: empresas maduras en gestión de riesgo, dispuestas a un esfuerzo de documentación y validación mayor que el del enfoque tradicional. Exige matriz de controles, análisis de riesgo por control y prueba documentada de eficacia, y necesita ser documentado por un QSA o por un evaluador interno calificado. Quien hace autoevaluación no puede usarlo. Tampoco combina con control compensatorio. Suele tener sentido en arquitecturas modernas, donde el control real no se parece al texto del estándar.
La v4.0.1, publicada en junio de 2024. La v4.0 se retiró en diciembre de 2024, así que es la única versión activa. La plantilla de Report on Compliance está en la revisión 3, de enero de 2025. Vale la pena registrar la fecha que sorprende a muchos: la mayor 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. Un programa documentado antes de eso y no revisado probablemente tiene brechas.
Depende de dos cosas que solo quedan claras en el diagnóstico: el tamaño real del alcance y cuánto de él se puede reducir desde el principio. No publicamos un plazo estándar porque sería una suposición, y porque el PCI SSC no divulga duración típica de proyecto. Lo que se puede decir con seguridad es que la definición de alcance es lo que más mueve el cronograma, y que contratar la evaluación antes de saber el tamaño del entorno suele costar un ciclo entero.
El PCI SSC no publica estadísticas de rechazo, así que no repetimos rankings de blog. Lo que el propio material oficial advierte es útil y se puede verificar: el requisito no cuenta como cumplido solo por estar planificado para después; la respuesta no puede copiarse de otro requisito ni del ciclo anterior; y un requisito excluido sin análisis debe marcarse como no probado, lo que aparece en la atestación como evaluación parcial. Del lado del alcance, la regla práctica publicada es empezar asumiendo que todo está dentro de alcance hasta probar lo contrario, y el evaluador confirma el alcance por su cuenta, anotando dónde discrepó del tuyo.
¿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.