Privacy by design: la guida 2021 al GDPR art. 25

Privacy by design non è uno slogan da convegno: è un obbligo di legge sancito dall’art. 25 del GDPR e una pratica concreta che ogni azienda italiana che tratta dati personali deve incorporare nei propri processi e nei propri software. Eppure, a tre anni dall’entrata in applicazione del Regolamento UE 2016/679, troppe PMI continuano a considerare la protezione dei dati come un adempimento formale da delegare al consulente esterno, invece che come un principio architetturale da integrare fin dalla progettazione di sistemi, applicazioni e procedure.

In questa guida educational pensata per DPO, software architect, CTO, legal counsel e compliance officer, vediamo cosa significa davvero progettare con la privacy in mente, quali sono i sette principi originali di Ann Cavoukian, le tecniche pratiche per implementare pseudonimizzazione e cifratura, come integrare la Data Protection by Design nel ciclo di vita del software (SDLC), quali errori commettono le PMI italiane e quali sanzioni rischiano. Una lettura di circa 15 minuti che vuole essere il punto di riferimento operativo per chi deve trasformare un principio normativo in scelte tecniche e organizzative concrete.

1. Privacy by design e by default: cosa significa

L’espressione privacy by design indica un approccio alla progettazione di sistemi, prodotti e servizi che incorpora la protezione dei dati personali fin dalle prime fasi di ideazione, e non come patch applicato a posteriori. Non si tratta di aggiungere un banner cookie o una checkbox di consenso: significa interrogarsi, prima ancora di scrivere una riga di codice, su quali dati siano realmente necessari, per quanto tempo debbano essere conservati, chi possa accedervi e con quali misure tecniche di protezione.

La privacy by default è il complemento operativo del medesimo principio: stabilisce che le impostazioni predefinite di un sistema debbano essere quelle più protettive per l’utente. Se un’app raccoglie posizione GPS, il default deve essere “disattivata”; se un social offre opzioni di visibilità, il default deve essere “amici” e non “pubblico”; se un gestionale traccia gli accessi, il default deve prevedere log riservati al solo amministratore.

La differenza non è semantica. By design riguarda il “come” si costruisce il sistema; by default riguarda “come si presenta” all’utente al primo avvio. Entrambi sono obblighi giuridici, non raccomandazioni.

2. Art. 25 GDPR: l’obbligo legale

Il Regolamento UE 2016/679, noto come GDPR, ha trasformato il principio teorico in obbligo cogente. L’articolo 25, intitolato “Protezione dei dati fin dalla progettazione e protezione per impostazione predefinita”, impone al titolare del trattamento di mettere in atto misure tecniche e organizzative adeguate, sia al momento di determinare i mezzi del trattamento, sia all’atto del trattamento stesso.

Il testo è chiaro: il titolare deve attuare i principi di protezione dei dati (minimizzazione, limitazione delle finalità, integrità e riservatezza) integrandoli nel trattamento e fornendo le garanzie necessarie. Non si parla di “best practice” ma di un obbligo che, se violato, espone alle sanzioni del Garante Privacy fino a 10 milioni di euro o al 2% del fatturato mondiale annuo (art. 83, par. 4).

Il considerando 78 specifica che il titolare deve adottare politiche interne, ridurre al minimo il trattamento, pseudonimizzare i dati il prima possibile, garantire trasparenza e consentire all’interessato di controllare il trattamento. Sono indicazioni operative che si traducono in scelte di architettura software.

3. I 7 principi originali di Ann Cavoukian

Il concetto di Privacy by Design nasce nel 2009 grazie ad Ann Cavoukian, allora Information and Privacy Commissioner dell’Ontario. Cavoukian formalizzò sette principi fondamentali che restano la bussola di chi progetta sistemi rispettosi della privacy:

1. Proattivo, non reattivo: anticipare e prevenire le violazioni invece di reagire dopo che si sono verificate.
2. Privacy come impostazione predefinita: l’utente deve essere protetto senza dover modificare alcuna configurazione.
3. Privacy incorporata nella progettazione: la protezione dei dati è parte integrante dell’architettura, non un componente aggiuntivo.
4. Funzionalità completa: privacy e funzionalità non sono in conflitto, si possono ottenere entrambe (somma positiva, non zero-sum).
5. Sicurezza end-to-end: protezione lungo l’intero ciclo di vita del dato, dalla raccolta alla cancellazione.
6. Visibilità e trasparenza: tutte le parti interessate devono poter verificare che le promesse siano mantenute.
7. Centralità dell’utente: l’interesse della persona è al centro di ogni scelta progettuale.

Questi principi non sono norme dirette, ma sono stati recepiti nello spirito dell’art. 25 GDPR e in numerose linee guida del European Data Protection Board (EDPB).

4. Privacy by design vs Privacy by default

Confondere i due concetti è un errore frequente. Vediamo le differenze in tabella:

Aspetto	Privacy by Design	Privacy by Default
Quando agisce	In fase di progettazione	In fase di esecuzione/uso
Cosa fa	Integra protezione nei processi e codice	Imposta i parametri più protettivi al primo avvio
Esempio tecnico	Cifratura at-rest del database utenti	Profilo utente impostato su “privato” di default
Riferimento	Art. 25, par. 1 GDPR	Art. 25, par. 2 GDPR

Sono complementari: un sistema può essere ben progettato (by design) ma con default permissivi, oppure avere default conservativi senza essere stato pensato architetturalmente per la privacy. Il GDPR richiede entrambi.

5. Tecniche pratiche: pseudonimizzazione, cifratura, minimizzazione dati

Tradurre i principi in pratica significa adottare tecniche concrete. Ecco le più rilevanti per chi sviluppa software gestionale o piattaforme web.

Pseudonimizzazione

La pseudonimizzazione consiste nel trattare i dati personali in modo tale che non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, conservate separatamente e protette. Un esempio classico: nella tabella ordini sostituire il nome cliente con un ID numerico, mantenendo la corrispondenza nome-ID in una tabella separata, cifrata e con accesso ristretto. La pseudonimizzazione è esplicitamente raccomandata dall’art. 25 e dal considerando 28.

Anonimizzazione

Diversa dalla pseudonimizzazione, l’anonimizzazione è irreversibile: il dato anonimo non è più riconducibile alla persona, neppure incrociandolo con altre informazioni. Il GDPR non si applica ai dati anonimi, ma raggiungere una vera anonimizzazione è tecnicamente complesso (k-anonymity, differential privacy).

Cifratura at-rest e in-transit

I dati personali devono essere cifrati sia quando sono memorizzati su disco (at-rest, AES-256) sia durante la trasmissione (in-transit, TLS 1.2+). Per i database, MySQL/MariaDB offrono Transparent Data Encryption; PostgreSQL supporta pgcrypto; lato applicativo, librerie come libsodium o le API native PHP (sodium_crypto_secretbox) consentono cifratura selettiva di colonne sensibili.

Minimizzazione dei dati

Raccogliere solo i dati strettamente necessari alla finalità dichiarata: se per inviare una newsletter basta l’email, non chiedere data di nascita e codice fiscale. Questa scelta riduce la superficie di attacco e l’esposizione legale in caso di data breach.

Controllo accessi e log

Implementare un sistema robusto di gestione utenti con ruoli granulari (RBAC), autenticazione multifattore per gli amministratori e log immutabili degli accessi ai dati personali è una richiesta esplicita dell’EDPB e del Garante Privacy. Il principio del least privilege stabilisce che ciascun utente debba avere accesso solo ai dati strettamente necessari al proprio ruolo: il magazziniere non deve poter consultare le buste paga, il commerciale non deve avere accesso ai dati medici dei clienti.

Privacy-Enhancing Technologies (PET)

Le PET sono tecnologie emergenti che permettono di elaborare dati personali riducendo i rischi privacy. Tra le più rilevanti nel 2021: differential privacy (aggiunta di rumore statistico per impedire la re-identificazione, già usata da Apple e Google in produzione), secure multi-party computation (calcolo congiunto su dati senza rivelarli alle parti), homomorphic encryption (operazioni matematiche su dati cifrati senza decifrarli), federated learning (training di modelli ML senza centralizzare i dati). Queste tecniche, per quanto ancora costose, rappresentano la frontiera della privacy by design.

