El cuestionario de autoevaluación (SAQ) de PCI DSS, explicado

Un cuestionario de autoevaluación (SAQ) es el documento que los comercios y proveedores de servicios utilizan para validar el cumplimiento de PCI DSS sin pasar por una auditoría completa en sitio. Respondes a un conjunto fijo de preguntas sobre los controles que aplican a cómo aceptas tarjetas, firmas una atestación de cumplimiento (AoC) y entregas ambos documentos a tu adquirente o a la marca de pago. Es la vía que toman la mayoría de comercios pequeños y medianos: un Report on Compliance (ROC) completo, firmado por un QSA, solo se exige en los tramos de transacciones más altos o cuando una marca lo pide expresamente.

El SAQ no es un único documento. Hay nueve variantes en PCI DSS v4.0.1, y elegir la correcta es la decisión más importante de todo el proceso. Si eliges un SAQ demasiado estrecho, estás atestando controles que en realidad no cubren tu flujo de pago, lo que supone una brecha de cumplimiento y un problema de responsabilidad ante un incidente. Si eliges uno demasiado amplio, te pasas meses respondiendo preguntas inútiles sobre sistemas que nunca tocan datos del titular.

Los tipos de SAQ y para quién son

Cada SAQ apunta a una forma concreta de aceptar pagos. La pregunta clave es siempre la misma: ¿tu entorno llega a almacenar, procesar o transmitir datos del titular de la tarjeta y, si lo hace, cómo?

SAQ A

Para comercios de comercio electrónico con tarjeta no presente que han externalizado por completo el manejo de los datos del titular a un tercero validado contra PCI DSS. Tu web redirige o incrusta un iframe de un proveedor de servicios de pago: tus servidores nunca ven los números de tarjeta. SAQ A es la variante más corta (alrededor de 30 preguntas en v4.0.1) y la que completan la mayoría de comercios online pequeños. Aun así tienes que confirmar que tu sitio no puede ser manipulado para redirigir a los clientes a una página de pago falsa, y por eso SAQ A en la v4 añadió requisitos de integridad de scripts y detección de cambios.

SAQ A-EP

Para comercios de comercio electrónico que externalizan la página de pago pero cuya web sigue controlando cómo se carga el formulario de pago: por ejemplo, sirves la página que contiene el iframe, o tu JavaScript construye la solicitud de pago. Tus servidores no almacenan datos de tarjeta, pero sí pueden influir en la página que los captura. SAQ A-EP es mucho más largo que SAQ A (alrededor de 150 preguntas) porque tu infraestructura web entra en el alcance.

SAQ B

Para comercios que usan únicamente terminales de pago autónomas con marcación telefónica (no IP) o máquinas de impresión. Sin conexión a internet ni almacenamiento electrónico. Es raro en 2026, pero sigue siendo válido para algunos minoristas presenciales de bajo volumen.

SAQ B-IP

Para comercios que usan dispositivos autónomos de entrada de PIN conectados por IP. El terminal está en la red, pero ningún otro sistema almacena, procesa ni transmite datos del titular. Conjunto de preguntas menor que el de SAQ C.

SAQ C

Para comercios con sistemas de aplicaciones de pago conectados a internet, lo habitual en configuraciones de TPV pequeñas en tienda. Los sistemas que intervienen en los pagos están aislados del resto de tu red.

SAQ C-VT

Para comercios que teclean los datos de la tarjeta en una terminal virtual sobre un dispositivo aislado conectado a un procesador de pagos validado contra PCI. No se almacenan datos de tarjeta en local.

SAQ P2PE

Para comercios que usan únicamente soluciones P2PE incluidas en la lista de PCI. Es el SAQ presencial más corto, porque el proveedor de la solución P2PE ha hecho el trabajo pesado y tu entorno se considera fuera de alcance para la mayoría de los controles.

SAQ D para comercios

El cajón de sastre. Si tu entorno de pago no encaja en ninguno de los anteriores —por ejemplo, almacenas datos del titular, aceptas varios canales con controles distintos o tienes una integración a medida—, rellenas el SAQ D. Cubre los 12 requisitos de PCI DSS y llega a unas 330 preguntas.

SAQ D para proveedores de servicios

El equivalente para proveedores de servicios. Cualquier proveedor de servicios validado contra PCI que pueda autoevaluarse (a la mayoría se les exige un ROC) usa este.

Cómo funciona en realidad el proceso del SAQ

