Guida al GDPR per chi non ne vuol sapere: dice il controller “lei non sa chi sono io”

Manca un anno al GDPR Doom’s Day e ovviamente siamo ancora impreparati ad affrontare la cosa.

Non lo dico io, ovvio, ma lo dicono le statistiche. E se i nostri amici al di la delle alpi sono messi non benissimo leggendo queste statistiche, vi lascio immaginare come siamo messi noi.

Siccome è un po che mi occupo della faccenda devo dire che mi sembra evidente che la comprensione di cosa sia il GDPR latita tra i responsabili aziendali, e le idee su come implementarlo sono spesso poche ma ben confuse.

Ho parlato in articoli precedenti diffusamente sul GDPR in tono lieve e talvolta ironico, ci provo ancora, anche se confesso che incomincio a provare un vago senso di inquietudine quando parlo di questi argomenti.

iniziamo dai alcuni errori di comprensione comuni

Il Bestiario GDPR

Il GDPR mi impedisce di collezionare i dati personali

lo ho sentito dire parecchie volte, ed ovviamente la risposta più corretta a questa osservazione è:

…ma la finiamo di dire pirlate?

Il GDPR è un regolamento che impone regole stringenti di gestione e processo dei dati personali, ma non ne impedisce ne la raccolta ne l’utilizzo. il punto è: sappiamo che ti servono, ma devi proteggere l’identità delle persone legate ai dati che hai raccolto.

Il GDPR è una roba IT, non mi interessa

e si …

…ma le multe le paghi tu non l’IT

Ovviamente tutto quello che non ci piace diventa un problema IT, peccato che l’IT sia impattata dal GDPR in maniera strumentale. Mi spiego meglio, l’IT deve implementare quelle misure che qualcuno decide debbano essere implementate per garantire il rispetto della normativa, ma non è l’IT che decide cosa implementare.

Il GDPR è una roba da avvocati, l’IT non centra

Ovviamente duale al precedente esiste la versione IT che si declina con un

ma a me cosa importa di sta roba?

peccato che una corretta implementazione dei dettami del GDPR imponga anche all’IT a ripensare i propri processi ed iniziare a gestire le cose in maniera adulta.

Io Faccio HR non mi devo occupare di queste cose

Ora notoriamente la mia posizione nei confronti della moderna interpretazione delle funzioni HR è abbastanza “critica” (lo so è un eufemismo).

…Il GDPR fa riferimento ai dati personali, ma anche quelli dei dipendenti…mi spiace ma ci sei dentro fino al collo caro HR manager…

Purtroppo per gli amici HR il GDPR non fa distinzioni tra clienti, fornitori o dipendenti. il GDPR si occupa di preservare le libertà fondamentali dell’individuo, essere impiegato non ne inficia né gli obiettivi né gli obblighi. Si, le funzioni HR devono tenere conto del GDPR.

e via scemenzando ne ho sentite fin troppe, anche da sedicenti personaggi che si offrono come esperti. Ok Ok loro dicono lo stesso di me 🙂

GDPR e Processi

Il primo che dovrebbe preoccuparsi del GDPR non è altri che il Board della azienda. La corretta implementazione del GDPR richiede infatti la esplicita presa in carico della azienda della implementazione della conformità alla nuova legge.

Nel dettato del GDPR viene esplicitato diverse volte che spetta all Data Controller di fare le valutazioni inerenti a quale sia il rischio legato alla getione dei dati personali tenendo presente da un lato le esigenze del business dall’altro le libertà individuali da proteggere.

In altre parole il motore della analisi è il Business. e questo non è un dominio che attiene all’IT ma al board della azienda.

l’implementazione del GDPR richiede che si sia in grado di fare una valutazione di Business dell’impatto del processo di raccolta ed elaborazione di dati personali. è il business che determina anche come devono essere gestiti e protetti questi dati.

Il soggetto utilizzato nella nomenclatura GDPR per fare queste valutazioni è il Data Controller. Il responsabile ultimo del trattamento, il CEO della azienda.

in altre parole chiedere alle funzioni IT di gestire il GDPR è come chiedere ad un pilota di progettare una macchina.

Alla fine della fiera la corretta implementazione della normativa richiede la definizione di processi definiti tracciabili e sicuri che consentano di gestire tutta la vita del dato personale all’interno della azienda. questo comporta:

la definizione delle responsabilità all’interno della struttura (ruolo che spetta per definizione al management)
la definizione del livello di rischio accettabile in relazione all’attività aziendale ed alla natura dei dati raccolti (che secondo il GDR spetta al management aziendale)
la implementazione di misure correttive atte a minimizzare il rischio ANCHE dal punto di vista informatico, cosa che richiede l’intervento delle funzioni IT e di sicurezza

