Che lo vogliate o no… E’ arrivato il GDPR! (Parte 1)
Allora ci siamo.
Dal 14 Aprile 2016 finalmente è stato ratificato il nuovo Regolamento Europeo sul Data Protection (GDPR). E’ stata cosi laboriosa la gestazione e cosi estenuante il travaglio di parto che mi viene alla mente il Big One californiano. Il presunto mare e terremoto che tutti hanno aspettato dall’inizio del secolo dopo quello del 1906 e che non si è mai verificato ma tutti sanno che accadrà e affosserà nella crosta terrestre la California.
In effetti quello del 1989 non è stato una cosa da poco … ma torniamo a noi
Sono passati diversi decenni dalla Direttiva Europea del 1995; da lì in poi la Legge 675, il DM 318 del 1999 e infine il Dlg.vo 196/2003. In ognuno di questi passi si è cercato di normare seguendo le esigenze e le stringenze della evoluzione tecnologica.
Si è passati dall’era dei fax a 200dpi al Cloud Computing nell’era del BigData degli IoT e della CyberSecurity. In 20 anni quello che nella fisica è successo in un secolo passando da quella newtoniana a quella quantistica, dal pezzo di ferro agli ologrammi, dal mezzo trasmissivo di rame a wi-fi/GPS, dal codice su scheda perforata alle Apps che girano nello smatphone senza che neppure se ne abbia consapevolezza.
Eppure, nonostante questo salto dimensionale e funzionale globale, in fondo i principi ispiratori della Carta di Nizza, da cui la prima direttiva era derivata, sono gli stessi che troviamo oggi in questo nuovo GDPR.
In questo primo articolo riassumo schematicamente soltanto in modo preliminare, alcuni elementi rilevanti e dirompenti; come sempre è stato per le rubriche da noi curate, i contenuti di ogni singola tematica saranno approfonditi e aggiornati con gli specifici pubblicazioni. Non è concepibile esaurire le molte problematiche dell’esteso articolato della Riforma. Interi seminari e copiose pubblicazioni sarebbero necessari anche solo per uno dei molti argomenti influenzati dal GDPR; si pensi al mondo della Sanità e del fascicolo elettronico, alla Identificazione Univoca Digitale, al Data Retention, l’universo del Cyberspace e le veicolazioni di transazioni IoT, BlueTooth, WI-FI e i BYOD promiscui.
L’ordine con il quale commento non è da interpretare secondo priorità. Non esiste infatti un aspetto più critico di altri perchè non esiste un criterio unico per la miriade di attività produttive e di servizi che dovranno adeguarsi. Sia che abbiamo già un ottimo Sistema Privacy sia che comincino dalle fondamenta rischivendone uno isperato alla privacy By Default e By Design.
Ogni azienda ha una proprio situazione ICT, un campo di applicazione e una tipologia di trattamento dati diversa da qualunque altra. E’ la combinazione di molte variabili di impresa che determinerà il Sistema Data Protection Aziendale (SDPA), e la prima considerazione che ne discende è che non esiste un ciclostile per il Manuale del sistema di Data Protection (MDP); ma le persone serie sanno che anche prima con il Dlg.196/03 questo era vero.
REGOLAMENTO NON DIRETTIVA
Prima di tutto invito a riflettere che si tratta di un Regolamento e non di una Direttiva!
La più banale delle considerazioni di questo pertiene la sua applicabilità. In effetti le direttive sono nate con la Comunità Europea quando ancora il Parlamento e il Consiglio avevano compiti settoriali distinti.
La direttiva aveva tipicamente due anni di aspettativa prima di essere recepita dai paesi membri. Con ciò si intende che poi le singole legislazioni locali, intraprendevano un percorso legiferativo, ognuna con i propri iter parlamentari e tempi attuativi.
Il Regolamento è valido in tutti gli stati membri subito, nello stesso modo e allo stesso tempo. Semplicemente, sono previsti due anni dalla ratifica perchè diventino cogenti le sue prescrizioni; in sintesi, a fronte di controlli delle autorità e/o controversie legate agli adempimenti non conformi, si è esposti al sistema sanzionatorio.
UNIFICAZIONE E SOSTANZIALITA’
Essenzialmente il GDPR univica il mondo della Privacy (trattamento e protezione dei dati personali) con quello della Sicurezza Informatica (ICT-SEC). Questa messa a fattor comune di due ambiti intimamente correlati e mutuamente dipendenti è in realtà una cosa antica e ha vissuto negli ultimi due anni nella miriade di provvedimenti da parte della Autorità Garante, da Rodotà, Pizzetti e attualmente Soro, che ha sempre cercato di contenere l’enorma disattenzione e sprovvedutezza tipicamente italiane delle aziende tenute alla conformità e dei potenziali “interessati”, coloro che dovrebbero beneficiare della protezione dei dati personali.
Il termine Privacy non è più elettivo e si è diluito nella più grande accezione del termine Data Protection. In effetti la protezione è un concetto che implica Sicurezza (fisica, logica e di gestione), Confidenzialità, Continuità, Diritto all’Accesso, anti-contraffazione, non repudiabilità, Identificazione Digitale Univoca, Disponibilità, tutela dal furto di identità,
Ognuno di questi elementi è una disciplina per il quale sono scritti e saranno scritti volumi interi quindi il GDPR ha comportato uno sforzo enorme di armonizzazione e unificazione normativa, prescrittiva e multidisciplinare. Accanto a questo non ignoriamo la lunga attesa dovuta anche alle attività degli interessi lobbistici ma ne scrivo altrove.
Una seconda parola chiave è la Compliance che è collegabile a due standard internazionali ISO 19600 (l’approccio sistemico alle “obligation”) e la ultima ISO 9001 che comporta il coinvolgimento degli stakeholder (il Regolamento è parte degli interessi) e l’analisi dei rischi (requisito innovativo del nuovo Regolamento formalizzato come modello di risk assessment e management assimilabile alla famiglia delle ISO 3100x).
Per l’ambito giuridico i cambiamenti sono molto evidenti, l’indirizzo è quello di una responsabilità che coinvolge sempre di più l’organizzazione come soggetto (approccio della responsabilità “penale” dell’impresa presente stabilmente dal 2001 con il Dlg.231/01. L’ OdV (organismo di vigilanza) implicito nelle prescrizioni legali, recependo una logica della applicazione delle buone pratiche e quelle di riferimento ISO27001 e la BS 10012, dovrebbe altrettando implicitamente annoverare al suo interno la fidura del DPO introdotto dal GDPR (vedi avanti “La finta questione de DPO”).
THE VERY FIRST GLIMPSE
Il titolo di quest paragrafo è provocatoriamente in inglese, perchè si allude al fatto che già dalle prime traduzioni del testo GDPR originale (peraltro il primo in assoluto è in francese), si è avuta la sensazione che alcune porzioni, soprattutto quelle di carattere prescrittorio e legale, avressero quello che internazionalmente è noto come “missing in translation” e che qui in Italia chiamiamo “discrasia”. Detto in termini estremamente riassuntivi, ci sono alcuni articoli che per essere bene interpretati e attesi, è meglio siano studiati dall’inglese. Peraltro, in molti dei 28 paesi della UE, si adotta direttamente il testo della versione inglese (n.d.r.).
Globalmente considerata l’intera “faccenda” è diventata molto meno formale e più sostanziale! Con ciò si intende che sono finiti per sempre i tempi della Privacy comprata a chili di carta. Ispirata alle normazioni contrattuali volontarie, ISO e BSI per citare quelle internazionali storiche, il GDPR deve essere atteso, attuato e dimostrabile con fatti e non solamente qualche foglio di carta.
Quando il GAT (nucleo speciale della GdF) effettuasse una ispezione, ovvero in sede di controversia (denuncia di terzi alla Autorità), non è più sufficiente mostrare una generica informativa, qualche foglio firmato dai dipendenti e un presunto manuale di 10 pagine che ricorda più ad una Carta di Servizi nella home di un sito di una clinica privata.
Si dovrà avere una chiara distribuzione delle nomine e delle designazioni dei ruoli del SDPA, un credibile e pertinente documento di valutazione dei Rischi e degli Impatti (cosidetto Privacy Impact Analisys, PIA), Piano di informazione e formazione attuato, provabile e aggiornato, una politica di qualificazione delle forniture ICT a mezzo di SLA e PLA, un piano di Audit effettivo e comprovabile da terzi, se adottata la strutturazione e l’inquadramento di un Data Protection Officer (DPO), il Disciplinare interno con eventuali certificazioni del Data Center on Premise (ISO20000 per i servizi e ISO27001 per la sicurezza della infrastruttura dei Sistemi Informativi). Naturalmente citiamo a braccio, ma la lista sopra non è esaustiva!
NOTIFICAZIONE NO, ANZI SI
E’ vero ! Non esite più la prima Notificazione presso il Registro del Garante a Piazza Monte Citorio. Tuttavia, forse un onere più impegnativo, è previsto che una azienda si doti di un impianto strutturale (sia formale, che procedurale) per far fronte alla tempestiva Notificazione del cosidetto Data Breach.
In definitiva, la Notificazione storica è solo sostituita da quella per la Sicurezza Informatica e Telematica. In sintesi, le società devono dotarsi di un sistema di gestione delle evenienze avverse di danni informatici. Non tanto e solamente per prevenirli, quanto nella escalation di valutazione di un indicente informatico del quale devono entro una settimana avvisare l’Autorità di riferimento e tutti gli Interessati i cui dati sono stati (anche solo presumibilmente) coinvolti nell’incidente. Vediamo meglio nel caso parliamo di operatori del settore delle comunicazioni elettroniche e successivamente presente in diversi provvedimenti specifici riguardanti per esempio la biometria, la condivisione di banche dati particolarmente ampie tra soggetti pubblici, le tutele dei dati sanitari contenuti nel dossier sanitario elettronico.
Nel Regolamento Art. 32 Bis, si adotta il concetto di adempimenti conseguenti ad una violazione di dati personali che coinvolge in modo diretto anche i fornitori di servizi di comunicazione elettronica accessibili al pubblico; tutti hanno l’obbligo della comunicazione all’Autorità Garante di eventuali violazioni di dati personali da essi conservati. Laddove esista poi il pregiudizio ai dati personali o alla riservatezza di un contraente o di altra persona, questi dovranno essere avvisati dell’avvenuta violazione anche se solo per pregiudiziale nocumento. Il “Provvedimento in materia di attuazione della disciplina sulla
comunicazione delle violazioni di dati personali” già indica :
a) un termine di 24 ore per fornire all’Autorità le prime sommarie informazioni con la possibilità di estendere a ulteriori 3 giorni l’integrazione di eventuali notizie utili;
b) l’istituzione di un registro in cui annotare le violazioni;
c) le modalità di compilazione del modulo di notifica formato da ben 17 punti.
Quindi già dal 2015 anche le pubbliche amministrazioni che detengono banche dati di grandi dimensioni a cui possono legittimamente accedere plurimi soggetti pubblici, devono comunicare al Garante, nelle 48 ore dalla conoscenza del fatto, le violazioni occorse ai dati personali detenuti e gli incidenti informatici. Tutti gli altri hanno 72 ore.
TUTTO SCHIACCIATO E SEMPLIFICATO, FORSE…
Una delle parole chiave molto di moda non solo per la Privacy, ma anche per molti altri ambiti legislativi parlamentari è quella della “Semplificazione”. In effetti anche per il nuovo Regolamento, alcune semplificazioni possono essere identificate… Attenzione però, che non necessariamente una semplificazione rende più “semplice” l’attendere gli adempimenti. Ciò che sicuramente si è semplificato è lo stile di emanazione degli articolati che secondo la tendenza internazionale, mira non tanto alla legiferazioni dettagliate di “cosa” si può e di “come” si deve fare riferendosi a tabelle prescrittive definite; piuttosto, cosi come accade con le linee guida (Guide Lines), le norme di buona operatività (good practisies) e le pratiche dovute (due diligence) indicano le direttive di condotta e i criteri da soddisfare per conformarsi ai requisiti di legge e agli adempimenti sul campo.
Uno tra i molti aspetti precocemente riscontrabile di questa filosofia riguarda la semplificazione della gestione delle nomine e delle deleghe dei soggetti e dei ruoli all’interno di un SDPA. In un certo senso ci si emancipa verso una semplificazione della articolata gerarchia fatta di Titolari del Trattamento, Responsabili del trattamento (esterni nel caso di fornitori), gestori delle chiavi, amministratori di sistema (interni o esterni), operatori del trattamento verso due fondamentali soggetti : Data Controllers e Data Processors.
Non conviene pensare di tradurli, tanto nel manuale del SDP converrà citarli cosi anche inconsiderazione della internazionalizzazione delle procedure (vedi più avanti “Dove vanno i dati transfrontalieri ma soprattutto da dove vengono“)
Altra cosa che non conviene interpretare è che sia tutto quì. A parte il caso del DPO di cui parliamo dopo, comunque occorreranno gli Amministratori di Sistema come figure se stanti, ma, nel caso di una terzializzazione di servizi ICT (Es. Cloud SaaS, PaaS, Sec-aaS, Storage-aaS ecc.) diventano Joint-Controllers (precedenti co-titolari). Peraltro, un corretto inquadramento negoziale dell’istituto del Joint Controller
rispetto ai trattamenti condivisi, se non vissuto solamente come prescrizione legale per i gruppi di imprese, è una occasione per definire responsabilità specifiche sui dati, e potrebbe rappresentare un vantaggio competitivo strategico per le corporates.
La cosa rivoluzionaria è che in caso di controversia (denuncia di un Interessato), danno informatico ai dati o di breccia/intrusione ICT queste figure, siano esse interne alla organizzazione o società esterne saranno congiuntamente responsabili e perseguibili ai fini della comminazione di sanzioni.
Questa si che è una entusiasmante nuova prospettiva…
DOVE FINISCONO LE AUTORITA’ NAZIONALI?
Alle organizzazioni che trattano dati personali, di qualunque classe e dimensione, saranno concessi due anni per adeguarsi. Questa è la notizia più direttamente connessa con la domanda frequente posta dalle aziende che negli ultimi anni ha aspettato la Riforma Europea : ma che fine fanno le Autorità a livello Nazionale?
Nonostante le profonde e storiche diversità tra gli Stati membri, in maniera idiosincratica l’Europa si appresta ad avere nuove norme ancora più uniformi in materia di circolazione dei dati personali e la concertazione tra autorità nazionali, come conferma anche il piano
d’azione per il 2016 annunciato ad inizio febbraio dall’art. 29 Working Party (WP29).
Il piano prevede, tra i vari punti, la costituzione di una task-force WP29- European Data Protection Board (organo di coordinamento delle autorità Garanti nazionali), nonché l’implementazione di sistemi informatici nell’ambito del c.d. One stop shop (sportello unico).
Molta importanza ha il ruolo che le Autorità locali avranno nel periodo di inter-regno di validità delle precedenti versioni nazionali fino al decorrere della cogenza vera e propria del nuovo European Regulation. Nel proprio Paese, le autorità avranno ampia facoltà di emanazione di provvedimenti e norme di interpretazione e applicazione dell’articolato nel GDPR. Ad esempio in merito agli obblighi distinti tra Pubblico e Privato nella nomina obbligatoria del DPO sulla base di trattamenti di dati particolarmente sensibili.
LA FINTA QUESTIONE DEL DPO
Quella del Data Protection Officer è una questione molto controversa e decisamente non chiara. Diversamente da molti altri adempimenti esplicitamente cogenti e mandatori, questo è stato discusso per anni. Più che per un problema di accountability, il DPO rappresenta un problema nel caso di trattamenti “particolari” (quelli che prima erano i dati sensibili) e nelle organizzazioni disseminate e dipartimentalizzate. Non è solo un risparmio economico, piuttosto la necessità di una competenza interdisciplinare e terza che in prima approssimazione ricorda il ruolo dell’ Auditor Interno e/o il Responsabile AQ di un Sistema di Qualità e Sicurezza in ambiente ISO.
Nella prima fase di elaborazione del GDPR, il DPO fu pensato come indispensabile, poi ci si è resi conto del fatto che questo Cristo deve conoscere tutte le normazioni europee, essere un esperto di leggi e di giurisprudenza (Es. Dlg231/01), essere certificato in almeno tre ambiti di Sicurezza Informatica (IT-ISO27001/ISO20000, Cyber Security e Risk Analysis NIST-CLUSIT, Cloud Computing – CSA/ENISA, Gestione di Processo – ITIL/CoBIT), essere un esperto certificato di progettazione e analisi dei rischi, deve essere esperto di docenza e formazione, deve essere terzo rispetto alla Proprietà aziendale più un’altra decina di expertise secondarie solo in ordine di excursus professionale per Sistemi di Qualità e Sicurezza.
Una simile profilazione individua qualcosa come 4 o 5 persone in tutta Italia, e se esistono si tratta di persone che su LinkedIn troviamo felicemente accasate all’interno di una organizzazione. Difficilmente, passerebbero al mondo del libero professionismo per girare come trottole e guadagnare molto meno.
Insomma, l’adozione di un DPO è definita non mandatoria ma raccomandabile ed eventualmente figura giuridica esterna.
A livello di comunità europea (Parlamento, Consiglio e Commissione o Trilogo), per un certo periodo gli emendamenti controversi hanno riguardato i DPO e le discussioni sembravano orientate a rendere questa figura mandatoria in ragione della dimensione della organizzazione (tipo numero di dipendenti), ma è stato fatto notare di come alcune attività di agenzia (Per es.: Centrali di rischio o studi di investigazione ), seppure con pochi dipendenti può effettuare controlli estremamente critici e dannosi sui dati personali. Quindi ha preso piede la metrica basata sulla quantità di records detenuti. Ma anche in questo senso si andava incontro a discriminazioni ed elusioni irragionevoli.
Insomma alla fine il DPO si è reso facoltativo a discrezione del Data Controller (principale nel caso di joint Controllers).
Di fatto un DPO potrebbe essere indispensabile per una azienda che habbia un Data Center intramurale (on premise), in quanto più efficace ed economico rispetto alla consulenza di una delle Big Four o di un lungo percorso certificativo che comunque non può garantire dalle prescrizioni legali. Si legga, non è che perchè abbiamo una certificazione ISO9001 significa che scongiuriamo le sanzioni del GDPR.
Il DPO è un finto problema perchè in realtà rappresenta un vantaggio competitivo per la società risolvendo e armonizzando ambiti legislativi, progettuali e di governo della Informatica e integrando gli obblighi delle normazioni di compliance.
MA QUANTO MI COSTA E COSA RISCHIO
Questa è la domanda che tutti noi consulenti ci sentiamo fare dai clienti. E va suddivisa su due voci di costo : quella del disegno, della progettazione e della implementazione di un nuovo SDPA e quella della esposizione nel caso di sanzione.
La seconda preoccupazione è piuttosto banale da chiarire. Tutte le cifre precedenti sono più che raddoppiate. Sono cioè possibili multe milionarie in quanto si è inteso valutare la rilevanza del danno provocato più che la solita considerazione amministrativa (che peraltro non ha funzionato mai come terrorismo minatorio presso le società). Per un senso di pudore dell lobby che hanno condizionato il Trilogo, si è concesso che nel caso delle multinazionali, a discrezione del giudice, per avere un conclamato effetto di deterrenza, si può arrivare dino al 4% dell’ultimo fatturato dichiarato a bilancio societario. E’ cioè sensibilizzata anche la multi-nazionale ala quale pagare qualche migliaia di Euro non cambia molto.
Forse perchè consulente, penso al mio primo Disciplinare Tecnico e DPS nel 1998 per una Clinica Privata nelle campagnie del Piacentino, mi concentro sui costi di realizzazione di un Sistema di Data Protection aziendale (SDPA).
Come spiegato in incipit, un sistema privacy non è ciclostilabile, soprattutto perchè i controlli saranno orientati alle verifiche sui sistema ICT : procedure di backup, misure di protezione perimetrale, formazione specifica per ogni ruolo, controllo delle forniture ICT, dove presente della compliance della impiantistica anti-intrusione e videosorveglianza per citare le prima a mente.
Ulteriore considerazione generale causale rispetto al precedente punto, il fatto che la tipologia di trattamenti (cartacei, digitali, DB distribuiti o pubblicati), la classe della dotazione informatica e delle piattaforme software utilizzate (LAN,WAN BladeSystem, virtualizzazione ecc), le finalità del trattamento (Legali, profilazione ecc.), il trasferimento e la condivisione con l’esterno dei dati (scambio transfrontaliero), l’ambito del processo di business (e-commerce, pubblicitario, assicurazioni, produzione, servizi ICT ecc.) rendono non plausibile pensare ad un lavoro uniforme e ripetitivo.
Che sia nominato DPO o si conporti come fornitore di prestazione consulenziale, un professionista deve svolgere attività comparative e multi disciplinarie di GRC (Governance, Risk and Compliance management).
Quindi per esaurire in modo riassuntivo, il costo e la quantità di lavoro consulenziale e di affiancamento, se possibile è decuplicato rispetto ai precedenti Sistemi Privacy. E che non sembri paradossale, ma questo è dovuto proprio al fatto che non si chiede più di avere una postura formale cartacea, ma un effettiva e attuata pletora di procedure e istruzioni operative comprovate e comprovabili di Sicurezza Informatica. Come abbiamo visto sopra nel paragrafo della Notificazione, per rendere obbligatoria e non eludibile questo ultimo adempimento si è previsto un articolato specifico per il rispetto del provvedimento sul Data Breach. Era in realtà previsto da prima con il Dlg.196/03, ma ora è posto alla stregua della Informativa e del Consenso al trattamento.
L’ARTICOLO 17 E IL DIRITTO ALL’OBLIO
La questione tanto dibattuta del diritto all’oblio è apparentemente legata ad uno scontro ideologico della civiltà delle persone come individui nei confronti del cyberspace. In merito all’indiscutibile posizione che sia o meno giusto, esauriamo la discussione dicendo semplicemente che si tratta di una ipocrisia, vissuta in quella linee di confine mai definita tra l’esigenza della tutela del singolo e il diritto di sapere de molti.
Affrontiamo in vece secondo lo spirito molto pratico di questo articolo mirato a capire cosa operativamente comporta l’adozione del Data Protection.
E’ sempre esistito il diritto dell’interessato all’esercizio dell’Art. 7 del Dlg.196/03 per la richiesta di accesso ai propri dati, al loro aggiornamento… Adesso è del tutto esplicito che l’interessato (chiunque) possa rivolgersi ad una organizzazione richiedendo in qualunque momento la completa, definitiva e retrospettica cancellazione dei dati che lo riguardano.
Chi sa’ cosa comporta la gestione di grandi repertori di DataBase, può incorrere in uno svenimento!!! Pensiamo cosa accadrebbe se tutti scrivessero ad una qualunque delle istituzioni pubbliche.
L’ARTICOLO 18 E IL DIRITTO ALLA PORTABILITA’
Non a caso dopo l’oblio (Art.17), troviamo l’articolo successivo relativo alla portabilità
Ci sarebbe un discorso molto articolato, soprattutto di natura giurisprudenziale, ma per farla breve e sempre coerenti con lo spirito riassuntivo di questa pubblicazione, una società deve approntare dimostrabili procedure che attestano come, a fronte della richiesta di cancellazione dagli archivi, è in grado di effettuarla dandone peraltro riscontro in tempi veloci ed in formati standardizzati fruibili secondo portabilità da un Interessato.
La esigenza di standardizzare formati fruibili in risposta alla richiesta di un interessato è finalizzata e finalizzabile alle esigenze di portabilità
Si intende con ciò la facoltà di conservare un proprio record di dati personali spostandolo da un repertorio ad un altro.
Nella migliore delle pochissime policies ufficialmente documentate, i grandi player danno la possibilità di esportare dei dati (CSV,XLM,ASCII o simile), ma con metriche di tracciato record del tutto arbitrarie… Quindi, come sempre è stato nell mondo dei DBs, gli oneri sono sempre dalla parte della struttura recipient. Che equivale a dire, tutti affari dell’ Interessato… Se vuole portarsi via i dati ne faccia quello che crede con chi gli pare.
Di questo, e molte altre cose, potremo solo etologicamente osservare la evoluzione ! Al momento nessuno sa’ cosa potrà realisticamente succedere perchè anche in un mondo come quello del Cloud Computing, di fatto la portabilità è pressocchè mitologia.
continua nella Parte 2
