El SAQ (“PCI DSS Self-Assessment Questionnaire” – Cuestionario de Auto-evaluación de PCI DSS) es una lista de validación (“checklist”) que le permite a determinados comercios y proveedores de servicio (en función de la cantidad de transacciones anuales que procese) presentar su estado de cumplimiento con PCI DSS posterior a un ejercicio de auto-evaluación, a diferencia de un RoC (Report on Compliance – Reporte de Cumplimiento) que debe ser rellenado por un Asesor QSA (Qualified Security Assessor) o un ISA (Internal Security Assessor) luego de una auditoría detallada.

Uno de los principales inconvenientes durante el proceso de rellenado del SAQ es que, al ser un documento de auto-evaluación, la persona o equipo a quien se le ha delegado la tarea de revisión interna de cumplimiento de PCI DSS puede no tener experiencia con este estándar o desconocer al argot técnico usado en el documento, con lo cual se puede contestar de forma errónea.

Para evitar estos problemas, a continuación se paso a paso el proceso de rellenado del SAQ, describiendo cada una de sus secciones y aclarando algunos puntos que pueden ser susceptibles de error.

Antes de proceder, recomendamos la lectura de los siguientes artículos introductorios a aquellos lectores que no se encuentran familiarizados con los documentos de auto-evaluación de PCI DSS:

 

Notas generales

  • Antes de empezar con el proceso de rellenado del SAQ/AoC, se debe validar que el documento corresponde a la última versión de PCI DSS.  Las versiones actualizadas de los cuestionarios de auto-evaluación se pueden encontrar en el sitio web del PCI SSC bajo el apartado “Biblioteca de documentos” (“Document Library”).
  • Los documentos del SAQ/AoC provistos por el PCI SSC se encuentran en formato PDF y MS DOCX. Estos documentos no deben ser modificados de ninguna manera (salvo los apartados explícitamente indicados) ni se debe retirar ninguna sección. No es aceptable la inserción de logos o imagenes, con el fin de garantizar la integridad del formulario.
  • El PCI SSC ha publicado versiones del SAQ/AoC en diferentes idiomas. Si la última versión del SAQ no se encuentra traducida, es indispensable rellenar la versión en inglés.
  • La “Sección 3: Detalles de la validación y la atestación” requiere de la firma escrita del comerciante y del QSA/ISA (si aplica). En este caso, la hoja debe ser impresa, firmada, escaneada y agregada a la versión digital (a menos que la entidad adquiriente solicite el SAQ impreso)
  • Siempre guarde una copia del SAQ y del AoC (Attestation on Compliance) y exija que su adquiriente confirme por escrito la recepción del documento. Tanto el SAQ como el AoC serán los primeros documentos que se le solicitarán en caso de detección de un incidente de seguridad con el fin de identificar los canales afectados y potencial afectación de datos de tarjeta de pago.
  • Recuerde que el SAQ y el AoC son documentos vinculantes. En caso de un incidente, si el SAQ no concuerda con la realidad del entorno afectado, el comercio o proveedor de servicios deberá asumir enteramente todos los costes derivados del problema (investigaciones legales y forenses, multas, demandas, etc.)

Antes de comenzar

Tal como su nombre lo indica, esta sección es una introducción al SAQ. Es imprescindible su lectura y comprensión antes de empezar con el proceso de rellenado del documento. Igualmente, se recomienda leer el documento “Self-Assessment Questionnaire – Instructions and Guidelines“, en el que se ofrecen más detalles respecto al objetivo y alcance de los cuestionarios de auto-evaluacion, así como el proceso de reporte y selección de SAQ.

Pasos para la realización de la auto-evaluación de PCI DSS

