PCI DSS: scope, deliverable e retest allineati al CDE

Per un audit PCI DSS (Payment Card Industry Data Security Standard), il penetration test vale solo se scope, deliverable e retest sono costruiti attorno al CDE e ai sistemi che lo influenzano.

Senza questo allineamento, il test produce un documento formalmente corretto ma inutile per il QSA, per il Report on Compliance e per chi deve dimostrare la tenuta reale del perimetro di pagamento.

Scope, deliverable e retest PCI DSS: la risposta operativa

Per rendere il penetration test utile a PCI DSS, lo scope deve nascere dal CDE e dai sistemi connessi, i finding devono essere collegati al rischio sul perimetro di pagamento, i deliverable devono essere riutilizzabili e il ciclo deve chiudersi con remediation e retest documentati. Senza questi elementi allineati al CDE, il test non produce evidenze spendibili per il QSA nel ciclo di certificazione.

Problemi pratici che questa guida aiuta a risolvere

Questa guida è utile per chi deve:

• Definire uno scope coerente con CDE, segmentazione e sistemi connessi;
• Capire quali deliverable servono davvero a management, auditor e assessor;
• Evitare report tecnici che non chiariscono l’impatto sul perimetro di pagamento;
• Collegare remediation e retest a evidenze davvero spendibili.

Checklist di preparazione

• Inventario aggiornato dei sistemi in scope e connessi al CDE;
• Mappa di segmentazione, VLAN, ACL e trust boundary rilevanti;
• Owner tecnici e referenti di business;
• Ambienti inclusi, esclusi e motivazione delle esclusioni;
• Elenco di API, portali e componenti applicative critiche;
• Criteri di severità condivisi;
• Finestra temporale e vincoli operativi;
• Processo già definito per remediation e retest.

Deliverable attesi

Output atteso	Perché serve	Chi lo usa
Executive summary	Sintetizza rischio, priorità e decisioni	Direzione, compliance, buyer
Dettaglio tecnico	Consente riproduzione e correzione	Team IT, Dev, Sec
Evidenza di sfruttabilità	Mostra che il rischio sul CDE è concreto	Auditor, assessor, security lead
Piano di remediation	Assegna tempi, owner e priorità	Owner tecnici e management
Retest	Conferma la chiusura o riduzione del rischio	Auditor, clienti, governance

Report utile e report debole a confronto

Report utile	Report debole
Parte dal perimetro PCI DSS reale	Testa componenti marginali
Chiarisce cosa è stato testato e cosa no	Lascia scope ambiguo
Collega finding e rischio sul CDE	Elenca issue senza contesto
Aiuta a pianificare remediation e follow-up	Si ferma al solo dettaglio tecnico
È leggibile anche da assessor e buyer	È usabile solo dal team security

Errori comuni da evitare

• Costruire lo scope senza partire dal CDE e dai sistemi che lo influenzano;
• Non verificare segmentazione e accessi laterali;
• Escludere API, funzioni amministrative o componenti di supporto rilevanti;
• Produrre un report senza executive summary;
• Eseguire la remediation senza retest;
• Non riportare gli esiti nella gestione del perimetro in scope.

Come interviene ISGroup

ISGroup può strutturare un percorso più efficace combinando Network Penetration Testing, Web Application Penetration Testing, Vulnerability Assessment ed eventualmente Virtual CISO, in modo da rendere il risultato utile al team di compliance e al QSA nel ciclo di verifica PCI DSS.

Domande frequenti su scope e retest PCI DSS

• Cosa deve contenere un report utile anche per il management?
• Per un’organizzazione in percorso PCI DSS, il management deve vedere quali componenti del CDE — portali e-commerce, API di pagamento, sistemi di processing, reti di accesso — sono stati testati, quali finding mostrano dove patch e controlli di segmentazione non reggono, e se le correzioni sono state chiuse con retest documentato. Il report deve alimentare la SAQ o il processo con il QSA.
• Quanto conta il retest in un percorso PCI DSS?
• Il retest ha rilevanza formale: il Requirement 11.4 di PCI DSS richiede penetration test e verifica della risoluzione delle vulnerabilità trovate. Non è opzionale — è la prova documentata richiesta dal QSA per confermare che le vulnerabilità sul CDE siano state effettivamente risolte e che la segmentazione dichiarata regga dopo la remediation.
• Un vulnerability assessment può sostituire il penetration test richiesto da PCI DSS?
• No. PCI DSS specifica che il Requisito 11.4 richiede penetration test con tentativi di accesso al CDE dall’esterno e dall’interno, non solo scansioni. Un Vulnerability Assessment soddisfa i requisiti di vulnerability scan (Req. 11.3) ma non quelli di penetration testing (Req. 11.4), che richiedono la dimostrazione di sfruttabilità e la verifica della segmentazione di rete.

Per evitare un penetration test generico e ottenere evidenze davvero utili per PCI DSS, il primo passo è definire scope, deliverable e percorso di retest in funzione del CDE e dei sistemi connessi. Il percorso può partire da un Vulnerability Assessment, proseguire con il Network Penetration Testing e approfondire le componenti applicative con il Web Application Penetration Testing.

Approfondimenti correlati

• La guida principale su PCI DSS e penetration test offre il quadro completo del requisito e del ciclo di compliance;
• L’articolo su quando il penetration test conta davvero per PCI DSS aiuta a valutare se e quando il test è realmente necessario;
• La sezione su evidenze utili per audit e vendor assessment PCI DSS completa il percorso con indicazioni pratiche per QSA e assessor.