Privacy by default: le linee guida del Garante spagnolo in aiuto dei Titolari del trattamento

Lo scorso ottobre, a pochi giorni di distanza il Garante spagnolo (AEPD) e l’European Data Protection Board (EDPB) si sono cimentati nell’emanazione di linea guida su due dei concetti – forse – più “fumosi” e complessi di tutto il GDPR, insieme a quelli di larga scala e legittimo interesse. Nel caso di specie le Autorità hanno concentrato i loro sforzi sul contenuto dell’articolo 25 del Regolamento europeo sulla protezione dei dati personali, ai sensi del quale: “Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso, il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudoni­mizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati” – cd. privacy by design o fino dalla progettazione.

“Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica” – cd. privacy by default o per impostazione predefinita.

Concentrandosi sul documento redatto dall’AEPD, è il caso di sottolineare come questo abbia come obiettivo principe quello di fornire un approccio pratico all’applicazione del principio di privacy by default, così come stabilito all’interno del GDPR e degli orientamenti adottati dal Comitato europeo per la protezione dei dati, e quindi al trattamento dei soli dati necessari e sufficienti per il raggiungimento delle finalità previste e per le quali i dati siano stati raccolti.

Si ricorda che tale principio dovrebbe applicarsi ogniqualvolta si verifichi un trattamento di dati personali, indipendentemente dalla natura del trattamento in essere.

Le linee guida in esame si compongono di 3 allegati^[1] e 9 parti, di cui si analizziamo quelle ritenute più rilevanti.

Obiettivi e destinatari delle linee guida dell’AEPD

L’obiettivo, come già anticipato, è quello di poter fornire una valida guida per l’applicazione della privacy by default, pensata per le unità o servizi che, all’interno dell’organismo titolare del trattamento, siano responsabili della progettazione, della selezione, dello sviluppo, della diffusione e dell’uso di applicazioni e servizi.

Come ricorda il considerando 78 del GDPR: “In fase di sviluppo, progettazione, selezione e utilizzo di applicazioni, servizi e prodotti basati sul trattamento di dati personali o che trattano dati personali per svolgere le loro funzioni, i produttori dei prodotti, dei servizi e delle applicazioni dovrebbero essere incoraggiati a tenere conto del diritto alla protezione dei dati allorché sviluppano e progettano tali prodotti, servizi e applicazioni e, tenuto debito conto dello stato dell’arte, a far sì che i titolari del trattamento e i responsabili del trattamento possano adempiere ai loro obblighi di protezione dei dati”.

In tal senso, quindi, la guida si rivolge anche a responsabili, sviluppatori o fornitori.

Principi delle linee guida dell’AEPD

Il Garante spagnolo AEPD ricorda come, ai sensi dell’articolo 25, un’applicazione “rendicontabile” della protezione dei dati by default divenga una delle misure di responsabilità proattiva che consentono di dimostrare il rispetto degli obblighi previsti dalla norma e quindi del cd. principio di accountability che grava sul Titolare.

Il GDPR rimane, però, flessibile con riferimento alla scelta delle misure di sicurezza adeguate a garantire tale conformità, così che l’ente potrà scegliere approcci e alternative diversi, pur nel rispetto del principio di minimizzazione: “minima quantità di dati personali, minima estensione del trattamento, minimo termine di conservazione e minima accessibilità ai dati personali”^[2].

Viene fatto notare come a loro volta, le – citate – Guidelines 4/2019 on Article 25 Data Protection by Design and by Default^[3] affermino che la Privacy by default faccia riferimento alle scelte effettuate rispetto ai valori di configurazione o alle opzioni di trattamento stabiliti nei sistemi e nelle procedure che attuano il trattamento e che determinano la quantità dei dati personali raccolti; la portata del trattamento, il periodo di conservazione e l’accessibilità.

Inoltre, il paragrafo 47 delle citate Linee Guida stabiliscono che le misure di sicurezza devono sempre essere incluse per default: “La sicurezza delle informazioni dovrebbe sempre essere l’impostazione predefinita per tutti i sistemi, i trasferimenti, le soluzioni e le opzioni nel trattamento dei dati personali”.

Tali doveri non vengono meno in capo al Titolare neppure nel caso si trattino dati di un numero ridotto di persone, e, nella scelta delle misure di sicurezza concrete da attuare, il processo di selezione per ciascuna di esse dovrà essere guidato da un’analisi dei rischi ex articolo 32 del Regolamento. È ovvio, altresì, che la privacy by default è indissolubilmente legata al concetto di protezione fin dalla progettazione, poiché le misure devono essere pensate fin dalla concezione del progetto ed attuate nella sua progettazione. Ma è altrettanto vero che a volte i due concetti potrebbero entrare in conflitto tra di loro, ad esempio nel caso in cui si portino all’eccesso le attività di monitoraggio o di autenticazione degli utenti tanto che le informazioni personali ottenute dall’utente possano rappresentare un rischio per i diritti e le libertà degli interessati.

Per ultimo viene citato il principio della trasparenza: solo conoscendo le caratteristiche del trattamento, l’interessato potrà decidere, liberamente e conscio delle possibili conseguenze, di selezionare quelle opzioni più avanzate dell’applicazione, del prodotto o del servizio capaci di incidere in modo significativo su di lui.