El primer paso de todo este proceso es validar que el canal de pago a ser reportado coincida totalmente con los criterios del SAQ a rellenar. Si estos criterios no aplican o el escenario (comercio electrónico, pagos telefónicos, transacciones presenciales, uso de terminales de pago virtuales, soluciones P2PE, etc.) no coincide con el tipo SAQ que se va a rellenar, lo más probable es que se tenga que rellenar un SAQ D. En este caso, se debe consultar con la entidad adquiriente, quien indicará el tipo de SAQ a reportar.

Flujograma de aplicabilidad de las diferentes versiones de SAQ dependiendo del canal de pago a reportar

Igualmente, en este apartado se ofrece una guía respecto a las respuestas de cada uno de los controles de la sección 2 “Cuestionario de Auto-evaluación”. En este caso, solamente se seleccionar una respuesta para cada pregunta:

Tipos de respuesta de cumplimiento a los controles de PCI DSS en los SAQ

En el apartado “Guía para la no aplicabilidad de ciertos requisitos específicos” se indican los criterios a tener en cuenta en el caso que ciertos controles del estándar no apliquen en determinados escenarios. No obstante, en el “Anexo C: Explicaciones de no aplicabilidad” se revisará este tema a fondo y se tendrá que justificar dicha respuesta.

Finalmente, en el apartado “Excepción legal” se indica la posibilidad que algunos controles no se puedan cumplir íntegramente debido a la existencia de restricciones legales del país o región en la que se encuentre el comercio o proveedor de servicios.

Ejemplo:

En el control 9.1.1: Por consideraciones legales en España las grabaciones de un sistema de circuito cerrado de televisión (CCTV) no se pueden almacenar más de un mes debido a la LOPD (Ley Orgánica de Protección de Datos), aunque el estándar PCI DSS indique que se deben almacenar tres meses como mínimo.

En este caso, dichos controles se deben responder como “NO” y luego justificarlo en “Sección 3: Detalles de la validación y la atestación”.

Ejemplo de excepción legal al cumplimiento de un control de PCI DSS (en este caso, debido a la LOPD española)

Sección 1: Información sobre la evaluación

El objetivo de esta seccion es demostrar que la Dirección apoya el proceso de cumplimiento de PCI DSS y definir un responsable en la organización encargado de esta tarea y – por otro lado –  describir el tipo de canales de pago empleados, el ámbito de cumplimiento y los terceros vinculados en el proceso.

Esta sección cuenta con dos partes:

  1. Parte 1. Información sobre el comerciante (o proveedor de servicios) y el asesor de seguridad certificado
  2. Parte 2. Resumen ejecutivo

Parte 1. Información sobre el comerciante (o proveedor de servicios) y el asesor de seguridad certificado

La “Parte 1. Información sobre Comerciante y Asesor de Seguridad Certificado” debe ser rellenada con los datos del responsable de la organización y de su asesor QSA en el caso que aplique.

La “Parte 1a. Información de la organización del comerciante” debe ser rellenada con los datos del responsable del cumplimiento de PCI DSS en la empresa, preferiblemente alguien del área directiva (CEO, CIO, CTO, CISO, CFO, etc.). Esta persona actuará como contacto en caso de que se requiera alguna comunicación por parte de los adquirientes o las marcas con el comercio o proveedor de servicios que está reportando el SAQ.

El apartado DBA (“Doing Business As” – Operando bajo el nombre de) se debe rellenar solamente en el caso que la empresa cuente con un nombre comercial u operativo diferente al nombre legal con el que se encuentra en el registro mercantil de su país. Si no aplica, simplemente indicar “No Aplica” o dejarlo vacío.

Parte 1a. Información sobre el contacto de la organización

