Guida al GDPR per chi non ne vuol sapere: e se provate a leggerlo il GDPR vi cala la palpebra?

 

Domanda: Che vuol dire GDPR?

 

Se otteniamo questo tipo di risposte:

• Grandiosa Donazione Per Riluttanti?
• Geniale Dono Per Repubblicani?
• Generosa Dotazione Per Remittenti?
• …

Allora abbiamo un piccolo problemino.

 

GDPR significa

General Data Protection Regulation

 

Allora proviamo a capirci:

almeno cosa significhi l’acronimo (che non richiede acredine nella lettura) dovrebbe essere assodato.

Insomma, ma lo avete sfogliato?

Se davvero volete implementarlo sto benedetto GDPR dovreste almeno provare a leggerlo, ma, vi assicuro, è una lettura non proprio amena.

Mettiamola così, se riuscite a non addormentarvi dopo la prima pagina siete già a buon punto, ma dopo averlo letto senza abbandonarvi tra le braccia di Morfeo (no non è il nome di un immigrato), viene il compito difficile: capirlo.

E si perché oltre ad essere una lettura non proprio divertente occorre anche capire che cavolo significhi tutta quella roba scritta in un legalese europeo.

Vediamo se ancora una volta, nel mio piccolo, riesco a darti una mano.

Iniziamo dal titolo:

General Data Protection Regulation.

General

Indica che si tratta di qualcosa di comprensivo, non nel senso che vi capisce, ma nel senso che comprende un sacco di cose.

Data

Ben lungi dall’essere Data il “robot umanoide” che in Start Trek Next Generation fungeva da ufficiale scientifico al servizio del comandante Picard, qui per data si intende, semplicemente, “i dati”.

Protection

Qui il termine fa riferimento alla protezione in senso lato delle risorse citate al termine precedente.

Il che significa che, utilizzando quanto appreso fino ad ora, stiamo parlando di un qualcosa che parla in maniera comprensiva della protezione dei dati.

Regulation

L’ultimo termine è Regulation. Questo termine merita un attimo più di attenzione, dal momento che è un termine specifico.

Directive Vs. Regulation

Ovviamente da buoni cittadini europei avete ben chiara la differenza tra Directive e Regulation. Fa parte della base minima di conoscenza civica che ognuno di noi dovrebbe avere (sono buono, non vi chiedo la differenza tra legge quadro e decreto legislativo).

Siccome io sono malfidente per definizione, mi permetto di supporre che non tutti abbiano chiaro la differenza tra “Directive” e “Regulation” e quindi provo a spiegarla.

Chiedo già scusa a giudici ed avvocati, legulei assortiti e giuristi vari per il linguaggio non proprio tecnico, ma lo scopo che mi propongo è quello di far capire le cose, non scrivere in “gergo” diventa quindi un obbligo.

Regulation

Quando ci troviamo di fronte a questa roba ci troviamo di fronte a una “legge” Europea che diventa parte integrante delle leggi di tutti gli stati membri.

In presenza di una “Regulation” gli stati membri non sono chiamati a legiferare. Il testo così come è (eventualmente tradotto nella lingua del paese) diventa parte integrante del suo corpo giuridico. Questo significa che vincoli, multe, azioni e altre cose alla legge collegate indicate nel testo sono immediatamente attuate nel momento in cui la “Regulation” diventa “attiva”

Come a dire dal 25 Maggio 2018 ti potresti aspettare un controllo e se non in regola ti potresti vedere comminata una multa pari al 4% del tuo giro d’affari… io ci starei attento…

Directive

Se la Regulation è un atto legislativo che entra immediatamente nel corpo giuridico del paese “cosi come è”, una direttiva (come quella che era in vigore prima del GDPR, la “Directive 95/46/EC” del 1995) è invece uno strumento tramite cui la UE setta gli obiettivi che ogni stato deve implementare attraverso la introduzione di leggi locali che devono regolare la materia in oggetto della “Directive”