Tuttavia, è altrettanto sbagliata un’applicazione del principio di minimizzazione che comprometta lo scopo trattamento. Ad esempio, concepire una valutazione clinica che raccolga informazioni insufficienti in modo che non sia possibile ottenere una diagnosi dell’individuo con livelli di precisione adeguati, non solo non rispetterebbe il principio di minimizzazione, ma sarebbe anche contrario al principio di lealtà del trattamento, in quanto non sarebbe possibile realizzare lo scopo dichiarato.

Applicazione concreta delle linee guida dell’AEPD

Il Garante spagnolo AEPD in questa sezione riporta il parere espresso dall’EDPB in relazione all’attuazione delle misure di privacy by default, che si concentra su tre strategie:

– Ottimizzare: significa applicare misure in relazione alla quantità di dati raccolti, all’estensione del trattamento, alla loro conservazione e alla loro accessibilità.

– Configurare: ossia strutturare il trattamento in relazione ai dati personali, alle impostazioni disponibili nelle applicazioni, nei dispositivi o nei sistemi. Parte di questa configurabilità dovrebbe essere lasciata sotto il controllo dell’interessato.

– Restringere: la restrizione sarebbe in grado di garantire che un trattamento il più possibile rispettoso della privacy. Le opzioni di configurazione dovranno, quindi, essere rispettare i valori di limitazione della quantità di dati raccolti, di estensione del trattamento, di conservazione e di accessibilità.

Viene, poi, citato un passaggio importante del documento dell’EDPB in cui si chiarisce come il fatto che i dati personali siano necessari per il raggiungimento di una finalità non stia a significare che tutti i tipi di trattamento possano essere effettuati con qualsiasi frequenza. Ciò comporterà che il trattamento dovrà essere analizzato nelle sue diverse fasi, al fine di rispettare, per ciascuna di esse, il principio di minimizzazione.

L’applicazione del principio di minimizzazione non è di fatto banale, in quanto richiede lo studio, la giustificazione e la determinazione dei dati necessari al trattamento.

Ottimizzazione del trattamento

Questa parte delle Linee Guida dell’AEPD si concentra sul rilievo che per l’adozione di qualsiasi misura di responsabilità proattiva sia indispensabile l’analisi delle attività di trattamento, suddividendola in fasi, determinando le operazioni da effettuare in ciascuna fase, essendo a conoscenza delle peculiarità di ciascuna fase per poterle ottimizzare. Questo approccio deve, ovviamente, essere parte di una strategia più ampia di applicazione razionale delle misure di responsabilità proattiva.

Quanto alla fase di analisi, è utile riportare un esempio semplificato di un’attività di trattamento relativa alla selezione del personale, citato dal Garante spagnolo AEPD.

In questo caso, i riquadri “grigi” sono quelli in cui non si tratterebbero dati di carattere personale.

Si noti che le operazioni di trattamento possono essere realizzate mediante componenti quali applicazioni, server, sistemi operativi, componenti di rete, librerie, ambienti di sviluppo, ecc., o anche componenti di terze parti, compresi i servizi di assistenza alla clientela, o quelli cd. off-the-shelf^[4].

Nella figura sottostante, invece, vengono messi in evidenza gli elementi che configurano le fasi di un trattamento:

I trattamenti possono essere sia semplici e lineari, con impostazioni predefinite molto limitate, ma anche trovarci complessi e con diverse funzionalità in modo da potersi adattare a profili diversi o a utenti con esigenze specifiche.

Anche in ragione di ciò, va tenuto sempre ben a mente che i dati che sarebbero necessari per possibili funzionalità future, anche a scelta dell’utente, non dovrebbero essere raccolti in prima battuta per impostazione predefinita.

In nessun caso, comunque, l’interessato dovrà trovarsi nella situazione di accettare forzosamente o di vedersi negato il servizio: l’accesso ad un servizio non può essere rifiutato solo perché l’utente ha scelto una configurazione restrittiva in relazione alla quantità di dati trattati o all’estensione del trattamento^[5].

Andrà, poi, sempre tenuta presente l’eventuale relazione tra trattamenti differenti, come esemplificato dalla figura che segue, in cui “i trattamenti 1 e 2 includono fasi di conservazione dei dati personali, che sono implementate nei servizi di banche dati dell’entità, mentre i trattamenti 2 e 3 includono fasi di raccolta dei dati implementate sulle stesse librerie di acquisizione dati (ad esempio, una API su Android)”:

Il titolare del trattamento dovrebbe analizzare ogni trattamento nell’ambito per individuare le esigenze di configurazione dei servizi comuni a trattamenti diversi, ad esempio:

• determinare i dati minimi necessari per ogni trattamento;
• effettuare una separazione logica e/o fisica dei dati personali utilizzati in ogni trattamento;
• gestire i diritti di accesso;
• impostare uno spazio separato per il trattamento di dati sensibili.

Senza dimenticare di occuparsi anche dei profili relativi ai principi di necessità, di minimizzazione, di data retention, di accesso e di capacità di controllo da parte dell’interessato.