La “Parte 1b. Información de la empresa del evaluador de seguridad certificado (QSA) (si corresponde)” solamente se debe rellenar en el caso que el comercio  o proveedor de servicios cuente con el soporte de un Asesor QSA en el proceso de rellenado del SAQ. Esto puede ocurrir por varias razones:

  • El comercio o proveedor de servicios considera que internamente no cuenta con la experiencia necesaria para rellenar el SAQ o quiere garantizar independencia en la auto-evaluación y contrata los servicios de un QSA
  • El adquiriente o las marcas han forzado al comercio a trabajar con un QSA debido a errores recurrentes detectados en SAQ presentados previamente y quieren garantizar que el SAQ coincida con el entorno real reportado
  • El comercio o proveedor de servicios ha tenido un incidente de seguridad relacionado con datos de tarjetas de pago en el pasado y las marcas o el adquiriente obliga a que se reporte el SAQ posterior a la revisión de un QSA

En el caso que no se cuente con el soporte de un QSA, dejar este apartado en blanco.

Parte 1b. Información de la empresa QSA que acompaña el proceso de rellenado del SAQ

Parte 2. Resumen ejecutivo

En este apartado se realiza una descripción de los canales de pago y el entorno de aplicabilidad de PCI DSS. En la “Parte 2a. Tipo de actividad comercial del comerciante” se deben marcar TODAS las actividades comerciales a las que se dedica la organización y que tienen relación directa o indirecta con datos de tarjetas de pago, seleccionando todas las opciones que apliquen. En el caso que la actividad no se encuentre explícitamente indicada, simplemente describirla en la sección “Otros”.

En la pregunta “¿Cuáles son los tipos de canales de pago a los que presta servicios su empresa?” se deben seleccionar TODOS los canales por los cuales se reciben transacciones con tarjetas de pago:

  • Transacciones en las que el cliente no está presente y se realiza validación empleando el CVV2:
    • Pedidos por correo/Teléfono (MOTO – Mail Order / Telephone Order): En esta categoría se encuentran call centers, servicios de atención telefónica, ventas por correo en los que el cliente registra sus datos de tarjeta en papel y los envía por correo, etc.
    • Comercio electrónico: En esta categoría están las tiendas online que capturan el dato de la tarjeta empleando formularios en browsers
  • Transacciones en las que el cliente está presente y se realiza validación empleando el PIN:
    • Tarjeta presente (en persona): En esta categoría están los comercios que reciben pagos a través de dispositivos TPV (Terminal de Punto de Venta – POS) mediante lectura física de la tarjeta (lectura de banda, NFC, chip EMV).

En la pregunta “¿Cuáles son los canales de pago que este SAQ abarca?“, el comercio o proveedor de servicio debe marcar el canal que se reporta en ese SAQ. Al respecto, se tienen dos opciones:

  1. Si el comercio tiene múltiples canales de pago y quiere reportarlos todos en un único SAQ, puede hacerlo siempre y cuando dichos canales cumplan las premisas de aplicabilidad del SAQ que va a presentar. Por ejemplo: Si se tiene un canal de comercio electrónico (SAQ A / SAQ A-EP) y un canal de pago presencial con TPV físico (SAQ B / SAQ B-IP) puede optar por rellenar un SAQ D y poner en N/C aquellos controles que no se requieren en ninguno de estos dos SAQ. Hay que recordar que el SAQ es simplemente un subconjunto de controles del estándar PCI DSS que aplican a un canal en particular.
  2. Si el comercio tiene múltiples canales de pago y presenta un SAQ por cada canal. Esto es viable siempre y cuando el comercio garantice que existe una adecuada segmentación y aislamiento entre los distintos canales y que no hay procesamiento, almacenamiento o transmisión que se solape entre ellos.

Parte 2a. Tipo de actividad comercial del comerciante

La “Parte 2b. Descripción del negocio de tarjeta de pago” debe describir de forma detallada los siguientes puntos:

  • Canales de pago presentes (y reportados en el SAQ) y la forma cómo se capturan, se transmiten y se procesan los datos de tarjeta de pago en el entorno
  • Cantidad de datos de tarjetas de pago almacenados, procesados y/o transmitidos anualmente. Es MUY IMPORTANTE que este dato quede claro. Si la organización lo desconoce, puede preguntarlo a su adquiriente. No es necesario que sea un dato exacto, puede ser una aproximación realista.

