Regolamento - 27/04/2016 - n. 679 art. 25 - Protezione dei dati fin dalla progettazione e protezione dei dati per impostazione predefinita1(A)

Misure organizzative data protection-by-design e by-default

Un'adeguata misura di sicurezza a cui l'art. 25 GDPR fa riferimento consiste nel non conservare il dato in chiaro ma trasformarlo mediante pseudonimizzazione al fine di garantirne una maggiore protezione. La pseudonimizzazione è una misura tecnica prevista dall'art. 32 del Regolamento, la quale trova applicazione nella sostituzione di uno o più attributi all'interno di un record con attributi differenti, cioè gli pseudonimi. Sebbene la pseudonimizzazione consenta ancora l'identificazione del dato pseudonimizzato mediante l'utilizzo di informazioni segrete, è importante evidenziare che non si tratta di un metodo di anonimizzazione, bensì di una misura di sicurezza. Il procedimento tecnico, tal quale descritto, vedrebbe l'applicazione generare pseudonimi attraverso una Pseudo-Random Function (PRF), che eviti l'assegnazione del medesimo pseudonimo a due valori differenti. È vitale inoltre che non vi sia alcuna correlazione diretta tra il valore da pseudonimizzare e l'output dell'algoritmo di pseudonimizzazione. Di conseguenza, l'utilizzo di semplici funzioni hash potrebbe compromettere l'efficacia della pseudonimizzazione, rendendo banalmente verificabile la presenza di un dato specifico all'interno del database. Per risolvere tale problematica, è possibile impiegare l'uso di HMAC (Hash-based Message Authentication Code), un particolare tipo di codice di autenticazione dei messaggi utilizzato insieme a una chiave segreta e un algoritmo di hashing robusto. Lo pseudonimo generato potrà essere un insieme di caratteri casuali, risultanti dalla funzione HMAC, oppure scelto a partire da una tabella contenente dati coerenti con il tipo di dato da sostituire. Una seconda tecnica di pseudonimizzazione menzionata è la tokenizzazione, che potrebbe essere utilizzata con lo stesso scopo. È essenziale che eventuali tabelle di corrispondenza vengano mantenute separate da quelle in cui risiedono le informazioni sensibili. Chiavi segrete o altre informazioni riservate devono essere custodite in maniera sicura, al di fuori della macchina che ospita i dati dell'applicazione. Il parere 05/2014 del WP29 mette in evidenza come, spesso, i titolari e i responsabili del trattamento erroneamente presumano che la sostituzione di uno o più attributi sia sufficiente a rendere un dataset anonimo. Tuttavia, la pseudonimizzazione del solo ID non è sufficiente a impedire l'identificazione di un individuo se i cosiddetti “quasi-identifiers” rimangono presenti nel dataset, o se i valori di altri attributi possono ancora identificare un individuo. Per conferire un grado di anonimato al dataset, dovrebbero essere adottate misure supplementari, quali la rimozione e la generalizzazione degli attributi, la cancellazione dei dati originali, o la loro aggregazione ad un livello elevato. Analogamente alla crittografia, la pseudonimizzazione richiede un'attenta valutazione, così come lo richiede la strategia per la sua eventuale implementazione. Alla luce di quanto esposto, l'operazione di pseudonimizzazione richiama l'episodio omerico della caverna del Ciclope: proprio come Ulisse e i suoi compagni si celano dietro pseudonimi per eludere la minaccia del Ciclope, così i dati personali si nascondono dietro pseudonimi per mitigare i rischi insiti nell'identificazione diretta. Risulta importante notare che secondo il Legislatore e i Garanti europei, per avere una vera anonimizzazione del dato bisogna ricorrere a tecniche quali la generalizzazione (es. nazione al posto di comune di residenza), le permutazioni (es. tra stringhe in un campo di un database, o tra campi diversi), l'introduzione di random noise in ogni campo oppure, in ultima istanza, la distruzione del dato. Ciò è ad esempio descritto nell'articolo Introduction to the hash function as a personal data pseudonymisation technique, pubblicato congiuntamente dal Garante spagnolo (AEPD, Agencia española de protección de datos) e dall'European Data protection Supervisor (EDPS). Si riporta, a titolo di esempio, un estratto da pag. 22: “Therefore, anonymisation procedures must ensure that not even the data controller is capable of re-identifying the data holders in an anonymised file.” Un dato è considerato anonimizzato, dunque, quando risulti impossibile l'individuazione di singleton (in matematica, si definisce “singleton” o “singoletto” un insieme di cardinalità unitaria, cioè un insieme avente esattamente un solo elemento) di persone fisiche; pertanto, non basta la possibilità di visualizzare dati aggregati: è necessario, infatti, che tale possibilità sia l'unica percorribile. Per quanto riguarda il ricorso alla pseudonimizzazione, è importante notare che una recente sentenza della Corte di Giustizia Europea ha radicalmente trasformato lo scenario che, dalla lettura del GDPR e dalle definizioni fornite dal Regolamento in relazione ai dati personali e anonimizzati, sembrava granitica. La vicenda coinvolge il Comitato di risoluzione unico (CRU), il Garante europeo della protezione dei dati (GEPD) e Deloitte. Al centro del dibattito vi è il trattamento dei dati personali raccolti dal CRU dagli azionisti e i creditori interessati del Banco Popular Español durante un processo di consultazione. In seguito alla raccolta dei dati, il CRU ha trasmesso a Deloitte, per analisi, informazioni pseudonimizzate, in forma di osservazioni. Dal punto di vista del CRU, i dati erano pseudonimizzati, poiché erano in possesso delle informazioni supplementari per ricondurre le osservazioni agli individui specifici. D'altra parte, per Deloitte, questi dati erano anonimi, dato che mancavano delle informazioni aggiuntive necessarie per la re-identificazione degli individui. Il problema è emerso quando il GEPD ha interpretato i dati trasmessi come dati personali, nonostante la pseudonimizzazione e la mancanza di possibilità di re-identificazione da parte di Deloitte. Questo ha portato al ricorso del CRU, che sosteneva che il GEPD non avesse valutato correttamente se i dati ricevuti da Deloitte potessero essere ricondotti agli individui interessati. Il Tribunale ha così sancito che i dati personali pseudonimizzati, in assenza di mezzi legali e tecnici che ne consentano l'identificazione, sono da considerarsi anonimi. Tale assunto riporta alla mente il principio di indeterminazione di Heisenberg. Questo principio suggerisce che la posizione e la velocità di una particella non possono essere misurate simultaneamente con precisione infinita – più si conosce l'uno, meno si può conoscere l'altro. Allo stesso modo, la natura dei dati (siano essi personali, pseudonimizzati o anonimi) dipende dalla prospettiva dell'osservatore e dalle informazioni che ha a disposizione. Il CRU e Deloitte, come due diversi osservatori nel mondo quantistico, hanno una visione diversa dei dati a causa delle diverse informazioni a loro disposizione. Mentre per il CRU i dati sono pseudonimizzati, per Deloitte sono anonimi. Il GEPD, nel tentativo di stabilire una misurazione precisa (come nel principio di indeterminazione), sembra non aver considerato adeguatamente la prospettiva di Deloitte, ossia l'incapacità di ricondurre i dati agli individui interessati, che rende tali dati anonimi per Deloitte, prospettiva che non era propria del Regolamento e che riadatta alle peculiarità della realtà sensibile le interpretazioni sinora fornite. Quindi, proprio come nella fisica quantistica, anche nel campo della protezione dei dati, la natura di un'informazione può dipendere dalla posizione dell'osservatore e dalle informazioni che ha a sua disposizione.