Data Controller e Data Processor

Non si può capire cosa sia il GDPR senza aver capito appieno chi è il Data controller, chi è il Data processor e come gira il fumo 🙂

Data Controller

chi cavolo è il data controller?

Il Data controller secondo il GDPR è il responsabile del trattamento dei dati, insomma quello che decide:

che dati raccogliere
per cosa utilizzarli
valutare e gestire il rischio (attraverso lo strumento della DPIA)

In quanto responsabile, spetta al Data Controller (il CEO aziendale o chi per lui) definire quale sia il livello di rischio accettabile e quindi quali siano le misure di mitigazione corrette da mettere in piedi tenendo presente i vincoli dettati dal GDPR.

Questo non significa che altre funzioni aziendali non siano coinvolte nel processo di definizione; HR, MKTG, Sales ed IT sono componenti attive del processo. Ma alla fine la decisione spetta a chi ha la responsabilità, e questa ricade, secondo il GDPR, sul Data Controller in quanto è l’owner delle attività di business e quindi l’unico che possa valutare, come richiede GPR esposizione e rischio.

Data Processor

Ma allora chi o cosa cavolo è un data processor?

Il data Processor altri non è che chi materialmente si occupa delle attività di raccolta e processo dei dati. In quest’ottica, ad esempio, il data processor può essere sia l’operatore marketing che fa le interviste telefoniche e raccoglie i dati, che la struttura IT che gestisce la struttura informatiche che questi dati manipola e gestisce seguendo le istruzioni impartite dal Data Controller..

Mentre il Data controller è una funzione aziendale interna, il data processor può essere anche una entità esterna. è il caso di servizi offerti da terzi: dai cloud providers, alle agenzie di marketing la variabilità dei data processor dipende da come i dati ed il business è stato disegnato ed implementato.

Essendo il Data controller chi decide quale sia il livello di rischio accettabile e quindi le opportune misure di mitigazione il processo di implementazione del GDPR non può partire dai data processor che invece sono le funzioni “implementative”.

Per esemplificare al data controller spetta la definizione dei parametri di business e il livello di rischio accettabile. questo comporta assumersi la responsabilità di come i dati vengono raccolti, gestiti e protetti.

Al Data processor invece spetta l’implementazione operativa delle misure di sicurezza richieste dal Data controller e le operazioni generiche di gestione dei dati.

Insomma il GDPR non dice che devi usare encryption, ma dice che spetta al Data Controller decidere se questa sia una misura adatta a proteggere le libertà individuali associate an un non corretto uso dei dati raccolti in funzione degli imperativi di business.

ovviamente il Data Controller è libero di andare dalle funzioni IT per chiedere:

si può fare?
quanto costa?

ma non spetta all’IT decidere in seno alla implementazione o meno della misura.

Altri aspetti del GDPR richiedono attività che coinvolgono un corretto disegno della struttura manageriale e di reporting che sono di delicata implementazione vista la storica sclerosi delle strutture manageriali italiane storicamente avverse a qualsiasi cambiamento. ma questo è un punto su cui il GDOR non transige, pur non dando indicazioni specifiche richiede l’esplicita responsabilità aziendale nei confronti della implementazione del dettato di legge. alcuni vincoli tuttavia sono esplicitati in termini di legislazione locale anche in italia, ad esempio come si sta definendo la figura del DPO che, è chiaro dal dettato del GDPR, non ha responsabilità diretta sulla implementazione del GDPR che rimane in toto al data controller, e che deve avere il garantito livello di autonomia ed indipendenza dalle altre funzioni aziendali (il che taglia fuori, ad esempio, it managers, sales managers o ruoli simili).

L’inversione dell’onere della prova

Un aspetto probabilmente non ancora ben digerito della nuova normativa è il concetto sottointeso di inversione dell’onere della prova.

Spetta al Data controller dimostrare di essere compliant al GDPR in caso di controlli e o di incidenti.

in altre parole:

sei colpevole se non dimostri la tua innocenza

Questo significa che gli obblighi indicati dal GDPR non sono formali ma sostanziali, e la loro implementazione deve essere formalmente dimostrabile, altrimenti, indipendentemente che ci si sia comportati bene o meno, si è formalmente e sostanzialmente non conformi e quindi perseguibili a termini della normativa.

Insomma non possiamo “ciurlare nel manico” più di tanto, ma siamo obbligati a mettere in piedi processi dimostrabili in maniera chiara, attraverso documentazione, reporting, funzioni aziendali correttamente definite.