Informazioni personali

Cerca nel blog

Translate

Visualizzazione post con etichetta European Union. Mostra tutti i post
Visualizzazione post con etichetta European Union. Mostra tutti i post

mercoledì 28 marzo 2018

Guida al GDPR per chi non ne vuol sapere: DPO il responsabile irresponsabile

Lo capisco, leggere il GDPR in inglese è una palla pazzesca…allora affidiamoci alla traduzione italiana …

la idea di tradurre in italiano un testo che deve diventare legge non sarebbe peregrina, ma siccome noi di solito traduciamo le cose con approssimazione assoluta ecco il capovalovoro italiano, DPO (Data Protection Officer) diventa Responsabile Protezione Dati… in barba al significato voluto da chi ha scrittoil GDPR non abbiamo potuto resistere alla ennesima dimostrazione di come con sottile abilità si possa creare confusione anche in ambiti chiarissimi.

Orbene la traduzione italica di DPO deriva da una consuetudine legata all’armonizzazione delle diciture presenti nelle varie leggti precedenti al GDPR con le nuove, la cosa non sarebbe grave se non fosse che il DPO NON è responsabile ne della protezione ne del trattamento dei dati. Secondo il GDPR la responsabilità cade interamente sul Data Controller e sul Data Processor, e al secondo in misura correlata a vincoli di gestione del dato indicati dal Data Controller.

Facciamo quindi uno sforzo di astrazione e esimiamoci dal significato delle parole in italiano.

l’ RPD è il DPO che per ruolo non è responsabilefdella protezione del dato

Lo so è imbarazzante dover negare il significato di un termine italiano (responsabile) ponendolo come termine distintivo di un ruolo che essenziamente non ha responsabilità in merito a quanto descritto dal rimanente acronimo.

Ci troviamo quindi nel curioso stato in cui secondo la legge italiana sulla privacy allineata al GDPR un responsabile della protezione dei dati non è responabile di tle protezione, e se non ci credete oltre me, il testo originale del GDPR fate un salto sul sito del garante http://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/8036793 .

1. Chi è il responsabile della protezione dei dati personali (RPD) e quali sono i suoi compiti?

Il responsabile della protezione dei dati personali (anche conosciuto con la dizione in lingua inglese data protection officer – DPO) è una figura prevista dall’art. 37 del Regolamento (UE) 2016/679. Si tratta di un soggetto designato dal titolare o dal responsabile del trattamento per assolvere a funzioni di supporto e controllo, consultive, formative e informative relativamente all’applicazione del Regolamento medesimo. Coopera con l’Autorità (e proprio per questo, il suo nominativo va comunicato al Garante; v. faq 6) e costituisce il punto di contatto, anche rispetto agli interessati, per le questioni connesse al trattamento dei dati personali (artt. 38 e 39 del Regolamento).

Fantastico l’RDP viene designato dal responsabile da cui ne consegue che il responabile è altro dall’RDP. il sillogismo funziona.

altro discorso poi è a chi serve un DPO, ci sono casi in cui la assegnazione del RDPDPO è obbligatoria, ed altri in cui non lo è. ma considerando la complessità dell’ambito cui il DPORDP lavora sarebbe consigliabile averlo, il GDPR chiede che tale figura sia indipendente ma non che sia un dipendente, ne che sia dedicato solo ad un cliente. è quindi possibile utilizzare servizi di DPORDP esterni che eplichino le funzioni richieste come da indicazione del garante.

Va da se che una figura che deve poter offrire funzioni di supporto e controllo, consultive, formative e informative a questo livello non può essere un junior e quindi il mercato attuale con cifre attorno ai 30k annui identifica come, tanto per cambiare, il mercato italiano non abbia ancora capito cosa sia il GDPR, il DPORDP e non solo.

Una nota finale, visto che in questo giorni ho visto e sentito di tutto, dal fatto che si deve ottenere la “certificazione GDPR”, vi ricordo che al momento in italia non esiste una certificazione per il DPORDP ne esiste in assoluto una certificazione GDPR.

 

sempre dal sito del garante prendo