Misure di sicurezza tecniche data protection-by-design e by-default

L'insieme dei contributi che riguardano la protezione dei dati personali durante la fase di progettazione di prodotti e servizi di natura informatica è notevolmente ampio. Tuttavia, è la European Union Agency for Cybersecurity (ENISA) e l'Information and Privacy Commisioner dell'Ontario (IPCO) che hanno brillantemente formulato dei principi generali chiave in merito all'argomento in questione. La disamina dei principi esposti da ENISA porta alla luce un totale di otto postulati, mentre l'analisi delle norme stabilite da IPCO ne individua sette. Nell'opera “Privacy and Data protection by Design - from policy to engineering”, ENISA sottolinea l'importanza di applicare, durante la progettazione di prodotti e servizi, i principi di minimizzare, nascondere, separare, aggregare, informare, controllare, forzare e dimostrare al trattamento dei dati personali. Il concetto di “minimizzazione”, come definito da ENISA, implica la raccolta, il mantenimento e il trattamento solo dei dati strettamente necessari per raggiungere l'obiettivo prefissato. Il termine “nascondere” fa riferimento alla capacità dell'organizzazione di negare l'accesso ai dati e alla loro visibilità a chiunque non sia autorizzato. La “separazione” si riferisce a un processo distribuito, nel quale, per esempio, tutti i dati appartenenti a un individuo non vengono registrati nello stesso database. Questo riduce i rischi legati alla profilazione non autorizzata o da parte di esterni che potrebbero entrare in contatto con i database dove tali dati sono conservati; l'estrinsecazione di tale principio è il ricorso alla pseudonimizzazione, di cui si tratterà più avanti. Il principio di “aggregazione” stabilisce che massimizzare il livello di aggregazione dei dati senza ricondurli a soggetti identificabili comporta l'ottenimento degli stessi risultati che si avrebbero se tale identificazione fosse possibile, generando cosiddetti “big data” invece di query personalizzate. Il concetto di “informare” prevede che il soggetto interessato sia consapevole delle finalità e delle modalità per le quali il trattamento dei suoi dati viene effettuato. “Controllare” implica l'implementazione tecnica dei diritti degli interessati, dando la possibilità al soggetto interessato, attraverso la programmazione di specifiche funzionalità, di esercitare i propri diritti relativi ai propri dati personali. “Forzare” viene definito da ENISA come l'applicazione al trattamento dei dati di politiche coerenti con le norme del Regolamento, richiedendole in qualità di requisiti tecnici sin dalle fasi di progettazione. Infine, “dimostrare” concerne il principio di responsabilizzazione di cui all'art. 24 GDPR, che richiede all'organizzazione di essere in grado di dimostrare la propria conformità a principi e norme del Regolamento. L'approccio di IPCO include sette principi fondamentali: “prevenire, non rimediare”; “privacy by default”; “privacy insita nel sistema”; “piena funzionalità”; “privacy end-to-end”; “visibilità e trasparenza”; “rispetto per l'utente e la sua privacy”. Il principio “prevenire, non rimediare” postula che la protezione dei dati non deve essere intesa come una misura reattiva, finalizzata a risolvere le violazioni una volta che si sono verificate, ma piuttosto come una misura preventiva, concepita per impedire che tali rischi si concretizzino in primo luogo. “Privacy by default”, contenuto anche nell'art. 25 del GDPR, è un principio che sostiene il rispetto del concetto di minimizzazione dei dati fin dalla loro origine, garantendo la protezione dei dati come aspetto implicito nel funzionamento del sistema che li tratta. Questa nozione è rafforzata dal principio “privacy insita nel sistema”, che enfatizza l'indivisibilità della protezione dei dati dal sistema che li gestisce. Il principio di “piena funzionalità” si riferisce all'ottimizzazione di quei processi che potrebbero ostacolare la protezione dei dati per favorire l'efficienza del prodotto o servizio sviluppato. “Privacy end-to-end” implica una costante vigilanza dalla creazione del processo fino alla fine del trattamento, in modo tale che in nessuna fase dello stesso la protezione dei dati sia trascurata. Il principio di “visibilità e trasparenza” sottolinea l'importanza di informare gli interessati sull'impiego di tecniche di protezione dei dati. Il principio “rispetto per l'utente e la sua privacy” riguarda gli stessi aspetti che ENISA individua con il termine “forzare”, ovvero comporta l'adozione di scelte e la configurazione di prodotti e servizi in conformità con le norme e i principi relativi alla protezione dei dati. Al fine di attuare efficacemente il principio di data protection-by-design, è indispensabile sviluppare tecnicamente applicazioni, prodotti e servizi che incorporino misure di sicurezza allo stato dell'arte, sfruttando le tecnologie più avanzate e rispettando i più alti standard di protezione.

