Quando un progetto è finito e qualcuno chiede «e la privacy?», la risposta costa dieci volte tanto. È il problema che l’articolo 25 del GDPR prova a risolvere con due parole — by design e by default — che quasi nessuno usa nel modo giusto.
Non sono due adempimenti
Si trovano quasi sempre scritti insieme, come se fossero due caselle da spuntare. Non lo sono. La privacy by design è un modo di progettare; la privacy by default è una delle sue conseguenze — la più visibile, ed è per questo che il GDPR l’ha tirata fuori e messa accanto all’altra.
L’idea non nasce a Bruxelles e non nasce nel 2016. La formula è di Ann Cavoukian, commissaria per l’informazione e la privacy dell’Ontario, e risale alla metà degli anni Novanta: vent’anni prima che diventasse obbligatoria in Europa. Nella versione originale i principi sono sette, e leggerli tutti serve, perché il GDPR ne ha tenuti due e ha lasciato gli altri cinque come sottinteso.
I sette principi, e cosa chiedono davvero
1. Prevenire, non correggere
I rischi si anticipano, non si aspettano. È il principio che in pratica si traduce nell’analisi del rischio e nella valutazione d’impatto: si fanno prima di aprire il progetto, non dopo il primo incidente.
2. Privacy come impostazione predefinita
In qualunque sistema — un software, un sito, un dispositivo — la protezione non deve richiedere un’azione della persona: deve essere già lì. Il caso più noto sono i cookie: un sito non installa cookie di profilazione finché qualcuno non dice di sì. Il caso meno noto sono le impostazioni di un social, dove la condivisione dovrebbe partire dal minimo e allargarsi su richiesta, non il contrario.
3. Privacy dentro il progetto, non accanto
La protezione dei dati è una funzionalità del prodotto, non un livello che si appoggia sopra alla fine. Una software house che sviluppa un CRM ci mette dentro la gestione dei consensi e i termini di cancellazione mentre lo progetta — non quando un cliente glielo chiede in gara.
4. Somma positiva, non somma zero
Il luogo comune dice che per avere più privacy si perde qualcos’altro: funzioni, velocità, sicurezza. Il principio dice il contrario, e nella maggior parte dei casi ha ragione: quando la protezione è progettata insieme al resto, non toglie niente. Toglie quando la si aggiunge dopo, perché a quel punto si può solo mettere una toppa.
5. Sicurezza per tutto il ciclo di vita
Dalla raccolta alla cancellazione, senza buchi. Cifrare i dati in transito e lasciarli in chiaro nell’archivio è un buco. Proteggerli benissimo per cinque anni e poi dismettere un server senza cancellarli è un buco. La catena vale quanto il suo anello peggiore, e l’anello peggiore è quasi sempre l’ultimo.
6. Visibilità e trasparenza
Le operazioni sui dati devono essere visibili e dimostrabili: chi tratta cosa, perché, con quale garanzia. Non è solo un obbligo verso le persone — è la condizione per cui l’organizzazione stessa sa cosa sta facendo. Un’azienda che non sa rispondere non ha un problema di trasparenza: ha un problema di controllo.
7. Rispetto per la persona
Impostazioni comprensibili, avvisi chiari, scelte reali. È il principio più facile da dichiarare e il più difficile da rispettare, perché costringe a rinunciare a qualche scorciatoia che funziona bene per l’azienda e male per chi sta dall’altra parte.
Cosa ne ha tenuto il GDPR
L’articolo 25 semplifica: chi decide come e perché trattare i dati deve adottare misure tecniche e organizzative adeguate fin dalla progettazione, e deve fare in modo che, per impostazione predefinita, si trattino solo i dati necessari a ciascuna finalità. Minimizzazione, pseudonimizzazione, limiti di accesso e di conservazione sono gli esempi che la norma stessa fa.
C’è poi un pezzo che si legge di rado, ed è il considerando 78: si rivolge a chi produce software e servizi, non a chi li usa. Dice che i prodotti andrebbero progettati in modo da permettere a chi li compra di rispettare le regole. Non è un obbligo diretto, ma è la ragione per cui in una gara ti chiedono se il tuo gestionale sa cancellare i dati di una persona: chi te lo chiede sta scaricando sul fornitore un requisito che la norma gli mette addosso.
Come si riconosce, in pratica
Non serve una teoria per capire se un’organizzazione progetta con la privacy dentro. Bastano tre domande, e sono le stesse che faccio a un cliente nuovo:
- Quando si parla di dati personali in un progetto nuovo? Se la risposta è «alla fine, quando lo vede il consulente», la privacy by design non c’è.
- Cosa succede se nessuno tocca le impostazioni? Se il comportamento predefinito è quello che raccoglie di più, manca la privacy by default.
- Chi sa dire dove finiscono i dati fra due anni? Se non lo sa nessuno, manca il ciclo di vita — e con lui la metà dei sette principi.
In una riga
Privacy by design vuol dire mettere la protezione dei dati dentro il progetto mentre lo si disegna, e non sopra quando è finito. Privacy by default vuol dire che chi non tocca niente è comunque protetto. Il resto — i registri, le informative, le valutazioni — sono il modo in cui si dimostra di averlo fatto.
Stai progettando qualcosa che tratterà dati personali, e vuoi impostarlo bene dall’inizio? Prenota una call di trenta minuti: si guarda il progetto e si stabilisce cosa serve davvero, prima che costi dieci volte tanto.