Sul tema della certificazione inoltre si richiama l’attenzione sul comunicato congiunto, pubblicato sul sito dell’Autorità il 18 luglio 2017 (doc. web n. 6621723), con il quale il Garante e ACCREDIA (l’Ente unico nazionale di accreditamento designato dal Governo italiano) hanno ritenuto necessario sottolineare – al fine di indirizzare correttamente le attività svolte dai soggetti a vario titolo interessati in questo ambito – che «al momento le certificazioni di persone, nonché quelle emesse in materia di privacy o data protection eventualmente rilasciate in Italia, sebbene possano costituire una garanzia e atto di diligenza verso le parti interessate dell’adozione volontaria di un sistema di analisi e controllo dei principi e delle norme di riferimento, a legislazione vigente non possono definirsi “conformi agli artt. 42 e 43 del regolamento 2016/679”, poiché devono ancora essere determinati i “requisiti aggiuntivi” ai fini dell’accreditamento degli organismi di certificazione e i criteri specifici di certificazione».

Si potrebbe obbiettare che sia tardi, ma sicccome siamo in ritardo su tutto siamo allineati alla timeline italiana.

 

ciao

mercoledì 12 luglio 2017

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…. ?

martedì 11 luglio 2017

Guida al GDPR per chi non ne vuol sapere: la vedi la luce in fondo al tunnel? … è il treno!

Vi rendete conto che alla attivazione del GDPR manca meno di un anno vero?

la vedi la luce in fondo al tunnel? … è il treno!

Allora ho provato un paio di giorni fa a spiegarti come leggere ed interpretare il significato di GDPR. Sono assolutamente certo e sicuro che tutto quanto scritto era già chiarissimo ai tuoi occhi, ma tant’è… provare a parlare amabilmente di un argomento tanto ameno non fa mai male.

Dicevo, in chiusura degli sproloqui nell’articolo precedente, che alcune note andavano premesse per meglio capire il testo.

In effetti se partiamo con il piede giusto magari non diventa una lettura amena, ma almeno comprensibile.

Tra le premesse della volta scorsa ne ho omesso volutamente una importantissima, giusto per darmi una scusa per proseguire a scrivere…

Le norme fissate dal GDPR sono il minimo livello di protezione

Le norme fissate dal GDPR sono il minimo livello di protezione richiesta dalla UE, questo significa che ogni stato membro può decidere norme più protettive che si accompagnino al testo.

In Italia l’esempio che balza subito agli occhi riguarda la gestione dei biscotti…er “…cookie” che da sola potrebbe generare una interessante sequenza di noiosissimi articoli ?

La premessa è necessaria non perché abbia qualcosa contro gli Oreo (anche se preferisco i Krumiri o i cantucci toscani) ma perché il primo capitolo di questo affascinante romanzo che ci accingiamo a leggere è le disposizioni generali.

Il documento è diviso in 99 articoli sparsi in 11 capitoli che contengono diverse sezioni. Ovviamente per poter venirne a capo occorre leggerli in maniera “dinamica” perché spesso ci sono referenze avanti e indietro, a destra e a sinistra, sopra sotto e anche in un altro paio di dimensioni a noi invisibili ma chiaramente descritte dalla teoria unificata delle stringhe di cui vi invito a prendere conoscenza (a meno che non indossiate mocassini, sandali e o ciabatte, cosa che vi preclude gran parte della conoscenza umana) …

Per venirne a capo vi giro due link utili:

https://www.suiteprivacy.it/pages/testoregolamentoue.aspx (in italiano)

https://www.privacy-regulation.eu/en/index.htm (in un sacco di lingue tra cui l’italiano, ma ho messo la referenza in inglese perché fa più professionale…vuoi mettere…)

Capitolo Primo

Era una notte buia e tempestosa

 

Il primo capitolo inizia con l’emozionante articolo 1 che ci racconta di cosa si parla nel testo:

Articolo 1

  1. This Regulation lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data.
  2. This Regulation protects fundamental rights and freedoms of natural persons and in particular their right to the protection of personal data.
  3. The free movement of personal data within the Union shall be neither restricted nor prohibited for reasons connected with the protection of natural persons with regard to the processing of personal data.

 

Lo so che in inglese è più sexy, ma se proprio vi difetta la lingua eccolo in linguaggio italico:

 

  1. Il presente regolamento stabilisce norme relative alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché norme relative alla libera circolazione di tali dati.

  2. Il presente regolamento protegge i diritti e le libertà fondamentali delle persone fisiche, in particolare il diritto alla protezione dei dati personali.

  3. La libera circolazione dei dati personali nell’Unione non può essere limitata né vietata per motivi attinenti alla protezione delle persone fisiche con riguardo al trattamento dei dati personali.

