Il concetto di protezione dei dati è percepito spesso in modo immediato come sinonimo di sicurezza, in realtà presenta dei connotati molti più estesi. Il Regolamento 679/2016 (“GDPR”) ha disposto formalmente l’estensione dell’ambito del concetto di protezione in fase di progettazione e requisitazione di nuovi processi e sistemi, prospettando una riconduzione delle misure di protezione attinenti alla privacy nell’ambito dei processi di “security by design”. L’articolo 25 del GDPR, come noto, ha statuito che sia al momento di determinare i mezzi del trattamento (fase di design delle soluzioni) sia all’atto del trattamento stesso, il titolare del trattamento deve mettere in atto misure tecniche e organizzative adeguate a garantire la conformità della soluzione disegnata ai principi e le tutele fondamentali previste dal GDPR. Le misure citate, a titolo esemplificativo, dall’articolo 25 del GDPR sono da considerarsi senz’altro lo standard minimo di riferimento delle misure da adottare in fase di progettazione di una soluzione, quali la misura della “pseudonimizzazione” valutata dal legislatore a priori “efficace” al fine di implementare i principi di protezione dei dati personali e la misura della “minimizzazione” ritenuta anch’essa a priori adeguata ad integrare, nelle soluzioni in fase di progettazione, le necessarie garanzie di tutela dei diritti degli interessati. Nel valutare l’adozione di misure di protezione dei dati e, quindi, nel valutarne anche la legittimità dell’esclusione (talvolta solo temporanea) di una misura, vanno considerati tutti gli elementi utili all’analisi del contesto, dei requisiti applicabili e dei rischi inerenti alla soluzione che si sta disegnando, tra cui in particolare andrebbero stimati:
- lo stato dell’arte e dei costi di attuazione di una misura;
- la natura, l’ambito di applicazione, il contesto e le finalità della soluzione in fase di progettazione che include il trattamento di dati personali;
- tutti i rischi di violazione delle disposizioni del GDPR o delle garanzie per i diritti delle persone interessate, incluse le diverse probabilità e gravità dei rischi.
Inoltre, sempre in fase di valutazione delle misure di protezione da adottare, il GDPR provvede che il tipico processo di “security by design” (ovvero il processo volto allo sviluppo sicuro di soluzioni dalla progettazione fino al testing) sia integrato dalla implementazione per impostazione predefinita di altre misure che, specificatamente, posso essere ritenute adeguate a ridurre il campo dei dati personali o la portata dei trattamenti.
Indice degli argomenti
Il processo di risk assessment in fase di progettazione
La valutazione delle misure di protezione dei dati personali in fase di progettazione non risulta nella pratica molto agevole, soprattutto nell’ottica di individuazione dei pre-settings da impostare (ad esempio, misure e funzionalità preimpostate), se non risulta a monte chiara l’identificazione dei rischi che una nuova soluzione può comportare e la valutazione dell’entità degli stessi. A tal proposito, i rischi inerenti la protezione dei dati personali dovrebbero essere considerati in base a una valutazione oggettiva mediante cui si stabilisce se i trattamenti di dati comportano un rischio o un rischio elevato, tenendo a mente come criterio di rischio target tutti i possibili impatti negativi che potrebbero emergere per i diritti e le libertà di una persona interessata (ossia la persona a cui si riferiscono i dati personali oggetto di trattamento da parte della soluzione in progettazione), come ad esempio un consumatore, un cliente, un paziente, un utente web e via dicendo. I rischi da analizzare e valutare in modo da individuare le opzioni di trattamento opportune devono essere considerati avendo riguardo delle operazioni di trattamento di dati personali insite nella soluzione in fase di progettazione suscettibili di cagionare un danno fisico, materiale o immateriale alle persone interessate. Tra i danni stimabili, il considerando 75 del GDPR indica di prestare particolare attenzione nel processo di risk assessment ai trattamenti di dati personali che potrebbero comportare delle discriminazioni, dei furti o usurpazioni d’identità, delle perdite finanziarie, dei pregiudizi alla reputazione, una perdita di riservatezza dei dati personali protetti da segreto professionale, una decifratura non autorizzata di dati pseudonimizzati oltre a qualsiasi altro danno economico o sociale significativo. Inoltre, la valutazione del rischio eseguita in fase di progettazione di una nuova soluzione dovrebbe considerare se gli interessati, a cui si riferiscono i dati personali oggetto di trattamento da parte della soluzione, rischiano di essere privati dei loro diritti o di una libertà (ad esempio, libera scelta di opporsi al trattamento dei propri dati personali) oppure rischiano che venga loro impedito l’esercizio del controllo sui dati personali che li riguardano. In ogni caso, massima attenzione nella valutazione del rischio dovrebbe essere posta quando la soluzione in progettazione potrebbe implicare il trattamento di dati appartenenti a “categorie particolari” (art. 9 e 10 GDPR), vale a dire dati da cui si possano rilevare l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, l’appartenenza sindacale, i dati genetici, i dati relativi alla salute o i dati relativi alla vita sessuale o a condanne penali e a reati o alle relative misure di sicurezza delle persone interessate. Altresì, lo sviluppo di soluzioni che supportino i processi aziendali di valutazione di aspetti personali di una popolazione di riferimento (si pensi ad esempio ai dipendenti oppure ad una popolazione di consumers in ambito assicurativo o finanziario), dovrebbe essere sottoposto ad una valutazione preliminare dei rischi associati in particolare quando la soluzione permette di eseguire attività di Business Intelligence (“BI”) volte a creare o utilizzare profili classificati mediante l’analisi o previsione di aspetti riguardanti il rendimento professionale, la situazione economica, la salute, le preferenze o gli interessi personali, l’affidabilità o il comportamento, l’ubicazione o gli spostamenti. Gli orientamenti per la messa in atto di opportune misure e per dimostrare la conformità della soluzione progettata al GDPR spingono all’adozione di politiche interne e misure volte a garantire di default:
- la riduzione al minimo il trattamento dei dati personali;
- la pseudonimizzazione dei dati personali il più presto possibile;
- un alto livello di trasparenza per quanto riguarda le funzioni e il trattamento di dati personali per consentire all’interessato di controllare il trattamento dei dati;
- continous improvement da parte della azienda che progetta nuove soluzioni in modo da creare e migliorare continuamente, e non una tantum, le caratteristiche di sicurezza delle soluzioni disegnate.
Sul punto, l’ENISA (Agenzia Europea per la sicurezza delle reti e dell’informazione) ha recentemente emesso un interessante documento di linee guida che indica raccomandazioni riguardanti il tema della data protection by default (ENISA_doc_Recommendations on shaping technology according to GDPR provisions_Exploring the notion of data protection by default, Dicembre 2018).
Le best practice messe in luce dall’ENISA
Il documento di Enisa “Recommendations on shaping technology according to GDPR provisions_Exploring the notion of data protection by default”, pubblicato il 28 gennaio 2019, fa luce sulle scelte delle impostazioni predefinite che devono essere tenute in considerazione nell’ingegneria del software per garantire un adeguato livello di protezione dei dati personali, in conformità alle previsioni del GDPR. Il documento nell’introduzione ribadisce come il concetto della privacy by default non sia un concetto nuovo, poiché gli sviluppatori si sono sempre occupati di valutare le adeguate pre-settings (ossia preimpostazioni) nella fase di progettazione, tuttavia il documento sottolinea come i pre-settings sono stati largamente considerati sotto il profilo della sicurezza mentre risulta un approccio meno standard e in ambito data protection. L’obiettivo del documento, corredato da esempi pratici, è quello di rafforzare una della finalità del GDPR, ovvero di garantire una maggiore equità nel trattamento dei dati personali, bilanciando le scelte di business, di sicurezza e di protezione dei soggetti interessati (nella accezione di consumatori o utenti). L’ENISA chiarisce, tuttavia, che le linee guida non vanno intese come uno standard di riferimento esaustivo ma un input all’analisi e ulteriore approfondimento sui diversi aspetti della protezione dei dati per impostazione predefinita, con particolare riferimento alle considerazioni che deriveranno dal continuo bilanciamento tra aspetti di protezione dei dati predefinite, requisiti di sicurezza e aspetti di usabilità delle soluzioni.
Raccomandazioni generali per aziende, produttori e utenti
L’ENISA fa luce sul diverso tipo di obblighi che gravano in capo alle aziende titolari del trattamento dei dati che vogliono adottare una nuova soluzione (ad es. un nuovo applicativo o piattaforma cloud) e quelli gravanti i capo ai produttori di servizi e applicazioni. Difatti, mentre il GDPR richiede espressamente ai titolari del trattamento dei dati di operare trattamenti sulla base di un approccio “privacy by design”, per i produttori di prodotti, servizi e applicazioni non è previsto obbligo diretto ai sensi del GDPR, tuttavia essi dovrebbero supportare i titolari del trattamento a raggiungere la piena compliance al GDPR, garantendo a loro volta una corretta progettazione e implementazione di misure pre-settings. I produttori di servizi e applicazioni dovrebbero astenersi dall’utilizzare modelli di progettazione che possano condurre a preimpostazioni o scelte non conformi ai principi fondamentale dettati dal GDPR nonché dalle best practice di riferimento, provvedendo invece ad incorporare adeguate misure di sicurezza e di protezione dei dati nei loro modelli e fornendo un’adeguata guida e supporto ai titolari committenti e agli utenti finali. Allo stesso tempo, l’ENISA indirizza una raccomandazione agli utenti finali partendo dal presupposto che gli utenti finali non potendo, per varie ragioni, contare sempre su servizi o applicazioni con preimpostazioni “privacy oriented” (e talvolta nemmeno su una preimpostazione sicura), dovrebbero cercare di porre massima attenzione nel comprendere le opzioni di sicurezza e di protezione dei dati che sono configurabili nei prodotti, sistemi o applicazioni che utilizzano.
Le properties e funzionalità esistenti al primo impiego
Il documento dell’ENISA pone molta attenzione in fase di progettazione di sistemi o serviti IT alle properties e funzionalità predefinite che incideranno in maniera significativa sul primo impiego dei sistemi o servizi, vale a dire i pre-settings che non comporteranno la richiesta di alcuna attività o scelta da parte dell’utente al primo utilizzo. Tali elementi risultano di vitale importanza poiché costituiscono la base su cui l’utente avvierà la sua prima interazione con il sistema o servizio e, se gli utenti non saranno in grado o disposti a configurare le impostazioni sulla base di proprie scelte, le impostazioni predefinite determineranno, di fatto, l’utilizzo duraturo del servizio o del sistema. In termini concreti, quindi, l’aspetto cruciale evidenziato dall’ENISA sta nel fatto le impostazioni di default se non correttamente implementate in linea ai principi del GDPR, possono incidere sulla protezione dei diritti e delle libertà delle persone non solo in un momento determinato ma per tutto il tempo di utilizzo di un sistema o servizio IT, ad esempio condizionando le scelte della quantità di dati personali raccolti, del tipo di trattamento, del periodo di archiviazione o quali e quanto soggetti potranno avere visibilità di quei dati. La cosiddetta “Privacy Engineering”, riveste oggi un ruolo determinante perché in grado di determinare per tutti i servizi e applicativi utilizzati nella quotidianità ma anche a livello più sofisticato aziendale il tipo e l’efficacia dell’incorporazione dei requisiti di riservatezza nella progettazione, a monte, e nel funzionamento, a valle, dei sistemi di informazione. In questo quadro, la stessa ENISA da atto che la scelta dei valori predefiniti corretti e adeguati allo scopo non è del tutto banale poiché richiede una valutazione della necessità per ogni scopo prefissato e un bilanciamento con altri requisiti che possono essere altrettanto importanti (si pensi all’usabilità). Tra i modelli di requisitazione messi in luce dall’ENISA per evidenziare pre-settings che spingono gli utenti verso scelte non sempre conformi ai principi del GDPR è stato indicato il settore delle app mobili, ove emergerebbe che gli utenti spesso non sanno quali sono le loro impostazioni predefinite e soprattutto se e come possono modificarle.
Default settings e privacy: modelli e misure
Nel processo di progettazione di servizi e sistemi IT, gli sviluppatori devono decidere i modi possibili per implementare la funzionalità desiderata. Facciamo due esempi:
- alcune funzioni sono cablate (“wired in”) cioè non possono essere configurate o modificate dopo che il sistema / servizio è stato progettato;
- altre funzioni dipendono dalla configurazione, ovvero indipendentemente dal fatto che tali funzioni siano attivate o meno e quali parametri vengano utilizzati, la loro configurazione può essere adattata in base alle esigenze degli utenti (cioè gli utenti finali possono modificare le impostazioni desiderate nel tempo, oppure una società committente dello sviluppo di una piattaforma può imporre la configurazione di alcuni settings utili per i propri dipendenti).
Per quanto riguarda le funzioni configurabili, quindi, gli sviluppatori devono determinare quali di essi devono essere pre-configurati, cioè impostati su valori specifici che vengono assegnati a un’impostazione configurabile del sistema o servizio, fino a quando tale impostazione sia cambiata mediante l’intervento dell’utente. La domanda da porsi in fase di progettazione è: questi valori tengono conto dei principi data protection? L’ENISA pone l’accento su quelle impostazioni predefinite che regolano gran parte dell’utilizzo quotidiano dei sistemi e dei servizi IT, che possono essere evidenti per gli utenti. Le impostazioni predefinite per la modalità di rete, la visualizzazione del sistema, le opzioni di backup, la configurazione del browser Internet sono solo alcuni dei casi tipici. I valori predefiniti di sicurezza determinano anche spesso le proprietà di sicurezza di base fornite da un servizio o un’applicazione. Le impostazioni predefinite rilevanti per garantire la conformità al GDPR risultano, dunque, tutte quelle che sono in grado di determinare il modo predefinito in cui un’applicazione o un dispositivo elabora i dati personali dell’utente, ad esempio per quanto riguarda l’accesso ai dati di contatto, l’uso della videocamera o del microfono di un dispositivo, i dati di geo-localizzazione di un mobile app. Sotto questo profilo, è indubbio che l’assegnazione di un valore predefinito serve anche a ridurre l’aggravio di attività in capo all’utente, in particolare:
- quando sono settate le impostazioni predefinite essenziali per consentire il corretto funzionamento di sistemi e servizi senza sottoporre agli utenti una moltitudine di domande e scelte da fare durante la loro esperienza di navigazione o utilizzo di un dispositivo o servizio;
- quando sono settate le impostazioni predefinite essenziali per ridurre la probabilità di errori lato utente dovuti, ad esempio, a errate selezioni di valori al mancato knowledge dell’utente medio rispetto alle attività di configurazione.
Ciò premesso, l’ENISA sottolinea come in ogni caso la possibilità di modificare le impostazioni predefinite attinenti la protezione dei dati personali da parte dell’utente rappresenti un requisito indispensabile che dovrebbe essere previsto ogni qualvolta, al primo utilizzo, sono state implementate delle default settings nel servizio o sistema IT offerto, al pari di ciò che accade per la modifica dei valori predefiniti di sicurezza (si pensi ad esempio alla modifica della password predefinita al primo utilizzo). In altre parole, le impostazioni predefinite sotto il profilo data protection (ad esempio, scelte di opt-in e di opt-out, opzioni sull’utilizzo o disattivazione dei cookies ecc.) giocano un ruolo fondamentale nella fase di progettazione di una soluzione poiché, come indicato in precedenza, l’impostazione predefinita determina come funzionerà il sistema o servizio se non sarà modificato nulla dall’utente. La tematica pertanto non attiene solo la fase di progettazione intesa come il punto di partenza ma, dal momento che molti utenti potrebbero non cambiare mai le impostazioni predefinite (per scelta, per mancata esperienza o altre ragioni), essa le impostazioni predefinite di trattamento (e protezione) dei dati personali rappresentano il modello che regolerà l’utilizzo duraturo di un sistema o servizio IT.
Le decisioni da prendere nella fase di progettazione
In fase di progettazione di una soluzione, gli sviluppatori si trovano difronte alla valutazione di alcune decisioni da assumere circa le funzionalità o comportamenti specifici della soluzione che è in costruzione. In via generale, il processo di valutazione può essere rappresentato nella seguente figura:
I criteri per la configurazione di default settings conformi al GDPR
Nel documento di linee guida dell’ENISA, l’Agenzia richiama alcune best practice di riferimento per l’impostazione dei valori predefiniti indicando alcuni esempi concreti per ciascuna delle 4 aree di misure citate dall’art. 25 del GDPR:
- quantità minima di dati personali;
- estensione minima del trattamento di dati personali;
- minimo periodo di conservazione dei dati personali;
- accessibilità minima dei dati personali.
Tali indicazioni, chiarisce l’ENISA, possono essere prese in considerazione per innalzare il livello di attenzione sulle specifiche casistiche ma non dovrebbero essere considerate una “valutazione legale di legittimità” nella scelta delle impostazioni predefinite migliori da adottare che andrà valutata, comunque, caso per caso.
Criterio della quantità minima di dati personali
Ridurre al minimo la quantità di dati personali da raccogliere e da utilizzare, in ogni step di un processo, è la pratica alla base di tutto l’approccio PbD. In altri termini, in ogni caso, a prescindere dal tipo di servizio o sistema da progettare, del contesto aziendale o degli utenti destinatari, il principio applicabile sempre è “meno dati personali, meglio è”. Un caso semplice di applicazione di questo criterio è rappresentato dalla raccolta di dati personali effettuata direttamente presso l’interessato, ad es. se un utente è invitato a compilare i dati personali mediante un form online. In questo caso, l’impostazione predefinita per la protezione dei dati è ridurre al minimo la quantità di campi del form di una pagina web o di una piattaforma (si pensi ad esempio alle pagine di back-office degli operatori di un customer service) ai soli necessari a perseguire la finalità prefissata. Inoltre, l’ENISA suggerisce come migliore pratica la scelta di valori da un elenco predefinito invece di offrire un campo di testo libero in cui l’utente potrebbe inserire ulteriori dati personali non necessari. Detto ciò, va sottolineato che la minimizzazione dei dati non si riferisce solo alla riduzione al minimo del numero dei campi ma segue un approccio anche qualitativo in tutte le successive progettazioni di raccolta dei dati personali. A tal fine, la minimizzazione può essere ottenuta anche aggregando, randomizzando o rendendo anonimi i dati personali. Altra buona pratica suggerita dell’ENISA consiste nella raccolta granulare di dati sulla base della necessità, ovvero quando sussistono dei sotto-scopi che governano diverse fasi dell’elaborazione dei dati una buona prassi che le impostazioni predefinite seguano questa granularità. Ad esempio, in uno scenario di e-commerce, un utente che naviga nel negozio online potrebbe decidere in primo luogo quali articoli acquistare valorizzando i relativi campi e solo successivamente potrà essere necessario anche che egli valorizzi i campi associati al nome e all’indirizzo di consegna dei prodotti selezionati. Inoltre, la minimizzazione può essere ottenuta in diversi casi mediante l’uso di misure tecnologiche specifiche, come ad esempio la pseudonimizzazione o la crittografia. Utilizzando il precedente esempio dello scenario di e-commerce, l’ENISA sottolinea come ad es. spesso la data di nascita potrebbe essere necessaria in caso alcune leggi proibiscano l’acquisto di alcuni beni in basi all’età (ad. esempio nell’ambito delle normative di prevenzione delle ludopatie oppure in tema di acquisto degli alcolici). In questo caso, un errore comune è ritenere necessario associare ad un utente la data esatta di nascita. Secondo l’ENISA invece buona prassi consisterebbe nell’implementazione di meccanismi in grado di verificare che la condizione “essere maggiorenne è soddisfatta” e trasferire e conservare traccia solo del risultato della applicazione della condizione (soddisfatta/non soddisfatta) anziché l’informazione specifica riguardante la data esatta di nascita. La minimizzazione, come anticipato, è una misura concreta da valutare sia in termini quantitativi che qualitativi. Sotto il secondo profilo, “l’entità minima” dei dati può differire per lo stesso tipo di dati in base alle finalità delle funzionalità del sistema. L’ENISA riporta alcuni esempi concreti di grande utilità: nell’area delle app mobili, i dati sulla posizione sono necessari solo per alcuni scopi specifici (ad esempio l’uso del navigatore), dovrebbe essere quindi inibito per impostazione predefinita l’uso dei dati di posizione per altre finalità a meno che siano attività e configurate volontariamente dall’utente in seguito. Allo stesso modo, l’accesso alla rubrica dello smartphone da parte di un app non dovrebbe essere considerato un default setting corretto ma solo in base alla finalità prefissata. Altro esempio utile richiamato dall’ENISA, in ottica del principio di minimizzazione, è l’utilizzo di “messenger” e in particolare della funzionalità che consente di default di sapere se un messaggio è stato visualizzato o meno e l’orario di accesso. Una buona pratica sarebbe quella di non settare di default questa impostazione ma di lasciarla configurabile da parte dell’utente, prevedendo che si chieda al destinatario se accetta / non accetta che queste informazioni siano inviate al mittente di un messaggio (ad esempio tale soluzione è attualmente incorporata come impostazione predefinita in diversi client di posta elettronica). Infine, per determinare la minimizzazione dei dati personali, non è rilevante solo la dimensione in bit. L’obiettivo è minimizzare è quello anche di minimizzare il rischio di trattamenti di dati appartenenti a categorie speciali (art. 9-10 GDPR) ovvero i cosiddetti sensibili o giudiziari senza che si sia verificata la condizione che ne legittima l’utilizzo o quando in ogni caso la medesima finalità potrebbe raggiungersi anche preferendo il dato personale comune a quello sensibile. Ad esempio, nell’ambito di sistemi di video riconoscimento o sorveglianza, in base alle finalità perseguite, la minimizzazione potrebbe essere applicata preferendo filmati a bassa risoluzione o con immagini sfocate o annerite rispetto alla conservazione di immagini ad alta risoluzione magari combinati con dati biometrici. L’analisi della necessità di una immagine dovrà tenere conto sicuramente della finalità perseguita, in base ad un bilanciamento del rischio con le esigenze esistenti ad esempio di caring o di accoglienza (che porterebbero a propendere per la prima soluzione) o di sicurezza e tutela del patrimonio aziendale (che potrebbero rendere necessaria l’adozione della seconda soluzione).
Criterio della portata minima del trattamento dei dati personali
Una delle migliori pratiche che tutti i titolari del trattamento di dati personali dovrebbero tener a mente si fonda sul criterio che “meno elaborazioni di dati personali sono realizzate per conseguire una finalità più si è conformi la principio della PbD”. Il trattamento di dati personali, come noto, comprende vari tipi di operazioni di trattamento, così come elencate dall’art. 4 del GDPR (ad esempio cancellazione, modifica, trasmissione ecc.). L’ENISA fa luce sul fatto che non è necessario ridurre il numero di operazioni di trattamento, ma ridurre al minimo il rischio per i diritti e le libertà degli interessati connessi alle operazioni di trattamento. Ad esempio, astenersi dall’archiviare i dati personali quando non è necessario riduce il rischio che un eventuale data breach possa coinvolgere anche quei dati personali. Di solito, questa è piuttosto una decisione di progettazione, tuttavia evitare che vi sia ad esempio una preimpostata archiviazione massiva dei dati in modo permanente supporta la riduzione della portata del trattamento ad un livello commisurato agli effettivi scopi perseguiti. Per fare un altro esempio, la portata delle operazioni di trattamento può essere ridotta nell’ambito dei Social Network con riferimento alle operazioni di “tagging” dei profili delle persone o alle “analisi biometriche” ove ciò non sia strettamente funzionale e pertinente allo scopo perseguito. La limitazione della portata dei trattamenti dei dati personali, inoltre, è strettamente correlata anche al tema della messa a disposizione degli utenti di un’area c.d. di “privacy self service” in cui gli utenti possono utilizzare strumenti adeguati a esercitare i loro diritti previsti dagli artt. 12-20 del GDPR). Una buona pratica, pertanto, potrebbe essere considerata prevedere delle dashboards apposite, ossia dei cruscotti configurati per l’esercizio dei diritti in modalità semplificate (flag per selezioni opt-in o opt-out, button per la disattivazione di cookies ecc.).
Criterio del periodo di conservazione necessaria dei dati personali
Altra misura chiave che ogni titolare del trattamento dovrebbe tenere in considerazione è quella connessa all’assunto che “ove non necessario, i dati personali non devono essere conservati”. La necessità, naturalmente, richiede una valutazione qualitativa che individui le basi di legittimazione di una conservazione dei dati personali per un periodo predefinito, duraturo o meno (ad esempio obblighi di legge, necessità di difesa in giudizio, necessità di eseguire un contratto stipulato con la persona interessata ecc.). Tale principio di conservazione limitata al necessario, si estende non solo ad esempio ai dati di un data base aziendale ma comprende anche tutte le copie o i log generati nel tempo. Trascorso il periodo di conservazione necessaria, i dati devo essere cancellati o anonimizzati. Ad esempio, nel caso in cui sia stato eseguito una survey, rivolta agli utenti web, una buona pratica riportata nel documento di linee guida dell’ENISA, sarebbe quella di prevedere, per impostazione predefinita, che le singole risposte degli utenti non siano memorizzate in associazione allo loro identità ove l’identità degli utenti non sia una informazione necessaria ai fini del sondaggio che ha l’obiettivo di raccogliere solo le risposte quali informazioni aggregate.
Criterio della accessibilità controllata
Buone politiche di “access management” adottate dall’azienda supportano certamente uno dei principi alla base della PbD, che è quello della limitazione dell’accesso ai dati personali sulla base della necessità. In concreto una buona profilazione degli accessi, basata sul criterio del “need to know”, supporta una gestione degli accessi allineata alle disposizione del GDPR. Ovviamente la tematica, ricorda l’ENISA, non deve essere solo gestita solo a livello infra-aziendale dovendosi anche tenere in considerazioni fattori esterni, come ad esempio l’integrazione dei sistemi aziendali con fornitori esterni (ad esempio i provider di servizi cloud), o la necessità di garantire un accesso alle autorità governative in caso di necessità. Inoltre, la limitazione degli accessi richiama la necessità di controllare e limitare la condivisione dei dati posto che, come è ovvio, l’accessibilità ai dati aumenta se i dati personali vengono copiati o trasferiti da/ad altri destinatari o resi in altro modo disponibili (ad esempio mediante pubblicazione). Sotto questo ultimo profilo, il requirement normativo previsto dall’articolo 25 del GDPR sotteso, alle logiche prassi di configurazione dei default settings, è molto semplice: nessuna pubblicazione ad un numero indefinito di destinatari è permessa per impostazione predefinita automatica (ovvero senza l’intervento attivo che abiliti tale scenario). Vediamo qualche esempio concreto messo in luce nel documento di linee guida dell’ENISA:
- nell’ambito dei social network, una buona pratica potrebbe essere quella di prevedere di default la limitazione della visibilità dei dati del proprio profilo solo al proprietario del profilo e al massimo alla cerchia di amici. Solo su scelta attiva ed espressa del proprietario del profilo si dovrebbe quindi attivare la pubblicazione del profilo alla comunità intera del social network;
- nell’ambito dei motori di ricerca, l’accessibilità da parte dei motori ai profili delle persone di default (con possibilità di essere ricercati nel web) dovrebbe non essere preimpostata, consentendo comunque all’utente di scegliere a posteriori di configurare impostazioni di accessibilità ai propri profili o contenuti più ampie (si pensi ad un annuncio di un evento privato pubblicato su un social network che venga di default reso indicizzato in un motore di ricerca);
- nell’ambito delle health app o fitness app, il caricamento e l’aggiornamento da parte degli utenti dei propri dati di misurazione delle performance o dei parametri di salute non dovrebbe di default essere configurato come anche condiviso con altri utenti o reso altrimenti accessibile, salvo che ciò non sia una configurazione modificata e prescelta in tal senso da parte dell’utente stesso.
Il dilemma tra impostazioni predefinite di protezione e requisiti di usabilità
Come accennato in precedenza, le impostazioni predefinite posso essere considerate non un ostacolo alla usabilità ma, in aderenza al GDPR e alle best practice di riferimento, una misura finanche tesa a migliorare l’usabilità di sistemi e applicazioni, evitando di sottoporre gli utenti a configurazioni continue e contribuendo a progettare dei sistemi o servizi user-friendly rispettosi dei diritti e delle libertà delle persone interessate. Tuttavia, affinché le impostazioni predefinite siano un fattore abilitante l’usabilità dei servizi o sistemi, è necessario che siano configurate in modo trasparente per gli utenti e che non influenzino gli utenti verso scelte non auspicabili, vessatorie o non in linea con la normativa di protezione dei dati personali applicabile. È abbastanza comune, secondo quanto riportato dall’ENISA, che alcuni modelli mirino a indirizzare gli utenti verso scelte non rispettose della privacy, spesso con la condizione di “look and feel” migliore (ovvero una interfaccia migliore o più accattivante).
I vantaggi dell’approccio privacy by default
L’applicazione di un approccio di PbD, fondato sul dettame dell’art. 25 del GDPR nonché di linee guida come quelle emesse dall’ENISA o delle altre best practice di riferimento, rappresenta un vantaggio importante sotto diversi profili, sia in fase di sviluppo che nell’ambito dell’utilizzo di soluzioni in ambito aziendale. In primo luogo, la gestione di tematiche complesse viene affrontata a monte, come elemento interno degli stessi strumenti, riducendo i costi di intervento a posteriori per la modifica delle soluzioni. Inoltre, un beneficio fondamentale per le aziende riguarda la possibilità di non limitare lo sviluppo e la customizzazione delle soluzioni, partendo dal presupposto che i parametri da rispettare (requisiti normativi del GDPR) non vanno intese come limitazioni ma come fattori abilitanti. Infine, assumendo l’utente una posizione centrale in ottica di PbD, adottando questo approccio si realizzano sistemi e servizi basati sulla fiducia, requisito fondamentale per l’attività aziendale. Le interazioni con l’utente basate sul trust, infatti, non producono solo un ritorno economico nell’immediato, ma anche un sentimento di fidelizzazione a medio-lungo termine ed una generale valutazione positiva da parte delle associazioni di categoria (ad esempio associazioni dei consumatori) o delle autorità competenti volte a valutare il livello di investimento in ricerca e implementazione di misure a protezione dei dati personali commisurate allo stato dell’arte e al contesto di riferimento.
I report di Solution Design come strumento di accountability
Oggi giorno, gran parte delle aziende, e in particolare i loro Chief Information Officer (CIO), hanno un obiettivo sfidante da traguardare che consiste nel fornire sistemi complessi in linea con la strategia aziendale (comprese le politiche IT), a un costo sostenibile e con un maggiore ritorno sugli investimenti. A ciò si aggiunge lo scenario normativo, dettato per esempio dal GDPR, che impone che i sistemi o servizi IT, basati su complessi modelli, spesso multi-vendor, garantiscano un livello adeguato di conformità ai principi di protezione dei dati personali (ovvero in ottica di PbD), e che sia garantita la capacità di dimostrare tale conformità ai principi normativi (cd. principio di accountability aziendale). Il compito non è dei più semplici. In particolare, anche laddove sia in fase di requisitazione e sviluppo, fino ad arrivare alla fase di test, si sia adottato un approccio basato sul rischio e siano state condotte tutte le valutazioni in ottica privacy by design (incluse le scelte di configurazione predefinita di misure di protezione dei dati), non è sempre agevole e immediato individuare il modo per tener traccia dei criteri adottati nelle scelte operate, delle valutazioni condotte, delle opzioni di trattamento rischio adottate fin dalla fase di progettazione. Inoltre, spesso si perde traccia documentale delle ragionevoli motivazioni che possono aver spinto l’azienda o il produttore di un sistema o servizio IT a preferire l’adozione di una misura invece che di un’altra (ad esempio tenendo in considerazione lo stato dell’arte, il contesto, i costi o altri elementi che il GDPR stesso prevede possano essere tenuti in considerazione in ottica di valutazione complessiva). Nell’ambito di grandi progetti di disegno di architetture software o progetti di Cloud Migration (ad esempio di CRM aziendali) o ancora in progetti di sviluppo di servizi innovativi per le aziende, diventa cruciale tener traccia formale di tutte le scelte operate sin dall’avvio del progetto, in modo da garantire che l’azienda titolare del trattamento dei dati possa comprovare l’adozione di una soluzione compliant al GDPR (in linea al principio di accountability). Sotto questo profilo un documento di estremo rilievo, a parere di scrive, è rappresentato dai Report di Solution Design che generalmente descrivono, nell’ambito di grandi progetti, la metodologia di lavoro utilizzata (es. standard, hybrid agile ecc.), la prototipazione delle soluzioni e la messa in produzione finale o medianti rilasci graduali prima del go-live di una soluzione. Questo tipo di documento è sempre stato considerato di esclusivo appannaggio di “tecnici” ovvero di web designer, sviluppatori di software, progettisti ecc., essendo meno comune ogni apporto di contenuti e considerazioni legali o normative, anche basate su attività di risk assemssment che descrivano le scelte operate nelle configurazioni di default settings in ottica privacy by design. Risulta, invece, a parere di chi scrive, di fondamentale importanza che tutta la documentazione descrittiva e attestante la prototipazione delle soluzioni sia supportata anche dai risultati di valutazioni normative, di legittimità e dei risultati delle valutazioni dei rischi e degli impatti per gli interessati (richiamando talvolta anche documenti specifici di DPIA) al fine di poter avere un maggior controllo delle scelte operate e una traccia documentale atta a comprovare il livello di conformità a GDPR o altre previsioni normative applicabili della soluzione disegnata (inclusi i provvedimenti o pareri delle Autorità Garanti). Per esempio, comunemente un documento di Report di Solution Design descrive la metodologia adottata in fase di progettazione e, ove la stessa si sia basata su un approccio PbD, il documento dovrebbe fornire anche informazioni dettagliate sugli elementi e criteri tenuti in considerazione nell’applicare tale approccio nella progettazione. In particolare, possibilmente con il supporto dei referenti o advisors Privacy, dell’ufficio Legale, del DPO (ove presente nel contesto aziendale), che sono intervenuti nelle analisi e nell’orientare le scelte di progetto, il documento dovrebbero fornire delucidazioni riguardo almeno i seguenti fattori:
- stato dell’arte e livello di conformità al GDPR di una soluzione standard acquistata “a pacchetto” dal titolare;
- effort di attuazione di customizzazioni funzionali ad allineare al GDPR la soluzione;
- natura, ambito di applicazione, contesto e le finalità del trattamento dei dati personali dei processi l’azienda si prefigge di gestire tramite la nuova soluzione;
- rischi di security e rischi per i diritti e le libertà degli interessati valutati.
Inoltre, anche la metodologia di attuazione dell’approccio di privacy by design dovrebbe essere descritta e tracciata in un documento al fine di tracciare gli steps e le modalità di valutazione del disegno della soluzione, ad esempio: riferimenti alle attività di risk assessment, alle valutazioni di impatto eseguite (DPIA), check di approfondimenti in ambito privacy dedicati a verificare la corretta implementazione delle misure di protezione prima dei singoli rilasci delle soluzioni, implementazione delle raccomandazioni del DPO (ove presente in azienda). Ancora, alcune sezioni di un documento di Solution Design, in particolari progetti come ad es. i progetti di cloud migration (si pensi ai processi di migrazione in cloud di grandi CRM aziendali), potrebbero prevedere la descrizione del design di un nuovo Data Model, ovvero il dettaglio di ciascuno dei campi previsti nel nuovo ambiente sviluppato. In questo contesto, appare ovvio, come la descrizione del Data Model possa andare di pari passo, in ottica di accountability, alla descrizione delle misure di protezione dei dati personali adottate in fase di individuazione e disegno dei campi, in particolare ad es. le misure per la minimizzazione dei campi, i controlli implementati per la prevenzione di trattamenti non conformi ad una base giuridica (ad es. implementazione di un flag “don’t process” in caso di unsuscribe dell’utente). Infine, altre informazioni che potrebbe essere utile tracciare in ottica di accountability possono riguardare, senz’altro, come operativamente la soluzione progettata ha tenuto conto delle funzionalità atte a garantire la gestione delle richieste degli utenti che potrebbero esercitare un diritto riconosciuto loro dal GDPR (ad esempio le funzionalità del sistema per esportare i dati ai fini della loro portabilità, le misure per cancellazione o anonimizzazione dei dati, le funzioni per attuare una limitazione dei trattamenti per un tempo definito di tempo).
