Il pci dss saq a è il questionario di self assessment più semplice previsto dal PCI DSS: meno di 30 domande contro le oltre 300 del SAQ D. Capire chi può compilarlo e come arrivarci è strategico per qualsiasi merchant che voglia ridurre il carico di compliance senza rinunciare alla sicurezza. La distinzione tra i diversi tipi di SAQ dipende da come e dove vengono trattati i dati carta.
I tipi di SAQ PCI DSS: da A a D, cosa cambia
Il PCI Security Standards Council ha definito diversi tipi di SAQ (Self-Assessment Questionnaire) per adattare gli adempimenti al profilo di rischio reale del merchant. Non tutti i merchant hanno lo stesso livello di esposizione: un ecommerce che usa un hosted payment page è molto diverso da un'azienda che processa i numeri di carta via telefono e li archivia in un database interno.
I tipi principali sono: SAQ A per merchant card-not-present che delegano completamente il trattamento dei dati carta a terzi certificati; SAQ A-EP per ecommerce con pagina di pagamento parzialmente delegata; SAQ B per terminal fisici non connessi a internet; SAQ C per sistemi POS connessi; SAQ D per tutti gli altri merchant, inclusi quelli che archiviano PAN o gestiscono il checkout direttamente. Il SAQ D è il più completo e oneroso.
SAQ A vs SAQ D: la differenza che vale ore di lavoro
La differenza tra SAQ A e SAQ D non è solo nel numero di domande. Il SAQ D richiede di documentare politiche di sicurezza, controlli di accesso, procedure di logging, vulnerability management, piani di risposta agli incidenti e molto altro. Un merchant medio impiega settimane per raccogliere prove e compilarlo correttamente, spesso con il supporto di un consulente esterno.
Il SAQ A, al contrario, si concentra su un perimetro minimo: verifica che il merchant non conservi, processi o trasmetta dati carta sui propri sistemi e che il provider di pagamento utilizzato sia certificato PCI DSS. Con il SAQ A, un merchant può gestire autonomamente il proprio self assessment in poche ore, senza consulenza specializzata e senza dover documentare l'intera infrastruttura IT.
Come passare dal SAQ D al SAQ A con la tokenizzazione
Il prerequisito per il SAQ A è che nessun dato carta transiti o venga conservato sui sistemi del merchant. La tokenizzazione risolve questo problema alla radice: il checkout invia i dati carta direttamente al vault certificato di PCI Proxy EU tramite una pagina di pagamento hosted o un SDK client-side. Il merchant riceve solo un token opaco, che non ha valore al di fuori del vault.
Questo cambiamento architetturale ha un impatto diretto sul tipo di SAQ applicabile. Un merchant che oggi compila un SAQ D perché il suo CRM o il suo gestionale riceve i PAN può migrare al SAQ A semplicemente adottando una soluzione di tokenizzazione certificata. Il perimetro si riduce, la documentazione si semplifica e il costo totale della compliance scende in modo significativo.
Domande frequenti
Quante domande ha il SAQ A?
Il SAQ A nella versione PCI DSS v4.0 contiene circa 22 requisiti verificabili, molti dei quali richiedono solo conferma che il trattamento dati sia delegato a un provider certificato. Il SAQ D, nella stessa versione, supera le 300 domande con richieste di prove documentali per ciascuna.
Il SAQ A vale per tutti i merchant ecommerce?
No. Il SAQ A è valido solo per merchant card-not-present che non toccano mai i dati carta sui propri server. Se il checkout è hosted interamente dal provider di pagamento certificato e il merchant non vede mai un PAN, il SAQ A è applicabile. Se invece il merchant gestisce anche solo una parte del form di pagamento, si ricade nel SAQ A-EP o nel SAQ D.
Con PCI Proxy EU quale SAQ devo compilare?
Nella configurazione standard, dove il checkout utilizza la pagina hosted o il client-side SDK di PCI Proxy EU senza che i dati carta transitino per i tuoi server, puoi compilare il SAQ A. Il tuo acquirer o PSP può confermare questo nella fase di onboarding.
Vuoi passare dal SAQ D al SAQ A riducendo drasticamente il tuo carico di compliance? Scopri PCI Proxy EU.