Il 14 aprile 2026, l’European Data Protection Board ha reso pubblica una delle iniziative più significative per la compliance GDPR degli ultimi anni: un template armonizzato per le valutazioni d’impatto sulla protezione dei dati (DPIA), adottato formalmente il 10 marzo 2026 e ora sottoposto a consultazione pubblica fino al 9 giugno 2026.
Per chi opera quotidianamente come DPO o consulente questo template rappresenta qualcosa di più di un semplice modulo da compilare. È il segnale che il panorama della documentazione DPIA in Europa sta per subire una trasformazione strutturale: da un insieme frammentato di approcci nazionali, spesso privi di basi comuni, a un’infrastruttura documentale condivisa che diventerà, dopo la consultazione, lo standard di riferimento per tutte le Autorità di controllo dello Spazio Economico Europeo.
L’obiettivo di questo articolo è analizzare il template EDPB nella sua interezza, esaminarne le implicazioni operative per chi produce DPIA nel quotidiano della consulenza e collocarlo nel suo contesto normativo e metodologico con riferimento alle linee guida WP248, al software PIA della CNIL, allo standard ISO/IEC 29134:2017 e al nuovo contesto del Regolamento AI Act. Il contributo si chiude con una tabella di raccordo sezione per sezione e una tabella comparativa con i principali approcci preesistenti.
Indice degli argomenti
Perché il template DPIA EDPB cambia la compliance europea
L’articolo 35 del Regolamento (UE) 2016/679 introduce per la prima volta nell’ordinamento europeo l’obbligo di una valutazione preventiva dell’impatto sui diritti e le libertà degli interessati per i trattamenti che presentano rischio elevato. La norma è costruita su tre livelli: un obbligo generale (comma 1), un elenco di casi che richiedono obbligatoriamente la DPIA (comma 3) e la possibilità per le Autorità di controllo nazionali di pubblicare elenchi di trattamenti per i quali la DPIA è richiesta o esclusa (commi 4 e 5).
Il contenuto minimo della DPIA è definito dal comma 7: descrizione sistematica dei trattamenti e delle finalità; valutazione della necessità e proporzionalità in relazione agli scopi; valutazione dei rischi per i diritti e le libertà degli interessati; descrizione delle misure previste per affrontare tali rischi, incluse le garanzie, le misure di sicurezza e i meccanismi per garantire la protezione dei dati. Il legislatore europeo non ha imposto una metodologia specifica, lasciando ai titolari la libertà di scegliere l’approccio più adatto, purché coprano questi elementi essenziali. Il comma 9 introduce un elemento spesso trascurato nella prassi: ove opportuno, il titolare deve sentire il parere degli interessati o dei loro rappresentanti in merito al trattamento previsto, fatta salva la protezione degli interessi commerciali o pubblici o la sicurezza dei trattamenti. Il comma 2 stabilisce che nella conduzione della DPIA il titolare si avvale della consulenza del DPO, ove designato, un obbligo processuale che si riflette nella Sezione 5 del template EDPB.
Le linee guida adottate dal Gruppo Articolo 29 nell’aprile 2017 e successivamente incorporate dall’EDPB (WP248rev.01) hanno rappresentato il primo tentativo di dare contenuto operativo all’art. 35. Il documento ha introdotto due contributi fondamentali: un sistema di criteri per valutare quando un trattamento possa presentare un rischio elevato anche al di fuori dei casi tipici e un’architettura per la conduzione della DPIA.
I nove criteri del WP248 sono diventati il riferimento standard per DPO e consulenti in tutta Europa: (1) valutazione o scoring, inclusa profilazione; (2) decisioni automatizzate con effetti legali o simili; (3) monitoraggio sistematico; (4) dati sensibili o di natura altamente personale; (5) trattamento su larga scala; (6) abbinamento o combinazione di dataset; (7) dati relativi a soggetti vulnerabili; (8) uso innovativo o applicazione di nuove soluzioni tecnologiche od organizzative; (9) quando il trattamento in sé impedisce agli interessati di esercitare un diritto o utilizzare un servizio. In linea generale, la presenza di due o più criteri indica la necessità di condurre una DPIA.
Le linee guida hanno chiarito che la DPIA non è un adempimento una tantum ma un processo continuo, soggetto a revisione ogni volta che cambiano i presupposti del trattamento o il contesto organizzativo e sociale in cui si svolge. Questo aspetto della DPIA come documento vivo è ripreso esplicitamente nel template EDPB 2026 attraverso il sistema di gestione delle versioni presente nella Sezione 0.
In assenza di linee guida operative da parte di molte autorità nazionali il software PIA open source sviluppato dal CNIL è diventato il riferimento metodologico di fatto per larga parte dei professionisti europei. Il software organizza il processo DPIA in quattro blocchi: contesto (natura, finalità, soggetti coinvolti), dati (categorie, conservazione, trasferimenti), processi (misure di conformità, diritti degli interessati), rischi (identificazione, valutazione, piano d’azione).
La versione italiana del software è stata sviluppata con la collaborazione del Garante per la protezione dei dati personali, che ne ha tuttavia precisato la natura meramente ausiliaria: lo strumento non costituisce un modello al quale fare riferimento in ogni situazione di trattamento, essendo stato concepito come ausilio metodologico per le PMI. Il software PIA presenta alcune limitazioni strutturali rispetto alle esigenze di organizzazioni complesse: non distingue esplicitamente tra rischi intrinseci al design del trattamento e rischi derivanti da eventi accidentali, e non prevede un tracciamento formale dello stato di implementazione delle misure.
Lo standard internazionale ISO/IEC 29134:2017 fornisce un framework metodologico per la conduzione di PIA che ha alcune sovrapposizioni con la DPIA GDPR ma ne differisce per scopo e struttura. Lo standard definisce un processo a più fasi che include l’identificazione del contesto e degli asset informativi, l’analisi dei requisiti di privacy, la valutazione dei rischi per la privacy con metodologie ispirate alla gestione del rischio ISO 31000, e la definizione di un piano di trattamento. È spesso adottato da organizzazioni con processi di risk management strutturati o operanti in contesti internazionali dove il GDPR non è l’unico framework di riferimento.
La tabella seguente mappa ciascuna sezione del template EDPB ai corrispondenti riferimenti normativi GDPR, alle linee guida WP248, al software PIA della CNIL e all’impatto pratico per DPO e consulenti.
| Sezione EDPB | Contenuto | Rif. GDPR | Link WP248 / PIA CNIL | Impatto pratico DPO |
| Sez. 0 — Overview | Titolare, responsabili, denominazione trattamento, pianificazione, scheda tecnica DPIA (team, versioning, ragioni attivazione) | Art. 35(1), Art. 35(7)(a) | Corrisponde al blocco Contesto del PIA CNIL. WP248 §4 (chi conduce la DPIA) | Richiede identificazione formale del team multidisciplinare con ruoli RACI, versioning del documento, motivazione esplicita che ha scatenato la valutazione |
| Sez. 1 — Descrizione sistematica | Dati trattati, finalità, usi secondari, natura/ambito/contesto, fasi funzionali, architettura tecnica e inventario asset | Art. 35(7)(a) — descrizione sistematica; Art. 30 (registro) | Blocchi Dati e Processi del PIA CNIL; WP248 §4 (descrizione del trattamento) | Mappatura per fase obbligatoria (raccolta, uso, storage, condivisione, cancellazione); inventario asset significativi; collegamento con registro ex art. 30 |
| Sez. 2 — Analisi del trattamento | Base giuridica per finalità, lifting categorie speciali, minimizzazione, qualità dati, misure conformità su art. 5, diritti, art. 28, art. 25, art. 32 con stato implementazione | Art. 6, 7, 9, 5(1)(a-f), Artt. 12-22, Art. 25, Art. 28, Art. 32 | Parzialmente nel PIA CNIL; WP248 §3 (liceità, minimizzazione, sicurezza) | Stato implementazione esplicito per ogni misura (Pianificato / Parzialmente / Implementato) — accountability tracciabile e roadmap di conformità integrata |
| Sez. 3 — Necessità e proporzionalità | Impatti BY DESIGN sui diritti degli interessati; valutazione necessità; bilanciamento vantaggi/impatti (proporzionalità) | Art. 35(7)(b) — necessità e proporzionalità; Considerando 75, 76 | Assente come sezione distinta nel PIA CNIL; elemento metodologico nuovo rispetto a WP248 | Valutazione del rischio strutturale (design risk): obbliga ad argomentare se il trattamento, anche se perfettamente eseguito, è compatibile con i diritti degli interessati |
| Sez. 4 — Valutazione e gestione del rischio | Rischi da eventi non-default (bug, attacchi, errori, abusi interni); metodo valutazione; rischio inerente; piano d’azione; misure aggiuntive; rischio residuo | Art. 35(7) (c-d) — rischi e misure; Art. 32; Considerando 90 | Blocco centrale del PIA CNIL; ISO/IEC 29134; WP248 §4 (valutazione rischi) | Distinzione esplicita tra rischio da progettazione e rischio da incidente; piano d’azione tracciabile con collegamento rischi/misure/residui |
| Sez. 5 — Parti interessate | Parere DPO con documentazione del recepimento; opinioni degli interessati o loro rappresentanti (con giustificazione se non coinvolti) | Art. 35(2) — parere DPO; Art. 35(9) — parere interessati | Previsto da WP248 §7; presente nel PIA CNIL come sezione separata | Richiede documentazione esplicita di come il parere DPO è stato integrato; il silenzio non è sufficiente se gli interessati non vengono coinvolti |
| Sez. 6 — Conclusione | 4 esiti possibili: abbandono / consultazione SA / approvazione / approvazione condizionata | Art. 35(7), Art. 36 (consultazione preventiva) | Equivalente alla sezione conclusiva del PIA CNIL, con decisioni più strutturate | Formalizzazione dell’esito decisionale; tracciabilità dell’intero percorso di valutazione |
La tabella seguente mette a confronto il template EDPB 2026 con i principali framework preesistenti: il software PIA della CNIL, le linee guida WP248 e lo standard ISO/IEC 29134:2017:
| Dimensione | CNIL PIA | WP248rev.01 | ISO/IEC 29134:2017 | Template EDPB 2026 |
| Natura | Software applicativo open source | Documento di orientamento | Standard internazionale ISO | Template documentale armonizzato |
| Status normativo | Strumento volontario | Adottato come EDPB linee guida vincolante | Standard volontario | Post-consultazione: standard unico o meta-template obbligatorio per le DPA |
| Copertura geografica | EU | EU, base per elenchi nazionali ex art. 35(4) | Globale (ISO) | EU dopo adozione formale |
| Struttura metodologica | 4 blocchi: Contesto, Dati, Processi, Rischi | Checklist 9 criteri + contenuto minimo art. 35 | Processo a 7 fasi (PIA lifecycle) | 7 sezioni con distinzione design risk / incident risk |
| Design risk vs incident risk | unico blocco rischi | Parziale (natura del trattamento citata) | Parziale (identificazione minacce) | Esplicita e strutturale: Sez. 3 vs Sez. 4 |
| Stato implementazione misure | Non previsto formalmente | Non previsto formalmente | Previsto nel piano trattamento rischi | Esplicito: Pianificato / Parzialmente / Implementato |
| Ruolo DPO | Sezione dedicata alla raccolta del parere | Obbligatorio per legge | Consigliato nelle best practice | Sez. 5: parere + documentazione del suo recepimento |
| Coinvolgimento interessati | Presente come opzione | Previsto art. 35, WP248 | Previsto nel processo PIA | Sez. 5: richiede giustificazione esplicita se non coinvolti |
| Coordinamento AI Act/FRIA | Non previsto | Non previsto perché antecedente | Non previsto | Non esplicito ma struttura compatibile |
| Aggiornamento periodico | Gestito dal software | Raccomandato ogni 3 anni | Previsto nel ciclo di vita PIA | Versioning esplicito nella Sez. 0 (scheda tecnica DPIA) |
Il template EDPB 2026 è compatibile con l’approccio ISO/IEC 29134 ma non lo sostituisce: il template definisce la struttura documentale minima, mentre lo standard fornisce indicazioni metodologiche per i processi di analisi. Per organizzazioni certificate o in percorso di certificazione ISO 27001 che già dispongono di un framework di risk management strutturato, il template EDPB può essere visto come lo strato documentale GDPR che si sovrappone all’infrastruttura di risk management esistente.
Dalla Helsinki Statement a uno standard documentale comune
Per comprendere la portata del template DPIA, è necessario collocarlo nel contesto più ampio del programma di lavoro che l’EDPB ha avviato con la Helsinki Statement del luglio 2025. Quella dichiarazione ha rappresentato un cambio di postura dell’EDPB: da organo prevalentemente orientato alla produzione di linee guida interpretative a istituzione che si impegna a fornire strumenti pratici e operativi per facilitare la compliance.
Tra i risultati concreti già prodotti in attuazione della Helsinki Statement: la consultazione pubblica lanciata nel 2025 per identificare i template più utili per le organizzazioni, nell’ambito della quale il template DPIA e il template per il registro delle attività di trattamento erano i più richiesti; le linee guida DMA-GDPR coprodotte con la Commissione Europea, prima assoluta nella storia dell’EDPB; e l’accelerazione sui temi dell’anonimizzazione e della pseudonimizzazione. Il template DPIA 2026 è il primo output concreto di un programma di standardizzazione documentale che includerà, secondo la roadmap annunciata, anche un template per la notifica di data breach e un modello per gli accordi di cooperazione.
Il valore politico e regolatorio di questo approccio è significativo. L’EDPB non sta imponendo una metodologia di risk assessment ma sta definendo un’architettura documentale comune che, dopo la consultazione, diventerà il parametro di riferimento per tutte le DPA europee. Questo significa che una DPIA prodotta secondo il template EDPB sarà riconosciuta come strutturalmente adeguata in tutti i Paesi dell’UE, eliminando il rischio di dover rifare o adattare la documentazione per trattamenti transfrontalieri.
Come il template DPIA EDPB struttura il documento
Il template è organizzato in sette blocchi, numerati da 0 a 6. La numerazione riflette una progressione logica che va dall’identificazione degli attori e del contesto alla decisione finale, passando per la descrizione del trattamento, la verifica di conformità, la valutazione della proporzionalità e la gestione del rischio. Ogni sezione è accompagnata da un documento di supporto che spiega come compilare ciascun campo, fornisce esempi e chiarisce i concetti chiave.
Governance, versioning e attori del trattamento
Sezione 0 — Overview del trattamento
La sezione di apertura non è un semplice frontespizio. Contiene quattro elementi strutturali: l’identificazione del titolare (o dei contitolari, con tabella separata per ciascuno e specificazione delle rispettive responsabilità), l’elenco dei responsabili e sub-responsabili del trattamento con definizione dei rispettivi obblighi e compiti, la denominazione del trattamento (compreso il nome nel registro delle attività ai sensi dell’art. 30), e la pianificazione con date di avvio e termine previsti.
Il quinto elemento, la scheda tecnica della DPIA, è quello metodologicamente più ricco. Richiede: il versioning del documento con il log delle modifiche; l’identificazione del team coinvolto nella conduzione della DPIA con ruoli, compiti e responsabilità (matrice RACI); le linee guida, standard e codici di condotta utilizzati come riferimento; le ragioni che hanno attivato la valutazione (con una checklist che copre i casi obbligatori ex art. 35, i casi probabili per rischio elevato secondo le linee guida EDPB e nazionali, e i casi in cui la DPIA è necessaria o opportuna per altre ragioni); l’ambito della valutazione; la data di completamento e la data di validazione formale; e se la DPIA è destinata a essere pubblicata o condivisa.
Il versioning esplicito della DPIA nella Sezione 0 è uno degli elementi più rilevanti per la governance interna. Consente di tracciare l’evoluzione della valutazione nel tempo fondamentale per dimostrare accountability in caso di ispezione o data breach e per gestire le revisioni periodiche.
Mappatura del trattamento e inventario tecnico
Sezione 1 — Descrizione sistematica del trattamento
Questa sezione risponde all’obbligo di descrizione sistematica dei trattamenti previsti e delle finalità del trattamento di cui all’art. 35 GDPR. È articolata in quattro sottosezioni. La descrizione ad alto livello richiede una tabella per ciascun dato personale trattato, con indicazione del tipo, della categoria di interessato e dell’eventuale appartenenza alle categorie particolari ex art. 9; una tabella per ciascuna finalità con indicazione dei dati coinvolti e giustificazione; una tabella per gli usi secondari o compatibili; e una sezione sulla natura, ambito e contesto del trattamento, che include specificamente le domande sul trattamento transfrontaliero e sui trasferimenti verso paesi terzi.
La descrizione funzionale 1.2 richiede una mappatura per fasi: raccolta, uso, storage, condivisione e trasferimento, cancellazione e distruzione idealmente integrata da diagrammi di flusso dati. La sezione 1.3 richiede invece un inventario dei mezzi di trattamento, degli asset di supporto e dell’architettura tecnica sottostante, con una granularità che si spinge agli asset significativi (portali pubblici, API, interfacce di condivisione dati), raggruppati per modulo logico o strato tecnico, con rimando a documentazione tecnica separata per il dettaglio completo.
L’inventario degli asset richiesto dalla sezione 1.3 è uno degli elementi che genera più lavoro aggiuntivo nelle DPIA per trattamenti tecnologicamente complessi. Per soggetti NIS2 che abbiano già condotto una BIA o un’analisi degli asset, questo blocco può essere alimentato direttamente dalla documentazione NIS2, con un’ottima opportunità di efficientamento documentale e integrazione dei framework normativi.
Compliance analysis e stato delle misure
Sezione 2 — Analisi del trattamento
La Sezione 2 è la più articolata del template e corrisponde alla compliance analysis. È divisa in tre blocchi principali: liceità del trattamento (2.1), minimizzazione dei dati e qualità (2.2) e misure di supporto alla conformità (2.3).
La parte sulla liceità (2.1) richiede, per ogni finalità identificata in 1.1.b, di indicare la base giuridica ex art. 6(1) GDPR con giustificazione inclusa, per il legittimo interesse l’analisi di bilanciamento. Per i dati appartenenti a categorie particolari ai sensi dell’art. 9, richiede di individuare la specifica condizione che consente il trattamento, con adeguata giustificazione.
Il blocco della minimizzazione (2.2) è diviso in due tabelle: una sulla minimizzazione e i periodi di conservazione, con richiesta di giustificazione per ogni dato trattato, destinatari e relativa giustificazione, periodo di conservazione e sua giustificazione; e una sulla qualità dei dati, con metriche, requisiti o soglie di qualità per ogni elemento di dato trattato. Quest’ultima è particolarmente rilevante per trattamenti che alimentano decisioni automatizzate o sistemi di AI, dove la qualità del dato è direttamente correlata alla correttezza delle decisioni prodotte.
Il blocco delle misure di conformità (2.3) è organizzato in cinque sottosezioni, ciascuna con una tabella che richiede le misure adottate, una discussione della loro adeguatezza ed efficacia, e lo stato di implementazione articolato in Pianificato, Parzialmente implementato o Implementato. Le cinque categorie sono: misure a supporto dei principi dell’art. 5 GDPR; misure a supporto dei diritti degli interessati; misure a supporto di altri requisiti GDPR (consenso ex art. 7, relazione con i responsabili ex art. 28, garanzie per i trasferimenti internazionali); misure a supporto della data protection by design e by default ex art. 25; misure di sicurezza del trattamento ex art. 32.
Lo stato di implementazione esplicito è uno degli elementi di maggior valore operativo del template. Trasforma la DPIA da documento statico a strumento di gestione del ciclo di vita della conformità, con tracciabilità delle misure nel tempo. Una DPIA compilata con molte voci Pianificato non è un problema in sé ma richiede un piano d’azione e un calendario di implementazione coerente con i rischi identificati nelle sezioni successive.
La distinzione tra rischi strutturali e rischi da incidente
Il contributo metodologico più importante del template è la separazione esplicita e strutturale tra due categorie di rischio che nella pratica vengono frequentemente trattate come un’unica dimensione.
Necessità, proporzionalità e rischi di progettazione
Sezione 3 — Necessità e proporzionalità: il cuore metodologico
La Sezione 3 è il contributo metodologico più innovativo e impegnativo del template EDPB. La sua struttura riflette un’intuizione analitica che nella pratica delle DPIA è spesso trascurata: il trattamento stesso, per come è stato progettato, può porre rischi ai diritti e alle libertà degli interessati anche quando tutto funziona esattamente come previsto e tutti gli attori rispettano le regole.
La sottosezione 3.1 richiede di identificare le minacce poste dal trattamento così come è stato progettato e pianificato per essere implementato, incluse le misure tecniche, legali e organizzative di mitigazione già previste. La tabella chiede: come la minaccia può materializzarsi; le fonti di rischio (finalità, progettazione errata, debolezze, esposizioni); l’impatto sui diritti e le libertà degli interessati. L’explainer chiarisce che questi sono rischi che esistono a prescindere da errori, rischi strutturali che derivano dalle caratteristiche intrinseche del trattamento: l’uso di identificativi univoci, la durata della conservazione, l’ampiezza della raccolta, la granularità dei dati, la natura delle decisioni supportate.
Le sottosezioni 3.2 e 3.3 affrontano rispettivamente la necessità e la proporzionalità. La necessità richiede di valutare se il trattamento previsto è efficace e il meno intrusivo possibile per i diritti degli interessati, con evidenza delle alternative considerate. La proporzionalità richiede un bilanciamento esplicito tra gli impatti sui diritti degli interessati e i vantaggi del trattamento, considerando sia i benefici individuali che quelli collettivi. L’explainer rimanda alle linee guida EDPS sul toolkit della necessità e alle linee guida EDPB sulla proporzionalità.
Per un consulente che produce DPIA per clienti con trattamenti ad alta intensità di dati (monitoraggio dipendenti, sistemi di scoring creditizio, videosorveglianza, profilazione) la Sezione 3 richiede uno sforzo qualitativo significativo: non è sufficiente elencare le misure di sicurezza, bisogna argomentare perché il trattamento è strutturalmente giustificato. Questa è la DPIA come strumento di governance reale, non come mero adempimento formale.
Rischi operativi, piano d’azione e decisione finale
Sezione 4 — Valutazione e gestione del rischio
La Sezione 4 affronta la categoria di rischi complementare a quella della Sezione 3: i rischi derivanti da eventi non ordinari, accidentali, illeciti o anomali. Questi includono: minacce alla riservatezza, integrità e disponibilità dei dati in ottica cybersecurity; bug software, configurazioni errate, diritti di accesso inappropriati, errori operativi, vulnerabilità non corrette, abusi interni, attacchi esterni inclusi ransomware.
La sottosezione 4.1.b richiede di descrivere il metodo di valutazione del rischio: i livelli di probabilità e gravità con i loro significati, le metriche di rischio, le modalità di prioritizzazione e le soglie di accettazione. Se si utilizza una metodologia consolidata esterna, occorre citarla con link alla fonte.
La sottosezione 4.1.c richiede la valutazione del rischio inerente: per ciascun rischio identificato si indicano la probabilità e la gravità con fattori modulanti, il livello di rischio risultante, e un’analisi sulla sua accettabilità. Un’importante precisazione metodologica dell’explainer: in protezione dei dati, un rischio può essere considerato non accettabile anche quando la probabilità di accadimento è bassa, se la gravità dell’impatto potenziale è molto elevata.
Il blocco del piano d’azione (4.2) richiede: le misure di mitigazione aggiuntive con indicazione dei rischi mitigati e dello stato di implementazione; il calcolo del rischio residuo dopo l’applicazione delle misure aggiuntive; e un piano operativo con attività specifiche, team responsabili, tempistiche e riferimenti a documentazione esterna. L’integrazione tra le misure di sicurezza della Sezione 2.3.e e il piano di mitigazione della Sezione 4.2 è un punto critico di coerenza interna del documento che deve essere presidiato con attenzione.
Sezione 5 — Coinvolgimento delle parti interessate
La Sezione 5 affronta due categorie di coinvolgimento previste dall’art. 35 GDPR. La prima è il parere del DPO: il template richiede non solo di documentare l’opinione, le conclusioni e le raccomandazioni del DPO, ma anche di spiegare come il parere sia stato recepito. Questa è una distinzione cruciale rispetto alla prassi di molte organizzazioni, dove il DPO viene consultato nel senso di informato ma le sue indicazioni non vengono documentalmente tracciate.
La seconda categoria riguarda le opinioni degli interessati o dei loro rappresentanti. Il template richiede, ove appropriato, di documentare la loro partecipazione nel processo DPIA inclusa una spiegazione del perché la loro partecipazione non sia stata ritenuta opportuna o possibile. Questo requisito, già presente nell’art. 35 GDPR e nelle linee guida WP248, viene ora formalizzato come elemento documentale obbligatorio: il silenzio non è sufficiente, occorre giustificazione esplicita.
Sezione 6 — Conclusione e decisione
La sezione finale formalizza l’esito della valutazione in quattro possibili decisioni: il trattamento deve essere abbandonato; il trattamento sarà sottoposto a consultazione preventiva con l’Autorità di controllo, obbligatoria quando le misure non riducono il rischio a livelli accettabili o nei casi previsti dall’art. 36 per trattamenti nel pubblico interesse; il trattamento può procedere; il trattamento può procedere solo dopo che siano soddisfatte le condizioni specificate. Segue uno spazio per una giustificazione opzionale della decisione adottata.
La formalizzazione di questi quattro esiti è un miglioramento rispetto a molte DPIA esistenti, che si chiudono con un generico il trattamento può procedere senza esplicitare le condizioni o le eventuali consultazioni necessarie. La decisione esplicita e tracciata è la forma più robusta di accountability documentale che un titolare possa offrire in caso di ispezione o contenzioso.
La Sezione 3.1 indaga i rischi di progettazione: minacce che il trattamento pone per sua stessa struttura, indipendentemente dal fatto che si verifichino errori, attacchi o deviazioni. Ad es. un sistema che raccoglie dati di localizzazione ogni trenta secondi pone rischi per la privacy degli individui anche se non subisce mai una violazione di sicurezza. Un algoritmo di scoring che utilizza indicatori pone rischi di discriminazione anche se funziona esattamente come progettato. Un sistema di videosorveglianza pervasiva con conservazione estesa pone rischi per la dignità e la libertà di movimento anche se i video non vengono mai visualizzati da persona non autorizzata.
La Sezione 4.1 indaga invece i rischi operativi o da incidente: minacce che si materializzano quando il sistema non funziona come previsto come ad es. bug, configurazioni errate, accessi non autorizzati, attacchi ransomware, errori operativi, abusi da parte di personale interno. Questi sono i rischi che più comunemente popolano le DPIA esistenti, spesso sono una lista di minacce mutuata da un’analisi di rischio cybersecurity.
Questa distinzione è rilevante perché obbliga il titolare a eseguire due valutazioni concettualmente diverse. La valutazione dei rischi di progettazione richiede una riflessione sulla legittimità strutturale del trattamento: anche se tutto funziona perfettamente, il trattamento è compatibile con i diritti degli interessati? La valutazione del rischio da incidente richiede invece una riflessione sulla robustezza operativa: quali misure tecniche e organizzative proteggono il sistema da eventi non previsti?
Nella pratica consulenziale, questa distinzione ha conseguenze immediate. Una DPIA relativa a un sistema di monitoraggio comportamentale dei dipendenti basato su strumenti di tracciamento delle interazioni digitali non può limitarsi a evidenziare misure di sicurezza tecniche, quali l’adozione dell’autenticazione multifattore o il monitoraggio dei log, ma deve valutare in modo sostanziale i rischi per i diritti e le libertà dei lavoratori, la proporzionalità del trattamento e la sua effettiva liceità. Deve anche affrontare la domanda strutturale: il monitoraggio sistematico e continuativo dei lavoratori, per la finalità indicata, è proporzionato rispetto all’impatto sulla dignità e sulla riservatezza del rapporto di lavoro?
L’esplicitazione di questa distinzione è anche una risposta a una prassi diffusa: quella di produrre DPIA che sono analisi di rischio cybersecurity applicate al GDPR, senza una valutazione degli impatti del trattamento sui diritti degli interessati. Il template EDPB non consente questo scivolamento: le due sezioni sono separate, richiedono due analisi diverse e la Sezione 3 viene prima della Sezione 4 non casualmente.
Cosa cambia con il template DPIA EDPB per DPO e consulenti
Per chi redige DPIA con una certa frequenza, la domanda vera è: quanto cambia rispetto a come lavoro oggi?
Dipende da quanto il processo è già strutturato. Se utilizzi già strumenti come il PIA della CNIL o un approccio basato sul WP248, il passaggio al template EDPB non stravolge il lavoro, ma richiede qualche integrazione mirata.
In concreto, bisogna:
- aggiungere la Sezione 3, distinguendo chiaramente tra rischi legati alla progettazione e rischi legati agli incidenti;
- indicare, nella Sezione 2.3, lo stato di implementazione delle misure (attivo, parziale o da implementare)
- strutturare meglio la Sezione 0, includendo versioni del documento, ruoli e responsabilità e motivazioni della DPIA;
- formalizzare l’esito finale nella Sezione 6, scegliendo tra le opzioni decisionali previste.
In sostanza, non è più lavoro ma un livello di dettaglio maggiore rispetto a un’impostazione già matura.
Integrazioni possibili con NIS2, ISO 27001 e AI Act
Per chi ha prodotto DPIA in forma più libera o meno strutturata, l’adozione del template EDPB rappresenta un salto di qualità significativo che richiede un ripensamento dell’intero processo. In particolare, la Sezione 3 implica una fase di analisi che non è puramente tecnica ma richiede un giudizio sostanziale sul bilanciamento tra gli interessi del titolare e i diritti degli interessati un giudizio che il DPO deve essere in grado di supportare con argomentazioni strutturate.
Per le organizzazioni soggette alla Direttiva NIS2 o in percorso di certificazione ISO 27001, il template EDPB offre opportunità di integrazione documentale concrete. La Sezione 1.3 sull’architettura tecnica può essere alimentata direttamente dall’inventario degli asset prodotto per NIS2 o per il Sistema di Gestione della Sicurezza delle Informazioni ISO 27001. La Sezione 4 sulla valutazione del rischio è concettualmente compatibile con le metodologie di risk assessment già in uso per NIS2 e per ISO 27001, tipicamente basate su ISO 27005. La distinzione tra design risk e incident risk del template EDPB è compatibile con la struttura del risk assessment NIS2, che distingue tra rischi legati alla progettazione dei sistemi e rischi legati alla loro operazione. Per i soggetti essenziali o importanti ai sensi di NIS2 che devono produrre DPIA per i trattamenti ad alto rischio, un approccio integrato che utilizza il template EDPB come output documentale GDPR alimentato dall’analisi di rischio NIS2 riduce la duplicazione degli sforzi e aumenta la coerenza del framework complessivo.
Il template EDPB non richiama espressamente la Fundamental Rights Impact Assessment (FRIA) prevista dall’art. 27 dell’AI Act per gli sviluppatori di sistemi AI ad alto rischio in determinati settori. Tuttavia, il documento di accompagnamento segnala la connessione tra DPIA e FRIA e ne annuncia un approfondimento in una prossima analisi.
Ciò che è già chiaro è il rapporto normativo tra i due strumenti: l’art. 26 dell’AI Act impone al deployer di utilizzare le informazioni fornite dal provider del sistema AI ai sensi dell’art. 13 per adempiere all’obbligo di DPIA di cui all’art. 35 GDPR. In altri termini, la documentazione tecnica del sistema AI è un input necessario per la DPIA. La struttura del template EDPB, in particolare la Sezione 3.1 con la valutazione dei rischi strutturali del trattamento, è particolarmente adatta a ospitare l’analisi dei rischi intrinseci di un sistema di AI: gli impatti che il sistema produce per la sua stessa progettazione prima ancora che si verifichino malfunzionamenti o violazioni di sicurezza.
Per i DPO e consulenti che gestiscono clienti deployer di AI ad alto rischio, il template EDPB può fungere da struttura integrante per un documento che copre simultaneamente l’obbligo DPIA GDPR e, parzialmente, i requisiti FRIA AI Act, riducendo la duplicazione e aumentando la coerenza delle valutazioni.
La consultazione pubblica e il valore strategico del template
Il template è in consultazione pubblica fino al 9 giugno 2026. I commenti possono essere inviati attraverso il sito web dell’EDPB. L’EDPB ha confermato che tutti i contributi ricevuti saranno pubblicati sul proprio sito previo screening per bloccare invii non autorizzati. La consultazione non è formale pro forma: il template è in versione 1.0 e l’EDPB ha dichiarato esplicitamente che le modifiche appropriate verranno introdotte sulla base dei feedback ricevuti prima della finalizzazione.
Per DPO, consulenti privacy e associazioni di categoria, questa è un’opportunità concreta di contribuire a modellare lo strumento che diventerà il riferimento paneuropeo. Gli ambiti su cui il contributo professionale può essere più prezioso includono: la gestione pratica del versioning e delle revisioni nel tempo; l’integrazione con sistemi di gestione della qualità e del rischio preesistenti; la coerenza tra il template DPIA e gli altri template annunciati; le modalità operative di coinvolgimento degli interessati in contesti B2C, B2B e nella PA; la calibrazione della granularità richiesta per l’inventario degli asset nella Sezione 1.3; il coordinamento con la FRIA dell’AI Act.
Per i consulenti che operano prevalentemente in contesti italiani, potrebbe essere opportuno segnalare nella consultazione la necessità di linee guida nazionali di accompagnamento che raccordino il template con le specificità dell’ordinamento italiano ad es. D.Lgs. 51/2018 per i trattamenti per finalità di polizia, normativa bancaria e assicurativa, TULPS per le strutture ricettive, Statuto dei Lavoratori per i trattamenti in ambito HR. Il template EDPB è costruito sul GDPR in senso stretto, e la stratificazione normativa italiana non è contemplata nella sua struttura attuale.
Il template DPIA dell’EDPB è un’infrastruttura documentale che ridefinisce cosa significa condurre e documentare una DPIA conforme al GDPR in Europa. La sua adozione ha implicazioni che vanno oltre la semplice struttura del documento.
Il template formalizza una distinzione metodologica che era implicita nella letteratura ma raramente messa in pratica: la differenza tra rischi strutturali del trattamento e rischi operativi da incidente. Questa distinzione eleva la qualità attesa delle DPIA e riduce la possibilità di produrre valutazioni che sono, nella sostanza, analisi di rischio cybersecurity con l’etichetta della compliance GDPR.
Una DPIA compilata correttamente con il template EDPB è, al contempo, una valutazione del rischio, un piano d’azione e un registro di accountability tutto in un unico documento strutturato.
L’armonizzazione documentale che seguirà all’adozione da parte delle DPA nazionali ridurrà significativamente la complessità della compliance transfrontaliera. Per le organizzazioni che operano in più Stati membri una DPIA prodotta secondo il template EDPB sarà riconosciuta come strutturalmente adeguata in tutta l’UE, eliminando la necessità di adattamenti nazionali della documentazione.
Il template posiziona la DPIA come punto di convergenza tra GDPR, NIS2 e AI Act per coerenza strutturale. L’inventario degli asset, l’analisi del rischio da incidente e la valutazione dei rischi del trattamento sono elementi che si interfacciano naturalmente con i framework NIS2 e con la FRIA dell’AI Act. Per i professionisti che gestiscono clienti soggetti a più di uno di questi regimi, il template EDPB offre la possibilità di costruire un’architettura documentale integrata, riducendo la duplicazione degli sforzi e aumentando la coerenza complessiva del programma di compliance.
Per i DPO, i consulenti privacy e i compliance officer, il messaggio è chiaro: il momento di familiarizzarsi con il template EDPB e di contribuire attivamente alla sua consultazione è adesso, prima che diventi lo standard definitivo. La qualità delle DPIA prodotte in Europa nei prossimi anni dipenderà in misura significativa da quanto seriamente la comunità professionale avrà preso questo strumento.
