Indice
Introduzione
“Che modello usiamo per la valutazione d’impatto?“. In otto anni di GDPR questa domanda ha ricevuto risposte diverse a seconda di chi la poneva e del Paese in cui operava. Diverse autorità di controllo hanno proposto il proprio modello – si pensi alla CNIL o all’AEPD – e anche la prassi professionale si è sviluppata attraverso strumenti e metodologie differenti.
Ad aprile si è tentato di ridurre questa frammentazione attraverso l’adozione, da parte dell’EDPB (European Data Protection Board), del primo modello europeo armonizzato di DPIA nella versione 1.0. A seguito del tradizionale periodo di consultazione pubblica si attende ora la versione definitiva.
La novità, però, non consiste soltanto nell’introduzione di un formato comune. Il modello propone infatti un modo più articolato di guardare al rischio, distinguendo i pregiudizi che possono derivare dalle caratteristiche intrinseche del trattamento da quelli che dipendono dal verificarsi di un incidente. La domanda non è soltanto cosa potrebbe accadere se qualcosa andasse storto – un attacco, un errore umano o una violazione dei dati -, ma quali rischi per gli interessati siano già incorporati nelle scelte con cui il trattamento è stato progettato e configurato.
Facciamo un passo indietro: cos’è la DPIA e quando serve
La valutazione d’impatto sulla protezione dei dati è il processo richiesto dall’art. 35 GDPR quando un trattamento, per natura, oggetto, contesto e finalità, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche. Serve a descrivere come i dati verranno trattati, a valutare se il trattamento sia necessario e proporzionato e a individuare le misure per ridurre i rischi.
In Italia, il perimetro dell’obbligo è definito dal provvedimento del Garante dell’11 ottobre 2018, che ha adottato l’elenco delle tipologie di trattamento soggette a valutazione d’impatto.
Su questo punto il template europeo non incide: interviene sul come si documenta la DPIA, non sul quando la si deve fare.
[Vedi anche: Quando occorre fare la valutazione d’impatto?]
Otto anni senza un formato comune – e il ruolo della CNIL
Prima dell’intervento dell’EDPB, il vuoto è stato colmato, di fatto, dalla CNIL. L’autorità francese ha messo a disposizione dei titolari un software di ausilio alla conduzione della valutazione d’impatto (PIA – Privacy Impact Assessment), gratuito e liberamente scaricabile, che offre un percorso guidato secondo una sequenza conforme alle linee guida del WP29.
Su questa impalcatura si è formata la prassi di larga parte dei professionisti europei. La versione in lingua italiana è stata realizzata con la collaborazione del Garante, che ne ha però precisato la natura meramente ausiliaria: non costituisce un modello di riferimento per ogni situazione di trattamento ed è stato concepito soprattutto come supporto per le PMI.
L’iniziativa dell’EDPB dà attuazione alla Dichiarazione di Helsinki del 2 luglio 2025, con cui l’EDPB si è impegnato a rendere più agevole la conformità al GDPR e a rafforzare la coerenza applicativa in Europa, e non è isolata: l’8 giugno 2026 l’EDPB ha adottato il modello per la notifica delle violazioni dei dati personali.
Cosa contiene il modello EDPB
Il template articola la valutazione in sette sezioni costruite per garantire una copertura tracciabile degli elementi prescritti dall’art. 35, par. 7 GDPR.
Sezione 0 – Panoramica del trattamento.
Prima ancora di descrivere il trattamento, il modello chiede titolo, versione, date, identificazione di titolare, contitolari ex art. 26 e responsabili ex art. 28. Soprattutto, chiede la composizione del gruppo di lavoro mappata su una matrice RACI (Responsible, Accountable, Consulted, Informed), con evidenza del ruolo del DPO, delle ragioni che hanno determinato l’avvio della valutazione, del perimetro di scoping e dell’approvazione finale.
Non basta che la valutazione sia stata fatta: deve risultare chi l’ha fatta, chi è stato consultato e chi l’ha approvata.
Sezione 1 – Descrizione sistematica del trattamento.
Si sviluppa su due livelli. Il primo, di carattere generale, copre categorie di dati, finalità, usi secondari o compatibili. Il secondo, funzionale, scende nei dettagli operativi: i mezzi del trattamento, gli asset di supporto (sistemi IT, servizi in outsourcing, archivi), i trasferimenti verso paesi terzi con indicazione del meccanismo applicabile (decisione di adeguatezza, clausole contrattuali standard) e sulle procedure di cancellazione e distruzione. Sono richieste espressamente la mappatura per fase del ciclo di vita – raccolta, uso, conservazione, condivisione, cancellazione – e il collegamento con il registro ex art. 30.
Descrivere il trattamento smette di significare descriverne la finalità e comincia a significare descriverne l’infrastruttura.
Sezione 2 – Analisi del trattamento.
Si esaminano la base giuridica per ciascuna finalità, la qualità dei dati, il rispetto dei principi. Qui compare uno degli elementi più utili sul piano operativo: lo stato di implementazione di ogni misura – pianificata, parzialmente implementata, implementata. È un accorgimento minimo, ma efficace: elimina l’ambiguità dei piani d’azione che si limitano a elencare contromisure senza chiarire quali siano già operative, e restituisce alla DPIA la funzione di guida pratica alla conformità.
Sezione 3 – Considerazioni su necessità e proporzionalità.
Il modello chiede innanzitutto di individuare le minacce che il trattamento, così come è stato progettato, comporta per i diritti e le libertà degli interessati. Solo a questo punto arrivano le domande su necessità e proporzionalità: il trattamento è necessario allo scopo? È la soluzione meno invasiva per raggiungerlo? E, sul piano della proporzionalità, i vantaggi che ne derivano superano gli svantaggi per i diritti e le libertà degli interessati?
Sezione 4 – Valutazione e gestione del rischio.
È la sezione che introduce la distinzione fra rischio di progettazione e rischio da incidente, di cui diremo tra poco. Per ciascun rischio identificato sono richieste una valutazione di probabilità e gravità dell’impatto e l’individuazione delle fonti di minaccia.
Sezione 5 – Coinvolgimento delle parti interessate.
Il modello chiede di documentare il parere del DPO, se presente, ma soprattutto come sia stato concretamente recepito nella valutazione – la domanda esplicita non è se il parere sia stato raccolto, ma come il titolare lo abbia attuato. Per gli interessati la consultazione non è automatica: dove è avvenuta va documentata, dove non è avvenuta il titolare deve spiegare perché non è stata ritenuta opportuna o perché non è stato possibile realizzarla.
Sezione 6 – Conclusione e decisione.
I rischi sono stati mitigati a sufficienza? Il trattamento può iniziare? È necessaria la consultazione preventiva dell’autorità ai sensi dell’art. 36 GDPR? È il punto in cui la DPIA smette di essere un’analisi e diventa una decisione, con un responsabile identificato.
Ciò che l’EDPB standardizza è la struttura minima di informazioni che una DPIA dovrebbe sempre registrare, quale che sia il metodo con cui il rischio viene misurato: da qui la qualificazione di “meta-template“.
Il modello, precisa l’EDPB, non è obbligatorio: i titolari possono continuare a condurre i propri processi di analisi e gestione del rischio come preferiscono, utilizzando la metodologia che ritengono più adatta. Tuttavia, il modello EDPB, in sede ispettiva o in occasione di una consultazione preventiva ex art. 36, diventerà il metro implicito rispetto al quale si misurerà la completezza di quanto documentato.
La vera novità: rischio di progettazione e rischio da incidente
Veniamo all’elemento più significativo: il modello richiede di valutare separatamente due categorie di rischio.
Il rischio di progettazione (design risk) è quello che discende dalle scelte strutturali del trattamento: ad esempio, la presenza di identificativi univoci, ampiezza del dataset raccolto, durata dei periodi di conservazione, assenza di pseudonimizzazione, opacità del modello decisionale. Esiste indipendentemente da errori di esecuzione, attacchi o negligenze: è il rischio insito nel modo in cui il sistema è stato concepito.
Il rischio da incidente (incident risk) è quello tradizionalmente presidiato: attacchi informatici, errori di configurazione, accessi non autorizzati da parte di dipendenti, phishing, guasti dei sistemi. È il rischio che qualcosa vada storto durante il ciclo di vita del trattamento.
La prassi tende a incentrare l’intera valutazione sulla seconda dimensione; il template europeo chiede invece di trattare in modo autonomo il rischio di progettazione, e di farlo prima – perché è l’unico che si possa davvero mitigare riprogettando.
La finestra temporale è ristretta: una volta che l’architettura è definita e il sistema è in esercizio, ridurre la retention o eliminare un identificativo univoco diventa un intervento costoso, che finisce regolarmente per essere rinviato.
Non a caso il tema compare già nella sezione su necessità e proporzionalità, prima ancora che nella valutazione del rischio vera e propria: il modello lo colloca a monte, dove l’art. 25 GDPR vorrebbe che stesse, e non in coda a un risk assessment di sicurezza che arriva quando le decisioni sono già state prese.
PIA della CNIL e template EDPB: cosa cambia davvero
Per chi ha costruito la propria prassi sul modello francese, il confronto puntuale è più utile di qualunque descrizione generale.
| Elemento | PIA CNIL | Template EDPB |
| Struttura | Quattro blocchi: contesto, dati, processi, rischi | Sette sezioni, cinquantuno campi |
| Scheda tecnica iniziale | Assente | Sezione 0 dedicata: versioning, team con matrice RACI, ruolo del DPO, scoping, approvazione |
| Descrizione del trattamento | Contesto e categorie di dati | Mappatura obbligatoria per fase del ciclo di vita, inventario degli asset di supporto, collegamento espresso al registro ex art. 30 |
| Rischio strutturale | Non previsto come sezione autonoma | Sezione distinta, anticipata dall’analisi di necessità e proporzionalità |
| Rischio da incidente | Nucleo dell’analisi | Una delle due dimensioni, non l’unica |
| Stato delle misure | Presente in forma parziale | Marcatore ternario esplicito: pianificata / parzialmente implementata / implementata |
| Coinvolgimento del DPO e degli interessati | Previsto ma poco formalizzato | Documentazione esplicita di come il parere del DPO è stato integrato |
| Natura dello strumento | Software di ausilio metodologico | Formato documentale comune, neutro rispetto alla metodologia di misurazione del rischio |
I due strumenti, quindi, non si escludono. La PIA resta un ausilio valido per condurre l’analisi; il template EDPB definisce come restituirla. Chi usa il software francese può continuare a farlo, a condizione di verificare che l’output copra i campi che il modello europeo pretende – e, come mostra la tabella, in almeno diversi punti oggi non li copre.
Cosa resta aperto: DPIA e FRIA
Il modello non risolve tutto, e alcuni temi resteranno presumibilmente aperti anche nella versione definitiva. Il più significativo riguarda il rapporto con la FRIA.
La FRIA (Fundamental Rights Impact Assessment), prevista dall’art. 27 dell’AI Act, non riguarda tutti i deployer di sistemi ad alto rischio: si applica a organismi di diritto pubblico, a enti privati che forniscono servizi pubblici, e a chi utilizza sistemi ad alto rischio per credit scoring o per la valutazione del rischio assicurativo. Per chi ricade in questo perimetro e tratta anche dati personali, i due obblighi si sovrappongono in larga parte: l’art. 27, par. 4, AI Act prevede che, dove gli obblighi FRIA siano già soddisfatti da una DPIA ex art. 35 GDPR, la FRIA si limiti a integrarla – non a duplicarla da zero.
[Vedi anche: Rischi e opportunità dell’AI: la FRIA come strumento strategico]
Il template EDPB del 14 aprile 2026, però, non contiene alcun riferimento all’AI Act. La lacuna è già stata segnalata in consultazione pubblica, con la proposta di aggiungere, nella scheda tecnica di sezione 0, un campo per indicare se il trattamento coinvolge un sistema ad alto rischio e se è stata acquisita la documentazione del provider.
Va detto che l’EDPB non ignora il problema: insieme alla Commissione europea sta lavorando a linee guida congiunte sull’interazione tra GDPR e AI Act, che dovrebbero chiarire anche se DPIA e FRIA potranno confluire in un unico documento.
Restano poi aperti altri due fronti, interni al solo impianto GDPR:
- le modalità di consultazione degli interessati ex art. 35, par. 9: il modello irrigidisce l’onere, ma non indica come la consultazione debba avvenire né quali forme siano ritenute adeguate;
- il riesame ex art. 35, par. 11: la sezione 0 obbliga a tenere uno storico delle versioni della DPIA, con data e motivo di ogni modifica – così un rischio identificato non resta un appunto informale, ma diventa un dato tracciato, più difficile da lasciar cadere nel tempo. Non basta, però, a risolvere il problema di fondo: la norma non indica quando una variazione del livello di rischio sia sufficientemente significativa da rendere necessario un aggiornamento della DPIA, né stabilisce con quale frequenza la valutazione debba essere riesaminata quando non intervengano cambiamenti rilevanti. La valutazione di questi aspetti resta dunque rimessa al titolare.
Cosa conviene fare adesso
In attesa della versione definitiva, l’indicazione è duplice.
Sul piano documentale, conviene iniziare a sperimentare il modello sulle DPIA in corso, anche solo come griglia di controllo sovrapposta al proprio formato. L’esercizio più utile è verificare quali dei cinquantuno campi la struttura attuale non intercetta: nella maggior parte dei casi le lacune riguarderanno la sezione 0 e i rischi di progettazione. Chi continua a usare template generici rischia di produrre valutazioni che le autorità di controllo, Garante incluso, potrebbero considerare insufficienti in sede ispettiva: non perché il formato sia sbagliato, ma perché non copre quanto il riferimento comune ormai presuppone.
Sul piano metodologico, l’adeguamento non si esaurisce nella sostituzione del modulo. Occorre piuttosto abituarsi a porre la domanda che il template rende obbligatoria: quali pregiudizi per gli interessati questo trattamento produce anche quando funziona come previsto? È una domanda che si può porre da subito, con qualunque formato, e che cambia l’esito della valutazione molto più di qualsiasi riorganizzazione dei campi.