Le applicazioni e i prodotti informatici, in conformità con i più elevati standard di sicurezza, devono incorporare procedure di autenticazione robuste e ben strutturate prima di consentire il trattamento di qualsiasi dato personale. Nel contesto della sicurezza informatica, il termine “robusto” si riferisce a una procedura di autenticazione che non è solamente una verifica superficiale, ma richiede almeno l'identificazione di un nome utente e una password per concedere l'accesso, una password che non sia ipotizzabile agevolmente da un attore malevolo della rete. In questa prospettiva, la creazione della password deve essere attentamente guidata dall'applicazione e/o dal servizio fornito dal titolare. Questo processo di orientamento assicura che la password contenga un numero di caratteri superiori ad 8, includendo una combinazione di lettere maiuscole e minuscole, numeri e caratteri speciali, aumentando così la resistenza della password agli attacchi. Oltre a ciò, le applicazioni e i prodotti possono essere sviluppati per interfacciarsi con sistemi di gestione centralizzata degli account. Questo riduce la proliferazione di credenziali di autenticazione, limitando così i potenziali punti di accesso per gli aggressori e migliorando l'efficienza della gestione delle credenziali. Nel contesto della sicurezza delle password, si ritiene che le password debbano essere conservate all'interno del servizio e/o dell'applicazione in forma crittografata, utilizzando algoritmi di cifratura adeguati. Questo garantisce che, anche nel caso in cui un attaccante dovesse ottenere accesso alle password memorizzate, queste sarebbero illeggibili e inutilizzabili senza la chiave di decrittografia. La password, inoltre, dovrebbe essere progettata in modo da non consentire all'utente il riferimento diretto allo stesso, dovrebbe avere una lunghezza massima di almeno 64 caratteri, e dovrebbe essere modificata al primo accesso se non è stata generata dall'utente. Queste misure aumentano ulteriormente la sicurezza della password. Per garantire un'ulteriore sicurezza, la password dovrebbe scadere frequentemente, un meccanismo che dovrebbe innescare la scadenza delle sessioni in corso. Questo aiuta a limitare il tempo durante il quale un attaccante potrebbe potenzialmente avere accesso a un account se riuscisse a ottenere la password. Infine, l'applicazione dovrebbe essere in grado di memorizzare gli hash delle password utilizzate dall'utente, in modo da impedire allo stesso di riutilizzarle. Questo impedisce un comune errore di sicurezza in cui un utente utilizza la stessa password su più account o la riutilizza frequentemente, il che può rendere più facile per un attaccante accedere a vari account. Nel contesto delle web-application, ovvero quelle applicazioni e servizi che necessitano di un token per mantenere una connessione attiva, diviene fondamentale l'implementazione di un token di ampiezza adeguata, imprevedibile, specificamente associato alla sessione dell'utente, e dotato di un meccanismo di scadenza correlato alla durata dell'inattività dell'utente. Tale meccanismo rappresenta un ulteriore presidio contro possibili intrusioni o attacchi informatici, rafforzando la robustezza della sicurezza applicativa.