Ejemplo:

Tiendas XYZ cuenta con un canal de pago online (comercio electronico) con captura de datos de tarjeta de pago empleando un formulario propio y enviado directamente al centro autorizador empleando POST a través de un canal HTTPS.

Se reciben aproximadamente 1 millón de transacciones de pago al año a través de este canal. No se almacenan datos completos del PAN, solamente 6 primeros y 4 últimos dígitos para temas de atención al cliente.

Parte 2b. Descripción del negocio de tarjeta de pago

La “Parte 2c. Ubicaciones”  debe enumerar TODAS las ubicaciones en las cuales se procesan, almacenan y/o transmiten datos de tarjetas de pago vinculadas con el canal presentado en el SAQ. En le caso que sean varias ubicaciones con características similares en una misma área geográfica, indicar la cantidad de instalaciones de ese tipo.

Parte 2c. Ubicaciones

La “Parte 2d. Aplicación de pago” requiere que se listen las aplicaciones de pago empleadas en la empresa. Una aplicación de pago es una aplicación de software que procesa, almacena o transmite datos de tarjetas de pago como parte de los procesos de autorización y liquidación de la transacción. Estas aplicaciones pueden ser desarrolladas internamente o pueden ser adquiridas bajo licencia, en cuyo caso esta aplicación debe cumplir con el estándar PA-DSS y estar listada en el sitio web del PCI SSC. En ambos casos se debe describir el nombre de la aplicación, la versión de la misma en el momento de reporte del SAQ, el nombre del proveedor (si es un desarrollo interno, simplemente indicarlo) y si se encuentra o no en las listas de PA DSS y su fecha de expiración.

Parte 2d. Aplicación de pago

La “Parte 2e. Descripción del entorno” es la parte más técnica del SAQ. En ella se deben indicar en términos generales las tecnologías (sistemas operativos, bases de datos, equipos activos de red, aplicaciones), configuraciones, soluciones de seguridad (FIM, antivirus, firewalls, IDS/IPS, gestión de logs, WAF, etc.)  y flujos de datos de tarjeta e indicar si se ha usado la segmentación para aislar dicho entorno del resto de la red corporativa.

Ejemplo:

El entorno de comercio electrónico de Tiendas XYZ comprende dos servidores frontales Apache v2.4 con mod_security v2.9 como WAF, en donde reside el aplicativo de pago desarrollado en PHP. El sistema operativo de los servidores es RedHat Enterprise Linux 7.3. Se cuenta con una base de datos MySQL v5.7 con almacenamiento de datos de tarjeta de pago empleando cifrado simétrico con AES256. El entorno está protegido por un firewall IPTABLES, antivirus ClamAv 0.99, Wazuh 2.0 (FIM), SNORT IDS 3.0 y Graylog como SIEM.  Se usa autenticación centralizada con Red Hat Directory Server y acceso remoto vía SSH v2 con MFA empleando FreeIPA+FreeOTP. Los equipos están virtualizados empleando KMV. Se cuenta con un par de conmutadores Cisco Catalyst 2960-X. El entorno es exclusivo para PCI DSS, por lo que no se realiza segmentación.

Se reciben datos de tarjeta de pago (PAN, nombre de titular, fecha de expiración y CVV2) en un formulario web. Estos datos son transmitidos del browser del usuario al servidor empleando HTTPS vía TLS 1.2. Para autenticación, se realiza una conexión punto a punto con el centro autorizador.

Parte 2e. Descripción del entorno

La “Parte 2f. Proveedores de servicio externos” describe las conexiones con terceros con los cuales se comparten los datos de tarjeta de pago por cualquier razón de negocio y/o técnica. Estos proveedores de servicio deben estar cubiertos por el control 12.8 de gestión de proveedores.