Dalla lettura impariamo innanzi tutto che al punto 1 stiamo parlando di persone fisiche in relazione ai dati personali.

La cosa è importante per 2 motivi:

a: le persone giuridiche, le aziende, non sono soggette al GDPR…che tradotto vuol dire che il mio nome e cognome ed il mio indirizzo di casa sono GDPR, il nome della società “Pizza & Fichi INC.” e la sua sede legale non sono oggetto di GDPR

ci può venire incontro alla comprensione il “recital 14” che cita:

(14) È opportuno che la protezione prevista dal presente regolamento si applichi alle persone fisiche, a prescindere dalla nazionalità o dal luogo di residenza, in relazione al trattamento dei loro dati personali. Il presente regolamento non disciplina il trattamento dei dati personali relativi a persone giuridiche, in particolare imprese dotate di personalità giuridica, compresi il nome e la forma della persona giuridica e i suoi dati di contatto.

b: i fantasmi, i personaggi storici e quelli di fantasia non sono soggetto al GDPR (quindi potete condividere liberamente il numero di telefono di Wonder Woman).

Se vogliamo meglio definire cosa significhi il concetto di protezione citato nel punto ci viene incontro il “recital” 1

(1) La protezione delle persone fisiche con riguardo al trattamento dei dati di carattere personale è un diritto fondamentale. L’articolo 8, paragrafo 1, della Carta dei diritti fondamentali dell’Unione europea («Carta») e l’articolo 16, paragrafo 1, del trattato sul funzionamento dell’Unione europea («TFUE») stabiliscono che ogni persona ha diritto alla protezione dei dati di carattere personale che la riguardano.

Al punto 2 troviamo invece l’oggetto di questo esercizio, la protezione delle libertà individuali con il focus sui dati personali.

Il secondo punto è importante perché definisce chiaramente quale ambito va considerato quando consideriamo un rischio all’interno del GDPR.

L’oggetto del regolamento è la protezione dei diritti fondamentali dell’individuo, questo significa che questo è il parametro di rischio da valutare quando si considerano le implementazioni del GDPR …

L’ultimo punto ci ricorda che all’interno della Unione Europea abbiamo conquistato il diritto alla libera circolazione delle persone, delle merci e anche dei dati. Chiaro che se non vi siete mai mossi da Vigevano potreste non apprezzare la cosa, ma tant’è …

Chiaro che se non vi siete mai mossi da Vigevano potreste non apprezzare la cosa, ma tant’è …

Come referenza vi suggerisco anche di leggervi i seguenti “recitals”:

12345678910111213

Articolo 2

 

L’articolo due ci porta in un viaggio esotico in lande inesplorate, ove una brezza leggera ci accarezza e le onde del mare….

Er..credo di essermi un attimo lasciato trasportare, morfeo mi ha catturato… torniamo alla cruda realtà.

L’articolo due ci dice dove viene applicato sto benedetto GDPR.

Il punto uno ci dice dove si applica, gli altri punti dove non si applica.

Ovviamente ci interessa il primo punto…

  1. Il presente regolamento si applica al trattamento interamente o parzialmente automatizzato di dati personali e al trattamento non automatizzato di dati personali contenuti in un archivio o destinati a figurarvi.

Si perché questo punto è fondamentale per capire l’ambito di applicazione, al solito iniziamo dalle parole per vedere se ne traiamo un senso …

Trattamento (Processing)

L’espressione generica indica che si ha a che fare con qualsiasi forma di trattamento eo manipolazione dei dati. Raccolta, archiviazione e lettura rientrano in questa descrizione…. Insomma qualsiasi cosa …

interamente automatizzato

Tradotto vuol dire tutti i sistemi che non richiedono intervento umano alcuno. Si pensi alla raccolta di dati via web per, ad esempio, una newsletter o un sito di marketing. I processi anche se non richiedono intervento umano sono soggetti al GDPR

parzialmente automatizzato

Nel caso vi sia intervento umano (ad esempio raccogli moduli scritti e li immetti in un sistema) il GDPR va comunque applicato. La norma prevede anche la parte umana di gestione, qualsiasi sia la forma. Anche il cartaceo è soggetto a GDPR.

non automatizzato