Nel caso di credenziali legate all'effettivo possesso di un indirizzo email, è imprescindibile garantire una verifica di esistenza e appartenenza, ripetendo tale procedura a intervalli regolari per confermare la validità e l'utilizzo continuativo dell'indirizzo email. Un tale processo di verifica costante garantisce una corretta e protetta gestione delle credenziali di accesso. Sarebbe altresì opportuno che l'applicazione o il servizio fornisca l'opportunità di attivare un meccanismo di autenticazione a due fattori. Tale sistema prevede la generazione di una password monouso (OTP) inviata all'utente tramite canali alternativi, la verifica di un elemento biometrico, o l'utilizzo di un dispositivo di esclusivo possesso dell'utente, come una smart card. Tale struttura di autenticazione multi-livello costituisce un ulteriore livello di sicurezza, ostacolando ulteriormente il potenziale accesso da parte di malintenzionati. Durante la fase di sviluppo, può rivelarsi fondamentale prendere in considerazione la possibilità di limitare o rallentare la procedura di accesso in caso di tentativi ripetuti non riusciti, per prevenire attacchi noti quali il brute force, basati sulla ripetizione di tentativi di accesso fino al raggiungimento della corretta combinazione. Allo stesso modo, l'applicazione o il servizio dovrebbero facilitare la gestione interna degli utenti, consentendo l'applicazione dei principi di least privilege e need to know. Tale meccanismo rispetta il principio di minimizzazione ex art. 5.1.c) del GDPR, limitando l'accesso ai dati a ciò che è strettamente necessario per compiere una specifica funzione. Per garantire la sicurezza del trattamento dei dati, sarebbe auspicabile predisporre l'applicazione o il servizio in modo da generare dei log di accesso. I dovrebbero possedere caratteristiche di completezza, inalterabilità e verificabilità dell'integrità, fornendo così tracciabilità e responsabilizzazione, potenziando la sicurezza e la trasparenza del trattamento dei dati. La documentazione che accompagna l'applicazione o il servizio dovrebbe essere esaustiva, descrivendo fin dalla fase di progettazione quali tipologie di dati vengono conservati e trattati, e i flussi di dati in entrata ed uscita verso altri server, applicazioni e servizi. Una tale documentazione favorisce la trasparenza e permette un'ampia comprensione di come i dati vengono utilizzati e trattati, offrendo un quadro chiaro dei processi di trattamento dei dati. Inoltre, dovrebbe essere prevista la possibilità di stabilire anticipatamente i tempi di conservazione per le varie tipologie di dati, e di richiedere e conservare esclusivamente i dati necessari per il funzionamento dell'applicazione o servizio. Una tale misura è conforme al principio di minimizzazione dei dati, riducendo la quantità di dati personali potenzialmente a rischio di esposizione. Nell'ottica di garantire il pieno esercizio dei diritti degli interessati, come delineato dal GDPR, è necessario che le applicazioni e/o i servizi siano sviluppati considerando la potenziale necessità che i dati personali possano essere soggetti a diritti di accesso, portabilità, limitazione e cancellazione.