La pregunta “¿Su empresa utiliza un Integrador o revendedor certificado (QIR)?” se debe rellenar única y exclusivamente si la empresa ha contratado los servicios de un QIR (“Qualified Integrator or Reseller”), que son empresas autorizadas para implementar, configurar y/o soportar aplicaciones validadas como PA-DSS.

En el siguiente campo se deben listar los proveedores de servicio y los servicios contratados.

Parte 2f. Proveedores de servicio externos

Para cerrar este apartado, la “Parte 2g. Elegibilidad para completar el SAQ” incluye una lista de validación de todas las premisas del entorno de pagos que deben ser cumplidas para presentar una versión específica del SAQ. Es importante que todas las casillas (excepto las opcionales, que vienen identificadas con itálica) sean rellenadas. Si un criterio no se cumple, lo más probable es que se esté empleando la versión incorrecta del SAQ.

Parte 2g. Elegibilidad para completar el SAQ

Sección 2: Cuestionario de Auto-evaluación

Esta sección contiene los resultados de la validación de la auto-evaluación por cada uno de los controles del SAQ. Está compuesto de las siguientes partes:

  • Pregunta de las PCI DSS: Control de seguridad incluyendo su numeracion en el estándar PCI DSS
  • Pruebas esperadas: Con el fin de validar la validez de la implementación del control en el entorno, en esta columna indica las pruebas que deben ser realizadas (entrevistas, revisión documental y de diagramas, verificaciones de configuración técnica, observación de ejecución de procedimientos, observación de controles de seguridad física, etc.).
  • Respuesta: Dependiendo de los resultados de las pruebas esperadas, el control se debe reportar de acuerdo con los criterios listados en la sección “Antes de comenzar”: SI, SI CON CCW, NO, C/C y NO PROBADO. Solamente se debe marcar un valor por respuesta y todos los controles del SAQ deben ser respondidos.

Sección 2: Cuestionario de autoevaluación

Anexo A: Requisitos adicionales de PCI DSS

Estos anexos deben ser rellenados si el comercio o proveedor de servicios está sujeto a alguna de las siguientes condiciones:

  • Anexo A1: Requisitos adicionales de las PCI DSS para proveedores de hosting compartido: Solamente aplica para proveedores de servicio. Debe ser rellenado en el caso que se ofrezcan servicios de hosting compartido en donde puedan existir sistemas dentro del alcance de PCI DSS
  • Anexo A2: Requisitos adicionales de las PCI DSS para las entidades que utilizan SSL/TLS temprana: En el caso que el comercio o proveedor de servicios emplee algún canal que transmita datos de tarjeta de pago con protocolos SSL o versiones de TLS temprana, debe rellenar este anexo. Para ello, se debe disponer de un plan de migración y mitigación de riesgos. Mayor información en el artículo “5 conceptos claves en el proceso de migración de SSL y versiones anteriores de TLS
  • Anexo A3: Validación suplementaria de las entidades designadas (DESV): Este anexo solamente se debe rellenar en el caso que una marca de pago o un adquiriente requiera la realización de verificaciones adicionales en el entorno. El formulario de DESV se debe rellenar aparte y se encuentra disponible para descarga en el sitio web del PCI SSC.

Anexo B: Hoja de trabajo de controles de compensación

En el caso que alguno de los controles de la “Sección 2: Cuestionario de Auto-evaluación” haya sido declarado como “SI CON CCW” se debe proceder a listar el control en esta tabla y describir las limitaciones, objetivo, riesgo identificado, controles compensatorios definidos y mantenimiento de los mismos.  Para mayor información acerca de controles compensatorios (o de compensación) revisar el artículo: Controles compensatorios: ¿Qué son y cuándo se utilizan?. Se debe rellenar una tabla por cada control compensatorio definido.

Anexo B de PCI DSS: Hoja de trabajo de controles de compensación

Anexo C: Explicaciones de no aplicabilidad