La principale differenza tra le due è che in caso di “Regulation” tutti i paesi membri dell’UE si trovano di fronte ad una legislazione omogenea in termini di obiettivi, adempimenti e struttura, mentre nel caso della “Directive” è dato al singolo stato la potestà legislativa per legiferare in merito agli obiettivi definiti. Va da se che, anche se alla fine l’obiettivo deve essere raggiunto in maniera il più possibile omogenea tra i vari membri, la reale modalità di raggiungimento può variare sensibilmente da stato a stato in caso di “Directive”.

Il fatto che una “Regulation” entri in vigore cosi come è stata emanata dagli organismi UE non significa, in realtà, che lo stato che la applica non deve legiferare in alcun modo…alcune attività accessorie possono essere richieste per adeguare il corpus legislativo alla “Regulation” in maniera che questa sia applicabile. Attenzione che questo potrebbe erroneamente portare a pensare che la “Regulation” non sia quindi in vigore, sbagliato… funziona anche se ne mancano i pezzi accessori, non si scappa questa parte il prossimo anno volenti o nolenti.

Fatto questo doveroso cappellino introduttivo siamo ora in grado di leggere il titolo.

GDPR significa:

 

Legge EU comprensiva e vincolante sulla protezione dei dati

Bene abbiamo passato il primo scoglio nella lettura del documento. Adesso manca tutto il resto, ma si sa chi ben comincia è a metà dell’opera.

GDPR un po di chiarimenti prima di leggere

Visto che siamo riusciti a leggere il titolo (bravi bravi) è meglio fissarci in testa un paio di cose prima di proseguire la lettura, giusto per essere in grado di interpretare quel misterioso testo.

• se non lo sai sallo

la prima cosa che dobbiamo metterci in testa è che il testo non è scritto per novizi o principianti, sta a noi andare a recuperare e capire le referenze nel testo. una cosa importante è ricordarsi che il GDPR è l’evoluzione della direttiva sulla privacy del 95, e quindi dobbiamo aspettarci almeno una somiglianza nella nomenclatura ed alcune assunzioni del tipo…questo è evidente era già presente nella legislazione precedente.

• non aspettarti il dettaglio tecnico

NOn troverete nel testo un dettaglio o un manuale di istruzioni modello Ikea. purtroppo la norma va interpretata, molti dei riferimenti fatti in merito alle implementazioni IT ad esempio parlano di misure “adeguate” senza il dettaglio che vorresti vedere. Temo che questo significhi che tu hai una certa responsabilità implementativa che richiede anche di fare scelte consapevoli ed informate. Intendiamoci la cosa è voluta per rendere la norma attuabile ad un mondo tecnologico in continua evoluzione. Ma non pensare per un momento che questa indeterminatezza ti autorizzi ad usare sistemi operativi obsoleti tipo Windows Millenium o robe del genere, fallo e poi prova a dimostrare che hai messo in piedi misure “ragionevoli” di protezione.

• Anche se sei piccolo devi seguire le regole

Non importa quale che sia la tua dimensione, le regole vanno seguite da tutti. Ognuno avrà l’obbligo di implementare le misure adatte in maniera “ragionevole” e confacente alle proprie possibilità. tradotto questo significa che non puoi fare finta di niente e relegare, ad esempio, l’it ad un retropensiero… sempio: i backup li devi fare e devono funzionare e lo devi poter provare…preparati.

• Vale ‘inversione dell’onere della prova: sei colpevole fino a che non provi la tua innocenza

Ebbene secondo il GDPR sei tu che devi dimostrare di essere allineato ai dettami di legge. Il non essere in grado di farlo è già di per sé una ammissione di colpa. Chi ti viene a controllare (il garante in Italia? vedremo) ti chiede di dimostrargli che hai fatto le cose bene, non è li che deve cercare il fatto che non lo hai fatto. Questo è esplicitamente detto nel testo e più volte rinforzato come quando si specifica chiaramente che il rischio residuo se troppo grande deve essere concordato con l’autorità di riferimento.

• Il rischio di cui ti devi preoccupare è al di fuori della azienda, questo cambia i parametri della valutazione.

Quando nel testo si parla di rischio deve essere chiaro che il rischio è che si danneggi la libertà dell’individuo a cui i dati sono correlati. in altre parole non devi valutare solo quanto sia facile che ti buchino la rete o ti rubino i faldoni con i dati, ma anche che può accedere se quei dati vengono usati male nei confronti del soggetto a cui sono riferiti.