Relativamente alla cancellazione dei dati, si impone che le applicazioni e/o i servizi prevedano meccanismi idonei a consentire, o a procedere autonomamente, alla cancellazione dei dati nel rispetto delle condizioni legali e contrattuali delineate dall'art. 17 del GDPR. In tutte le circostanze, l'architettura delle applicazioni e/o dei servizi deve essere tale da poter fornire un'efficace testimonianza dell'avvenuta cancellazione dei dati.

È inoltre di fondamentale importanza che le applicazioni e/o i servizi implementino meccanismi capaci di “marcare” i dati come limitati ai sensi dell'art. 18 del GDPR, proibendo quindi il trattamento di un dato limitato. Tale disposizione riguarda il diritto di limitazione del trattamento, che prevede la sospensione del trattamento dei dati personali dell'interessato (si rimanda all'art. 18 del GDPR per ulteriori approfondimenti).

Durante la fase di progettazione, si deve tenere conto della necessità di aggregare e inviare all'utente tutti i dati che lo riguardano, sia per garantire il diritto di accesso che per permettere la portabilità dei dati. Quest'ultima deve avvenire tramite la creazione di formati di comune utilizzo capaci di contenere l'intero complesso di dati relativi all'interessato. A tal fine, è raccomandabile l'impiego di formati con struttura campo/valore, tra i quali si annoverano comunemente XML, CSV e JSON (per ulteriori dettagli si veda l'art. 20 GDPR).

È importante sottolineare che il progresso tecnologico degli anni recenti ha trasformato le modalità di condivisione e trattamento dei nostri dati personali. Questa evoluzione ha portato alla nascita di nuove tecniche per la condivisione, elaborazione e archiviazione dei dati, generando nuovi modelli di trattamento di dati e introducendo nuove minacce e difficoltà per l'utente finale nel comprendere e controllare tale trattamento. La continua presenza online dei soggetti interessati ha comportato un incremento dell'elaborazione di ingenti quantità di dati personali quotidianamente. L'intero ciclo di vita dei dati è stato ampliato con la partecipazione di numerosi attori e l'utente finale non è più in grado di capire e controllare pienamente chi ha accesso ai suoi dati personali, per quanto tempo e con quale scopo.

Spesso, queste nuove tecnologie sono state introdotte senza una valutazione preventiva dell'impatto sulla privacy degli utenti e, in generale, rispetto alla protezione dei dati. In questo contesto, il trattamento dei dati personali è spesso caratterizzato dall'assenza di uno scopo prestabilito e dalla scoperta di nuove correlazioni tra i fenomeni osservati, ad esempio nel caso dei big data o dell'apprendimento automatico. Tale modalità di funzionamento è in conflitto con i principi di necessità e limitazione dello scopo, come previsto dal GDPR. La blockchain e le tecnologie dei registri distribuiti, ad esempio, offrono la possibilità di sostituire le transazioni basate sulla mediazione, ma a costo di una potenziale perdita di controllo degli individui sui loro dati, che rimangono visibili nella catena a tutti i partecipanti alla blockchain, finché è attiva o anche oltre, in aperta contraddizione con il principio della minimizzazione dei dati oltre a costituire un grave ostacolo per l'esercizio del diritto di cancellazione da parte dei soggetti interessati. Infine, i sistemi di intelligenza artificiale potrebbero essere autorizzati a prendere decisioni con un certo grado di autonomia per raggiungere specifici obiettivi, ad esempio nella valutazione del punteggio di credito nel settore finanziario o nei processi di assunzione all'interno di un'azienda. Tale autonomia potrebbe essere considerata confliggente con i principi del Regolamento e con quanto disposto dall'art. 22 GDPR.