Configurabilità dei servizi e dei sistemi

Il Garante AEPD inizia dando la definizione di servizio non configurabile^[6], per poi proseguire con esempi di sistemi configurabili, quali la raccolta dei dati di geolocalizzazione, la memorizzazione nei registri delle attività, i permessi di accesso al contenuto delle informazioni di identità da richiedere ad un utente del sistema, la possibilità di cifrare le comunicazioni, l’uso di identificatori pubblicitari, ecc.

È onere del Titolare stabilire i requisiti di configurabilità in ciascuna delle sue fasi, in funzione dell’analisi effettuata, per poi trasferirli alle fasi di progettazione e di attuazione. Soprattutto quando si trattino dati di minori o dati sui gruppi di persone che si trovano in situazioni vulnerabili (vittime di violenza, persone a rischio di esclusione sociale, ecc.).

La configurabilità deve tenere conto dei seguenti quattro aspetti:

– identificazione dei requisiti, cioè la determinazione e selezione di una serie di parametri suscettibili di essere modificati.

– determinare di quali opzioni saranno sotto il controllo esclusivo del titolare e con quali limiti;

– determinare di quali opzioni saranno sotto controllo dell’interessato^[7];

– determinare se i componenti off-the-shelf soddisfino i requisiti di configurabilità.

Restrizioni by default

L’accesso alla funzionalità di base del sistema (funzionalità iniziale, valori di fabbrica, …) deve essere sempre disponibile e selezionata inizialmente senza che sia necessario alcun cambiamento da parte del responsabile o dell’utente.

In applicazione del principio di lealtà o “fairness”^[8], il Titolare deve garantire che non siano utilizzati “schemi oscuri” o “dark patterns”, cioè interfacce utente progettate per influenzare mediante manipolazioni psicologiche e occulte le scelte della persona interessata, almeno per quanto riguarda il trattamento dei suoi dati personali.

Mezzi di protezione dei dati by default

Il Garante spagnolo AEPD evidenzia come sia necessario adottare misure riguardanti:
– la quantità di dati personali raccolti, sia da un punto qualitativo che quantitativo^[9];

– l’estensione del trattamento (secondo i principi di necessità, pertinenza e non eccedenza);

– il periodo di conservazione (nel rispetto del principio di minimizzazione^[10]);

– l’accessibilità dei dati^[11].

Ovviamente, di tutto ciò sarà certamente obbligatorio poter dar prova documentale, anche ai sensi del citato principio di accountability.

1. Si segnala nello specifico l’Allegato 2 contenente una lista esemplificativa (ma non esaustiva) delle possibili opzioni di configurazione, alla cui attenta lettura si rimanda. ↑
2. Linee guida AEPD, pagina 5. ↑
3. Al paragrafo 2.2. ↑
4. Ossia componenti preesistenti (“prelevati dallo scaffale”), prefabbricati, progettati per un altro scopo specifico, che provengono anche da usi precedenti dalla stessa entità, o di uso generale, che sono incorporati nella realizzazione di un trattamento. ↑
5. Si veda anche punto 3.1.2 delle “Guidelines 05/2020 on consent under Regulation 2016/679” dell’EDPB. ↑
6. Un servizio, un sistema o un’applicazione è “non configurabile” quando nella progettazione e nell’implementazione esistono parametri fissi che determinano in modo inalterabile il modo in cui il trattamento viene eseguito. In questi casi, si dice che la funzionalità è “wired-in” o cablata. ↑
7. Non è sempre necessario dare il controllo all’interessato in relazione alle opzioni di configurazione, ma se ciò avviene è importante che l’utente sia adeguatamente informato e comprenda le conseguenze, per quanto riguarda la sua privacy, i suoi diritti e le sue libertà, di scegliere una o più impostazioni o di modificare i valori predefiniti (ad esempio, nei casi in cui l’utente voglia ampliare le finalità iniziali del trattamento con funzionalità estese). In ogni caso, in caso di modifica, deve essere possibile tornare ai valori iniziali prestabiliti e recuperare la configurazione “privacy friendly” impostata ab origine in modo facile, semplice ed intuitivo. ↑
8. ex articolo 5.1 lettera a) del GDPR. ↑
9. Il Titolare dovrà considerare il volume dei dati personali trattati, il livello di dettaglio, le diverse categorie e i tipi di dati personali richiesti e necessari per effettuare un’operazione di trattamento, compresi i dati raccolti, quelli generati o dedotti da tali dati. ↑
10. Se un dato personale non è più necessario dopo l’esecuzione di una fase del trattamento, il dato dovrà essere eliminato (il che può comportare, in alcuni casi, il blocco 19 o l’anonimizzazione). Ad esempio, nei casi in cui è necessario utilizzare captcha su siti web, occorrerà giustificare la conservazione di tali informazioni per l’uso nelle fasi successive del trattamento. ↑
11. Questa analisi deve essere effettuata per ogni fase del trattamento e deve prevedere la definizione dei ruoli e delle responsabilità, il controllo dei privilegi di accesso e l’introduzione di meccanismi di controllo dell’accesso. ↑