Che cos'è la privacy-by-design e come si inserisce virtuosamente nel complesso tema della prevenzione di un (personal) data breach?

I due argomenti evocati sono entrambi attualissimi e destinati ad avere uno sviluppo ancora più intenso nell'immediato futuro: soprattutto il primo, oggi ancora poco esplorato, che schiude anche notevoli prospettive lavorative.

Ne ho parlato come relatore su invito di Anorc Professioni il 6 giugno scorso allo SMAU di Bologna, edizione R2B - Reasearch to Business. Di seguito una breve sintesi del mio intervento.

Partiamo da alcune cifre

La prima: 41%. Secondo un rapporto del 2018 di Kaspersky Lab, 41% è la percentuale delle PMI nel mondo che hanno subìto almeno un (personal) data breach nella loro storia.

È molto: quasi una su due.

Eppure verosimilmente si tratta perfino di un valore al ribasso rispetto al dato effettivo. Kaspersky è una delle più solide realtà in materia di sicurezza informatica, ed è ragionevole ritenere che la percentuale si riferisca alle sole violazioni IT, quelle cioè che intuitivamente associamo al concetto di violazione di dati personali, ma non riporti gli eventi di natura organizzativa, che spesso non sono neppure individuati dai titolari del trattamento come occorrenze di un (personal) data breach.

Il "lato in ombra" del data breach

I (personal) data breach di natura organizzativa sono in realtà una parte rilevante dell'insieme, ma sono collocati, per così dire, nel lato in ombra*, quello meno meno visibile e meno compreso.  Nell'incontro allo Smau Bologna, ho presentato numerosi esempi di questa tipologia di violazioni.

La casistica è ampia e davvero comune. A livello di esperienza personale, quasi nessuno dei (personal) data breach organizzativi di cui mi sono occupato era stato avvertito come tale dal titolare del trattamento e quasi nessuno era stato oggetto di notifica al Garante e di comunicazione agli interessati, pur laddove tali adempimenti risultavano dovuti.

Le conseguenze possono essere devastanti, e non solo sul piano sanzionatorio o risarcitorio, ma anche su quello della compromissione dei rapporti di fiducia.

Forniamo un altro dato

59.000+: è il numero di (personal) data breach notificati alle autorità di controllo nell’Unione europea dal 25.5.2018 al 28.1.2019 (dati DLA Piper).

Di questi 15.400 soltanto nei Paesi Bassi.

Spiccano i valori registrati in Germania e Regno Unito, ma perfino in Polonia, che ha indicato cifre superiori di oltre tre volte rispetto al nostro Paese.

Gli appena 630** casi notificati da noi forniscono allora la misura eloquente di un problema italiano: in larga misura ignoriamo che cosa sia un (personal) data breach o non comprendiamo perché dovremmo preoccuparcene.

Dunque non abbiamo alcuna preparazione per prevenirlo e successivamente per gestirlo.

In realtà, l'impreparazione o perfino la scelta di non procedere a notifica e a comunicazione quando siano dovute diventano solo fattori di moltiplicazione del danno, rischiosi quanto inutili.

Per usare un linguaggio crudo, un (personal) data breach non è questione di se, è solo questione di quando. Tenerlo nascosto spesso non si rivela scelta lungimirante, considerata la capacità di propagazione dei dati compromessi: prima o poi c'è da attendersi che la vicenda verrà all'attenzione dell'autorità di controllo (ad esempio su segnalazione o reclamo degli interessati) e averne aggravato le conseguenze e omesso gli adempimenti risulterà in una maggiore sanzione e potenzialmente in maggiori obblighi risarcitori.

Ma allora quali strategie applicare?

Naturalmente la chiave è la prevenzione. L'intero approccio moderno alla protezione dei dati personali è basato sul giocare d'anticipo, sull'accountability, sulla comprensione e limitazione del rischio, sullo studio e l'implementazione di buone policy, su istruzioni chiare e su un preciso riparto dei compiti (chi fa cosa, chi può accedere a cosa, chi può modificare cosa).

Ma questo è ancora un modello classico: correttissimo e necessario, tuttavia si può andare oltre. La soluzione migliore è infatti di natura progettuale: investire nella privacy-by-design.

Nel mio intervento allo  SMAU mi è parso che un buon angolo per affrontare il tema fosse partire da un concetto introdotto dal compianto Shigeo Shingo, figura leggendaria di riformatore dei processi organizzativi: il poka-yoke***, vale a dire il design a prova di errore.  Il poka-yoke è una rivoluzione copernicana nell'approccio ai problemi.

