Sul portale iCLHUB ho pubblicato un semplice software programmato on Excel per determinare se la vostra organizzazione deve tenere e aggiornare il registro dei trattamenti a norma del GDPR.
Il file è disponibile per il dowload cliccando QUI.
È iniziato il processo di cambiamento del Codice privacy
È iniziato il processo di cambiamento del Codice privacy.
Solo pochi giorni fa il Parlamento delegava il Governo a emanare atti normativi per modificare il nostro Codice privacy, al fine di allinearlo alle disposizioni del GDPR che, come ben sappiamo o dovremmo sapere, è già in vigore e diventerà applicabile tra meno di sei mesi.
Nel frattempo, lo stesso Parlamento si è dato da fare per apportare le prime modifiche attraverso una legge: lunedì 27 novembre, infatti, è stata pubblicata sulla Gazzetta Ufficiale la Legge n° 167, del 20 novembre u.s, recante disposizioni per l’adempimento degli obblighi derivanti dall’appartenenza dell’Italia all’Unione europea – Legge europea 2017 (GU Serie Generale n° 277 del 27/11/2017). La legge entrerà in vigore il prossimo 12 dicembre.
Tralasciando il fatto che mi sembra incomprensibile delegare il Governo e poi agire direttamente (cfr. L 163/2017, art. 13, in particolare il co. 3, lett. b)), andiamo a vedere cosa è effettivamente cambiato e proviamo a determinarne gli effetti concreti.
Al codice in materia di protezione dei dati personali sono state apportate due importanti modifiche.
All’articolo 29 (Responsabile del trattamento), dopo il comma 4 è stato inserito il 4-bis:
“Fermo restando quanto previsto ai commi 1, 2, 3 e 4, il titolare può avvalersi, per il trattamento di dati, anche sensibili, di soggetti pubblici o privati che, in qualità di responsabili del trattamento, forniscano le garanzie di cui al comma 2. I titolari stipulano con i predetti responsabili atti giuridici in forma scritta, che specificano la finalità perseguita, la tipologia dei dati, la durata del trattamento, gli obblighi e i diritti del responsabile del trattamento e le modalità di trattamento; i predetti atti sono adottati in conformità a schemi tipo predisposti dal Garante”.
Sempre all’art. 29, il comma 5 è stato sostituito dal seguente:
“Il responsabile effettua il trattamento attenendosi alle condizioni stabilite ai sensi del comma 4-bis e alle istruzioni impartite dal titolare, il quale, anche tramite verifiche periodiche, vigila sulla puntuale osservanza delle disposizioni di cui al comma 2, delle proprie istruzioni e di quanto stabilito negli atti di cui al comma 4-bis”.
Infine, dopo l’articolo 110 è stato aggiunto il 110-bis. (Riutilizzo dei dati per finalità di ricerca scientifica o per scopi statistici), che recita:
“1. Nell’ambito delle finalità di ricerca scientifica ovvero per scopi statistici può essere autorizzato dal Garante il riutilizzo dei dati, anche sensibili, ad esclusione di quelli genetici, a condizione che siano adottate forme preventive di minimizzazione e di anonimizzazione dei dati ritenute idonee a tutela degli interessati.
2. Il Garante comunica la decisione adottata sulla richiesta di autorizzazione entro quarantacinque giorni, decorsi i quali la mancata pronuncia equivale a rigetto. Con il provvedimento di autorizzazione o anche successivamente, sulla base di eventuali verifiche, il Garante stabilisce le condizioni e le misure necessarie ad assicurare adeguate garanzie a tutela degli interessati nell’ambito del riutilizzo dei dati, anche sotto il profilo della loro sicurezza”.
Dunque, quali sono gli effetti di queste prime modifiche al Codice? Vediamoli insieme.
Innanzi tutto possiamo dire che, soprattutto quando il responsabile del trattamento è esterno, il titolare deve stipulare con lui un contratto scritto, il cui contenuto è solo in parte vincolato dal nuovo Codice: al di là di quello che sarà la volontà delle parti, che si accorderanno come meglio riterranno, questo contratto deve contente almeno la finalità perseguita, la tipologia dei dati, la durata del trattamento, gli obblighi e i diritti del responsabile del trattamento e le modalità di trattamento. A ben vedere, è molto diverso dal testo del GDPR, che prevede che nel contratto siano indicati la materia disciplinata e la durata del trattamento, la natura e la finalità del trattamento, il tipo di dati personali e le categorie di interessati, gli obblighi e i diritti del titolare del trattamento, oltre a tutti quegli elementi indicati dalle lettere da a) a h) del par. 3 dell’art. 28 del GDPR e dai paragrafi successivi.
Già qui ci sarebbe da criticare fortemente chi ha scritto il testo delle Legge. A parte che è inutile averlo fatto, avrebbe almeno potuto copiare bene.
Nella seguente tabella evidenzio le differenze.
| Caratteristiche del contratto | Nuovo Codice privacy modificato | GDPR |
| Forma scritta | Sì | Sì |
| Materia disciplinata | No | Sì |
| Natura del trattamento | No | Sì |
| Finalità perseguita | No | Sì |
| Tipologia di dati | Sì | Sì |
| Categorie di interessati | No | Sì |
| Durata del trattamento | Sì | Sì |
| Obblighi e diritti del titolare del trattamento | No | Sì |
| Obblighi e diritti del responsabile del trattamento | Sì | Sì |
| Modalità del trattamento | Sì | Sì |
| Altre specifiche | No | Sì |
| Obbligo di conformarsi agli schemi proposti dal Garante | Sì | Sì |
L’ultimo periodo dell’nuovo comma 4-bis obbliga implicitamente il Garante a predisporre degli “schemi tipo”, cosa che il GDPR gli riconosce come facoltativa.
Sostanzialmente, il nuovo comma 5 non apporta variazioni o innovazioni nel modo in cui i titolari devono vigilare sui propri responsabili.
Il nuovo art. 110-bis, invece, offre una nuova opportunità per i titolari, ovvero quella di trattare ulteriormente i dati già in loro possesso per finalità di ricerca scientifica o statistiche. In linea con il par. 4 dell’art. 9 del GDPR, il Parlamento ha posto due importanti vincoli: il primo è che deve essere ottenuta un’autorizzazione da parte del Garante (magari ci sarà spazio per delle autorizzazioni generali?), mentre il secondo è che, comunque, a prescindere dall’aver ottenuto l’autorizzazione o dalle misure di sicurezza adottate, non sarà lecito trattare per finalità di ricerca scientifica o statistiche i dati genetici. Mi viene da chiedermi come ci si dovrà comportare quando questo divieto contrasterà con finalità d’interesse pubblico rilevante, come la salvaguardia della vita o dell’incolumità fisica dell’interessato o di terzi (cfr. Dlgs 196/2003, art. 26, co. 4, lett. b) e GDPR, art. 6, per. 1, lett. d) e art. 9), con particolare riferimento ai casi in cui qualcuno si sottopone a terapie mediche sperimentali che, per loro stessa natura servono a salvaguardare la vita di qualcuno e sono ancora in fase di studio e, quindi, fortemente legate alla ricerca.
Ritengo che soprattutto su quest’ultimo punto si apriranno dibattiti interessanti nel prossimo periodo.
La simbiosi tra il registro del responsabile e la valutazione d’impatto sulla protezione dei dati
La simbiosi tra il registro del responsabile e la valutazione d’impatto sulla protezione dei dati
Sono due adempimenti richiesti dal GDPR con peculiari caratteristiche che si realizzano attraverso la formazione di due documenti distinti, solamente se ricorrono i casi specificati. Ma a ben vedere, il loro legame è molto più profondo di quanto possa apparire e potrebbe essere utile considerarli “simbiotici”.
In biologia la simbiosi è un rapporto che s’instaura a livello intimo tra due soggetti e che tende a legarli in maniera forte e mutuale, con lo scopo ultimo di portare un vantaggio reciproco a entrambi nel corso del tempo e dell’evoluzione del contesto di riferimento.
È possibile, dunque, trovare questo tipo di connessione tra il registro del responsabile del trattamento e la valutazione d’impatto sulla protezione dei dati? E se è possibile, quanto sarebbe utile farlo?
Questa è la domanda con cui sono uscito dal seminario organizzato da AssoDPO a Milano lo scorso 26 ottobre, durante il quale si è ampiamente dibattuto sullo stato dell’applicazione del GDPR a circa 200 giorni dalla sua definitiva applicazione diretta su tutto il territorio dell’Unione. Molte informazioni utili e un importante spunto di riflessione, appunto.
Come mia abitudine, parto dal considerare i principali riferimenti normativi, per circoscrivere il discorso che altrimenti rischierebbe di divagare troppo. Vi invito, perciò, a considerare il secondo e quinto paragrafo dell’art. 30 e il primo dell’art. 35, avendo sempre in mente i precetti dell’art. 5.
Quando parlo di simbiosi intendo dire che esiste uno stretto rapporto che lega il registro del trattamento del responsabile alla valutazione d’impatto svolta dal titolare e viceversa e, in un’ottica complessiva di gestione del rischio, non trovo poi così assurdo ipotizzare che il contenuto del primo, dovrebbe essere considerato nella seconda, fermo restando che è anche dai risultati della valutazione d’impatto che deriva l’adozione del registro stesso.
Così, se è vero che un titolare che, a seguito della valutazione d’impatto, individuati rischi elevati per i diritti e le libertà degli interessati deve richiedere l’adozione di un registro da parte del suo responsabile anche se questo potrebbe applicare (al netto del rapporto con il titolare) la deroga prevista dal quinto paragrafo dell’art. 30, trovo altrettanto vero che, in un complessivo sistema di gestione dei rischi, il titolare abbia il legittimo interesse, per non dire il diritto, di consultare il registro del responsabile per venire a conoscenza di quali siano gli eventuali altri titolari con cui ha rapporti.
Questo perché oggi non è possibile non considerare anche gli “altri titolari” come una fonte di rischio. Così come in un condominio con locali a uso commerciale, quando si redigono i DVR per la sicurezza sul lavoro, non si possono non considerare anche le altre attività presenti per via delle conseguenze sull’affollamento complessivo in caso di evacuazione o con effetti diretti sulla valutazione di rischi derivanti dalla vicinanza con obiettivi “sensibili” per rischi di rapina o attacchi terroristici (pensiamo, per esempio, se nello stesso stabile ci fossero al piano terra una filiale di una banca o delle poste, e ai piani superiori un laboratorio di oreficeria e un’ambasciata o un consolato), analogamente si dovrebbero considerare gli altri titolari per via dalla loro “attitudine” a essere bersaglio di tentativi di violazioni di dati.
Proviamo a pensare al caso in cui un’azienda che si occupa di conservazione e archiviazione documentale. In pratica l’attività consiste nell’offrire uno spazio fisico in cui è possibile lasciare i propri documenti che saranno conservati e archiviati secondo logiche predefinite su scaffali all’interno di capannoni.
Bene, è chiaro che se oltre ai nostri, ci fossero anche documenti di altri titolari, penso ci sarebbe utile valutare il rischio che qualcuno che si introduce nell’archivio per danneggiare uno degli altri, possa accidentalmente danneggiare anche noi. E questa valutazione ritengo che possa essere utile per una protezione dei dati in senso lato, anche in caso di dati informatici e in caso di dati non personali in senso stretto (bilanci societari, brevetti, progetti di vario genere…).
E quindi lo chiedo di nuovo: esiste una simbiosi tra il registro del responsabile e la valutazione d’impatto sulla protezione dei dati personali?
A mio modo di vedere, la risposta è affermativa: sì, perché se conosco il contesto di riferimento posso valutare e gestire il rischio.
A questo punto, quindi, la questione si sposta sulla volontà del responsabile di rendere disponibile l’informazione. Gli strumenti contrattuali e tecnici per assistere il titolare nella sua valutazione senza necessariamente diffondere informazioni che il responsabile potrebbe voler o dover mantenere riservate esistono.
A chi serve il DPO?
A chi serve il DPO?
Il DPO è una figura su cui si discute parecchio e da tempo. Tuttavia c’è ancora un velo di insicurezza circa gli ambiti merceologici in cui dovrebbe essere sicuramente nominato.
A chi serve il DPO? O meglio: in quali casi deve essere nominato?
La domanda sembra scontata, perché bastano pochi minuti di ricerca per imbattersi in uno dei tanti “interessanti articoli” sull’argomento che sono fioriti nell’ultimo biennio, ma che – diciamocelo – non hanno aggiunto nulla di più di quanto non fosse già stato chiaramente detto dal GDPR e successivamente descritto dalle linee guida di dicembre 2016.
Una critica forte che mi sento di fare è che in questo ultimo lustro, pochi si sono posti davvero il problema di determinare a chi serve il DPO, ma ricade in quelle categorie di soggetti titolari o responsabili del trattamento per i quali la nomina sarebbe obbligatoria, ma in modo non così immediatamente palese.
È pacifico e scontato che un ospedale debba nominarlo, così come deve farlo una pubblica amministrazione e, allo stesso modo, chi fornisce servizi di vigilanza da remoto. Ma gli altri? A chi serve il DPO?
Quanto segue è tratto da un episodio che mi è accaduto negli scorsi giorni.
Mi trovavo in cassa al supermercato e ho notato un cartello che, insieme ad altri avvisi, ricordava che il Codice Penale vieta la somministrazione di bevande alcooliche ai minori di sedici anni o agli infermi di mente. Per comodità, riporto integralmente il testo della norma:
Codice Penale – Art. 689.
Somministrazione di bevande alcooliche a minori o a infermi di mente.L’esercente un’osteria o un altro pubblico spaccio di cibi o di bevande, il quale somministra, in un luogo pubblico o aperto al pubblico, bevande alcooliche a un minore degli anni sedici, o a persona che appaia affetta da malattia di mente, o che si trovi in manifeste condizioni di deficienza psichica a causa di un’altra infermità, è punito con l’arresto fino a un anno.
La stessa pena di cui al primo comma si applica a chi pone in essere una delle condotte di cui al medesimo comma, attraverso distributori automatici che non consentano la rilevazione dei dati anagrafici dell’utilizzatore mediante sistemi di lettura ottica dei documenti. La pena di cui al periodo precedente non si applica qualora sia presente sul posto personale incaricato di effettuare il controllo dei dati anagrafici.
Se il fatto di cui al primo comma è commesso più di una volta si applica anche la sanzione amministrativa pecuniaria da 1.000 euro a 25.000 euro con la sospensione dell’attività per tre mesi.
Se dal fatto deriva l’ubriachezza, la pena è aumentata.
La condanna importa la sospensione dall’esercizio.
Fermi tutti! Abbiamo letto bene?
In pratica il Codice Penale ci sta dicendo che chi somministra (vende) alcoolici deve controllare un documento d’identità valido per accertarsi dell’età dell’acquirente/consumatore e deve accertarsi del suo stato di salute psichica, perché se dal controllo risultano determinate informazioni, allora non può vendere nemmeno una birra leggera. Tra l’altro, è anche contemplata la possibilità di avvalersi di incaricati per espletare il controllo e ci sono precise indicazioni anche per i distributori automatici.
Incredulo, ho approfondito la ricerca e mi sono imbattuto in più d’una sentenza della Cassazione, che sostanzialmente confermavano quanto scritto nel Codice; una in particolare (Sentenza n° 46334 del 2013, emessa dalla V Sezione Penale), citando anche la Legge 125/2001, arriva a dire che:
La natura di reato di pericolo della somministrazione di bevande alcooliche a minori di anni sedici impone una effettiva e necessaria diligenza nell’accertamento dell’età del consumatore, atteggiamento che, nel caso in cui la somministrazione sia stata preceduta dalla richiesta, da parte del cameriere addetto alle consumazioni, dell’età dell’avventore, non può essere soddisfatto né dalla presenza nel locale di cartelli indicanti il divieto di erogazione di bevande alcooliche ai minori, né limitandosi a prendere atto della risposta del cliente sul superamento dell’età richiesta, ove ciò non corrisponda al vero.
Si tratta di un obbligo che grava innanzitutto sul soggetto che gestisce l’esercizio commerciale in cui si pratica la vendita al pubblico di bevande alcoliche, assicurandone la somministrazione, su richiesta dei clienti, personalmente o attraverso forme di organizzazione del lavoro incentrate sull’impiego di uno o più dipendenti retribuiti.
Per completezza, riporto anche l’articolo della citata legge:
Legge 125/2001 – Art. 14-ter: Introduzione del divieto di vendita di bevande alcoliche a minori.
1. Chiunque vende bevande alcoliche ha l’obbligo di chiedere all’acquirente, all’atto dell’acquisto, l’esibizione di un documento di identità, tranne che nei casi in cui la maggiore età dell’acquirente sia manifesta.
2. Salvo che il fatto non costituisca reato, si applica la sanzione amministrativa pecuniaria da 250 a 1.000 euro a chiunque vende o somministra bevande alcoliche ai minori di anni diciotto. Se il fatto è commesso più di una volta si applica la sanzione amministrativa pecuniaria da 500 a 2.000 euro con la sospensione dell’attività da quindici giorni a tre mesi.
Vediamo come le norme italiane e la giurisprudenza della Cassazione confermano quanto scritto poco sopra: l’esercente deve controllare.
Ora aggiungiamo quanto scritto nel GDPR e nelle linee guida, in particolare l’art. 37 del primo e i concetti di “attività principale”, “larga scala” e “monitoraggio regolare e sistematico”.
Anche se sembra strano, considerate tutte le norme, le linee guida e le sentenze, appare chiaro che:
- Chi vende o somministra alcoolici deve controllare i documenti e lo stato di salute psichica del cliente.
- Quest’obbligo – che a mio modo di vedere persegue finalità di pubblica sicurezza e interesse, oltre che di tutela della salute del cliente stesso – rende l’attività di controllo un’attività principale, perché condizione essenziale per la vendita o la somministrazione (salvo voler andare contro disposizioni di legge).
- Conseguentemente, il trattamento dei dati è effettuato su larga scala (perché coinvolge praticamente tutti i soggetti che intendono acquistare la bevanda alcoolica) ed è svolto in modo regolare e sistematico (poiché deve essere fatto almeno la prima volta che si presenta un nuovo cliente e deve essere fatto per adempiere a norme cogenti).
- I dati raccolti possono riguardare minorenni e possono essere sensibili o particolari.
Se poi consideriamo che, in presenza di un distributore automatico, il trattamento dei dati implica anche un processo decisionale automatizzato che produce effetti giuridici sull’interessato (cioè l’acquisto della proprietà, o meno, della bevanda alcoolica), è chiaro che l’intero processo di vendita si basa su un trattamento dei dati personali che è tutt’altro che poco rischioso (in termini di responsabilità e gestione dei rischi sui diritti degli interessati).
E se al distributore automatico si può ragionevolmente immaginare di essere in un contesto “riservato”, altrettanto non si può dire di un locale aperto al pubblico. Possiamo ragionevolmente affermare che c’è il rischio di mettere in forte imbarazzo l’acquirente nel caso non si volesse vendere il prodotto alcoolico perché lo riteniamo in “stato di deficienza psichica” (magari perché malato, oppure perché ebbro); ho usato il termine “forte imbarazzo” per evitare di scrivere “ledere la sua personalità” in presenza di altre persone.
A questo punto la domanda è:
A chi serve il DPO? Se ho un bar, un ristorante o un distributore automatico e vendo alcoolici, devo nominarlo?
Ebbene, se non siete giocatori d’azzardo e non vi piace rischiare di incorrere in sanzioni, la mia risposta potrebbe non piacervi.
Perché è SÌ.
Personalmente, ritengo che questo sia uno dei casi in cui è chiaro che quando si scrivono le regole, talvolta ci si dimentica che poi qualcuno dovrebbe anche applicarle. Uscendo dal ruolo di consulente privacy, non nascondo la mia perplessità di fronte a quanto è così chiaramente scritto nei testi normativi.
Forse, in questo caso, l’errore più grosso lo hanno commesso i legislatori.
Software gestionali per la privacy: benefici e rischi
Software gestionali per la privacy: benefici e rischi
Prima di procedere con l’acquisto, così come durante il suo utilizzo, sarebbe bene ricordarsi che un programma gestionale è solamente uno strumento che per rendere al meglio deve essere maneggiato con l’adeguata preparazione.
Capiamoci fin da subito: non sono contro i gestionali per partito preso, anzi, direi piuttosto che mi schiero con chi ritiene che le macchine non possono fare tutto e non possono sostituirsi all’uomo. Se è vero che avere un software apporta alcuni benefici, lo è altrettanto che espone chi lo usa a nuovi rischi.
Tralasciamo il fatto che non tutti i gestionali sono uguali e che possono comportare spese differenti in termini di acquisto della licenza, o investimenti per lo sviluppo interno, o canoni per l’assistenza, e che ovviamente possono offrire una qualità di servizio differente, e concentriamoci su alcuni (tutti è difficile farlo in questa sede) dei benefici e dei rischi che interessano prevalentemente il lato operativo della faccenda.
Tra i benefici penso si possano elencare una miglioria nella gestione complessiva degli adempimenti, una migliore organizzazione delle scadenze e una facilità di accesso a determinate informazioni sul modello organizzativo adottato per proteggere i dati personali.
In alcune realtà, potrebbe essere un valido strumento per la conduzione di audit o, comunque, per espletare alcuni dei controlli necessari, tra cui la valutazione di impatto sulla protezione dei dati (c.d. DPIA), e migliora senza dubbio gli effetti del lavoro di squadra e della collaborazione attiva, sempre più rilevanti e importanti nelle organizzazioni moderne, soprattutto se il suo impego non è limitato a poche persone chiave.
D’altro canto, i rischi sono comunque dietro l’angolo.
Innanzi tutto si rischia di sostituire completamente l’elemento umano, trasformando potenzialmente alcuni dei trattamenti da “manuali” a “automatizzati”, con tutto quanto ne consegue anche sotto l’aspetto della tutela dei diritti degli interessati.
Secondariamente, affidarsi troppo al software potrebbe allontanare dalla realtà effettiva dei fatti chi è incaricato di controllare il sistema, come i responsabili o i DPO. Se il software non funzionasse correttamente (e non è un’ipotesi da escludere a priori, visto che è prassi consolidata emettere patch o aggiornamenti per correggere anomalie o bachi) potrebbe avere effetti negativi sulla realtà percepita e, di conseguenza, sull’efficacia del controllo e della gestione complessiva.
Infine, basare il proprio operato esclusivamente sul gestionale per la privacy, genera un errore di fondo gravissimo (a mio parere) soprattutto in sede di valutazione d’impatto: procedendo solo con il software, non potremmo più parlare di “valutazione”, bensì dovremmo parlare di “misurazione”.
Il perché è presto detto: ogni realtà è differente e ognuna include necessariamente operatori (responsabili del trattamento, DPO, incaricati, IT manager…) differenti che hanno ognuno ciascuno un bagaglio di conoscenze ed esperienze diversi e di cui è doveroso tenerne conto in sede di valutazione che, oltre tutto, è di per sé un prodotto di queste conoscenze ed esperienze. Una valutazione è necessariamente soggettiva e deve essere relativa al contesto osservato, perché è sulla base delle sue caratteristiche e dei risultati della valutazione stessa, che il titolare del trattamento può mettersi nella condizione di essere adempiente alle norme vigenti, su tutte il GDPR, con particolare riferimento agli artt. 24, 25, 32 e 35, che richiedono tutti di tenere conto dell’ stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche i rischi gravanti sui diritti e le libertà degli interessati.
Tutto questo, senza scomodare la più recente giurisprudenza che è arrivata ad affermare che il concetto di dato personale, fortemente legato all’identificabilità anche indiretta della persona fisica a cui si riferiscono, è correlato anche alla “facilità” e all’impegno necessario per identificarla. Tradotto: se io scrivo Mario Rossi o John Smith, in questo testo e per coloro che lo leggono, sono quattro parole che di dato personale hanno ben poco.
Pensare di essere a posto con la privacy solo perché si è comprato un software per la sua gestione, è come salire su un’auto da F1 e pensare di poter vincere il GP di Montecarlo senza aver mai guidato quel mezzo, né mezzi simili, né essere mai stato in pista, né aver mai visto le strade di Montecarlo aperte al traffico.
Chi lo fa, è un pericolo per sé e per gli altri. Con l’aggravante di non essere pienamente consapevole di cosa significhi effettivamente occuparsi della protezione dei dati personali.
Linee guida sul DPO in italiano
Linee guida sul DPO: arriva la traduzione in italiano
Il Garante pubblica la traduzione ufficiale delle linee guida del WP29
Sul sito internet dell’Autorità Garante per la Protezione dei Dati Personali sono disponibili dal 3 febbraio 2017 le traduzioni ufficiali, a cura del Garante stesso, dei documenti rilasciati il 13 dicembre 2016 dal Working Party 29, l’istituzione europea che raccoglie i rappresentanti delle varie autorità di controllo nazionali in materia di privacy.
Sono infatti disponibili, ora, i testi delle linee guida sui responsabili per la protezione dei dati (in inglese data protection officer), che ora acquistano l’acronimo italiano RPD in luogo dell’inglese DP, e le relative FAQ.
La pubblica consultazione si è chiusa il 15 febbraio e a breve si attendono le versioni definitive.
Magari la traduzione non è stata tempestiva, ma comunque è utile per continuare a parlare sempre di più di questo ruolo fondamentale sotto il profilo strategico e organizzativo delle imprese e delle pubbliche amministrazioni e che diventerà obbligatorio in molte realtà con l’applicazione del GDPR, a partire dal 25 maggio 2018. Mancano solo 475 giorni.