Guida al GDPR per chi non ne vuol sapere: ma quante carrozze ha questo treno?


Ho appena finito di parlarvi amabilmente degli articoli 1 e 2 del primo capitolo di quell’avvincente romanzo che è il GDPR che già siamo arrivati all’articolo 3, e sembrava solo ieri che stavamo leggendo il titolo….

Beh torniamo quindi a noi.

Articolo 3

L’articolo 3 introduce, in un legalese da paura, l’ambito territoriale di pertinenza del GDPR che, tradotto in italiano, significa dove deve risiedere un soggetto per finire invischiato in tutto questo.

La lettura puntuale dell’articolo è un esercizio semantico interessante e non banale. Come a dire che è scritto in maniera abbastanza incomprensibile.

Cerchiamo di tirare un sospiro e capiamo cosa questo articolo ci porta, perché, purtroppo, è interessante.

Se leggiamo i 3 punti che compongono l’articolo capiamo che il regolamento si applica a coloro che “processano” i dati di persone fisiche residenti in Europa sia che siano in EU o meno. In particolare:

Se sei un soggetto in EU devi rispettare il GDPR anche se fai il trattamento dei dati all’estero, quindi se sei una società con ragione sociale in EU e stai raccogliendo dati di residenti europei ma hai i server in “Cina” o in “USA” devi rispettare il GDPR.

Se non sei un soggetto in EU ma lavori con dati di europei (cittadini o residenti) in Europa allora sei vincolato al GDPR, e non importa se il trattamento ha fini commerciali o meno. Questo significa, ad esempio, che Linkedin o Facebook o Google devono rispettare il GDPR per raccogliere i dati in EU.

La domanda che sicuramente tutti si pongono è: ma allora posso mettere i miei dati su Baidu? E Baidu è vincolato al rispetto del GDPR?

Ora a parte che non è detto che tutti sappiano chi è questo Baidu, il punto è interessante. Leggendo l’articolo 3 mi verrebbe da dire che si, anche Baidu (il Google cinese, vi aiuto) dovrebbe conformarsi. Il punto è, eventualmente, come esercitare il diritto di controllo e quindi le eventuali multe se il soggetto che raccoglie i dati europei risiede completamente al di fuori dell’UE senza avere in UE una rappresentanza legale.

Considerando la natura di Internet la domanda non è peregrina, andare a batter cassa o chieder conto del rispetto delle regole in Cina o USA non è decisamente un esercizio di facile applicazione.

Almeno l’articolo 3 ci definisce il perimetro territoriale cui fare riferimento: se hai a che fare con dati personali di cittadini eo residenti dell’Unione Europea anche se non sei una entità EU dovresti rispettare le regole.

Diciamo, per contro, che se un cittadino europeo va al di fuori dell’unione e lascia i suoi dati a aziende che niente hanno a che fare con l’unione europea non è coperto dal GDPR, il che non ci dovrebbe stupire… In teoria quando siamo, ad esempio, in un paese extra UE dobbiamo seguire le leggi del paese che ci ospita. Ad esempio, se ti mandano andiamo a quel paese, diciamo in UK, e guidi come in Italia poi non stupirti se questi ti dicono che stavi guidando contromano … a meno che guidi regolarmente contromano anche in Italia, allora sei il proprietario della Ford Focus bianca che tutte le mattine mi sorpassa e si fa un paio di km contromano per evitare la coda sulla statale della val Tidone 😊.

Ma torniamo al GDPR che, come al solito, ho divagato. Per finire la comprensione dell’articolo al solito vi suggerisco la lettura dei seguenti “recitals”:

22232425

In particolare ci viene comodo leggere il numero 22

(22) Qualsiasi trattamento di dati personali effettuato nell’ambito delle attività di uno stabilimento di un titolare del trattamento o responsabile del trattamento nel territorio dell’Unione dovrebbe essere conforme al presente regolamento, indipendentemente dal fatto che il trattamento avvenga all’interno dell’Unione. Lo stabilimento implica l’effettivo e reale svolgimento di attività nel quadro di un’organizzazione stabile. A tale riguardo, non è determinante la forma giuridica assunta, sia essa una succursale o una filiale dotata di personalità giuridica.

In cui si specifica al di la di qualsiasi ragionevole dubbio (ma quelli irragionevoli sono sempre accetti) che lo stabilimento (non balneare)

Dopo l’articolo 3 troviamo, incredibile a dirsi:

Articolo 4

Commovente a dirsi, le definizioni di quanto troviamo dopo arrivano con l’articolo 4.

Le varie definizioni possono essere accompagnate da i relativi “recitals” in particolare:

262728293031323334353637, 38, , 424348, 67, 8586868788, 91, 124, 150

Ovviamente i 26 punti fanno riferimento a diversi capitoli, quindi lacune definizione non le abbiamo incontrate ancora ma arriveranno solo dopo.

Attenzione attenzione, sapete cosa c’è dopo l’articolo 4?

Ovvio l’articolo 5 ma sopratutto:

Il capitolo 2, dove si parlerà dei principi su cui si basa il GDPR. 7 articoli che ci definiranno il bi ed il ba

Articolo 5 – Principi applicabili al trattamento di dati personali (39)
Articolo 6 – Liceità del trattamento (4041424344454647484950)
Articolo 7 – Condizioni per il consenso (32334243)
Articolo 8 – Condizioni applicabili al consenso dei minori in relazione ai servizi della società dell’informazione (38)
Articolo 9 – Trattamento di categorie particolari di dati personali (515253545556)
Articolo 10 – Trattamento dei dati personali relativi a condanne penali e reati
Articolo 11 – Trattamento che non richiede l’identificazione (57)

Che dite li dobbiamo vedere tutti uno per uno o possiamo solo saltare la dove ci sono coe interessanti da capire?

Buona lettura…. 😊

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: ma quante carrozze ha questo treno? 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