Art. 32 GDPR: il test regolare delle misure di sicurezza è obbligatorio?

Una procedura di test sì, se adeguata al rischio. Un penetration test per nome, no.

L'art. 32, par. 1 chiede al titolare e al responsabile del trattamento di mettere in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, «che comprendono, tra le altre, se del caso» quattro misure elencate. La lettera d) recita: «una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento».

Tre parole reggono il peso. Procedura: un'attività organizzata e continuativa, non un test isolato. Regolarmente: ripetuta, con un intervallo che il regolamento non fissa. Se del caso: le misure elencate si applicano in funzione del rischio, ed è per questo che l'articolo si apre con lo stato dell'arte, i costi di attuazione, la natura, l'oggetto, il contesto e le finalità del trattamento, e la probabilità e gravità del rischio per i diritti e le libertà delle persone.

La risposta onesta ha quindi due metà. Nessuno può indicare un articolo del GDPR che dica «penetration test annuale». E un titolare che tratta dati personali su larga scala senza alcuna procedura che verifichi se le sue misure di sicurezza funzionano davvero fatica a dimostrare che quelle misure sono adeguate.

• Art. 32, par. 1: misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, che comprendono, se del caso, a) pseudonimizzazione e cifratura, b) la capacità di assicurare su base permanente riservatezza, integrità, disponibilità e resilienza dei sistemi e dei servizi di trattamento, c) la capacità di ripristinare tempestivamente disponibilità e accesso dopo un incidente, e d) la procedura di test, verifica e valutazione regolari citata sopra.
• Art. 32, par. 2: nel valutare l'adeguato livello di sicurezza si tiene conto in special modo dei rischi di distruzione, perdita, modifica, divulgazione non autorizzata o accesso, accidentali o illegali, ai dati personali.
• Art. 32, par. 3: l'adesione a un codice di condotta approvato o a un meccanismo di certificazione approvato può essere utilizzata come elemento per dimostrare la conformità al paragrafo 1.
• Art. 24, par. 1: il titolare mette in atto misure adeguate per garantire, ed essere in grado di dimostrare, la conformità; dette misure sono riesaminate e aggiornate qualora necessario.
• Art. 5, par. 1, lett. f) e par. 2: dati trattati con un'adeguata sicurezza («integrità e riservatezza») e titolare competente per il rispetto dei principi e in grado di comprovarlo («responsabilizzazione»).
• Art. 28, par. 3, lett. c) e h): il contratto impone al responsabile di adottare tutte le misure richieste dall'art. 32 e di mettere a disposizione le informazioni necessarie a dimostrare la conformità, consentendo e contribuendo alle attività di revisione, comprese le ispezioni, del titolare o di un soggetto da questi incaricato.
• Art. 83, par. 4, lett. a): le violazioni degli obblighi degli articoli da 25 a 39 sono soggette a sanzioni fino a 10 000 000 di euro o, per le imprese, fino al 2% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore.

Il considerando 83 aggiunge che il titolare o il responsabile dovrebbe valutare i rischi inerenti al trattamento e attuare misure per limitarli, tenendo conto dello stato dell'arte e dei costi di attuazione rispetto ai rischi e alla natura dei dati personali.

Le indicazioni più chiare del Comitato europeo per la protezione dei dati (EDPB) sui test si trovano nelle Linee guida 01/2021 sugli esempi di notifica delle violazioni dei dati personali (versione 2.0, adottata il 14 dicembre 2021), nelle misure raccomandate dopo i casi di studio:

• Ransomware: il fatto che un attacco sia stato possibile è di solito il segno di vulnerabilità nel sistema del titolare, e le debolezze e le falle individuate vanno documentate e affrontate senza ritardo. Tra le misure consigliate ci sono vulnerability e penetration test su base regolare e la revisione, il test e l'aggiornamento dell'analisi dei rischi quando si valutano le contromisure.
• Esfiltrazione di dati tramite servizi esposti su internet: audit periodici di sicurezza informatica, vulnerability assessment e penetration test sono inoltre necessari per individuare in anticipo questo tipo di vulnerabilità e correggerle. L'elenco delle misure consigliate comprende audit sistematici di sicurezza informatica e vulnerability assessment (penetration test).

Le linee guida presentano queste misure come consigliate e precisano che l'elenco non è esclusivo né esaustivo: ogni trattamento è diverso e il titolare decide quali misure si adattano. Indicano comunque che cosa un'autorità di controllo considererà probabilmente stato dell'arte quando una violazione sfrutta una debolezza nota e verificabile.

Due decisioni recenti dell'autorità di controllo svedese, l'IMY, mostrano l'art. 32 applicato alla qualità delle misure di sicurezza e all'assenza delle procedure che avrebbero fatto emergere il problema:

• Sportadmin, 6 milioni di corone (28 gennaio 2026). Dopo un attacco del gennaio 2025 che ha esposto i dati di oltre 2,1 milioni di persone, per lo più bambini e ragazzi, l'IMY ha accertato una violazione dell'art. 32. Ha rilevato che la società conosceva da tempo alcune debolezze e aree a rischio elevato senza fare abbastanza, e che mancava delle procedure necessarie per individuare le carenze delle misure di sicurezza esistenti e di un sistema per rilevare in tempo reale intrusioni e tentativi di intrusione.
• Miljödata, 1,8 milioni di corone (22 settembre 2026). Dopo un attacco dell'agosto 2025 che, secondo la società, ha coinvolto 2,2 milioni di persone, l'IMY ha ritenuto il livello di sicurezza tecnica e organizzativa insufficiente rispetto ai dati trattati. Ha rilevato che la società non aveva svolto controlli sufficienti all'installazione di nuovo software e non aveva un monitoraggio automatico in tempo reale dei propri sistemi, e l'ha sanzionata per violazione dell'art. 32, par. 1.

