{"id":979,"date":"2021-07-28T16:11:00","date_gmt":"2021-07-28T14:11:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/privacy-by-design-gdpr-guida-2021\/"},"modified":"2021-07-28T16:11:00","modified_gmt":"2021-07-28T14:11:00","slug":"privacy-by-design-gdpr-guida-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/privacy-by-design-gdpr-guida-2021\/","title":{"rendered":"Privacy by design: la guida 2021 al GDPR art. 25"},"content":{"rendered":"

Privacy by design<\/strong> non \u00e8 uno slogan da convegno: \u00e8 un obbligo di legge sancito dall’art. 25 del GDPR<\/strong> 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.<\/p>\n

In questa guida educational pensata per DPO, software architect, CTO, legal counsel e compliance officer<\/strong>, 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<\/em> 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.<\/p>\n

\"Sviluppatore
Privacy by design integrata nel ciclo di sviluppo software (SDLC).<\/figcaption><\/figure>\n

1. Privacy by design e by default: cosa significa<\/h2>\n

L’espressione privacy by design<\/strong> 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.<\/p>\n

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

La differenza non \u00e8 semantica. By design<\/em> riguarda il “come” si costruisce il sistema; by default<\/em> riguarda “come si presenta” all’utente al primo avvio. Entrambi sono obblighi giuridici, non raccomandazioni.<\/p>\n

2. Art. 25 GDPR: l’obbligo legale<\/h2>\n

Il Regolamento UE 2016\/679<\/strong>, noto come GDPR, ha trasformato il principio teorico in obbligo cogente. L’articolo 25<\/strong>, 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.<\/p>\n

Il testo \u00e8 chiaro: il titolare deve attuare i principi di protezione dei dati (minimizzazione, limitazione delle finalit\u00e0, integrit\u00e0 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<\/a> fino a 10 milioni di euro o al 2% del fatturato mondiale annuo (art. 83, par. 4).<\/p>\n

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.<\/p>\n

3. I 7 principi originali di Ann Cavoukian<\/h2>\n

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

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

    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).<\/p>\n

    \"Scudo
    Pseudonimizzazione, cifratura e minimizzazione: le difese tecniche del GDPR.<\/figcaption><\/figure>\n

    4. Privacy by design vs Privacy by default<\/h2>\n

    Confondere i due concetti \u00e8 un errore frequente. Vediamo le differenze in tabella:<\/p>\n\n\n\n\n\n\n\n\n
    Aspetto<\/th>\nPrivacy by Design<\/th>\nPrivacy by Default<\/th>\n<\/tr>\n<\/thead>\n
    Quando agisce<\/strong><\/td>\nIn fase di progettazione<\/td>\nIn fase di esecuzione\/uso<\/td>\n<\/tr>\n
    Cosa fa<\/strong><\/td>\nIntegra protezione nei processi e codice<\/td>\nImposta i parametri pi\u00f9 protettivi al primo avvio<\/td>\n<\/tr>\n
    Esempio tecnico<\/strong><\/td>\nCifratura at-rest del database utenti<\/td>\nProfilo utente impostato su “privato” di default<\/td>\n<\/tr>\n
    Riferimento<\/strong><\/td>\nArt. 25, par. 1 GDPR<\/td>\nArt. 25, par. 2 GDPR<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Sono complementari: un sistema pu\u00f2 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.<\/p>\n

    5. Tecniche pratiche: pseudonimizzazione, cifratura, minimizzazione dati<\/h2>\n

    Tradurre i principi in pratica significa adottare tecniche concrete. Ecco le pi\u00f9 rilevanti per chi sviluppa software gestionale o piattaforme web.<\/p>\n

    Pseudonimizzazione<\/h3>\n

    La pseudonimizzazione<\/strong> consiste nel trattare i dati personali in modo tale che non possano pi\u00f9 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 \u00e8 esplicitamente raccomandata dall’art. 25 e dal considerando 28.<\/p>\n

    Anonimizzazione<\/h3>\n

    Diversa dalla pseudonimizzazione, l’anonimizzazione<\/strong> \u00e8 irreversibile: il dato anonimo non \u00e8 pi\u00f9 riconducibile alla persona, neppure incrociandolo con altre informazioni. Il GDPR non si applica ai dati anonimi, ma raggiungere una vera anonimizzazione \u00e8 tecnicamente complesso (k-anonymity, differential privacy).<\/p>\n

    Cifratura at-rest e in-transit<\/h3>\n

    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.<\/p>\n

    Minimizzazione dei dati<\/h3>\n

    Raccogliere solo i dati strettamente necessari alla finalit\u00e0 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.<\/p>\n

    Controllo accessi e log<\/h3>\n

    Implementare un sistema robusto di gestione utenti<\/a> con ruoli granulari (RBAC), autenticazione multifattore per gli amministratori e log immutabili degli accessi ai dati personali \u00e8 una richiesta esplicita dell’EDPB e del Garante Privacy. Il principio del least privilege<\/em> 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.<\/p>\n

    Privacy-Enhancing Technologies (PET)<\/h3>\n

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

    Data retention policy automatica<\/h3>\n

    Conservare i dati indefinitamente \u00e8 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.<\/p>\n

    6. PIA e DPIA: valutazione di impatto<\/h2>\n

    La Privacy Impact Assessment<\/strong> (PIA), nella sua forma normata dal GDPR come Data Protection Impact Assessment<\/strong> (DPIA, art. 35), \u00e8 il processo strutturato di analisi dei rischi privacy di un trattamento. Non \u00e8 facoltativa: \u00e8 obbligatoria quando il trattamento pu\u00f2 presentare un rischio elevato per i diritti e le libert\u00e0 delle persone fisiche.<\/p>\n

    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.<\/p>\n

    Una DPIA ben strutturata include:<\/p>\n