L'articolo 32 del GDPR non contiene un elenco di misure obbligatorie. Chiede misure tecniche e organizzative adeguate al rischio, cita quattro esempi (pseudonimizzazione e cifratura, riservatezza e integrità e disponibilità e resilienza dei sistemi, capacità di ripristino dopo un incidente, procedura per testare e valutare regolarmente l'efficacia delle misure) e lascia a chi tratta i dati la scelta e l'onere di dimostrarla. Questa pagina spiega come si fa quella scelta e quali evidenze servono.
L'articolo 32 del Regolamento (UE) 2016/679 si intitola Sicurezza del trattamento. Il primo comma chiede a titolare e responsabile del trattamento di mettere in atto misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio, tenendo conto di quattro elementi: lo stato dell'arte, i costi di attuazione, la natura e l'oggetto e il contesto e le finalità del trattamento, e il rischio per i diritti e le libertà delle persone fisiche.
Poi, e questo è il punto che quasi tutti leggono male, aggiunge "tra cui, se del caso" e elenca quattro esempi. Non sono un obbligo assoluto: sono indicazioni di cosa il legislatore considera pertinente.
Il secondo comma dice contro cosa ci si difende: distruzione, perdita, modifica, divulgazione non autorizzata o accesso accidentale o illegale ai dati personali trasmessi, conservati o comunque trattati. Il terzo comma riconosce che l'adesione a un codice di condotta approvato o a un meccanismo di certificazione può essere usata come elemento per dimostrare la conformità. Il quarto chiede di assicurarsi che chi opera sotto l'autorità del titolare tratti i dati solo su istruzione.
Da qui discende tutto il resto: l'articolo 32 è una norma basata sul rischio, non una checklist, e l'unico modo di rispettarla è scegliere, motivare e documentare.
La domanda che arriva più spesso è "quali sono le misure di sicurezza obbligatorie per il GDPR". La risposta onesta è che non esistono nella forma in cui viene chiesta. La vecchia normativa italiana, l'allegato B del Codice Privacy, conteneva un elenco di misure minime; è stato abrogato proprio perché un elenco fisso invecchia male e diventa un alibi.
Il GDPR ha scelto l'approccio opposto. Due aziende che trattano dati diversi, con rischi diversi, devono adottare misure diverse, e entrambe sono conformi se la scelta è proporzionata e documentata. Uno studio di tre persone che gestisce anagrafiche di clienti e una clinica che tratta dati sanitari di migliaia di pazienti non hanno lo stesso obbligo, anche se leggono lo stesso articolo.
Questo ha una conseguenza pratica che conviene accettare subito: nessun fornitore può rendervi conformi all'articolo 32 vendendovi un prodotto. Un prodotto copre una parte del rischio. La conformità è la capacità di spiegare perché quella parte era quella giusta da coprire per prima, e di mostrare che funziona ancora.
La valutazione ha una struttura semplice, che si ripete per ogni trattamento rilevante.
Quando il trattamento presenta un rischio elevato, alla valutazione dell'articolo 32 si affianca la valutazione d'impatto dell'articolo 35. Sono due cose distinte: la prima riguarda le misure, la seconda l'ammissibilità stessa del trattamento.
Pur senza un elenco obbligatorio, la pratica ha consolidato un insieme di misure tecniche che è difficile non adottare e ancora più difficile giustificare di aver omesso.
| Misura | Rischio che riduce | Riferimento nell'art. 32 |
|---|---|---|
| Cifratura dei dati in transito e a riposo | Divulgazione non autorizzata in caso di intercettazione o furto di supporti | comma 1, lettera a |
| Pseudonimizzazione dove il dato identificativo non serve | Riduce l'impatto di un accesso non autorizzato | comma 1, lettera a |
| Controllo degli accessi e privilegio minimo, con autenticazione a più fattori | Accesso illegale, uso improprio da parte di personale autorizzato | comma 1, lettera b, e comma 4 |
| Gestione delle vulnerabilità sui sistemi esposti | Accesso non autorizzato dall'esterno | comma 1, lettere b e d |
| Registrazione degli eventi e capacità di rilevare gli incidenti | Incidenti che restano invisibili e quindi non notificati nei termini | comma 1, lettera b |
| Backup verificati con prove di ripristino | Perdita e indisponibilità dei dati | comma 1, lettera c |
| Segmentazione della rete | Propagazione di un attacco da un sistema a tutti gli altri | comma 1, lettera b |
| Protezione dell'identità del dominio di posta | Frodi e phishing a nome dell'organizzazione verso interessati e fornitori | comma 1, lettera b |
Accanto a queste stanno le misure organizzative, che valgono quanto le tecniche: istruzioni scritte a chi tratta i dati, formazione, procedura di gestione degli incidenti con i tempi di notifica, nomina dei responsabili del trattamento con l'articolo 28, verifica dei fornitori.
È la lettera che fa la differenza tra un documento e una conformità reale, ed è quella che viene disattesa più spesso. L'articolo non chiede di avere misure: chiede una procedura per testare, verificare e valutare regolarmente la loro efficacia.
Regolarmente significa a cadenza definita e ripetuta, non una volta in fase di adeguamento. Una scansione delle vulnerabilità fatta nel 2024 non dice nulla sul 2026: nel frattempo sono stati pubblicati nuovi difetti, sono cambiati i sistemi esposti, qualcuno ha aperto una porta per un fornitore e non l'ha richiusa. La misura che era adeguata ha smesso di esserlo senza che nessuno se ne accorgesse.
Le forme di verifica che soddisfano la lettera d, in ordine di frequenza con cui andrebbero eseguite:
La differenza fra il test occasionale e la verifica continua non è tecnica, è probatoria: la prima dimostra com'era un giorno, la seconda dimostra come è stato tenuto.
L'articolo 5, paragrafo 2, introduce il principio di responsabilizzazione: non basta essere conformi, bisogna essere in grado di dimostrarlo. Per le misure di sicurezza la documentazione minima ragionevole è questa.
Chi ha già un sistema di gestione certificato parte avvantaggiato: la gestione delle vulnerabilità richiesta dalla ISO/IEC 27001 produce gran parte delle stesse evidenze. Il terzo comma dell'articolo 32 lo riconosce esplicitamente, pur precisando che una certificazione è un elemento a favore e non una presunzione di conformità.
Molte aziende italiane si trovano oggi a rispondere a due normative sullo stesso perimetro tecnico. Conviene vederle insieme, perché le misure si riusano.
Il GDPR protegge i dati personali e guarda al danno per la persona. La NIS2 protegge la continuità dei servizi essenziali e importanti e guarda al danno per il sistema economico. Le misure dell'articolo 21 della NIS2, gestione del rischio, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, gestione delle vulnerabilità, si sovrappongono in larga parte con quelle che l'articolo 32 chiede di scegliere.
La differenza sta nelle conseguenze e nei tempi di notifica, e nel fatto che la NIS2 rende responsabili gli organi di amministrazione. Chi rientra in entrambi i perimetri non ha due programmi da costruire: ha un programma solo, documentato due volte con due chiavi di lettura. Se non sai se la NIS2 ti riguarda, la verifica degli obblighi di sicurezza risponde in sei domande.
Dai provvedimenti pubblicati emergono ricorrenze che vale la pena evitare, e nessuna di esse riguarda tecnologie esotiche.
Il filo comune è sempre lo stesso: la distanza fra ciò che è scritto e ciò che è vero. Le verifiche ripetute servono a tenere quella distanza vicina allo zero.
Un ordine di lavoro realistico per una PMI che parte da poco o niente.
I prodotti Defensio coprono i punti uno, due, tre e parte del sei, e producono le evidenze in un formato che si consegna a un revisore. I punti quattro e sei restano lavoro dell'organizzazione, con o senza un consulente: nessuno strumento può motivare al posto tuo perché una misura era adeguata.
Non esiste un elenco di misure obbligatorie. L'articolo 32 chiede misure tecniche e organizzative adeguate al rischio e cita quattro esempi a titolo indicativo: pseudonimizzazione e cifratura, capacità di assicurare riservatezza, integrità, disponibilità e resilienza dei sistemi, capacità di ripristinare tempestivamente i dati dopo un incidente, e una procedura per testare e valutare regolarmente l'efficacia delle misure. La scelta spetta al titolare del trattamento, che deve poterla motivare. L'elenco di misure minime dell'allegato B del vecchio Codice Privacy è stato abrogato proprio perché un elenco fisso non si adatta ai rischi diversi di organizzazioni diverse.
Significa proporzionato alle conseguenze che un incidente avrebbe per le persone i cui dati sono trattati, valutate tenendo conto dello stato dell'arte, dei costi di attuazione e della natura, dell'oggetto, del contesto e delle finalità del trattamento. Il metro non è il danno per l'azienda ma il danno per l'interessato: furto di identità, frode, discriminazione, perdita di controllo sui propri dati. Un trattamento di dati sanitari richiede misure più robuste di un elenco di contatti commerciali, a parità di dimensione dell'azienda.
L'articolo 32 dice "regolarmente" senza fissare una cadenza, quindi la frequenza va scelta e motivata in base al rischio. La pratica consolidata è: verifica continua o almeno mensile dei sistemi esposti su internet, perché è il perimetro che cambia più in fretta; prove di ripristino dei backup almeno semestrali; penetration test annuale o dopo ogni cambiamento architetturale rilevante; riesame della valutazione del rischio almeno una volta l'anno e comunque a ogni nuovo trattamento. Un controllo eseguito una sola volta in fase di adeguamento non soddisfa la lettera d.
No, ma aiuta. Il terzo comma dell'articolo 32 dice che l'adesione a un codice di condotta approvato o a un meccanismo di certificazione può essere utilizzata come elemento per dimostrare la conformità. È un elemento a favore, non una presunzione: il perimetro di una certificazione può essere più stretto dei trattamenti di dati personali, e gli obblighi del GDPR restano in capo al titolare. In pratica un sistema di gestione certificato produce gran parte delle evidenze che servono, e questo accorcia molto il lavoro.
Il titolare del trattamento risponde della scelta del responsabile e delle istruzioni che gli ha dato, e il responsabile risponde delle proprie misure ai sensi degli articoli 28 e 32, che si applicano a entrambi. Affidare un trattamento a un fornitore senza un contratto conforme all'articolo 28 e senza aver verificato le sue misure è una carenza del titolare, che il Garante contesta come tale. La verifica va rifatta nel tempo, non solo alla firma.
Non è nominato nel testo, come nessuna tecnologia specifica. La lettera d del primo comma chiede però una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure, e per i sistemi raggiungibili da internet la verifica ripetuta delle vulnerabilità è il modo ordinario di soddisfarla. Il punto non è lo strumento ma l'evidenza: una cronologia di controlli con date, esiti e correzioni dimostra la gestione; un documento che afferma che i sistemi sono sicuri non dimostra nulla.
L'articolo 32 riguarda la sicurezza del trattamento e si applica sempre: quali misure adotti e perché. L'articolo 35 riguarda la valutazione d'impatto sulla protezione dei dati, obbligatoria solo quando il trattamento presenta un rischio elevato per i diritti e le libertà delle persone, e mette in discussione il trattamento stesso, non solo le sue misure. Quando la valutazione d'impatto serve, la parte sulle misure di sicurezza è quella dell'articolo 32, che vi confluisce.
Sì, il testo le mette sullo stesso piano e il quarto comma è interamente organizzativo: il titolare deve assicurarsi che chiunque agisca sotto la sua autorità e abbia accesso a dati personali li tratti soltanto su sua istruzione. Istruzioni scritte, formazione documentata, procedura di gestione degli incidenti, contratti con i responsabili e verifica dei fornitori sono misure a tutti gli effetti, e sono anche quelle che costano meno da attuare e che vengono contestate più spesso quando mancano.
La verifica ripetuta dei sistemi esposti produce, a ogni giro, l'esito confrontabile che l'articolo 32 chiede di conservare. Parti dal vulnerability assessment continuo oppure dalla verifica degli obblighi se non sai ancora cosa ti riguarda.