Nessuna delle due decisioni parla di penetration test. Entrambe descrivono l'assenza di procedure che verifichino e monitorino se le misure funzionano, cioè la lacuna a cui risponde l'art. 32, par. 1, lett. d). Per la vicenda sanzionatoria vedi la nostra analisi GDPR articolo 32: la multa è per il test che non hai fatto.

Poiché l'art. 32 è basato sul rischio, metodo e intervallo li stabilisce il titolare, che deve saperli motivare. Una procedura difendibile risponde di solito per iscritto a cinque domande:

1. Quali trattamenti, quali sistemi? Parti dal registro delle attività di trattamento e collega ogni trattamento a rischio elevato ai sistemi che lo supportano, in particolare quelli esposti su internet e quelli che contengono categorie particolari di dati.
2. Quali test, perché? Scansioni di vulnerabilità per le debolezze note, penetration test dove la domanda è la sfruttabilità, test di ripristino per l'art. 32, par. 1, lett. c), revisioni degli accessi e controlli di configurazione. Gli esempi dell'EDPB indicano vulnerability e penetration test regolari per i servizi esposti su internet.
3. Con quale frequenza? Lega l'intervallo al rischio e ai cambiamenti: a calendario, e prima che nuovo software vada in produzione, che è proprio la lacuna citata dall'IMY nel caso Miljödata.
4. Chi esegue i test? Il GDPR non richiede un tester esterno. Registra chi ha eseguito ogni test, con quali qualifiche e perché è obiettivo rispetto ai sistemi nel perimetro.
5. Cosa succede dopo? Finding, correzione, retest e rischi accettati, riesaminati e aggiornati come chiede l'art. 24, par. 1.

Se il trattamento è coperto da una valutazione d'impatto ai sensi dell'art. 35, il piano di test rientra tra le misure che descrive. I responsabili del trattamento devono aspettarsi che i titolari chiedano le stesse registrazioni in base all'art. 28, par. 3, lett. h).

Scritto nel regolamento:

• Una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure di sicurezza, se adeguata al rischio (art. 32, par. 1, lett. d), per titolari e responsabili.
• Misure riesaminate e aggiornate qualora necessario, e la capacità di dimostrare la conformità (artt. 24, par. 1, e 5, par. 2).
• L'obbligo del responsabile di adottare tutte le misure dell'art. 32 e di consentire e contribuire alle attività di revisione (art. 28, par. 3, lett. c) e h).

Basato sul rischio, deciso da titolare o responsabile:

• Quali test, con quale profondità, frequenza e da parte di chi, secondo stato dell'arte, costi, trattamento e rischio per le persone.

Linee guida, non legge:

• Le Linee guida EDPB 01/2021: vulnerability e penetration test regolari e audit periodici di sicurezza come misure consigliate.

Non scritto da nessuna parte:

• Un penetration test obbligatorio, una frequenza fissa, una certificazione del tester o un certificato di sicurezza GDPR che sostituisca la valutazione del titolare.

Zero Hunt è un red team AI autonomo per reti e infrastrutture: penetration test automatizzati su un'appliance on-premise, con AI privata e human in the loop. Non decide cosa è adeguato ai sensi dell'art. 32, non è un'autorità di controllo né un meccanismo di certificazione e non sostituisce la valutazione d'impatto, il parere del DPO o un tester indipendente. Il GDPR non è tra i 34 framework su cui il motore mappa i risultati: i report esportati citano l'art. 32 come riferimento normativo incrociato, e lo stesso registro firmato documenta i test regolari che l'art. 32 chiede.

• Regolare per costruzione. Campagne black box e gray box eseguite una volta, ogni giorno, ogni settimana, ogni mese o con una pianificazione personalizzata, e prima o dopo le modifiche: l'intervallo scritto nella tua procedura è quello che viene davvero eseguito.
• Prova di efficacia, non solo di esistenza. Ogni finding registra se la debolezza è stata effettivamente sfruttata, ed è la differenza tra sapere che una misura esiste e sapere che funziona. Ogni correzione si ritesta con la stessa prova.
• I dati personali restano in sede. Nessun dato del cliente lascia l'appliance: i modelli girano sull'appliance senza servizi AI esterni, quindi i dati personali toccati da un test e la mappa di ciò che è sfruttabile non vengono inviati a un altro responsabile del trattamento.
• Approvazione umana dei passi rischiosi. Cinque livelli di autonomia stabiliscono cosa deve attendere un operatore, utile quando i test toccano sistemi di produzione con dati personali. Vedi human in the loop.
• Registri che dimostrano la conformità. Ogni tentativo di attacco è una voce firmata Ed25519 in una catena di hash SHA-256, e i report esportati sono firmati ECDSA, a supporto della responsabilizzazione dell'art. 5, par. 2.

Per capire come si inserisce nella tua procedura ex art. 32, prenota una call di readiness di 30 minuti.

• Regolamento (UE) 2016/679 (GDPR), artt. 5, 24, 28, 32 e 83 e considerando 83 (EUR-Lex)
• Linee guida EDPB 01/2021 sugli esempi di notifica delle violazioni dei dati personali, versione 2.0 (EDPB, in inglese)
• Sanzione amministrativa a Sportadmin, 28 gennaio 2026 (IMY, in inglese)
• Sanktionsavgift mot Miljödata för bristande säkerhet, 22 settembre 2026 (IMY, in svedese)