El cuestionario en sí es solo una parte del trabajo. El PCI Security Standards Council publica cada SAQ como un PDF que rellenas, pero para atestar con honestidad tienes que hacer cuatro cosas en orden.

1. Define el alcance de tu entorno de datos del titular. Mapea cada sistema, proceso y tercero que almacene, procese o transmita datos del titular, más todo lo que esté conectado a esos sistemas. Subestimar el alcance del CDE es el motivo más común por el que los SAQ acaban siendo, en la práctica, falsos. El alcance del entorno de datos del titular (CDE) debe documentarse: los auditores y los investigadores forenses pedirán el diagrama de red.

2. Elige el tipo de SAQ correcto. Usa los criterios de elegibilidad que aparecen al principio de cada SAQ. Si aceptas tarjetas por más de un canal —digamos comercio electrónico más teléfono—, normalmente tienes que completar un SAQ por cada canal, o recurrir al SAQ D.

3. Comprueba cada requisito. Un SAQ no es una lista de buenas intenciones. Cada pregunta cuestiona si un control está implantado, y la respuesta debe sustentarse en evidencia (políticas, configuraciones, registros, muestras de datos). «Implantado» significa probado en los últimos 12 meses.

4. Firma la atestación de cumplimiento. La AoC es el documento con peso legal. La firma un directivo de la empresa y se entrega a tu adquirente. Una atestación falsa se trata con dureza si más tarde un incidente revela que los controles no estaban implantados.

Qué cambió en PCI DSS v4.0.1

Las versiones actuales de los SAQ reflejan PCI DSS v4.0.1, publicada en junio de 2024. El plazo de transición a la v4 venció el 31 de marzo de 2025, así que todo SAQ que se presente hoy debería ser contra la v4.0.1: la v3.2.1 está retirada. Los dos cambios que pillan desprevenidos a la mayoría de comercios:

• Gestión de scripts en las páginas de pago (Requisito 6.4.3 + 11.6.1). Incluso los comercios de SAQ A tienen ahora que inventariar los scripts cargados en las páginas de pago y detectar cambios no autorizados. Fue una respuesta directa a los ataques de skimming tipo Magecart.
• Opción de enfoque personalizado. Para la mayoría de los controles, ahora puedes cumplir la intención de un requisito por medios alternativos, pero tienes que documentar la implementación personalizada y someterla a revisión. El enfoque personalizado no está disponible para los comercios de SAQ A.

Dónde fallan la mayoría de los SAQ

Tres patrones que vemos una y otra vez al revisar la postura de cumplimiento de los comercios:

Tratar los pagos telefónicos como fuera de alcance. Un comercio completa el SAQ A de su web y se olvida de que el centro de llamadas también acepta pagos con tarjeta no presente por teléfono. El canal telefónico mete a todo el centro de contacto —agentes, sistemas de grabación, captura de pantalla, CRM— dentro del CDE. El enmascaramiento DTMF para pagos telefónicos es la forma estándar de volver a reducir ese alcance. Sin él, el SAQ A no te cubre y casi con seguridad necesitas el SAQ D.

Subestimar el alcance de la red. Todo lo conectado al CDE —hasta una impresora o un puesto de trabajo— está en el alcance. «Conectado a» incluye las VLAN compartidas, los sistemas de autenticación compartidos y las redes de gestión.

Evidencia caducada. Las preguntas dicen «¿está el control implantado?», pero la evidencia que respalda un sí tiene que estar vigente. Una prueba de penetración de hace 18 meses, un escaneo de vulnerabilidades del año pasado, una política sin revisar desde 2022: todo eso significa que la respuesta debería ser no.

SAQ A frente a SAQ D para centros de contacto

Si aceptas cualquier pago con tarjeta por teléfono y tus agentes pueden oír los números de tarjeta, no eres elegible para el SAQ A por muy segura que sea tu plataforma de comercio electrónico. Los pagos telefónicos meten tu centro de contacto en el CDE. Para mantenerte en SAQ A —o para dejar un centro de llamadas completamente fuera de alcance— necesitas una solución de pago telefónico que impida que el agente oiga los tonos DTMF o vea los dígitos. El cumplimiento de PCI en centros de contacto explica la arquitectura. Bien hecho, ni el agente ni el sistema de grabación reciben nunca datos del titular, así que el centro de contacto vuelve a quedar fuera de alcance y el SAQ A vuelve a ser válido.