Data retention policy automatica

Conservare i dati indefinitamente è una violazione del principio di limitazione della conservazione (art. 5, par. 1, lett. e). Una policy di retention ben implementata prevede regole differenziate per categoria di dato (es. fatture 10 anni per obblighi fiscali, dati di profilazione 24 mesi, log di accesso 6 mesi) e processi automatici di cancellazione o archiviazione.

6. PIA e DPIA: valutazione di impatto

La Privacy Impact Assessment (PIA), nella sua forma normata dal GDPR come Data Protection Impact Assessment (DPIA, art. 35), è il processo strutturato di analisi dei rischi privacy di un trattamento. Non è facoltativa: è obbligatoria quando il trattamento può presentare un rischio elevato per i diritti e le libertà delle persone fisiche.

Il Garante italiano ha pubblicato un elenco delle tipologie di trattamenti che richiedono DPIA obbligatoria: trattamenti su larga scala di categorie particolari di dati, monitoraggio sistematico di luoghi accessibili al pubblico, valutazioni o scoring (incluso il credit scoring), trattamenti che coinvolgono soggetti vulnerabili.

Una DPIA ben strutturata include:

• Descrizione sistematica del trattamento e delle finalità
• Valutazione della necessità e proporzionalità
• Identificazione e valutazione dei rischi per gli interessati
• Misure previste per affrontare i rischi (incluse le tecniche di privacy by design)
• Consultazione del DPO e, se necessario, del Garante

Per approfondire DPIA e ruolo del DPO consigliamo la lettura del nostro articolo dedicato a DPIA, DPO e obblighi GDPR, parte del cluster Compliance.

7. Privacy by design nel software development lifecycle (SDLC)

Integrare la privacy nel ciclo di vita dello sviluppo software è la traduzione operativa dell’art. 25. Vediamo come si articola in ciascuna fase.

Fase di analisi e requisiti

I requisiti privacy devono essere raccolti insieme ai requisiti funzionali. User stories del tipo “Come utente, voglio poter cancellare il mio account in modo definitivo” o “Come DPO, voglio un report degli accessi ai dati negli ultimi 12 mesi” devono entrare nel backlog. Il Data Mapping, ovvero la mappatura dei flussi di dati personali, è un’attività preliminare imprescindibile.

Fase di design

Le decisioni architetturali (database schema, API contract, autenticazione, logging) devono essere valutate sotto il profilo privacy. Il Threat Modeling in stile STRIDE o il framework LINDDUN (specifico per privacy) aiutano a identificare le minacce ai dati personali prima ancora di scrivere codice.

Fase di implementazione

Lo sviluppatore applica le tecniche viste sopra: cifratura, pseudonimizzazione, validazione input contro injection, sanitizzazione output contro XSS, gestione corretta dei segreti (mai in chiaro nel codice o nei repository Git).

Fase di testing

I test di sicurezza devono includere scenari privacy: l’utente A può vedere i dati dell’utente B? Il log conserva password in chiaro? L’export GDPR dei dati personali funziona correttamente? La cancellazione è effettiva o lascia tracce?

Fase di deploy e maintenance

Il monitoraggio continuo (SIEM, log analysis), le procedure di gestione dei data breach (notifica entro 72 ore al Garante, art. 33), gli aggiornamenti di sicurezza tempestivi e la revisione periodica della DPIA chiudono il cerchio.

8. Casi pratici (form contatto, login, e-commerce, app mobile)

Vediamo quattro scenari ricorrenti e come applicare privacy by design e by default.

Form di contatto sito web

Privacy by design: campi minimi (nome, email, messaggio), tokenizzazione CSRF, rate limiting anti-spam, cifratura TLS, salvataggio in DB con cifratura at-rest, retention policy automatica (es. cancellazione dopo 24 mesi). Privacy by default: checkbox marketing NON pre-spuntata, finalità ben separate (contatto vs newsletter vs profilazione).