E qui ci casca l’asino …nel senso che se non lo hai ancora capito anche i tuoi documenti cartacei vanno considerati qui, non ci si scappa. Quindi non è che se pensi d fare il furbo e scrivi tutto su un block notes sei al sicuro…

archivio (originale Filing System)

Non facciamoci ingannare dalla terminologia. La traduzione archivio qui deriva da “Filing System” e non File System. Non parliamo di archiviazione digitale, ma di archiviazione tout court. C’hai presente i bei faldoni che lasci accessibili a chiunque…non puoi più farlo.

Insomma il regolamento si occupa della gestione e processo dei dati personali in qualunque loro forma indipendentemente dalla modalità di processo, archiviazione o raccolta.

Vi lascio l’emozionante esercizio di capire dove non si applica, io già ho faticato su questo.

E non dimenticativi i “recitals” per capire di cosa si parla: 1415161718192021

Ciaooo

 

 

 

 

venerdì 26 maggio 2017

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:

  1. la definizione delle responsabilità all’interno della struttura (ruolo che spetta per definizione al management)
  2. 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)
  3. 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:

  1. si può fare?
  2. 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.

 

 

 

 

venerdì 3 febbraio 2017

Guida al GDPR per chi non ne vuole sapere: devi iniziare, ma cosa devi fare?

Hai già realizzato che tra un anno dovrai essere conforme alle nuove leggi sulla privacy dettate dal GDPR?

Ok Ok ho capito

devi pensare di passare da il tuo:

“chissenfrega della privacy tanto non è una roba di business “

a

“ops se stavolta non faccio le cose per bene rischio una multa fino al 4% sul mio fatturato. maledetto @#][<> GDPR

 

e stai entrando in ansia.

a dire il vero non credo tu lo stia facendo, anzi credo che continui a dire la prima frase come un mantra, ma facciamo finta che tu ti sia reso conto che stai per andare a metterti un un fiume di rogne se non fai qualche cosa, il punto è cosa fare?

Vediamo se ti posso aiutare. Certo, vorrei poterti spiegare cosa sia il GDPR cosa significhi data privacy e data protection, ma siccome so che non sei interessto a capire il perchè ma solo il cosa cercherò di essere il piu elementare possibile.

Passo numero uno, ti serve un DPO

Che cavolo è un DPO?

Il DPO è il tizio che ti dovrebbe aiutare a gestire le richieste derivanti da questo signor GDPR che nessuno, al momento, ti ha ancora presentato ma che sembra sia ansioso di darti multe e prendere i tuoi soldi.

DPO in inglese sarebbe Data Protection Officer, che in italiano puoi tradurre come Responsabile della Protezione dei Dati: ma come non ti bastava dover prendere un IT manager (quando lo hai)?

Ora lo so che tu vorresti chiamare il tuo IT manager e dirgli,

fai te prendi uno dei tuoi e dagli sta sola AGGRATIS

ma, purtroppo, temo non funzioni così.

Il signor GDPR, un perfido europeo insensibile ai tuoi bisogni, ha imposto che questo DPO deve essere un ruolo che gode di una certa indipendenza, e addirittura sembra che l’orientamento sia quello di dire che questo signore è incompatibile col ruolo di IT manager (una ditta tedesca è gia stata sanzionata per questo, ma si sa i tedeschi sono pignoli).

Ti dirò di più un DPO deve avere garantita autonomia per darti le indicazioni su come implementare la conformità alle richieste del signor GDPR  ma tu mantieni la responsabilità delle scelte aziendali, come a dire

  • se lui ti dice di fare “A” e tu invece fai “B” il responsabile sei tu
  • se lui ti dice di fare “B” perché tu gli hai detto che vuoi cosi il responsabile sei tu
  • comunque io responsabile sei tu.

andiamo bene, già sono sicuro che la cosa non ti piace, se ti stava antipatico il signor GDPR ora immagino incominci a detestare anche questo signor DPO, chiunque esso sia.

Voglio essere sincero con te, in Italia si sta ancora discutendo cosa sia un DPO, c’è chi dice un giurista, c’è chi dice sia un informatico,io ti dico è un po di tutti e due… ma in caso sia un giurista specializzato ti costerà di più … sai bene che gli specialisti IT li prendi per un tozzo di pane dal cognato del fratello dell’amico del cognato del salumiere.

