Privacy by design per aziende: 5 passaggi con EDPB e ISO 27701
Privacy by design significa integrare la protezione dei dati personali fin dalla progettazione di ogni sistema, prodotto o processo, non aggiungerla dopo come una toppa. L’articolo 25 del GDPR lo rende un obbligo per ogni titolare del trattamento, indipendentemente dalle dimensioni dell’azienda. Non basta applicarla una volta: va dimostrata nel tempo attraverso misure tecniche e organizzative documentate, secondo al principio di accountability.
In breve:
- La conformità alla privacy by design richiede l’integrazione di misure tecniche e organizzative fin dalla fase di progettazione, documentate e dimostrabili nel tempo.
- La privacy by default impone impostazioni predefinite che proteggono gli utenti senza azioni manuali, come limitare la raccolta ai dati necessari o disattivare automaticamente funzioni come la geolocalizzazione.
- Le misure chiave comprendono pseudonimizzazione, cifratura, controllo degli accessi, logging e politiche di conservazione automatizzate, da applicare fin dal primo rilascio.
- La valutazione d’impatto sulla protezione dei dati (DPIA) è obbligatoria per trattamenti ad alto rischio, e deve essere parte integrante del progetto, non un adempimento successivo.
- La documentazione accurata delle scelte progettuali e delle DPIA è essenziale per dimostrare la conformità e l’applicabilità di un sistema di gestione certificato, come ISO 27001 e ISO 27018.
Indice
- Privacy by design cos’è e in cosa differisce dalla privacy by default
- Perché il GDPR obbliga la privacy by design: articoli e responsabilità
- I principi fondamentali della privacy by design: come applicarli
- Le misure tecniche e organizzative da mettere in campo
- La valutazione dei rischi e la DPIA nella fase di progetto
- Scenari applicativi: dalla registrazione utente al cloud
- Standard e linee guida di riferimento per l’implementazione
- Come documentare le scelte progettuali per dimostrare la conformità
- Checklist operativa in 5 passaggi per iniziare
- La prospettiva di Securityhub sulla privacy by design
- I servizi Securityhub per rendere operativa la privacy by design
- Fonti
Privacy by design cos’è e in cosa differisce dalla privacy by default
La privacy by design è l’approccio con cui la protezione dei dati entra nel progetto fin dalla prima riga di codice o dalla prima bozza di processo, non come controllo finale prima del lancio. Chi costruisce un modulo di raccolta dati decide già in fase di analisi quali campi sono davvero necessari, per quanto tempo conservarli e chi potrà accedervi.
La privacy by default è un concetto distinto ma complementare: riguarda le impostazioni predefinite di un sistema, quelle che l’utente trova senza aver toccato nulla. Un servizio conforme non chiede più dati di quanti servano per la finalità dichiarata, e le opzioni più protettive per la persona devono essere quelle attive di default, non quelle da attivare manualmente.
Alcuni esempi rendono la distinzione operativa:
- Un modulo di registrazione progettato secondo privacy by design chiede solo nome, email e password, spostando dati opzionali (telefono, indirizzo) in una fase successiva e non obbligatoria.
- Un’app conforme a privacy by default arriva con la geolocalizzazione disattivata e la condivisione dei dati con terzi impostata su «no», lasciando all’utente la scelta di attivarla.
- Un sistema di log applica retention automatica: i dati grezzi vengono cancellati dopo un periodo limitato salvo diversa necessità documentata.
- Un CRM aziendale segmenta l’accesso ai dati sensibili solo al personale che ne ha realmente bisogno per il proprio ruolo.
La differenza pratica sta qui: la privacy by design guida le scelte architetturali, la privacy by default guida le configurazioni che l’utente finale incontra per primo.
Perché il GDPR obbliga la privacy by design: articoli e responsabilità
L’articolo 25 del GDPR non lascia spazio a interpretazioni facoltative. Il primo paragrafo impone al titolare di adottare misure tecniche e organizzative adeguate «sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso», tenendo conto dello stato dell’arte, dei costi di attuazione, della natura, dell’ambito, del contesto e delle finalità del trattamento, oltre ai rischi per le persone interessate. Questa formulazione compare nella guida interpretativa all’art.25 del GDPR, che chiarisce come la norma richieda un bilanciamento concreto, non un adempimento formale.
Il secondo paragrafo introduce la privacy by default come obbligo distinto: il titolare deve garantire che, per impostazione predefinita, siano trattati solo i dati necessari per ciascuna finalità specifica. Il terzo paragrafo lega tutto ai meccanismi di certificazione approvati, apre quindi la porta a standard come ISO 27701 come prova di conformità.
L’obbligo vale per una startup di tre persone come per una multinazionale: cambia la proporzionalità delle misure, non l’esistenza del dovere. E l’accountability richiede di poter mostrare, in caso di controllo, quali scelte sono state fatte e perché.
I principi fondamentali della privacy by design: come applicarli
Le linee guida EDPB 4/2019 sull’articolo 25 traducono l’obbligo normativo in principi operativi, spesso riassunti come sette criteri guida ispirati al lavoro originario di Ann Cavoukian. Ogni principio corrisponde a una scelta progettuale concreta:
- Proattività, non reattività — anticipare i rischi privacy nella fase di analisi, non correggerli dopo un incidente. In pratica: una checklist privacy nel documento di specifica funzionale.
- Privacy come impostazione predefinita — i valori di default proteggono la persona senza richiedere azioni attive. In pratica: consenso al marketing disattivato all’apertura dell’account.
- Privacy incorporata nella progettazione — non un modulo aggiuntivo ma parte dell’architettura. In pratica: campi di database progettati per la pseudonimizzazione fin dallo schema iniziale.
- Piena funzionalità, un approccio a somma positiva — la protezione dei dati non deve sacrificare l’utilità del servizio. In pratica: cifratura che non degrada le prestazioni percepite dall’utente.
- Sicurezza end to end per l’intero ciclo di vita — dalla raccolta alla cancellazione. In pratica: policy di retention automatizzata collegata al database di produzione.
- Visibilità e trasparenza — le persone devono poter verificare come i loro dati vengono trattati. In pratica: un’informativa privacy scritta in linguaggio chiaro, non in gergo legale.
- Rispetto della privacy dell’utente — l’interesse della persona resta centrale nelle scelte di design. In pratica: interfacce che non usano pattern ingannevoli per estorcere consensi.
Un consiglio: Trasforma ogni principio in un requisito di accettazione del progetto (un “criterio di done” nel linguaggio agile): se un principio non si traduce in una riga verificabile del capitolato tecnico, resta teoria e non arriva mai in produzione.
Le misure tecniche e organizzative da mettere in campo
L’articolo 25 non elenca in modo esaustivo le misure da adottare, ma indica la pseudonimizzazione come esempio esplicito. Nella pratica aziendale, il catalogo si è consolidato attorno a poche famiglie di interventi ricorrenti.
- Pseudonimizzazione: sostituire identificatori diretti (nome, codice fiscale) con chiavi che richiedono una mappatura separata per essere ricollegati alla persona.
- Cifratura: proteggere dati a riposo e in transito, così che una violazione non esponga informazioni leggibili.
- Controllo degli accessi (access control): assegnare permessi granulari basati sul ruolo, non su credenziali condivise.
- Registrazione degli eventi (logging): tracciare chi ha accesso a cosa, utile sia per la sicurezza sia per dimostrare conformità in caso di verifica.
- Politiche di conservazione (retention policy): definire e automatizzare la cancellazione dei dati oltre il periodo necessario.
Per un’applicazione web, questo significa configurare il database con campi pseudonimizzati dal primo deploy, non aggiungerli come refactoring successivo. Per un servizio cloud, significa verificare contrattualmente che il fornitore applichi le stesse misure sui propri sistemi, un tema approfondito nella guida su come implementare misure tecniche per la protezione dei dati.
Sul fronte organizzativo, ogni misura tecnica ha bisogno di un responsabile interno che ne verifichi l’efficacia e di personale formato a riconoscere quando una nuova funzionalità richiede una valutazione privacy prima del rilascio.
La valutazione dei rischi e la DPIA nella fase di progetto
Non ogni trattamento richiede una valutazione d’impatto sulla protezione dei dati (DPIA), ma alcuni scenari la rendono obbligatoria: monitoraggio sistematico su larga scala, trattamento di categorie particolari di dati, uso di nuove tecnologie con rischio elevato per le persone, o profilazione automatizzata con effetti significativi.
Una DPIA integrata al progetto segue una struttura riconoscibile:
- Descrizione del trattamento: finalità, dati coinvolti, flussi tra sistemi e soggetti terzi.
- Valutazione della necessità e proporzionalità: perché quei dati, per quanto tempo, con quale base giuridica.
- Identificazione dei rischi: probabilità e gravità di un impatto negativo sulle persone.
- Misure di mitigazione: le stesse misure tecniche e organizzative viste sopra, calibrate sul rischio specifico.
Il risultato della DPIA non è un documento da archiviare, ma un input diretto alle scelte architetturali: se il rischio residuo resta alto, il progetto va rivisto prima del rilascio, non dopo. Questo collegamento tra valutazione e documentazione è ciò che rende l’accountability verificabile in un audit.
Scenari applicativi: dalla registrazione utente al cloud
Nella registrazione di un nuovo account, privacy by design e by default lavorano insieme: il modulo raccoglie solo i campi indispensabili, il consenso a comunicazioni facoltative resta disattivato, e la password viene salvata come hash, non in chiaro.
Nell’internet delle cose (IoT), le sfide sono diverse: un dispositivo che raccoglie dati telemetrici deve poter anonimizzare le informazioni non essenziali prima dell’invio al server, ricevere aggiornamenti di sicurezza automatici, e permettere di limitare la raccolta ai soli dati funzionali al servizio offerto.
- Un termostato smart che invia solo dati aggregati di temperatura, non log dettagliati di ogni interazione dell’utente.
- Un fornitore cloud che accetta clausole contrattuali chiare su dove sono conservati i dati e chi può accedervi come sub-responsabile.
- Un reparto HR che segmenta l’accesso ai fascicoli dei dipendenti in base al ruolo, non all’anzianità aziendale.
Nei rapporti con fornitori e sub-responsabili cloud, la responsabilità del titolare non si esaurisce alla firma del contratto: va verificato periodicamente che le misure dichiarate corrispondano a quelle effettivamente in uso, un principio che la guida su come proteggere i dati personali per le PMI tratta in modo operativo.
Standard e linee guida di riferimento per l’implementazione
Le linee guida EDPB 4/2019 restano il documento più autorevole: definiscono i principi guida, spiegano come applicarli al ciclo di vita del trattamento e forniscono esempi settoriali che vanno oltre la lettera dell’articolo 25.
A livello nazionale, le pagine del Garante privacy dedicate a Data Protection by Design e by Default raccolgono riferimenti normativi e risorse pratiche pensate per il contesto italiano.
Sul piano degli standard tecnici, ISO 27701 estende ISO 27001 per includere un sistema di gestione delle informazioni sulla privacy (PIMS), utile per trasformare i principi normativi in controlli misurabili e verificabili in audit.
Un dato da tenere presente: l’articolo 25, paragrafo 3, del GDPR menziona esplicitamente i meccanismi di certificazione approvati come strumento per dimostrare conformità: un fattore che rende gli standard ISO più di un’opzione tecnica, un vero elemento probatorio.
Come documentare le scelte progettuali per dimostrare la conformità
Dimostrare la privacy by design richiede prove scritte, non promesse verbali. Il registro delle decisioni progettuali dovrebbe includere: la valutazione dei rischi effettuata, le alternative scartate e perché, le misure tecniche implementate con relativa data, e gli esiti di eventuali DPIA collegate.
Chi approva queste scelte cambia in base alla struttura aziendale: nelle PMI spesso è il titolare stesso insieme al DPO, se nominato; nelle organizzazioni più grandi il compito coinvolge il responsabile IT, il legale interno e la funzione di compliance. Il ruolo del DPO diventa centrale proprio in questa fase di validazione documentale.
Le revisioni non sono un evento unico: vanno pianificate a intervalli regolari, tipicamente in coincidenza con ogni modifica sostanziale al trattamento, e integrate negli audit interni previsti dal sistema di gestione della sicurezza. Il concetto di responsabilizzazione privacy approfondisce come strutturare questo registro in modo che resti utile anche a distanza di anni.
Checklist operativa in 5 passaggi per iniziare
Applicare privacy by design non richiede di rifare l’intera architettura in un giorno. Serve un ordine di priorità legato al rischio reale.
- Mappa i dati trattati: quali dati raccogli, dove vanno, chi vi accede.
- Applica la minimizzazione: elimina ogni campo raccolto senza una finalità specifica documentata.
- Configura i default protettivi: consenso disattivato, condivisione con terzi disattivata, retention limitata.
- Valuta se serve una DPIA: profilazione, dati sensibili o nuove tecnologie sono segnali da non ignorare.
- Documenta ogni scelta: registro delle decisioni, data, responsabile, esito.
| Priorità | Azione | Quando intervenire |
|---|---|---|
| Alta | Minimizzazione dei dati raccolti | Prima del rilascio di qualsiasi nuova funzionalità |
| Alta | Configurazione dei default protettivi | In fase di progettazione dell’interfaccia |
| Media | Valutazione DPIA | Trattamenti su larga scala o dati sensibili |
| Media | Documentazione delle scelte | Ad ogni modifica sostanziale del trattamento |
Se il trattamento coinvolge dati sensibili, volumi elevati o fornitori cloud multipli, il momento di coinvolgere un consulente esterno è prima del rilascio, non dopo una segnalazione del Garante.
La prospettiva di Securityhub sulla privacy by design
La differenza tra un’azienda che rispetta l’articolo 25 sulla carta e una che lo applica davvero si vede quando arriva un audit o una segnalazione: chi ha solo un’informativa privacy ben scritta scopre che non basta, perché l’accountability chiede prove delle scelte tecniche, non intenzioni dichiarate.
L’errore più comune che osserviamo è trattare la privacy by design come un progetto a se stante, separato dallo sviluppo software o dalla gestione IT quotidiana. Funziona il contrario: quando i controlli di minimizzazione e pseudonimizzazione entrano nei requisiti di accettazione di ogni nuovo progetto, la conformità diventa un sottoprodotto del lavoro ordinario, non un carico aggiuntivo da gestire a fine anno.
Chi ha dubbi su quando serve una valutazione formale può partire dalla guida sul ruolo del DPO: se la risposta non è ovvia, è già il momento di chiedere supporto.
— Valerio
I servizi Securityhub per rendere operativa la privacy by design
Securityhub trasforma i principi dell’articolo 25 in un sistema di gestione verificabile, invece di lasciarli come intenzioni scritte in un documento che nessuno controlla più dopo il primo audit. La differenza rispetto a un adeguamento fatto internamente senza metodo sta nella struttura: un sistema di gestione certificato secondo ISO 27001 costringe l’organizzazione a documentare, riesaminare e correggere le misure privacy con la stessa disciplina richiesta dall’articolo 25.
Securityhub accompagna le aziende italiane nella certificazione ISO 27001, utile per chi vuole integrare privacy e sicurezza in un unico sistema di gestione riconosciuto. Per le realtà che trattano dati nel cloud, la certificazione ISO 27018 offre una prova concreta delle misure adottate specificamente per la protezione dei dati personali in ambiente cloud. Chi parte da zero trova un percorso strutturato nella guida ai passaggi per la certificazione ISO 27001, utile per capire tempi e requisiti prima di avviare il progetto. Il primo passo concreto è richiedere una valutazione iniziale dei requisiti applicabili alla propria organizzazione.
Questo articolo fornisce informazioni generali e non sostituisce il parere di un avvocato qualificato. Consulta un professionista legale qualificato riguardo al tuo caso specifico prima di agire in base a questo contenuto.
Fonti
- Linee guida 4/2019 su articolo 25 Data Protection by Design and by Default
- Data Protection by Design e Data Protection by Default – Garante Privacy
Raccomandati
