Blog

Privacy by design: cos’è e come si applica davvero

Privacy by design non è un documento da allegare a un progetto: è il modo in cui un software viene costruito fin dalla prima riga. Cosa chiede davvero l’art. 25 del GDPR e come si traduce in scelte tecniche concrete.

«Privacy by design» è una di quelle espressioni che si leggono ovunque e si capiscono di rado. Spesso viene trattata come un documento da allegare a un progetto, una casella da spuntare prima di andare online. In realtà non è un adempimento burocratico: è il modo in cui un software viene pensato e costruito fin dalla prima riga, perché protegga i dati delle persone senza che nessuno debba ricordarsene dopo.

Cosa dice davvero il GDPR

Il principio è scritto nero su bianco nell’art. 25 del GDPR, che parla di «protezione dei dati fin dalla progettazione e per impostazione predefinita». Sono due cose distinte. La protezione fin dalla progettazione, by design, riguarda le scelte fatte mentre il sistema viene costruito. La protezione per impostazione predefinita, by default, riguarda come il sistema si comporta appena acceso, prima che qualcuno tocchi una sola impostazione.

La legge non impone una tecnologia precisa. Chiede un risultato: che la tutela dei dati sia incorporata nel sistema, proporzionata ai rischi, e non aggiunta a posteriori come una toppa. È una differenza di sostanza, non di forma. Un sistema progettato bene non ha bisogno di rincorrere la conformità: ce l’ha già dentro.

Non è un documento, è un’architettura

L’errore più comune è ridurre la privacy by design a un file. Si scrive una relazione, si archivia, e si continua a costruire come prima. Ma un PDF non protegge nessun dato. A proteggere i dati sono le decisioni tecniche: quali informazioni si raccolgono, dove si salvano, chi può vederle, per quanto tempo restano, cosa succede quando non servono più. Queste decisioni si prendono in fase di progetto, e cambiarle dopo costa molto di più che farle bene all’inizio.

I principi, tradotti in scelte concrete

Privacy by design diventa utile solo quando smette di essere uno slogan e diventa una serie di scelte. Tradotti nella pratica, i principi suonano così.

  • Minimizzazione. Si raccolgono solo i dati che servono davvero a erogare il servizio. Un campo che non si raccoglie non va protetto, non si perde in una violazione, non va conservato. Il dato più sicuro è quello che non esiste.
  • Protezione predefinita. Le impostazioni iniziali sono le più tutelanti: nessun trattamento opzionale attivo di default, visibilità ridotta al minimo, consenso chiesto solo dove serve e mai preselezionato.
  • Limitazione della conservazione. Ogni dato ha una scadenza. Si decide fin dall’inizio quando un’informazione va cancellata o resa anonima, e lo si automatizza, invece di accumulare per sempre.
  • Accesso minimo. Ognuno vede solo ciò che gli serve per il suo compito. Un ruolo amministrativo non implica accesso a tutto: i permessi sono granulari e verificati a ogni richiesta.
  • Sicurezza incorporata. Cifratura dei dati sensibili, password mai in chiaro, log che non registrano informazioni personali complete. La sicurezza non è un modulo aggiunto in fondo, è parte di come il sistema è scritto.
  • Trasparenza. Chi usa il servizio può sapere quali dati vengono trattati e perché, in modo leggibile, non sepolto in venti pagine di condizioni.

Privacy by default: l’esempio del modulo di contatto

Un caso semplice rende l’idea meglio di ogni definizione: un modulo di contatto. La versione costruita senza pensarci raccoglie nome, cognome, telefono, azienda, e magari aggiunge uno strumento di statistiche che profila chi lo compila. La versione progettata con privacy by design chiede solo ciò che serve a rispondere, protegge il modulo dallo spam senza tracciare nessuno, e conserva la richiesta per il tempo necessario a gestirla, non per sempre.

# Dati raccolti dal form: solo il minimo necessario a rispondere
email       # per richiamare la persona
messaggio   # la richiesta vera e propria
# Niente nome obbligatorio, niente telefono, niente profilazione.

# Conservazione: la richiesta non resta per sempre
retention = 12 mesi  ->  poi cancellazione automatica

Nessuna delle due versioni viola la legge in modo evidente. Ma solo la seconda incorpora la tutela nel sistema, invece di affidarla alla buona volontà di chi lo gestisce. Questa è la differenza che l’art. 25 chiede di fare.

Perché conviene, non solo perché è obbligatorio

Costruire così non è un costo imposto dalla normativa. È un sistema migliore, sotto ogni aspetto che conta.

  • Meno rischio. Meno dati raccolti e conservati significano meno danni se qualcosa va storto. Una violazione fa meno male quando c’è poco da rubare.
  • Più fiducia. Un servizio che chiede solo l’essenziale, e lo dice chiaramente, è un servizio di cui le persone si fidano di più.
  • Costi più bassi. Incorporare la tutela dei dati durante lo sviluppo costa una frazione di quanto costa rifare un sistema già in produzione per metterlo in regola.
  • Conformità più semplice. Quando le scelte giuste sono già nel sistema, dimostrare di rispettare il GDPR diventa una formalità, non un’emergenza.

Quando serve un passo in più: la DPIA

Per i trattamenti che possono comportare un rischio elevato per le persone, il GDPR chiede una valutazione d’impatto, la DPIA. Non è un obbligo per ogni progetto, ma quando serve va fatta prima di costruire, non dopo. È proprio lì che la privacy by design mostra il suo senso: permette di individuare i rischi quando correggerli costa poco, cioè sulla carta, invece che su un sistema già in funzione.

Da dove si comincia

Privacy by design non richiede strumenti esotici. Richiede di porsi le domande giuste all’inizio del progetto, e di scrivere le risposte nel codice, non solo in un documento.

  • Mappare i dati: quali informazioni entrano nel sistema, da dove arrivano e perché servono.
  • Togliere il superfluo: ogni campo che non risponde a una finalità chiara va eliminato.
  • Fissare le scadenze: per ogni dato, decidere quanto a lungo va conservato e automatizzarne la cancellazione.
  • Chiudere gli accessi: permessi minimi, verificati a ogni operazione, non concessi una volta e dimenticati.
  • Documentare le scelte: non al posto di farle, ma per poterle dimostrare.

Alla fine, privacy by design non è un certificato da appendere al muro. È un modo di costruire: partire dalla domanda «di questo dato ho davvero bisogno?» e lasciare che la risposta guidi l’architettura. È così che è costruito questo sito, ed è l’approccio con cui penso ogni progetto: la protezione dei dati non come un vincolo da subire alla fine, ma come il punto di partenza.

Come questi principi diventano scelte tecniche concrete, dal form alla CSP ai log, in un sito reale:

Privacy e sicurezza by design, in pratica: le scelte dietro un sito reale

← Tutti gli articoli

Un progetto o un dubbio da affrontare?

Descrivi cosa ti serve: valutiamo insieme l’approccio giusto.

Richiedi una valutazione
Privacy by design: cos’è e come si applica davvero | Custralis