ISO 27701: scope, deliverable e retest per sistemi PII

Per supportare un percorso ISO 27701 (Privacy Information Management Systems), lo scope del penetration test deve nascere dai sistemi, dai ruoli e dalle integrazioni che trattano dati personali, non da una lista generica di asset.

Senza questo allineamento, il test produce un documento tecnicamente corretto ma poco utile al Privacy Manager, al DPO e agli auditor che verificano l’adeguatezza dei controlli PII.

In sintesi per ISO 27701

Per rendere il penetration test davvero utile a ISO 27701, occorre definire uno scope realistico sui sistemi che trattano PII, collegare i finding al rischio privacy, pretendere deliverable riutilizzabili e chiudere il ciclo con remediation e retest. Senza questo allineamento, il test non aiuta il Privacy Manager a dimostrare l’adeguatezza dei controlli PII né a rispondere alle aspettative di DPO, Garante e auditor ISO 27701.

Problemi pratici che questa guida aiuta a risolvere

Questa guida è utile per chi deve:

• Definire uno scope coerente con ruoli privacy, tenant e sistemi che trattano dati personali;
• Capire quali deliverable servono davvero a management, privacy officer, auditor e buyer;
• Evitare report che non chiariscono l’impatto sulla PII;
• Collegare remediation e retest a evidenze davvero spendibili.

Checklist di preparazione

• Inventario aggiornato dei sistemi che trattano PII;
• Mappa di ruoli, permessi e funzioni amministrative;
• Elenco di API, export, webhook e integrazioni rilevanti;
• Ambienti inclusi, esclusi e motivazione delle esclusioni;
• Dati e funzioni più sensibili da sottoporre a verifica;
• 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, privacy, buyer
Dettaglio tecnico	Consente riproduzione e correzione	Team IT, Dev, Sec
Evidenza di sfruttabilità	Mostra che il rischio sulla PII è concreto	Auditor, buyer, 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 dai sistemi che trattano davvero PII	Testa componenti marginali
Chiarisce cosa è stato testato e cosa no	Lascia lo scope ambiguo
Collega finding e rischio privacy	Elenca issue senza impatto sui dati
Aiuta a pianificare remediation e follow-up	Si ferma al solo dettaglio tecnico
È leggibile anche da auditor e buyer	È usabile solo dal team security

Errori comuni

• Costruire lo scope senza partire da ruoli, trattamenti e tenant reali;
• Escludere API, esportazioni o aree amministrative;
• Non distinguere sistemi che trattano PII da quelli di contorno;
• Produrre un report senza executive summary;
• Eseguire la remediation senza retest;
• Non riportare gli esiti dentro il governo del rischio privacy.

Come interviene ISGroup

ISGroup può strutturare un percorso più efficace combinando Web Application Penetration Testing, Code Review ed eventualmente Virtual CISO, in modo da produrre evidenze integrabili nel PIMS e leggibili da Privacy Manager, DPO e auditor che verificano i controlli PII secondo ISO 27701.

Domande frequenti su scope, deliverable e retest per ISO 27701

• Cosa deve contenere un report utile anche per il management?
• Per un’organizzazione con PIMS sotto ISO 27701, il management deve vedere quali sistemi che trattano PII — portali, API, banche dati, sistemi di consenso — sono stati testati in relazione ai controlli del PIMS, quali finding espongono PII a rischio di trattamento non autorizzato e se le correzioni sono state chiuse. Il report deve aiutare il DPO e il privacy team a valutare l’adeguatezza delle misure e a documentare la compliance al GDPR e alla legislazione applicabile.
• Quanto conta il retest in un percorso legato a ISO 27701?
• Conta perché ISO 27701 estende ISO 27001 con requisiti specifici per la privacy. Il retest è la prova che le misure correttive sui sistemi che trattano PII non solo hanno chiuso la vulnerabilità tecnica, ma hanno anche ripristinato la conformità ai principi di privacy by design richiesti dal PIMS.
• Un vulnerability assessment può sostituire questo tipo di test?
• No. ISO 27701 richiede di valutare i rischi per la privacy degli interessati, non solo le vulnerabilità tecniche. Un VA identifica le superfici deboli; un penetration test verifica se quelle superfici portano concretamente a PII accessibili oltre quanto autorizzato, se i meccanismi di consenso sono bypassabili o se i diritti degli interessati possono essere compromessi. È questa la verifica che un DPO include nel dossier del PIMS.

Per evitare un penetration test generico e ottenere evidenze davvero utili per ISO 27701, il primo passo è definire scope, deliverable e percorso di retest in funzione dei sistemi che trattano PII. È possibile partire da una Code Review, proseguire con il Web Application Penetration Testing e usare il Virtual CISO per trasformare il lavoro in un presidio più continuativo.

Approfondimenti correlati

• La guida principale su ISO 27701 e penetration test offre il quadro completo del tema e il contesto normativo di riferimento;
• L’articolo su quando il penetration test conta davvero per ISO 27701 aiuta a valutare se e quando attivare un test nel percorso di conformità;
• La sezione dedicata ad audit e vendor assessment per ISO 27701 illustra quali evidenze produrre per auditor e fornitori.