• Le multe non sono una per tutto, sono multe su punti specifici. E rimane poi il danno arrecato a terzi

qui mi sembra che molti non abbiano chiaro il fatto che la struttura delle multe del GDPR non ti garantisce di prenderne solo una che copra tutte le inadempienze. Rischi di beccartene piu di una se sei una multinazionale o se sei beccato con le mani nella marmellata in più aree… ed in ogni caso le multe fanno riferimento alla non attuazione della normativa, ma non coprono i danni procurati alle persone a cui i dati sono riferiti, e le eventuali cause civili eo penali associate.

• I soggetti non sono solo i tuoi clienti

Il GDPR fa riferimento ai cittadini e residenti in UE. in questa categoria rientrano non solo i tuoi clienti,ma i tuoi contatti di marketing, i tuoi fornitori ed anche i tuoi dipendenti.

 

beh che dite abbiamo fatto abbastanza premesse? se si buona lettura:

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

ciaooooo

a

 

Related articles

• UK firms ‘failing to prepare’ for regulation changes after Brexit (telegraph.co.uk)
• EU Proposals Could Force Vendors to Release Stored Data (cmswire.com)
• Queen’s Speech: Here Are The Government’s Tech Plans For The Next Two Years (gizmodo.co.uk)
• GDPR: Are you prepared? (helpnetsecurity.com)
• Low GDPR preparedness represents revenue threat (helpnetsecurity.com)
• GDPR and the technology market | The Puchi Herald Magazine (thepuchiherald.com)
• Are you ready for the EU GDPR? (helpnetsecurity.com)

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Guida al GDPR per chi non ne vuol sapere: e se provate a leggerlo il GDPR vi cala la palpebra? was originally published on The Puchi Herald Magazine

Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio 😊

Ma se ti dico “rischio” tu che mi rispondi?

Er… no non intendo la sequela di insulti o le minacce più o meno velate a cu stai quasi sicuramente pensando, stavo cercando di parlare di GDPR…

No, no, GDPR non è una parolaccia, calmiamoci.

Insomma volevo solo chiedere che cosa associate alla idea di rischio indicata dal GDPR.

Ne parlo qui perché ultimamente ho avuto modo di vedere come molti non hanno bene chiaro cosa sia questo fantomatico rischio di cui si parla.

Allora cerchiamo di fare un poco di chiarezza ad un livello che persino io possa capire di cosa stiamo parlando, quindi estremamente basso.

Genericamente quando parliamo di rischio facciamo riferimento alla eventualità di subire un danno (più incerto di quello implicito in pericolo).

In termini estremamente generici questo significa dover analizzare una serie di cose associate ad un evento che comporti rischi:

• la prima è: chi subisce il danno
• la seconda è: l’entità del danno
• la terza è: la probabilità che l’evento si possa verificare.

Il primo punto è fondamentale, i quanto il soggettooggetto del rischio determina pesantemente le altre due occorrenze sia in termini di valutazione quantitativa che qualitativa e quindi guida le scelte rivolte a ridurre, mitigare il rischio, trasferirlo o comunque gestirlo in toto o la sua parte residua.

Il secondo punto afferisce alla entità del danno. A seconda del tipo di rischio che stiamo analizzando l’entità viene solitamente parametrizzata attraverso valori di facile lettura, come ad esempio la perdita economica associata.

Il terzo punto va ovviamente ad indirizzare la esigenza di calcolare quante possibilità ci siano che l’evento infausto che causa il danno possa accadere. Laddove ci fosse la certezza non si parlerebbe di rischio e quindi le analisi di cui sopra sarebbero inutili e parleremmo, semplicemente, di pericolo.

L’analisi del rischio ci consente di mettere in atto quelle procedure e comportamenti che possano minimizzare gli effetti dannosi. Questo può essere effettuato attraverso diverse scelte NON mutuamente esclusive tra di loro.

Ad esempio:

• Si può scegliere di indirizzare gli sforzi in direzione dell’abbassamento dell’entità del danno subito in caso di evento infausto
• Si può scegliere altrimenti di indirizzare gli sforzi in direzione dell’abbassamento della probabilità che l’evento infausto possa accadere.

Potrebbe accadere che uno specifico evento si possa semplicemente eliminare dalla nostra tabella dei rischi a seguito delle azioni intraprese ma più spesso accade che i costi per l’eliminazione del rischio siano così alti che conviene invece accettare un rischio residuale.

Le azioni per abbassare il rischio possono essere ad esempio di mitigazione (vedi i due punti precedenti) o di trasferimento.

La soglia di accettabilità del rischio dipende ovviamente da valutazioni soggettive e oggettive e dipende dall’ambito di cui stiamo parlando.

Non esiste azione umana che sia esente dal rischio, ma la percezione e l’accettazione del rischio dipende ovviamente dal dominio cui stiamo facendo riferimento.

Ok ok ti sei annoiato con cose che sai benissimo meglio di me, anche se non sai di saperle (dopotutto tutti attraversano la strada e quindi gestiscono rischi….)

Torniamo al GDPR.

Il rischio in termini di GDPR è il rischio di danneggiare la privacy e le libertà fondamentali di un soggetto.

Usando i tre punti di cui si parlava all’inizio del mio sproloquio potremmo dire che:

chi subisce il danno è l’utenteutenti i cui dati personali vengono in qualche maniera indirizzati dall’evento in analisi (copia, cancellazione, modifica e via dicendo)

l’entità del danno è quanto l’utente possa essere danneggiato dall’evento specifico ed è, ovviamente, legato alla natura dei dati in oggetto e a quello che a questi dati è accaduto.

La probabilità che l’evento infausto possa accadere è invece legata ai processi in uso per la gestione dei dati raccolti.

Non facciamo i soliti errori per favore:

Innanzi tutto per poter implementare correttamente il GDPR occorre fare una valutazione del rischio implicito nella gestione dei dati personali, utilizzando come riferimento quello descritto sopra.

Chi deve fare queste valutazioni è chi si occupa di questa cosa. In ultima analisi spetta al responsabile dell’azienda utilizzando il DPO quando presente come fonte autorevole di indicazioni in merito.

Spetta al responsabile aziendale o “data controller” quindi decidere:

• quale sia il rischio residuo accettabile
• quale siano le azioni da intraprendere per mitigare, minimizzare i rischi legai al GDPR.

Questa cosa è di fondamentale importanza da capire. Nella nomenclatura del GDPR il Data controller o responsabile della gestione dei dati personali è la fonte delle decisioni. Il o i data processor pur condividendo una responsabilità operativa nella gestione della sicurezza del dato non sono responsabili delle scelte operate per proteggerli come tali.

Come a dire che non sta alle strutture IT decidere cosa fare, al più all’IT possono essere demandate le scelte implementative, una volta individuata la via di mitigazione che il “data Controller” ritiene più adatta ad abbassare la soglia di rischio fino ad un livello di rischio residuale accettabile, laddove queste richiedano una opzione tecnologica e non di processo.

Questa osservazione implica la comprensione di una cosa non sempre chiara in chi si occupa di GDPR:

il rischio in termini di GDPR è cosa diversa dal rischio di Business o dal rischio di Cyber Security.

Mescolare questi 3 domini assieme senza avere chiara a distinzione tra i 3 tipi di rischio comporta semplicemente l’indirizzamento verso scelte errate in quanto:

o non indirizzano la natura del rischio in oggetto (e quindi rappresentano una duplice voce di costo in termini di spese effettuate inutilmente e di rischio ancora presente)

o non mitigano correttamente tale rischio entro la soglia di accettabilità (rischio residuo accettabile).

o portano a scelte non ottimali e quindi più costose rispetto il necessario.

Purtroppo la non esatta comprensione del GDPR sta portando molte aziende a vedere la cosa solo in termini meramente tecnologici, associando il rischio GDPR al rischio tipico della Cyber Security. Questo rischia di far intraprendere alle aziende percorsi errati o eccessivamente onerosi.

Ma che differenza c’è?

Per capire la differenza tra un rischio di cyber security, di business e di uno legato al GDPR occorre pensare attentamente alla natura intrinseca del rischio in senso del GDPR.