Prendete un cavo usb e provate a collegarlo sottosopra, non entra nel suo alloggiamento: è un design poka-yoke, a prova di errore. Oppure prendete uno di quei giochi per bambini con la stella, il cubo e il cilindro che devono entrare nei rispettivi alloggiamenti: è inutile forzare le forme nell'alloggiamento sbagliato, non entrano. Anche questo è un design poka-yoke.

Non si tratta solo di forma: il poka-yoke può riguardare altri aspetti come il colore o la funzionalità.

Si pensi, in quest'ultimo caso, a quelle cassettiere metalliche in cui, per evitare il rovesciamento, è materialmente possibile aprire solo un cassetto per volta, prevenendo così alterazioni decisive del baricentro.

Costruire un sistema in termini poka-yoke significa, in altre parole, costruirlo in modo che il suo normale utilizzo sia necessariamente corretto, non possa essere altrimenti che corretto.

Ecco, proviamo ora a fare il salto essenziale

Proviamo a trasportare l'idea di poka-yoke sul piano della protezione dei dati personali e avremo uno dei punti chiave della privacy-by-design, specialmente sul piano organizzativo: disegnare procedure di sicurezza e di trattamento dei dati a prova di errore. Nell'incontro allo Smau Bologna ho fatto alcuni esempi concreti, molti altri se ne possono proporre. La strada è questa, qui è il futuro.

È soprattutto anche una questione di visione, di abbracciare un'idea di sicurezza e di buona organizzazione che parta dall'accettazione realistica dell'errore umano. In un (personal) data breach il fattore più debole e più esposto è in genere proprio quello umano. La mancanza umana prima o poi inevitabilmente si verificherà, bisogna perciò strutturare il processo in modo tale che esso sia a prova di errore.

Includere la privacy nella progettazione

Ovviamente la privacy-by-design non è solo questo, è anche il risparmio dei dati personali o meglio, ove possibile, l'utilizzo di informazioni anonime. Vuol dire mettere nell'"impasto" – si passi la trasposizione alimentare – l'ingrediente privacy (o meglio: la protezione dei dati personali).

Vuol dire che quando si studia un trattamento o una serie di trattamenti, quando si progetta un'app, l'esperto di protezione dei dati personali (che a mio personale avviso non può che essere un giurista informatico) deve sedere fianco a fianco e dialogare con il progettista, con l'esperto IT, con l'ingegnere.

La protezione dei dati personali deve essere una delle ruote dentate di cui idealmente si compone un processo.

Bisogna arrivare a questo, e bisogna farlo al momento della progettazione, perché, dopo, ridisegnare per correggere può rivelarsi estremamente dispendioso.

Se si vuole un'immagine d'attualità, i dati personali vanno considerati con la stessa attenzione che nel mondo fisico cominciamo a riservare alla plastica: usarne troppi, usarne senza motivo, è ormai inquinamento digitale. Dunque, meno dati personali si usano, più razionalmente si usano, meglio è: questo vuol dire ragionare in termini di privacy-by-design.

E l'interazione della privacy-by-design con il (personal) data breach?

L'interazione è evidente: se costruiamo processi a prova di errore umano, ridurremo a priori le vulnerabilità. Ben più efficace di impartire istruzioni è fare in modo che qualcosa non possa semplicemente avvenire. Più efficace ancora è combinare insieme questi fattori (anche perché istruire e formare è obbligatorio).

Inoltre, ed è il secondo punto affrontato, se costruiamo processi che impiegano meno dati personali, ridurremo a priori la superficie d'attacco e le conseguenze di un (personal) data breach.

Si aggiunga che applicare la privacy-by-design non è solo una scelta di prevenzione virtuosa e intelligente rispetto al rischio, che prima o poi si paleserà, di violazione di dati personali, è anche un obbligo di legge, imposto dall'art. 25 GDPR e la cui innosservanza è sanzionata dall'art. 83.4 GDPR. Dunque va necessariamente realizzata e occorre fornire prova di averlo fatto.

Note:

* il riferimento al "lato in ombra" vuole essere una citazione del Dig.Eat 2019, evento organizzato ogni anno a Roma dai colleghi dello studio legale Lisi-D&L Department con il patrocinio di Anorc. L'edizione tenutasi il 30 maggio 2019 è stata intitolata "The dark side of..." e ha esplorato con un format  visionario il "lato in ombra" del digitale.

** 630 è il valore numerico corretto (al 31.12.2018) riportato nella Relazione per l'anno 2018 del Garante per la protezione dei dati personali.

*** Il riferimento al poke-yoke applicato alle procedure organizzative in materia di sicurezza e trattamento dei dati personali è stato sviluppato in parallelo anche dai colleghi di ICT Legal Consulting, con cui collaboro in qualità di of counsel. La convergenza di risultati mi pare indichi una giusta direzione.