Il problema del DPO è che deve spiegarti (non lo invidio) cosa DEVI fare per mettere in sicuro i dati che gestisci e che possono essere soggetti al GDPR. ma questo richiede:

  1. di capire le leggi sulla privacy
  2. di capire come i sistemi di gestione dei dati sono implementati
  3. di capire come funzioni il tuo business
  4. di capire come proteggere i dati in funzione dei tuoi sistemi, del tuo business e delle leggi sulla privacy

Insomma, il DPO dovrebbe essere un manager di provata esperienza cosa che, da sola, è quasi insopportabile, e mettere il naso nelle tue cose.

ora hai diverse scelte:

  1. puoi usare un consulente esterno
  2. puoi assumere o specializzare una persona interna
  3. puoi fregartene (come stai facendo al momento) e rischiare allegramente la multa.

ovviamente i tre punti hanno pro e contro, se usi un esterno devi pagarlo ma puoi cambiarlo se on fa quello che vuoi tu, se usi un interno rischi che no possa fare il suo lavoro precedente, se te ne freghi beh, spera che non ti becchino.

E dopo che hai preso un DPO?

Ora supponiamo che alla fine ti sia messo una mano sul cuore ed una sul portafoglio ed hai scelto l’opzione 1 o 2 (escludo la 3)

che fare?

il primo step da seguire è mettere insieme tutte le teste pensanti della tua azienda, la gente IT ed il DPO e fare 2 cose:

  1. scoprire dove sono i dati soggetti al GDPR e come li gestisci
  2. effettuare una robaccia che si chiama PIA (Privacy Impact Assessment) che vuol dire, basicamente,

questi primi due passi sono importantissimi perchè, diciamocelo chiaro, tu non hai la minima idea di

  • cosa siano i dati,
  • dove siano,
  • come li usi,
  • a cosa ti servono,
  • come li raccogli,
  • come li gestisci ,

La cosa spaventosa è che di sicuro il signor GDPR obbligherà le aziende a farsi carico si una enorme quantità di dati da proteggere.

Cerco di essere chiaro: tutti i dati  che possono essere utilizzati per fare riferimento ad una persona che vive sono dati personali ai sensi GDPR:

  • ID,
  • cookie,
  • indirizzi IP,
  • indirizzi di posta elettronica,
  • ogni identificatore di dispositivo personale
  • i metadati senza identificatore che possono essere afferiti ad una persona
  • ….

Non sai di che parlo? SALLO!!!!

ok ok lo so non ne capisci nulla di sta roba, per questo ti dicono che devi usare un DPO che, in qualche modo, deve essere capace di parlare con te e i tuoi managers e spiegarVi le cose, con l’IT manager e spiegargli le cose, con chi si occupa di sicurezza …..

capire dove siano questi dati, cosa siano non è quindi elementare, ma almeno una volta che lo hai fatto puoi passare al secondo step, la PIA.

No la PIA non è la Paperon Intelligence Agency

Non devi aspettarti che Paperino venga in tuo soccorso. la PIA è uno strumento che ti aiuta a capire i rischi cui sei soggetto gestendo i dati che stai gestendo e che neanche sapevi che stavi gestendo.

la PIA ti serve per capire cosa si rischia e come si protegge. purtroppo la PIA richiede che il tuo DPO, l’IT manager e il responsabile della sicurezza siano in grado di fare queste valutazioni, il che significa, implicitamente, che il cognat del vicino del fratello del salumiere sotto casa a cui fai riferimento come “guru” economico per tutte le tue esigenze IT probabilmente non sarà abbastanza.

Insomma se la PIA alla fine ti dice che sei messo maluccio non ti stupire, anzi stupisciti se ti dice il contrario.

…. e finalmente puoi iniziare a lavorare

una volta che hai DPO, e PIA puoi finalmente iniziare a ragionare su cosa ti serve, aspettati parecchio lavoro in termini di:

  1. come gestisci i tuoi dati
  2. policy e procedure da implementare
  3. tecnologie e, scusa la parolaccia, roba IT che manca o va gestita davvero tipo: backups, databases, sicurezza …

la cosa cattiva è che dovrai lavorarci parecchio

la cosa buona è che potresti scoprire che gestire bene le cose alla fine può anche farti lavorare meglio, anche se probabilmente in maniera diversa da prima.

se vuoi ne parliamo, fammi sapere….

 

 

lunedì 1 febbraio 2016