Sistema di login

Password hashate con bcrypt o Argon2 (mai MD5 o SHA1), 2FA disponibile e raccomandata, rate limiting anti-brute-force, log dei tentativi falliti, notifica all’utente di accessi sospetti, token di sessione rigenerati ad ogni privilege escalation, cookie con flag HttpOnly, Secure, SameSite=Lax.

E-commerce

Dati di pagamento mai memorizzati lato server (delegare a PSP PCI-DSS compliant), indirizzi spedizione cifrati, account guest disponibile (privacy by default = non forzare la registrazione), funzione “elimina account” effettiva, export ordini in formato portabile (art. 20). Per chi sviluppa gestionali personalizzati integrati con e-commerce, la sincronizzazione dei dati deve seguire gli stessi principi.

App mobile

Permessi richiesti solo al momento dell’uso effettivo (just-in-time permission), nessuna telemetria attiva di default, dati sensibili in Keychain/Keystore e non in UserDefaults/SharedPreferences, certificate pinning per API critiche, build di produzione senza log verbose. Su iOS la transizione App Tracking Transparency introdotta da Apple con iOS 14.5 (aprile 2021) impone l’opt-in esplicito per il tracciamento cross-app: una manifestazione concreta di privacy by default a livello di sistema operativo.

API e microservizi

Quando l’architettura è distribuita, ogni chiamata API che trasporta dati personali deve essere autenticata, autorizzata, registrata e cifrata. Pattern come API gateway con rate limiting per endpoint, scope OAuth granulari, JWT firmati con chiavi a rotazione, audit log centralizzato sono parte integrante della privacy by design moderna. Mai esporre endpoint amministrativi su rete pubblica senza VPN o IP whitelist.

9. ISO/IEC 27701 e altri standard

Pubblicato nell’agosto 2019, lo standard ISO/IEC 27701 estende il sistema di gestione della sicurezza delle informazioni ISO/IEC 27001 con requisiti specifici per la gestione delle informazioni privacy (Privacy Information Management System, PIMS). È la prima certificazione internazionale dedicata espressamente alla privacy ed è strutturata per essere mappata sul GDPR.

Altri standard rilevanti:

• ISO/IEC 29100: framework di privacy
• ISO/IEC 29134: linee guida per la valutazione d’impatto privacy
• ISO/IEC 29151: codice di pratica per la protezione dei dati personali
• NIST Privacy Framework (gennaio 2020): approccio risk-based americano

La certificazione ISO 27701 non è obbligatoria, ma fornisce evidenza documentale dell’aderenza ai principi di privacy by design e può essere valutata positivamente in caso di ispezione del Garante o di richiesta da parte di clienti enterprise.

10. Errori frequenti delle PMI italiane

Dall’esperienza sul campo emergono pattern ricorrenti di non-conformità. Eccone i più diffusi:

• Privacy come adempimento formale: informativa scaricata da internet, registro dei trattamenti aggiornato una sola volta, DPO nominato ma mai consultato.
• Software legacy senza cifratura: gestionali interni con database esposti senza TLS, password salvate in chiaro, accessi non tracciati.
• Backup non cifrati: copie di sicurezza su NAS o cloud senza cifratura, accessibili a chiunque entri nella rete locale.
• Ex dipendenti con account attivi: mancanza di un processo di offboarding che disabiliti tempestivamente le credenziali.
• Mancata DPIA: trattamenti di videosorveglianza, geolocalizzazione veicoli aziendali o profilazione clienti avviati senza alcuna valutazione di impatto.
• Cookie banner non conformi: pre-spunta dei consensi, “accetta tutti” più visibile di “rifiuta tutti”, cookie tecnici e di profilazione mescolati.
• Trasferimenti extra-UE non valutati: uso di servizi cloud USA dopo Schrems II senza Standard Contractual Clauses aggiornate e Transfer Impact Assessment.
• Mancata nomina dei responsabili: fornitori IT, agenzie marketing, commercialisti che trattano dati senza accordo ex art. 28.

Questi errori non sono solo violazioni formali: rappresentano falle concrete che, in caso di data breach, espongono l’azienda a sanzioni significative.

