PCI DSS.
Delimitare dati di pagamento e dipendenze, chiarire le responsabilità operative e concordare l'attestazione adatta con il soggetto competente.
- PCI DSS v4.0.1 · PCI SSC
- Di Jonathan Bezdek
- Aggiornato al: 22/10/2026
- Tempo di lettura: 8 min.
Risposta breve.
PCI DSS è lo standard di settore per proteggere i dati delle carte di pagamento. Riguarda esercenti, fornitori e sistemi che trattano tali dati o ne influenzano la sicurezza. La versione attuale è PCI DSS v4.0.1. Ambiente di pagamento e ruolo determinano l'ambito; il percorso di attestazione, per esempio SAQ o ROC, va concordato con acquirer o circuito.
PCI DSS 4.0 e la versione attuale.
PCI DSS collega requisiti tecnici e operativi di sicurezza per i dati di pagamento. Il PCI Security Standards Council, in breve PCI SSC, sviluppa lo standard e i relativi strumenti di supporto. Come dimostrare il rispetto in uno specifico programma di pagamento è invece stabilito dai soggetti competenti che accettano l'attestazione, tipicamente acquirer e circuiti; PCI SSC FAQ 1473 spiega questa distinzione dei ruoli.
PCI DSS v4.0.1 è la versione riportata nella Document Library ufficiale. Secondo la pubblicazione PCI SSC sulla revisione, v4.0 è stata ritirata il 31 dicembre 2024. La data del 31 marzo 2025, già prevista per i nuovi requisiti v4, è rimasta invariata. Alla data di questa pagina il termine è trascorso; non è una scadenza futura di introduzione.
Un'attestazione completata con successo non sostituisce la protezione continua. Per l'organizzazione pratica, le modifiche a percorsi di pagamento, applicazioni e fornitori dovrebbero essere occasione per riesaminare l'ambito concordato. Una nuova integrazione checkout può creare dipendenze diverse dalla soluzione precedentemente valutata, anche se la stessa impresa continua ad accettare pagamenti.
A chi si applica PCI DSS.
Secondo la panoramica PCI SSC, PCI DSS non si rivolge solo a organizzazioni che conservano, trattano o trasmettono dati delle carte. Va considerata anche la possibile influenza sulla sicurezza dell'ambiente dei dati dei titolari di carta, Cardholder Data Environment o CDE. Esercenti e fornitori dovrebbero quindi descrivere prima il proprio ruolo concreto e le prestazioni effettivamente fornite.
Esternalizzare la gestione dei pagamenti non comporta un'esenzione automatica. PCI SSC FAQ 1092 distingue un possibile ambito diretto più ridotto dei requisiti dalla responsabilità persistente per fornitori adeguati, compiti concordati e attestazione richiesta. Anche per un checkout ospitato, chiarite con il soggetto competente quali presupposti debba soddisfare l'integrazione tecnica scelta.
Il confine è dimostrato da misure efficaci, non solo da un nome nel diagramma architetturale. PCI SSC FAQ 1115 spiega che occorre verificare i sistemi connessi e l'efficacia effettiva della segmentazione. Escludere prematuramente accessi amministrativi, servizi di supporto o interfacce può portare a descrivere un ambito di verifica incompleto.
Organizzare i requisiti PCI DSS nell'operatività.
L'attuazione collega protezione dell'ambiente di pagamento e procedure operative tracciabili. I seguenti sei ambiti sono un orientamento redazionale per pianificare, non una riproduzione dei dodici requisiti ufficiali o dei singoli punti di verifica; la loro applicabilità concreta viene esaminata rispetto all'ambito confermato.
Rendere comprensibili flussi di pagamento e ambito.
Seguite concretamente dove nascono le informazioni di pagamento, quali componenti sono coinvolte e quali persone o fornitori possono influenzarle. Registrate il confine confermato insieme alle relative ipotesi. Una descrizione comprensibile aiuta sviluppo, operatività e soggetto che accetta l'attestazione a discutere dello stesso percorso di pagamento.
Gestire sistemi e modifiche in sicurezza.
Assegnate responsabili chiari alle applicazioni e alle componenti infrastrutturali coinvolte. Collegate le modifiche alla domanda se nuove connessioni, funzioni o dipendenze cambino l'ambito confermato. Nella pratica quotidiana una cronologia tracciabile delle modifiche è più utile di un'istantanea raccolta soltanto per la verifica.
Limitare utilizzo e trasmissione dei dati.
Come domanda pratica iniziale, verificate quali dati di pagamento siano effettivamente necessari per la procedura scelta e dove possano formarsi copie. Considerate esportazioni, log e processi di supporto. La pianificazione dettagliata della sicurezza deve corrispondere a tipi di dati e finalità d'uso; una classificazione generica di riservatezza non spiega ancora queste decisioni.
Organizzare gli accessi in modo tracciabile.
Collegate le responsabilità funzionali alle possibilità tecniche effettivamente concesse. Considerate, oltre ai dipendenti, account di servizio, accessi amministrativi e fornitori. Per organizzare il lavoro è consigliabile chiarire chi approva un accesso, chi gestisce le modifiche e come si riconosce una revoca tempestiva.
Verificare l'operatività e gestire le conoscenze acquisite.
Pianificate registrazioni e verifiche adatte insieme ai responsabili dell'ambiente di pagamento. Una singola scansione o un test di penetrazione descrive solo il proprio oggetto. Per i rilievi, registrate quale modifica ne consegue e come verificarne l'effetto, anziché equiparare un risultato di test all'intera attestazione PCI DSS.
Includere fornitori e incidenti.
Definite referenti operativi e modalità di azione in caso di anomalie. Per le prestazioni esternalizzate, i propri compiti dovrebbero restare comprensibili accanto agli impegni del fornitore. PCI SSC FAQ 1576 spiega che l'attestazione di un fornitore deve coprire i servizi utilizzati; un documento aziendale qualsiasi non basta automaticamente.
Attuare PCI DSS come compito continuo.
Concordare ruolo e percorso di attestazione.
Come avvio pratico, chiarite con acquirer o circuito il vostro ruolo, l'attestazione attesa e il referente competente prima di scegliere un modulo.
Rilevare un percorso di pagamento.
Descrivete dati, applicazioni, sistemi e fornitori coinvolti dall'avvio del pagamento fino alle registrazioni operative residue.
Confermare l'ambito.
Verificate connessioni rilevanti e componenti che influenzano la sicurezza e fate valutare nel merito la delimitazione, compresa l'eventuale segmentazione.
Consolidare i compiti nell'operatività.
Assegnate misure di protezione e responsabilità condivise a persone concrete e collegate l'attuazione a registrazioni adeguate.
Preparare evidenze coerenti.
Verificate che i documenti richiesti descrivano lo stesso servizio, ruolo e ambito e che le decisioni aperte siano state gestite in modo tracciabile.
Seguire modifiche e verifiche successive.
Concordate gli intervalli richiesti di attestazione e verificate, in caso di cambiamenti, che ambito, evidenze dei fornitori e responsabilità operative restino adeguati.
Certificazione PCI e forma effettiva di attestazione.
L'attestazione PCI DSS riconosciuta utilizza i documenti ufficiali previsti. Un SAQ documenta un'autovalutazione ammessa, un ROC i risultati del relativo percorso di verifica e una AOC la relativa conferma. Secondo PCI SSC FAQ 1220, documenti qualsiasi chiamati certificati di conformità non sostituiscono i modelli ufficiali.
Il soggetto che accetta l'attestazione determina il percorso richiesto; una verifica può coinvolgere un Qualified Security Assessor, in breve QSA. Secondo PCI SSC FAQ 1473, ambito e applicabilità devono essere valutati correttamente. Scegliere il nome di un SAQ non conferma quindi che siano soddisfatti i relativi criteri di idoneità o che tutti i requisiti rilevanti siano attuati.
Anche il modello adatto va utilizzato nella versione attuale. Il PCI SSC ha modificato le regole SAQ A con effetto dal 31 marzo 2025 e ha chiarito espressamente che eliminare singoli punti di verifica dal questionario non annulla i requisiti PCI DSS sottostanti. Concordate date di attestazione e obblighi successivi per il vostro caso, anziché presumere una durata generale del certificato.
Inquadrare gli altri framework.
ISO 27001 tratta la gestione della sicurezza delle informazioni nell'ambito definito; l'attestazione PCI DSS è una decisione separata per l'ambiente di pagamento. I CIS Controls sostengono la definizione generale delle priorità di sicurezza, ma non stabiliscono un percorso di validazione PCI. Il GDPR riguarda i trattamenti di dati personali e va verificato indipendentemente dall'attestazione sui dati di pagamento.
In Secani.
Secani offre un proprio catalogo aziendale redazionale su PCI DSS v4.0.1. Il profilo rileva, tra l'altro, ambito CDE, ruolo di esercente o fornitore e percorso SAQ/ROC concordato. Questi dati di lavoro sostengono la gestione strutturata; non sostituiscono né i documenti ufficiali di verifica né la conferma dell'idoneità o il giudizio del soggetto competente.
Iniziare con un percorso concreto di pagamento.
Scegliete un percorso di pagamento effettivamente utilizzato e individuate responsabilità funzionale e tecnica. Registrate quali prestazioni fornite direttamente e quali sono svolte da un fornitore. Concordate poi l'attestazione attesa con il soggetto competente prima di pianificare l'impegno sulla base di un questionario ritenuto adatto.
Fonti.
- PCI SSC: panoramica PCI DSS e destinatari
- PCI SSC: Document Library ufficiale
- PCI SSC: pubblicazione di PCI DSS v4.0.1
- PCI SSC FAQ 1473: soggetti competenti e percorso di attestazione
- PCI SSC FAQ 1092: gestione dei pagamenti esternalizzata
- PCI SSC FAQ 1576: attestazioni dei fornitori
- PCI SSC FAQ 1220: documenti ufficiali anziché certificati di conformità
- PCI SSC FAQ 1115: sistemi connessi e segmentazione
- PCI SSC: modifiche a SAQ A dal 31 marzo 2025
- PCI SSC: bollettino SAQ del 15 ottobre 2024
Domande frequenti.
No, non automaticamente. L'esternalizzazione può modificare l'ambito diretto; la responsabilità per fornitori adeguati, compiti chiari e attestazione richiesta resta da considerare separatamente.
Non soltanto in base all'impegno desiderato. Devono essere soddisfatti i criteri di idoneità e il percorso richiesto va concordato con il soggetto che accetta l'attestazione.
Certificati generici di conformità non sono un sostituto riconosciuto dei documenti ufficiali. Fanno fede il percorso di verifica concordato e le relative relazioni o conferme ufficiali.
No. Un certificato ISMS riguarda l'ambito dichiarato del sistema di gestione; requisiti e percorso di attestazione per l'ambiente di pagamento richiedono chiarimenti separati.
Delimitare il percorso di pagamento.
Parliamo di come gestire in Secani ambito, compiti ed evidenze.
Questa pagina inquadra PCI DSS con parole proprie e non sostituisce i documenti ufficiali PCI SSC né una verifica specialistica. I requisiti del rispettivo programma di pagamento e le decisioni del soggetto competente restano da rispettare separatamente.