Il Regolamento europeo per la protezione dei dati personali (il GDPR) ha pesanti impatti sui sistemi informativi e, si sa, i sistemi informativi non si modificano con facilità. In particolare, molte difficoltà nell’applicazione del GDPR si riscontrano sulla gestione del diritto all’oblio, del periodo di conservazione e del consenso nelle varie applicazioni. Vediamo perché.
Indice degli argomenti
Applicazione del GDPR: il perché dei ritardi
Il primo computer commerciale, l’UNIVAC I, fu messo in funzione solamente 68 anni fa, il 14 giugno 1951. Dal 1951 ad oggi l’informatica ha fatto passi da giganti nei sistemi operativi e nei linguaggi di programmazione e nell’estensione dei problemi trattati.
Le “aziende” (ovviamente non tutte coincidono con questo stereotipo) tendono ad accumulare tecnologie e a ritardare i cicli di ammodernamento del parco applicativo fino a che non sia strettamente necessario, perché nella decisione di investimento intervengono contrastanti logiche di business, calcoli sul ritorno dell’investimento e la difficoltà di gestire il processo di modernizzazione con le risorse umane disponibili. È facile che progrediscano a piccoli o grandi balzi; per esempio, è possibile che nel 1999 abbiano sostituito il sistema contabile fatto in casa con un ERP, che nel 2010 abbiano finito di affiancare al mainframe i sistemi open, che nel 2015 abbiano esternalizzato la posta elettronica e che nel 2020 spostino l’IT nel cloud mentre già pensano alla blockchain…
Sistemi di cui non si ha più controllo
La conseguenza di tutto questo sono sistemi informativi eterogenei e stratificati, e silos applicativi interconnessi on premise e nel cloud da interfacce batch, near real time o real time, dei quali nessuno ha più la piena conoscenza. Ciò avviene in misura maggiore per le aziende più grandi e di non recente costituzione e per quelle soggette alle profonde trasformazioni dovute alle operazioni societarie di fusione e acquisizione.
Dovrebbe essere il tempo di ragionare di metodologie e strumenti di data governance e, al di là degli obblighi di compliance, concentrarsi sui vantaggi di business che tale pratica è in grado di portare; ma comprendere quali dati vengono gestiti e come, è chiave anche per una gestione sostanziale del GDPR.
Diritto all’oblio, consensi e data retention: occorre tenerne conto
In merito al GDPR, l’organizzazione e gli utenti, nel loro operato, dovrebbero tenere conto di alcune cose molto importanti e le applicazioni informatiche dovrebbero coadiuvarli congruentemente:
- ogni interessato potrebbe dare il consenso all’uso dei propri dati personali solamente per alcune delle finalità proposte dall’azienda. In mancanza dei prerequisiti legali il dato non può essere utilizzato per lo specifico trattamento in oggetto;
- a fronte di una richiesta di cancellazione (ai sensi dell’articolo 17) ci possono essere casi in cui la cancellazione sia dovuta e altri no (per esempio per un obbligo legale dell’Unione e dello Stato). In caso positivo i dati personali devono essere cancellati, viceversa, in caso negativo, è necessario farne un uso limitato a quanto strettamente necessario (articolo 18);
- anche in assenza di una specifica richiesta dell’interessato, i dati devono essere cancellati quando le finalità per i quali sono stati raccolti sono state conseguite.
Nel complesso le applicazioni dovrebbero essere “consapevoli” delle limitazioni di utilizzo dei dati personali a seconda del contesto e permetterne la cancellazione nel momento appropriato. Questi requisiti sono abbastanza semplici da realizzare al momento della progettazione iniziale di una applicazione ma sono estremamente difficili da aggiungere alle applicazioni esistenti.
Il problema della complessità gestionale
La complessità sta nella capacità di poter gestire la numerosità delle relazioni (cardinalità) tra finalità, attività, applicazioni, business logic, data store e data model e nel fatto che tali relazioni si intrecciano in maniera multipla (interfogliamento):
- i dati personali sono raccolti per certe finalità. Un esempio di finalità è l’instaurazione e gestione del rapporto di lavoro;
- le attività sottese sono: l’amministrazione del personale, la formazione del personale, la valutazione del potenziale e della prestazione ecc.;
- è molto probabile che le attività siano realizzate con l’ausilio di una o più applicazioni (ad esempio, il sistema delle risorse umane per i due stabilimenti principali e il sistema nel cloud per la gestione dei talenti);
- la business logic appartiene all’applicazione e consiste nell’insieme di regole implementate nel programma che permettono di svolgere i compiti dati. Per esempio, è la business logic che approva l’invio di un email a tutti i dipendenti che non hanno ancora completato il corso sulla sicurezza del lavoro;
- il data store è il luogo IT dove si memorizzano i dati raccolti: molto spesso è un database ma possiamo annoverare qui anche i file system, il sistema di email ecc. Le applicazioni usano i data store per rendere persistenti i dati di cui hanno bisogno;
- i dati nei data store sono organizzati secondo un data model. Il data model descrive i dati presenti e le loro relazioni. È il data model che dice se la colonna 1 della tabella 1 contiene i cognomi dei dipendenti e via dicendo.
Cardinalità e interfogliamento per gestire la complessità gestionale
Uno specifico insieme di dati personali può essere raccolto per multiple finalità, declinate in differenti attività, ognuna delle quali realizzate da una o più applicazioni che seguono differenti business logic e memorizzano i dati in uno o più data store del cui data model spesso non si ha più cognizione. In aggiunta, i dati possono essere stati copiati per vari motivi tra diversi data store e le applicazioni concorrono contemporaneamente a diversi trattamenti.
Alcune applicazioni si basano sulla presenza dei dati personali per effettuare calcoli e analisi che, pur non trattando il dato personale, su di esso si basano. Un esempio è il calcolo del totale di vendite per regione geografica a partire dall’importo degli ordini al dettaglio. Nel caso in cui i record si debbano cancellare dopo qualche tempo per il diritto all’oblio o per la limitazione della conservazione, la validità di tali calcoli sarebbe vanificata.
È quindi complesso passare dalle finalità del trattamento (che è un concetto legale) al sistema informatico perché i due mondi condividono i dati personali ma sono fondamentalmente estranei. Cardinalità e interfogliamento logorano la volontà di molti analisti volenterosi che devono decidere come implementare le limitazioni d’uso (per il consenso e le limitazioni del trattamento) e la cancellazione dei dati (per il diritto all’oblio e la scadenza dei termini di conservazione) delle molte applicazioni interessate.
Come venirne fuori?
Non c’è un unico modo di affrontare questo problema. Molto dipende da fattori legati alla specifica azienda, alla sua storia, a come sono fatti i suoi sistemi informativi, se ha un sistema informativo monolitico o frammentato, se ha un’applicazione per la gestione dei clienti (e del personale) molto più importante delle altre che sono quindi solo dei “satelliti” o meno, se usa molto o poco software pacchettizzato, se ha già iniziato un percorso di adeguamento “dal basso” o no.
Avere a disposizione le informazioni relative ai dati personali, quali siano e dove siano e a quali categorie di interessati appartengano è di fondamentale importanza. Tali informazioni possono essere nella testa di una persona o un team e/o raccolti e usati tramite uno strumento informatico seguendo una metodologia di data governance, la cui adozione è spinta nell’organizzazione da un data steward.
Tale cognizione usata insieme ai registri delle attività di trattamento (obbligatorio ai sensi di legge, articolo 30) ma esteso con le informazioni relative agli asset IT, permetterebbe di predisporre un piano ottimale. Data governance e registri dei trattamenti sono due ingredienti principali della ricetta per la compliance al GDPR.
Il cuore di un sistema di data protection
Alle aziende complesse conviene investire anche in un sistema informativo per la gestione della protezione dei dati personali. Contrariamente a quanto può sembrare a prima vista da questo nome, non sarebbe un sistema di security (pertinente al CISO, Chief Information Security Officer) ma di un sistema per trattare le richieste degli interessati, gestirne il consenso e fornire alle applicazioni le informazioni sulle quali adattare la business logic per tenere conto responsabilmente delle loro richieste. Inoltre, potrebbe fornire le informazioni di utilizzo dei dati personali a fini di reporting e per alimentare le procedure di cancellazione allo scadere dei periodi di conservazione.
In pratica sarebbe realizzato un sistema centralizzato di conservazione dell’informazione del consenso (prestato, negato, ritirato) di ogni interessato. Il sistema distingue tutti i diversi tipi di consenso, secondo le finalità che sarebbero censite analiticamente. Esso deve essere alimentato opportunamente da chi (utente o sistema) lo raccoglie inizialmente o lo modifica successivamente (anche tramite il sotto-sistema di gestione delle richieste degli interessati), tenendo traccia delle modifiche.
Le applicazioni, prima di fare uso dei dati personali, dovranno chiedere l’informazione di consenso al sistema di conservazione e nel farlo lo stesso registrerà la richiesta con data, esito e dati accessori. Tale informazione permette alle applicazioni di usare propriamente i dati personali e di converso fornisce elementi relativi all’uso storico atti ad alimentare i sistemi che procedono alla cancellazione dei dati.
Da un punto di vista tecnico il nuovo sistema tratta alti volumi di transazioni, richiede prestazioni elevate in read-write (tipiche di un in-memory database), e richiede la modifica del codice delle applicazioni che lo usano.
Quest’ultimo fatto è sicuramente il problema principale e per alleviare i costi della soluzione bisogna definire dei pattern d’uso e ingegnerizzare delle soluzioni software il più possibile basate sull’architettura (per esempio, a seconda dei linguaggi di programmazione, delle stored procedure o API). Alcuni DBMS di mercato sono capaci di aggiungere automaticamente del codice eseguibile alle interrogazioni SQL agendo in riduzione sul “result set”; questo semplifica il lavoro ma sicuramente non lo elimina.
Conclusione
Il GDPR ha sollecitato i dipartimenti IT con nuove sfide assolutamente non banali ed evidenziato un’altra volta la necessità di avere il governo e la gestione dei dati aziendali. Sapere dove siano i dati, cosa essi rappresentino, averne una descrizione, conoscerne e controllarne la qualità eccetera, è un fattore critico per le aziende di successo degli anni a venire, tanto più quanto più esse si “disfano” dei sistemi spostandoli nel cloud. Ci sono addirittura alcune aziende che possiedono solo dati (Google, Uber, Facebook, Instagram, Airbnb…): per queste, ma anche per le altre, la fiducia del consumatore e il rispetto dei loro diritti sarà sempre di più un fattore determinante il loro successo. Il Data Steward si faccia forte del GDPR così come l’hanno fatto il Security Officer e il Legal.
