Due obblighi distinti dell’art. 25 GDPR. Uno si argomenta con documenti, l’altro si legge nel pannello di configurazione. È questa asimmetria a decidere dove arriva il rilievo.
Serena de Luca | DPO/RPD — Advisor in Governance, Privacy & Compliance | I&P Partners S.r.l., Cagliari
Settembre 2026
Nella maggior parte delle organizzazioni la conformità all’art. 25 GDPR è affidata a due cose: un paragrafo dell’informativa e una dichiarazione del fornitore. Poi arriva una verifica, e la domanda non riguarda come il sistema è stato progettato. Riguarda chi ha impostato quel valore, quando, e sulla base di quale finalità.
| In breve Privacy by design e privacy by default sono due obblighi distinti dell’art. 25 del Regolamento (UE) 2016/679. Il primo impone di incorporare la protezione dei dati nelle scelte sui mezzi del trattamento e nella sua gestione corrente. Il secondo impone che, senza alcun intervento, il sistema tratti solo i dati necessari a ciascuna finalità. Il primo si argomenta. Il secondo si osserva. |
| In sintesi L’art. 25 GDPR contiene due obblighi separati, non due formulazioni dello stesso principio.La privacy by design non si esaurisce nella fase progettuale: la norma la àncora a due momenti, la determinazione dei mezzi e il trattamento in corso.La privacy by default riguarda uno stato osservabile del sistema su quattro dimensioni tipizzate: quantità dei dati raccolti, portata del trattamento, periodo di conservazione, accessibilità.L’asimmetria che conta in sede di verifica è probatoria: il design si ricostruisce con documenti, il default si legge nella configurazione.Nei sistemi acquistati la configurazione predefinita la stabilisce quasi sempre il fornitore. Il titolare la eredita — e ne risponde comunque. |
Cosa prevede esattamente l’art. 25 GDPR?
L’art. 25 del Regolamento (UE) 2016/679 — il GDPR — è composto da tre paragrafi che assolvono funzioni diverse. Il primo riguarda il processo: tenuto conto dello stato dell’arte, dei costi di attuazione, della natura, dell’ambito, del contesto e delle finalità del trattamento, nonché dei rischi per i diritti e le libertà delle persone fisiche, il titolare adotta misure tecniche e organizzative adeguate ad attuare i principi di protezione dei dati in modo efficace e a integrare le garanzie necessarie. La norma indica la pseudonimizzazione come esempio, non come contenuto esaustivo.
Il dettaglio che quasi tutte le sintesi divulgative perdono è temporale: il paragrafo 1 àncora l’obbligo a due momenti distinti — al momento di determinare i mezzi del trattamento e all’atto del trattamento stesso. La privacy by design non è, testualmente, un obbligo che si consuma prima dell’avvio. È un obbligo che accompagna il trattamento per tutta la sua durata. Chi la legge come una checklist di progettazione ne applica metà.
Il secondo paragrafo cambia oggetto. Non descrive un processo: descrive uno stato. Il titolare deve garantire che, per impostazione predefinita, siano trattati solo i dati personali necessari per ogni specifica finalità. L’obbligo è tipizzato su quattro dimensioni — la quantità dei dati raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità — e si chiude con una regola puntuale: le misure devono garantire che, per impostazione predefinita, i dati personali non siano resi accessibili a un numero indefinito di persone fisiche senza l’intervento della persona fisica interessata.
Il terzo paragrafo attribuisce ai meccanismi di certificazione previsti dall’art. 42 il valore di elemento per dimostrare la conformità: un elemento, non una presunzione.
Qual è la differenza operativa tra privacy by design e privacy by default?
La distinzione corrente — design come «prima», default come «impostazioni predefinite» — è corretta ma poco utile, perché descrive le due norme dall’esterno senza dire cosa cambia per chi deve dimostrarne il rispetto. La differenza che produce conseguenze è un’altra: le due disposizioni hanno un regime probatorio diverso.
| Dimensione | Privacy by design — art. 25(1) | Privacy by default — art. 25(2) |
| Oggetto | Il processo che conduce alle scelte sui mezzi e sulle garanzie | Lo stato in cui il sistema si trova senza alcun intervento |
| Momento | Determinazione dei mezzi e trattamento in corso | Configurazione iniziale e ogni modifica successiva |
| Perimetro | Non tipizzato: dipende da rischio, contesto, stato dell’arte, costi | Tipizzato: quantità, portata, conservazione, accessibilità |
| Come si dimostra | Ricostruzione documentata delle alternative valutate e delle ragioni della scelta | Ispezione diretta della configurazione effettiva |
| Come si contesta | Occorre argomentare l’inadeguatezza di una valutazione | Basta rilevare uno scostamento tra impostazione e finalità dichiarata |
| Chi la determina in concreto | Chi sceglie architettura e mezzi del trattamento | Chi rilascia il prodotto — e chi non modifica il preset |
Letta così, la differenza non è temporale. È probatoria. E ha una conseguenza immediata su dove si concentra l’esposizione reale.
Perché la privacy by default è l’obbligo che si contesta per primo?
Perché è l’unico dei due la cui violazione si accerta senza ricostruire le intenzioni di nessuno. Un modulo che raccoglie un campo non necessario alla finalità dichiarata, una conservazione impostata di fabbrica su un valore indeterminato, un profilo visibile in via predefinita a tutti gli utenti interni di un applicativo: nessuno di questi rilievi richiede un giudizio sull’adeguatezza di una valutazione del rischio. Richiede il confronto tra due elementi entrambi documentabili — la finalità come risulta dal registro e dall’informativa, e la configurazione come risulta dal sistema.
La privacy by design, al contrario, si contesta solo entrando nel merito di una valutazione. È possibile, ed è successo, ma è un rilievo più oneroso da costruire: presuppone di dimostrare che una misura ragionevolmente disponibile è stata ignorata, tenuto conto dei costi e dello stato dell’arte. Il titolare che ha documentato le alternative e le ragioni della scelta ha, su questo terreno, un ampio spazio difensivo.
Ne discende un’asimmetria che vale la pena rendere esplicita: lo sforzo documentale delle organizzazioni tende a concentrarsi sull’obbligo che si difende con l’argomentazione, e a diradarsi sull’obbligo che si accerta con un’osservazione. È l’esatto contrario di quello che l’esposizione suggerirebbe.
Chi decide davvero la configurazione predefinita?
Nella grande maggioranza dei casi, non il titolare. I sistemi che trattano dati personali nelle organizzazioni italiane sono acquistati, non costruiti: gestionali, piattaforme SaaS, moduli verticali, applicativi in cloud. La configurazione predefinita arriva dal fornitore, calibrata sulle esigenze del suo mercato di riferimento, non sulle finalità del singolo cliente. Il titolare la eredita. E ne risponde comunque, perché l’art. 25(2) grava su di lui a prescindere da chi ha materialmente impostato il parametro.
Da qui in avanti la valutazione dipende da una sola variabile, e non è la gravità del trattamento: è se il parametro rientri nella disponibilità del titolare.
- Il parametro è configurabile. Il preset del fornitore non è una giustificazione: la mancata modifica è una scelta del titolare, e ricade in via diretta nell’art. 25(2). In questo caso il rilievo è pieno e non condivisibile con nessuno.
- Il parametro non è configurabile e il comportamento predefinito eccede la finalità. Il problema si sposta a monte, sulla selezione del fornitore e sul contenuto del contratto: qui operano gli obblighi generali del titolare e la disciplina del rapporto con il responsabile del trattamento. Nelle amministrazioni, la sede naturale di questa scelta è il capitolato — non la DPIA, che interviene quando il perimetro tecnico è già stato definito da altri.
C’è poi il punto meno presidiato di tutti: gli aggiornamenti. Un rilascio del fornitore può reintrodurre un preset, attivare una funzione nuova con la propria impostazione predefinita, modificare la visibilità di un campo. La conformità all’art. 25(2) non è uno stato che si acquisisce: è una condizione che ogni aggiornamento può far decadere senza che nessuno se ne accorga. Le organizzazioni che verificano la configurazione privacy dopo un rilascio sono, per esperienza di mandato, una minoranza netta — e quasi sempre sono le stesse che hanno un processo di change management già maturo per altre ragioni.
L’obiezione: non si sta caricando l’art. 25(2) di più di quanto dica?
L’obiezione è fondata e va formulata nella sua versione forte. L’art. 25(2) disciplina la minimizzazione per impostazione predefinita. Non nomina i fornitori, non disciplina la gestione dei rilasci, non istituisce un obbligo espresso di verifica periodica della configurazione. Ricavarne una disciplina della catena di fornitura è, sul piano testuale, un’estensione. Chi sostiene che quegli obblighi vivano altrove — negli obblighi generali del titolare e nella disciplina del rapporto con il responsabile — ha dalla sua la lettera della norma.
La lettura qui proposta regge per due ragioni. La prima è testuale: le quattro dimensioni elencate dal paragrafo 2 — quantità, portata, conservazione, accessibilità — non sono principi astratti, sono parametri di configurazione. Una norma che descrive uno stato del sistema descrive necessariamente uno stato da mantenere, non da raggiungere una volta. La seconda è sistematica: il principio di responsabilizzazione chiede al titolare di dimostrare il rispetto, non di averlo delegato. Se il titolare non può modificare la configurazione e non è in grado di dimostrare di averne verificato l’adeguatezza, non ha un problema di fornitore. Ha un problema proprio.
Resta vero che questa ricostruzione sposta parte del peso argomentativo su obblighi contigui anziché derivarlo interamente dall’art. 25. Chi preferisce l’altra strada arriva alle stesse conclusioni operative percorrendo un itinerario diverso. La divergenza è dogmatica; l’esito pratico coincide. Ed è l’esito pratico che viene verificato.
Come si documenta la conformità all’art. 25 senza produrre carta inutile?
Non serve una «policy privacy by design». È il tipo di documento che si scrive una volta, si allega a tutto e non risponde a nessuna domanda. Serve una traccia decisionale essenziale, per ciascun sistema che tratta dati personali, su tre punti.
- Quali alternative sono state considerate al momento di scegliere i mezzi, e perché è stata scelta questa. Tre righe con una motivazione reale valgono più di dieci pagine di principi generali, perché sono le uniche a reggere la domanda successiva.
- Quali parametri di configurazione incidono sulle quattro dimensioni dell’art. 25(2), su quale valore sono impostati, chi li ha impostati e in che data. È l’unico contenuto documentale che un verificatore può confrontare direttamente con il sistema.
- Chi verifica, dopo ogni aggiornamento rilevante, che la configurazione non sia cambiata; con quale cadenza; e dove risulta l’esito della verifica.
Il terzo punto è quello che manca quasi sempre. È anche l’unico che trasforma l’art. 25 da dichiarazione in misura: senza di esso, la documentazione fotografa uno stato che il sistema può aver già abbandonato.
Nelle procedure di acquisto, la domanda decisiva va posta prima dell’aggiudicazione: quali parametri sono nella disponibilità dell’ente e quali no. Posta dopo, l’unica leva rimasta è contrattuale — e a quel punto è già stata spesa.
Il test
Aprire il pannello di configurazione dell’ultimo sistema adottato, scegliere una qualsiasi delle quattro dimensioni dell’art. 25(2) e rispondere a tre domande: chi ha impostato questo valore, in funzione di quale finalità, e chi se ne accorgerà se il prossimo aggiornamento lo modificherà.
Se le risposte non esistono, la conformità all’art. 25 non è una misura. È un’affermazione contenuta in un’informativa.
La verifica della configurazione predefinita è, per singolo sistema, un’attività circoscritta. La sua assenza no.
Dott.ssa Serena de Luca
DPO/RPD — Advisor in Governance, Privacy & Compliance
I&P Partners S.r.l. — Cagliari | serena.deluca@partnerprivacy.it | partnerprivacy.it