Al igual que con los controles compensatorios, en esta tabla se deben enumerar todos los controles del SAQ que fueron catalogados como N/C (No corresponde). Se debe listar el código del control y ofrecer una explicación válida y descriptiva de la no aplicabilidad de dicho control en el entorno.

Anexo C: Explicaciones de no aplicabilidad

Anexo D: Explicación de los requisitos no probados

En el “Anexo D: Explicación de los requisitos no probados” se debe proceder igual que con el Anexo C: Listar aquellos controles que fueron catalogados como “No Probado”, indicar qué parte o partes no fueron probadas y su justificación.

Anexo D: Explicación de los requisitos No probados

En este punto es muy importante comprender las diferencias entre “N/C” (No Corresponde) y “No Probado”:

Descripción del valor “No Probado”

 

Sección 3: Detalles de la validación y la atestación

Esta sección contiene el resultado general de la auto-evaluación. La “Parte 3. Validación de la PCI DSS” concluye si el ejercicio concluye que la organización está en alguno de los siguientes estados:

  • En cumplimiento: En este caso, todos los controles han sido contestados como “SI” o con alguna de las siguientes opciones: “SI CON CCW”, “N/C” o “No probado”. En este último caso, se deben rellenar los anexos  B, C y D descritos anteriormente.
  • Falta de cumplimiento: Si alguno de los controles fue contestado como “NO” entonces la organización se encuentra en estado FALTA DE CUMPLIMIENTO. En este caso, es imprescindible diseñar un plan con fechas límite para la alineación del entorno y la corrección de los controles con cumplimiento negativo.
  • En cumplimiento con excepción legal: En el caso que alguno de los controles haya sido contestado como “NO” pero dicho imcumplimiento provenga de una restricción legal, entonces identificar en la tabla el requisito afectado y describir cómo la restricción legal impide el cumplimiento con PCI DSS.

Parte 3. Validación de PCI DSS

La “Parte 3a. Reconocimiento de estado” requiere de una aceptación unilateral del comercio o proveedor de servicio en donde acepta que lo que se indica en el SAQ es correcto. Para ello, se deben validar todas las casillas. Hay que recordar que con esto el comercio o proveedor de servicio está asumiendo de forma tácita que cualquier fraude causado por errores en su implementación de PCI DSS y/o en el reporte del SAQ correrán bajo su responsabilidad.

Parte 3a. Reconocimiento de estado

Finalmente, las “Partes 3b. Declaración del comerciante“, “Parte 3c. Reconocimiento del Evaluador de seguridad certificado (QSA) (si corresponde)” y “Parte 3d. Participación del Asesor de seguridad interna (ISA) (si corresponde)”  deben ser rellenados y firmados. Hay que tener en cuenta que es necesario imprimir la hoja, firmarla y escanearla. En el caso que se considere el uso de firma digital, contactar con el adquiriente para validar si esta opción es aceptada.

Partes 3b, 3c y 3d: Firmas del comerciante, del QSA (si aplica) y del ISA (si aplica)

La última sección es la “Parte 4. Plan de acción para los requisitos por falta de cumplimiento” que corresponde a una tabla en donde se deben relacionar los requisitos y su estado de cumplimiento global (SI / NO). Si hay alguno identificado como “NO”, se deben estipular las fecha límites de alineación e implementación de las medidas correctivas. En este punto es imprescindible contactar con la entidad adquiriente para discutir las fechas de cumplimiento.

Parte 4. Plan de acción para los requisitos por falta de cumplimiento

Attestation on Compliance (AoC)

El documento “Attestation on Compliance (AoC)” (“Declaración de Cumplimiento”) es una versión simplificada del contenido del SAQ, obviando los detalles de cumplimiento por cada uno de los controles del estándar.

En el momento de reporte y envío de documentos, siempre se debe acompañar el SAQ con su correspondiente AoC. Estos dos documentos deben ir juntos y firmados y ser congruentes el uno con el otro.

Si tienes preguntas, no olvides dejar tu comentario o ingresar al foro.