L'attuazione del principio privacy by design in tali contesti è impegnativa poiché non può essere estrinsecata nel modo tradizionale. Le operazioni di trattamento devono essere ripensate e ridisegnate, a volte radicalmente, così come le minacce e i vettori di attacco, possibilmente con la definizione di nuovi attori e responsabilità, e con un ruolo di primo piano per la tecnologia stessa come elemento di garanzia. Il principio è considerato un concetto multiforme: nei documenti giuridici, da un lato, è generalmente descritto in termini molto ampi come un principio generale; da parte dei ricercatori e degli ingegneri, d'altra parte, è spesso equiparato all'uso di specifiche Privacy Enhancing Technologies (PETS). Tuttavia, implementare tale concetto nelle fasi di progettazione non è declinabile né in una semplice lista di principi né può essere ridotto all'implementazione di tecnologie specifiche. In realtà, è un processo che coinvolge vari componenti tecnologici e organizzativi, che attuano i principi di privacy e protezione dei dati mediante l'adozione tempestiva e adeguata di misure tecniche e organizzative, tra cui anche le PETS.

Pseudonimizzazione

Un'adeguata misura di sicurezza a cui l'art. 25 GDPR fa riferimento consiste nel non conservare il dato in chiaro ma trasformarlo mediante pseudonimizzazione al fine di garantirne una maggiore protezione. La pseudonimizzazione è una misura tecnica prevista dall'art. 32 del Regolamento, la quale trova applicazione nella sostituzione di uno o più attributi all'interno di un record con attributi differenti, cioè gli pseudonimi. Sebbene la pseudonimizzazione consenta ancora l'identificazione del dato pseudonimizzato mediante l'utilizzo di informazioni segrete, è importante evidenziare che non si tratta di un metodo di anonimizzazione, bensì di una misura di sicurezza. Il procedimento tecnico, tal quale descritto, vedrebbe l'applicazione generare pseudonimi attraverso una Pseudo-Random Function (PRF), che eviti l'assegnazione del medesimo pseudonimo a due valori differenti. È vitale inoltre che non vi sia alcuna correlazione diretta tra il valore da pseudonimizzare e l'output dell'algoritmo di pseudonimizzazione. Di conseguenza, l'utilizzo di semplici funzioni hash potrebbe compromettere l'efficacia della pseudonimizzazione, rendendo banalmente verificabile la presenza di un dato specifico all'interno del database. Per risolvere tale problematica, è possibile impiegare l'uso di HMAC (Hash-based Message Authentication Code), un particolare tipo di codice di autenticazione dei messaggi utilizzato insieme a una chiave segreta e un algoritmo di hashing robusto. Lo pseudonimo generato potrà essere un insieme di caratteri casuali, risultanti dalla funzione HMAC, oppure scelto a partire da una tabella contenente dati coerenti con il tipo di dato da sostituire. Una seconda tecnica di pseudonimizzazione menzionata è la tokenizzazione, che potrebbe essere utilizzata con lo stesso scopo. È essenziale che eventuali tabelle di corrispondenza vengano mantenute separate da quelle in cui risiedono le informazioni sensibili. Chiavi segrete o altre informazioni riservate devono essere custodite in maniera sicura, al di fuori della macchina che ospita i dati dell'applicazione. Il parere 05/2014 del WP29 mette in evidenza come, spesso, i titolari e i responsabili del trattamento erroneamente presumano che la sostituzione di uno o più attributi sia sufficiente a rendere un dataset anonimo. Tuttavia, la pseudonimizzazione del solo ID non è sufficiente a impedire l'identificazione di un individuo se i cosiddetti “quasi-identifiers” rimangono presenti nel dataset, o se i valori di altri attributi possono ancora identificare un individuo. Per conferire un grado di anonimato al dataset, dovrebbero essere adottate misure supplementari, quali la rimozione e la generalizzazione degli attributi, la cancellazione dei dati originali, o la loro aggregazione ad un livello elevato. Analogamente alla crittografia, la pseudonimizzazione richiede un'attenta valutazione, così come lo richiede la strategia per la sua eventuale implementazione. Alla luce di quanto esposto, l'operazione di pseudonimizzazione richiama l'episodio omerico della caverna del Ciclope: proprio come Ulisse e i suoi compagni si celano dietro pseudonimi per eludere la minaccia del Ciclope, così i dati personali si nascondono dietro pseudonimi per mitigare i rischi insiti nell'identificazione diretta. Risulta importante notare che secondo il Legislatore e i Garanti europei, per avere una vera anonimizzazione del dato bisogna ricorrere a tecniche quali la generalizzazione (es. nazione al posto di comune di residenza), le permutazioni (es. tra stringhe in un campo di un database, o tra campi di-versi), l'introduzione di random noise in ogni campo oppure, in ultima istanza, la distruzione del dato. Ciò è ad esempio descritto nell'articolo Introduction to the hash function as a personal data pseudonymisation technique, pubblicato congiuntamente dal Garante spagnolo (AEPD, Agencia española de protección de datos) e dall'European Data protection Supervisor (EDPS). Si riporta, a titolo di esempio, un estratto da pag. 22: “Therefore, anonymisation procedures must ensure that not even the data controller is capable of re-identifying the data holders in an anonymised file.” Un dato è considerato anonimizzato, dunque, quando risulti impossibile l'individuazione di singleton (in matematica, si definisce “singleton” o “singoletto” un insieme di cardinalità unitaria, cioè un insieme avente esattamente un solo elemento) di persone fisiche; pertanto, non basta la possibilità di visualizzare dati aggregati: è necessario, infatti, che tale possibilità sia l'unica percorribile. Per quanto riguarda il ricorso alla pseudonimizzazione, è importante notare che una recente sentenza della Corte di Giustizia Europea ha radicalmente trasformato lo scenario che, dalla lettura del GDPR e dalle definizioni fornite dal Regolamento in relazione ai dati personali e anonimizzati, sembrava granitica. La vicenda coinvolge il Comitato di risoluzione unico (CRU), il Garante europeo della protezione dei dati (GEPD) e Deloitte. Al centro del dibattito vi è il trattamento dei dati personali raccolti dal CRU dagli azionisti e i creditori interessati del Banco Popular Español durante un processo di consultazione. In seguito alla raccolta dei dati, il CRU ha trasmesso a Deloitte, per analisi, informazioni pseudonimizzate, in forma di osservazioni. Dal punto di vista del CRU, i dati erano pseudonimizzati, poiché erano in possesso delle informazioni supplementari per ricondurre le osservazioni agli individui specifici. D'altra parte, per Deloitte, questi dati erano anonimi, dato che mancavano delle informazioni aggiuntive necessarie per la re-identificazione degli individui. Il problema è emerso quando il GEPD ha interpretato i dati trasmessi come dati personali, nonostante la pseudonimizzazione e la mancanza di possibilità di re-identificazione da parte di Deloitte. Questo ha portato al ricorso del CRU, che sosteneva che il GEPD non avesse valutato correttamente se i dati ricevuti da Deloitte potessero essere ricondotti agli individui interessati. Il Tribunale ha così sancito che i dati personali pseudonimizzati, in assenza di mezzi legali e tecnici che ne consentano l'identificazione, sono da considerarsi anonimi. Tale assunto riporta alla mente il principio di indeterminazione di Heisenberg. Questo principio suggerisce che la posizione e la velocità di una particella non possono essere misurate simultaneamente con precisione infinita – più si conosce l'uno, meno si può conoscere l'altro. Allo stesso modo, la natura dei dati (siano essi personali, pseudonimizzati o anonimi) dipende dalla prospettiva dell'osservatore e dalle informazioni che ha a disposizione. Il CRU e Deloitte, come due diversi osservatori nel mondo quantistico, hanno una visione diversa dei dati a causa delle diverse informazioni a loro disposizione. Mentre per il CRU i dati sono pseudonimizzati, per Deloitte sono anonimi. Il GEPD, nel tentativo di stabilire una misurazione precisa (come nel principio di indeterminazione), sembra non aver considerato adeguatamente la prospettiva di Deloitte, ossia l'incapacità di ricondurre i dati agli individui interessati, che rende tali dati anonimi per Deloitte, prospettiva che non era propria del Regolamento e che riadatta alle peculiarità della realtà sensibile le interpretazioni sinora fornite. Quindi, proprio come nella fisica quantistica, anche nel campo della protezione dei dati, la natura di un'informazione può dipendere dalla posizione dell'osservatore e dalle informazioni che ha a sua disposizione.