Privacy by design e by default.

Due obblighi, non uno

La privacy by design e la privacy by default sono formulate come un unico obbligo del GDPR, ma richiedono due cose diverse, e i professionisti finiscono nei guai quando le confondono. By design significa che i controlli sulla privacy vengono integrati in un sistema fin dalla fase dei requisiti, prima che venga scritta una riga di codice o che venga scelto un fornitore, anziché aggiunti una volta che cominciano ad arrivare le richieste di accesso degli interessati. By default significa che quando un utente non fa nulla, il sistema si trova già nella sua impostazione più protettiva: la raccolta dei dati più ridotta, la conservazione più breve, la condivisione più rigorosa. Uno riguarda come costruisci; l'altro ciò che il sistema fa il primo giorno, senza alcuna configurazione.

La distinzione conta perché un team può soddisfare l'uno e mancare l'altro. Puoi condurre una revisione di progettazione approfondita, documentare una DPIA, e comunque rilasciare un prodotto i cui interruttori predefiniti sono tutti impostati sulla massima condivisione perché è ciò che ha chiesto il team di crescita. Quel prodotto è privacy by design ma non by default, e non è conforme. Accade anche il contrario: un'impostazione predefinita prudente aggiunta a un sistema che non è mai stato valutato lascia il titolare del trattamento incapace di dimostrare come sia stata fatta la scelta.

Cosa cambia davvero nella pratica

Il cambiamento pratico consiste nello spostare la privacy a monte. Anziché far esaminare al legale una funzionalità finita, i requisiti di privacy diventano vincoli di progettazione che ingegneria e prodotto portano avanti fin dal primo sprint. La minimizzazione dei dati smette di essere uno slogan e diventa una domanda posta per ogni campo di ogni modulo: ci serve questo per erogare il servizio, e se no, perché è qui. La limitazione della finalità diventa un vincolo su ciò per cui un insieme di dati potrà essere successivamente riutilizzato. La conservazione diventa un calendario predefinito che il sistema impone, non una pulizia manuale che nessuno si ricorda di eseguire.

• Raccogli il minimo dei campi di cui il servizio ha realmente bisogno, e giustifica ciascuno di essi.
• Imposta i periodi di conservazione come valori predefiniti imposti, con cancellazione o anonimizzazione automatica alla loro scadenza.
• Imposta i valori predefiniti di condivisione, visibilità e profilazione sull'opzione meno permissiva, lasciando che l'utente scelga di autorizzarne di più.
• Applica la pseudonimizzazione e la cifratura come scelte architetturali standard anziché come eccezioni.
• Delimita l'accesso ai dati personali per finalità, così che un sistema esponga solo ciò che una determinata funzione richiede.

Come si colloca rispetto ai concetti vicini

La privacy by design si comprende più facilmente per contrasto con ciò con cui le persone la confondono. Non è la stessa cosa di una DPIA, che è un elemento di prova del fatto che l'obbligo più ampio è stato adempiuto per una specifica attività di trattamento a rischio più elevato. Non è la security by design, che protegge i dati dagli attaccanti indipendentemente dal fatto che quei dati avrebbero dovuto essere raccolti; la privacy by design parte un passo prima, mettendo in discussione la raccolta stessa. E non è un controllo una tantum. Poiché i sistemi evolvono, l'obbligo è continuo: ogni nuova funzionalità, integrazione o flusso di dati riapre le stesse domande su minimizzazione, finalità e impostazioni predefinite.

In un programma maturo la privacy by design diventa un'abitudine radicata nel ciclo di vita dello sviluppo anziché un checkpoint in capo al legale. Prodotto e ingegneria sollevano le domande da soli, la DPIA viene attivata automaticamente quando il trattamento supera una soglia di rischio, e la configurazione predefinita viene esaminata come parte del rilascio anziché scoperta in produzione. Questa è la differenza tra un'organizzazione che può dimostrare il principio e una che si limita ad affermarlo.