Entra in vigore in questi giorni la nuova normativa sulla protezione dei dati personali delle persone fisiche: General Data Protection Regulation, per gli amici, GDPR. Penso che le diverse novità introdotte costringeranno anche noi developer a modificare il modo in cui affrontiamo i progetti software in termini di priorità di sviluppo e di scelta delle feature essenziali. Ho provato ad elencare alcuni aspetti che, personalmente, ritengo meritino attenzione.

Le novità dietro la norma

Oltre a portare una certa dose di ansia e panico nelle aziende che non si sono ancora messe in regola, il Regolamento tenta soprattutto di introdurre un cambiamento culturale. Con le nuove indicazioni, i processi di sicurezza dei dati vengono promossi da "problema a valle" a "processo a monte" dell'organizzazione aziendale.

Sarà necessario, da qui in avanti, introiettare nell'organizzazione e nell'organigramma aziendale figure e attività legate alla sicurezza dei dati. Questo impone un'attenzione concreta alla sicurezza (dei dati personali ma non solo) e promuove la Sicurezza a funzione essenziale al pari di quelle amministrative, commerciali e produttive.

In particolare, i concetti alla base della normativa che più mi sembra utile mettere in evidenza a supporto di quanto detto, sono: Proprietà dei dati, Privacy by Default, Privacy by Design e Trasparenza.

Sulla questione della Proprietà dei dati, la normativa chiarisce in modo inequivocabile che i dati sono del singolo e la loro proprietà non può essere ceduta a terzi. Quello che l'utente cede non è la proprietà ma l'uso e in particolare l'uso per un obiettivo specifico, limitato nei modi e nei tempi. Questo implica, ad esempio, che una volta raggiunto l'obiettivo specifico i dati andrebbero cancellati.

Con il concetto di Privacy by Default si indica la necessità di tutelare i dati personali “di default”, cioè a prescindere che l'utente lo richieda. Questo implica che l'utente non deve “accettare” o richiedere all'azienda l'applicazione di comportamenti che tutelino i dati ma che è responsabilità dell'azienda garantire il corretto trattamento dei dati ab origine e per tutti. Questo vale anche nell'atto di cessione/condivisione dei dati verso terzi: i dati vanno protetti anche durante questa fase di passaggio.

La Privacy by Design indica che il dato deve essere tutelato sin dalla progettazione di sistemi informatici e processi aziendali che ne prevedano l’utilizzo. Un software deve garantire da subito il livello di sicurezza adeguato e le funzionalità necessarie per dare modo all'utente di far valere i propri diritti.

Infine, il tema della Trasparenza indica che chi gestisce i dati personali deve rendere noti i rischi che il sistema introduce e le procedure messe in atto a tutela delle informazioni. Inoltre, si ha l'obbligo di rendere noti incidenti di sicurezza (Data Breach).

Una breve checklist per lo sviluppatore

A fronte di quanto detto e tralasciando gli obblighi formali necessari per essere conformi, diventa chiaro che tutti i futuri progetti software andranno ragionati mettendo in conto di gestire fin dall'inizio un po' di elementi che spesso sono lasciati in fondo o aggiunti successivamente, come ad esempio la gestione della rimozione di dati o i meccanismi di tracciamento dei consensi.

Ho preparato una piccola lista dei punti principali da approfondire e trattare (anche con il cliente!) come piccolo memorandum:

1. Vita e durata dei dati personali: la proprietà dei dati è dell'utente che ne cede l'uso per motivi specifici.

   • Quanto tempo dura l'uso?
   • Cosa succede quando l'obiettivo è stato raggiunto?
   • Il sistema che stiamo sviluppando potrà continuare a lavorare senza i dati dell'utente?
   • Se i dati vengono rimossi cosa succede all'integrità della base dati?
   • Sarà possibile e/o utile conservare dati d'uso anonimizzati?
   • Quando un dato viene rimosso, il sistema è in grado di far partire un processo aziendale (automatico o meno) che garantisca la richiesta di cancellazione verso tutti i soggetti terzi a cui sono stati ceduti i dati in modo che anche loro possano provvedere all'eliminazione?
   • Ci sono delle API che vanno usate per cancellare i dati da servizi esterni?

2. Raccolta del consenso: il consenso deve essere espresso in modo consapevole ed esplicito.

   • La UX della fase di raccolta del consenso è abbastanza facile da non essere considerata un ostacolo all'esercizio dei diritti dell'utente?
   • Il consenso è raccolto esplicitamente, ovvero senza opzioni di default che possono essere considerate ingannevoli?
   • Ogni uso dei dati è esposto separatamente dagli altri senza formule aggregate?
   • L'utente ha un modo altrettanto semplice di accedere ai consensi e rimuoverli?
   • Se l'utente è un minore, come si comporta il sistema? Come si raccoglie il consenso del tutore legale?

3. Considerare subito un sistema di tracciamento dei consensi: il tema della trasparenza dà all'azienda che tratta i dati l'onere di dimostrare, in caso di richiesta dell'utente, quando e quali consensi sono stati dati.

   • Quali dati sono raccolti e per quali finalità?
   • Quando è stato espresso il consenso?
   • Viene richiesto di marcare con cifratura e firma digitale questo tipo di informazioni?
   • Vanno condivise con altri sistemi informativi presenti in azienda o con un Registro del Trattamento preesistente?

4. Portabilità dei dati: sempre per il principio di proprietà dei dati, andrebbe garantita la possibilità all'utente di esportare i propri dati in un formato standard o facilmente gestibile in modo che lui possa, in caso, trasferirli verso altri gestori.

   • Quali formati sono disponibili per esportare i dati nel settore applicativo principale del software?
   • Esiste una modalità facilmente accessibile per l'utente in modo che possa recuperare i propri dati?
   • C'è una procedura di importazione dei dati in modo da poter importare dati provenienti da altri software equivalenti?

5. Decisioni automatizzate: sono poco trasparenti e costringere l'utente in categorie predeterminate limitandone le scelte, perpetuare stereotipi o dar luogo a previsioni inesatte.

   • Sono usati algoritmi di profilazione? L'utente ne è informato correttamente?
   • Cosa succede all'algoritmo se l'utente nega (anche in parte) il consenso? Come risponde il sistema a tale evento?
   • L'utente deve poter richiedere la revisione da parte di un umano: l'operatore ha la possibilità di accedere a tutti i dati necessari per la revisione della decisione?

6. Integrazione con i processi di tutela dei dati personali esistenti: l'azienda probabilmente tratterà in modo organico dati personali provenienti da altre fonti.

   • Come integrare i sistemi con i dati raccolti dal nuovo prodotto/servizio?
   • L'integrazione introduce dei nuovi punti vulnerabili? Come gestire queste problematiche e ridurre il rischio?

Questa è la mia lista, qual è la vostra? Fatemi sapere come la modifichereste o cosa vale la pena di aggiungere lasciando un commento o contattandomi con un tweet.