Privacy Impact Assessment

Privacy Impact Assessment

Privacy impact assessments (PIAs) are tools which can help organizations identify the most effective way to comply with their data protection obligations and meet individuals’ expectations of privacy. An effective PIA will allow organizations to identify and fix problems at an early stage, reducing the associated costs and damage to reputation which might otherwise occur. PIAs are an integral part of taking privacy by design approach.

Key points:

A PIA is a process which assists organizations in identifying and minimizing the privacy risks of new projects or policies.
Conducting a PIA involves working with people within the organization, with partner organizations and with the people affected to identify and reduce privacy risks.
The PIA will help to ensure that potential problems are identified at an early stage, when addressing them will often be simpler and less costly.
Conducting a PIA should benefit organizations by producing better policies and systems and improving the relationship between organizations and individuals.
A privacy impact assessment states what personally identifiable information (PII) is collected and explains how that information is maintained, how it will be protected and how it will be shared.

A PIA should identify:

Whether the information being collected complies with privacy-related legal and regulatory compliance requirements.

The risks and effects of collecting, maintaining and disseminating PII.
Protections and processes for handling information to alleviate any potential privacy risks.
Options and methods for individuals to provide consent for the collection of their PII.
PIAs are not something organizations did a lot (or any) of 15 years ago, although key compliance issues were still considered. Moving from then to now, awareness and significance of data protection has increased. More sophisticated technology has enabled more sophisticated data processing, on a greater scale, and in more intrusive ways. Not addressing the risks may cause damage or distress to individuals, low take-up of a project by customers, damage to relationships and reputation, and time and costs in fixing errors (as well as penalties for non-compliance). A project may partly or wholly fail. These are some of the drivers for carrying out PIAs, and for them to become a new legal requirement under EU data protection law.

Existing PIA frameworks

In the UK, the Information Commissioner’s Office has promoted PIAs for a number of years, although the Data Protection Act 1998 does not require PIAs to be carried out. The ICO published a PIA Handbook in 2007, which was replaced in 2014 by a more up-to-date PIA Code of Practice. Some sectors have additional PIA requirements or guidance. For example, government departments were required to adopt PIAs following a data handling review by the Cabinet Office in 2008. PIAs and PIA methodologies are also promoted in many other countries around the world.

A lot of organizations have therefore already integrated PIAs into project and risk management procedures, following existing recommendations and guidance. Other organizations may not yet be so familiar with PIAs, as they are not yet compulsory for most sectors.

Either way, EU organizations will need to adopt new PIA procedures, or review and adapt existing procedures, in order to meet the new requirements.

New legal requirement under the GDPR

The compromise text of the EU General Data Protection Regulation (GDPR) was published on 15 December 2015. At the time of writing, it is expected to have final approval soon, and then come in force in early 2018. Article 33(1) contains the new obligation for conducting impact assessments:

‘Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk for the rights and freedoms of individuals, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data…’

As the GDPR is a data protection law, the requirement is for a data protection impact assessment (DPIA). This applies to the processing of personal data recorded in electronic or paper-based format. There may also be privacy issues associated with non-personal information, for example communications data or information about corporate entities; and relevant legal requirements include communications laws, direct marketing rules and confidentiality requirements. Wider privacy issues can also arise from, for example, surveillance, bodily testing or searching, which may also trigger human rights and other privacy laws. Often these matters go hand-in-hand with data protection issues, as personal data is recorded as a result of the relevant activities, but separate privacy concerns can also arise. Therefore, whilst this article focuses on data protection impact assessments under the GDPR, PIAs may also address wider privacy risks.

When a DPIA will need to be carried out

Article 33 requires a DPIA to be carried out where processing is ‘likely to result in a high risk’. Article 33(2) contains a list of cases where DPIAs shall, in particular, be carried out:

‘(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the individual or similarly significantly affect the individual;
(b) processing on a large scale of special categories of data referred to in Article 9(1), or of data relating to criminal convictions and offences referred to in Article 9a;
(c) a systematic monitoring of a publicly accessible area on a large scale.’
The first of these would capture many data analysis activities, for example where an evaluation of a person’s characteristics or behaviors impacts the services they may receive or how they are treated. The definition of ‘profiling’ lists performance at work, economic situation, health, personal preferences, interests, reliability, behavior, location and movements as matters which may be analyzed or predicted.

Large-scale use of sensitive types of data is captured by (b). As well as the existing categories of sensitive personal data under the DPA, this now captures genetic and biometric data.

Thirdly, large-scale public monitoring would require a DPIA, which may include use of CCTV, drones or body-worn devices.

In addition, under Articles 33(2a) and 33(2b), the supervisory authority (the ICO in the UK) shall establish a list of the kind of processing operations where a DPIA is required and may establish a list of processing operations where no DPIA is required.

The lists are subject to (where appropriate) co-operation with other EU supervisory authorities and the EU Commission, and must take into account opinions of the (new) European Data Protection Board.

Article 33 requires the DPIA to be carried out ‘prior to the processing’; in other words, prior to starting the relevant activities. A post-implementation review would be too late (although may still be of benefit if a DPIA was not undertaken previously).

Organizations will therefore need to identify whether projects or activities which arise fall within a category described above or may otherwise result in a high risk. Even within organizations which do not regularly carry out high-risk data processing, changes to existing activities can turn previously low risks into high ones. For example, adopting new technology to assist with an established business procedure can affect how personal data is used.

Identifying the need for a DPIA is commonly achieved by an initial assessment during project planning (as is also recommended within the ICO’s PIA Code of Practice). At that stage, business teams can identify intended uses of personal data and assess potential data protection risks. The outcome determines whether or not to proceed further with a DPIA.

Of course, even if an initial assessment does not determine a high risk or trigger specific DPIA requirements under the GDPR, organizations may wish to continue with an assessment to address lower data protection risks and ensure compliance.

Exception to the DPIA requirement

Article 33(5) contains a potential exception for regulated activities carried out pursuant to a legal obligation or public interest. The controller may not be required to carry out a DPIA if one has already been carried out as part of setting the legal basis for those activities. Recital 71 refers to activities of doctors and attorneys in using health and client data – it is unclear whether this is touching on the same point – it seems to indicate that such processing activities shall not be considered as being on a ‘large scale’ rather than being a specific exception.

Procedure for carrying out a DPIA

Article 33(1a) provides that the controller shall seek the advice of the data protection officer, where designated (in accordance with Article 35), when carrying out a DPIA.

Article 33(3) provides that the DPIA shall contain at least:

‘(a) a systematic description of the envisaged processing operations and the purposes of the processing, including where applicable the legitimate interest pursued by the controller;
(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
(c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1;
(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.’
These steps are comparable to those within the ICO’s PIA Code of Practice, which is useful in considering what they might mean in practice.

Firstly, an organization must describe the proposed flows of information involved in the activity or project, ensuring it is clear how and why personal data is being used at each stage. Diagrams as well as written descriptions can be useful to convey this.

Secondly, an organization must assess whether the proposed use is of data necessary and proportionate to its legitimate purposes; for example, are there alternative ways to achieve the same project objectives?

Next it is clear that a DPIA involves a risk assessment. This involves considering the potential impacts of proposed activities on the relevant individuals and the organization, and the likelihood of such impacts arising. Impacts may include, for example, loss or misuse of data, intrusion into private lives, lack of transparency and non-compliance. Solutions must then be found to avoid or mitigate risks and demonstrate compliance. These may include introducing additional elements into the project (such as anonymisation, pseudonymisation or security measures), or changing aspects of the project (such as collecting less data or doing fewer processing operations).

Organizations may use risk assessment methodologies already in place for other legal or organizational risks, or may create tailored risk assessments for the purpose of DPIA procedures.

Article 33(3a) provides that compliance with approved codes of conduct shall be taken into account in assessing data protection impacts. Codes of conduct relating to different sectors or types of activity may be approved under Article 38.

Consultation with data subjects

Article 33(4) requires controllers, ‘where appropriate’ to ‘seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of the processing operations’.

This means consulting with those whose privacy is affected by the proposed activities, as it is these privacy risks that the DPIA is seeking to address. However, it may not always be appropriate to do this, for example when protecting overriding interests to keep aspects of the proposed project confidential. Public sector organizations, in particular, may already have formal consultation processes, and the ICO’s PIA Code of Practice also gives guidance on consultation, but this may be a new consideration for some organizations.

Data processors

Article 26(2) sets out requirements for the terms of contracts between data controllers and data processors (which are more detailed than the current requirements under the DPA). These include that the processor shall assist the controller in ensuring compliance with requirements for DPIAs.

The processor’s role may be particularly important, for example, where it is providing technology central to the relevant project, as it will be in the best position to identify and address privacy and security risks relating to its own technology.

Consultation with supervisory authorities

Article 34 contains a procedure for consultation with the supervisory authority (the ICO in the UK) as a result of (or potentially as part of) a DPIA. Recital 74 indicates the intention for consultation where the controller considers that high risks cannot be mitigated by reasonable means. However, Article 34 states that consultation is required where the processing would result in a high risk in the absence of mitigating measures. As DPIAs are required only for high-risk activities, this could mean consultation is always needed following required DPIAs. Further clarity on the intended interpretation would therefore be useful, as it is likely to have a big impact on timetables and resources for controllers and the ICO.

As part of the consultation, the supervisory authority must give advice to the controller where it is of the opinion that the intended activities would not comply with the GDPR. If appropriate mitigating measures have been established, therefore, perhaps no further action is required. Advice must generally be given within eight weeks although this may be extended in complex circumstances. The authority may also use its other powers (eg to investigate further or order compliance).

The ICO already provides support to organizations which wish to consult on data protection matters, but the GDPR will require a more formal process and resources for DPIA consultation. For controllers, consultation could assist in finding solutions, though it could also delay or restrict projects.

Post-implementation reviews

Article 33(8) provides:

‘Where necessary, the controller shall carry out a review to assess if the processing of personal data is performed in compliance with the data protection impact assessment at least when there is a change of the risk represented by the processing operations.’

Regular post-implementation reviews or audits can be used to assess whether the risks have changed, and ensure the solutions identified during the DPIA have been and continue to be adopted appropriately.

Data protection by design and by default

Article 23 contains general requirements for data protection by design and by default. These mean that measures designed to address the data protection principles should be implemented into processing activities, and that the default position should be to limit the amount of data used and the processing activities to those which are necessary for the relevant purposes. Carrying out DPIAs, even where particularly high risks have not been identified, may be a good way to demonstrate these matters are being addressed.

EU Directive for the police and criminal justice sector

The GDPR has been prepared alongside the new Data Protection Directive for the police and criminal justice sector, which will separately need to be implemented into UK law. Articles 25a and 26 of the Directive contain requirements similar to those in the GDPR in relation to DPIAs and consultation with the supervisory authority.

What to do now

DPIAs will not become a legal requirement under the GDPR for a couple of years yet. However, there are benefits in starting (or continuing) now to build DPIA (or PIA) processes into existing project and risk management procedures. As well as the existing advantages of DPIAs, this will enable them to be part of business as usual when the new law arrives. In addition, DPIAs conducted now will ensure that high-risk data processing activities in existence when the GDPR takes effect will have had the prior assessment envisaged by the new requirements.

It is, of course, still early days in working out how the detail of the provisions discussed above will be interpreted in practice, and we can expect further guidance at UK and EU level (including the required lists of activities which will require a DPIA). Existing PIA guidance, such as within the ICO’s Code of Practice, should help organizations to get on track, and procedures can be refined further as we get more clarity on the specific GDPR requirements.

sabato 2 marzo 2013

Cloud Security Alliance Releases First Guidelines for Cloud Service Providers Delivering Services in the European Union : Cloud Security Alliance

Cloud Security Alliance Releases First Guidelines for Cloud Service Providers Delivering Services in the European Union : Cloud Security Alliance

CLOUD SECURITY ALLIANCE RELEASES FIRST GUIDELINES FOR CLOUD SERVICE PROVIDERS DELIVERING SERVICES IN THE EUROPEAN UNION 

CSA Privacy Level Working Group Encourages Adoption Worldwide as a Powerful Self-regulatory Tool for Data Protection Transparency and accountability in the Cloud

RSA CONFERENCE –  San Francisco, CA – February 25, 2013 – The Cloud Security Alliance (CSA) Privacy Level Agreement (PLA) Working Group today released the Privacy Level Agreement (PLA) Outline for Cloud Service Providers providing services in the European Union. The Outline provides a structure for Cloud Service Providers (CSP) to disclose, in a consistent matter, information about the privacy and data protection policies, procedures and practices used when processing personal data that customers upload or store in the CSP’s servers. Once a PLA outline is completed by a CSP, it will provide current and potential customers with a new tool to assess that CSP’s disclosure of its practices.