11. Sanzioni mancata privacy by design

Il GDPR all’art. 83 distingue due fasce di sanzioni amministrative pecuniarie. La violazione dell’art. 25 rientra nella fascia inferiore (par. 4): fino a 10 milioni di euro o al 2% del fatturato mondiale annuo, se superiore. Sanzioni più elevate (20 milioni / 4%) sono previste per la violazione dei principi generali, dei diritti degli interessati e dei trasferimenti internazionali.

Casi reali di sanzioni per carenze di privacy by design includono:

• Provvedimenti del Garante italiano contro aziende che hanno subito data breach evitabili con cifratura adeguata
• Sanzioni nordiche (Norvegia, Svezia) contro società che hanno raccolto dati eccessivi rispetto alla finalità (violazione del principio di minimizzazione)
• Provvedimenti CNIL (Francia) contro piattaforme con default non protettivi degli utenti minorenni

Oltre alla sanzione, l’impatto reputazionale e i costi di remediation post-breach (notifica agli interessati, perizie forensi, eventuali risarcimenti civili) possono superare di gran lunga la multa stessa. Studi del settore stimano il costo medio di un data breach in oltre 4 milioni di dollari globali e in circa 3 milioni di euro in Europa, considerando i costi diretti (notifica, forense, legali) e indiretti (perdita di clienti, calo del prezzo delle azioni, premi assicurativi futuri).

Va inoltre ricordato che il GDPR all’art. 82 riconosce il diritto al risarcimento degli interessati che abbiano subito un danno materiale o immateriale a causa di una violazione del Regolamento. Negli ultimi due anni si sono moltiplicate le class action privacy in Europa: i tribunali italiani hanno già riconosciuto risarcimenti per data breach, anche per il danno morale derivante dalla mera perdita di controllo sui propri dati.

12. Domande frequenti

La privacy by design è obbligatoria anche per le piccole imprese?

Sì. L’art. 25 GDPR si applica a tutti i titolari del trattamento, indipendentemente dalle dimensioni. Variano le misure adeguate, non l’obbligo. Una microimpresa può implementare misure più leggere (es. cifratura del backup tramite VeraCrypt) ma non può ignorare il principio.

Chi è responsabile dell’implementazione: il DPO o il CTO?

Il responsabile è il titolare del trattamento. Il DPO ha funzione consultiva e di sorveglianza. Il CTO o software architect implementa le misure tecniche. Il legale traduce le scelte in clausole contrattuali. È un lavoro di squadra coordinato dal vertice aziendale.

Posso usare un software open source senza fare privacy by design?

No: usare un software esistente non esime dall’obbligo. Devi valutare se il software scelto rispetti i principi (audit), configurarlo correttamente (privacy by default), eventualmente integrarlo con misure aggiuntive (cifratura colonne, log, IAM).

Come dimostro di aver applicato privacy by design?

Tramite documentazione: registro dei trattamenti aggiornato, DPIA delle attività ad alto rischio, threat model, code review con focus privacy, log di audit, policy interne, formazione del personale. La documentazione è prova fondamentale in caso di ispezione.

Le soluzioni cloud sono compatibili con privacy by design?

Possono esserlo se scelte correttamente: SLA con misure di sicurezza adeguate, certificazioni del provider (ISO 27001, ISO 27701, SOC 2), regione di hosting in UE, accordo ex art. 28, valutazione dei rischi di accesso da parte di autorità extra-UE. Sono fondamentali soluzioni cloud sicure che integrino privacy by design fin dalla progettazione.

Posso adottare un approccio “compliance minima” e poi migliorare?

Sconsigliato. Aggiungere privacy by design dopo equivale spesso a riprogettare l’applicazione. Costa molto di più che integrarla fin dall’inizio, e nel frattempo accumuli rischio di sanzione e di data breach.

Per un quadro complessivo del GDPR in azienda consigliamo la lettura della nostra guida al GDPR aziendale per PMI, articolo pillar del cluster Compliance, e l’approfondimento sul modulo GDPR integrato in ERP Brenta.