Il GDPR si preoccupa delle libertà fondamentali dell’individuo espresse attraverso la difesa della sua “privacy”.

Ora prendiamo un paio di eventi esemplificativi dei domini di Cyber Security: DoS (Denial of Service) e attacco Ransmomware.

L’attacco  dDos

In caso di attacco DoSdDoS che blocchi una struttura, siamo in presenza di un evento dannoso che potrebbe impattare il business di una azienda nel caso colpisca, ad esempio, una interfaccia di e-commerce o una di mera presenza marketing online.

Dal punto di vista del business a seconda della interfaccia impattata le valutazioni di rischio potrebbero essere diverse ma potremmo dire che, se siamo in presenza di un attacco su di una interfaccia di E-commerce l’impatto (ed il rischio) è alto mentre in caso di una interfaccia di puro marketing potrebbe essere di medio livello

Dal punto di vista meramente Cyber, un attacco Dos è tanto più grave quanto maggiore sia la probabilità che esso avvenga e che impatti diverse strutture. In caso di un attacco ad un servizio online di E-commerce siamo in presenza di tutti gli elementi per definirlo un rischio elevato (probabilità, impatto, facilità di attacco….), ma la stessa analisi vale per un sito marketing. Dal punto di vista cyber quindi abbiamo valutazioni discordanti rispetto a quello di business.

Ora se ci mettiamo nei panni del GDPR in entrambi casi il rischio di esposizione dei dati dell’utente sono minimi o nulli, dono quindi in entrambi i casi eventi di basso rischio in termini di GDPR che potrebbero quindi essere considerati accettabili in termini in di rischio residuale.

 

L’attacco Ramsonware

Ricordate wannacy? Giusto per nominare l’ultimo?

In caso di business gli effetti di un ransomware che attacchi, ad esempio, le strutture di billing potrebbero essere disastrose, mentre l’attacco ad una serie limitata di PC potrebbe essere ininfluente.

Dal punto di vista Cyber invece la probabilità di attacco ad un terminale di un utente è più alta, e potenzialmente potrebbe dare adito ad attacchi diffusi interni, ne consegue che dal punto di vista cyber ci si potrebbe attendere addirittura una valutazione più alta di rischio sul pc dell’utente che sul sistema di billing.

Dal punto di vista del GDPR se sono in piedi processi che consentano il recupero dei dati in tempi accettabili (non è richiesta la immediatezza) un ransomware presenta un livello di rischio medio ed addirittura basso nel caso di un sistema di billing che tenga le anagrafiche separate (e quindi non impattate dall’attacco cui stiamo facendo riferimento nell’esempio.

 

È interessante notare che data la diversa natura del rischio anche le azioni di mitigazione da intraprendere sono diverse nei due casi a seconda del tipo di rischio di cui parliamo.

Nel caso del ransomware, ad esempio, dal punto di vista del GDPR potrebbe essere sufficiente una buona struttura di backup isolata dal sistema, mentre nel caso di business la business continuity richiederebbe una serie ben diversa di sforzi implementativi.

Mescolare e fare confusione non è una buona strada da seguire.

Fare confusione sui diversi domini di rischio, anche se afferenti ad un medesimo evento, può portare a scelte non corrette di mitigazione eo trasferimento.

Se questo è vero in generale, nel caso del GDPR assume un significato ancora più grande in quanto occorre capire che il soggetto a rischio è esterno alla azienda e quindi le azioni da intraprendere sono concettualmente diverse.

Non definire sin dall’inizio le responsabilità e modello di calcolo del rischio comporta scelte, nella migliore delle ipotesi, sbagliate.

 

Meditate gente meditate

Ciao

Antonio

 

 

 

 

 

 

var aid = '6055',
    v = 'qGrn%2BlT8rPs5CstTgaa8EA%3D%3D',
    credomain = 'adkengage.com',
    ru = 'http://www.thepuchiherald.com/wp-admin/post.php';
document.write('');

Guida al GDPR per chi non ne vuol sapere: raschia raschia rimane il rischio 😊 was originally published on The Puchi Herald Magazine