In un precedente articolo abbiamo trattato della valutazione del rischio privacy per adempiere ai requisiti del GDPR (Regolamento UE 2016/679 sulla protezione dei dati personali), ma chi ha o deve implementare un sistema di gestione per la sicurezza delle informazioni come deve considerare la valutazione dei rischi sui trattamenti di dati personali? Tale valutazione è implicita nella valutazione dei rischi sulla sicurezza delle informazioni, ovvero è un “di cui” di essa? Oppure, come sostengono alcuni esperti di privacy, è tutta un’altra cosa e va considerata separatamente? Cerchiamo di chiarire questi aspetti.

Cos’è il rischio per la sicurezza delle informazioni?

Partiamo dalla valutazione del rischio per la sicurezza delle informazioni, ovvero essenzialmente per i sistemi di gestione certificati ISO 27001.

Prima di parlare di valutazione del rischio dovremmo soffermarci sulla terminologia: sicurezza delle informazioni non è “sicurezza informatica” e non è “cybersecurity”. Tralasciamo le discussioni sul termine cybersecurity (in italiano “sicurezza cibernetica”?) che per taluni equivale alla sicurezza informatica, per altri è la protezione delle informazioni digitali da attacchi informatici (non da incidenti naturali!), per altri ancora ha a che fare con la sicurezza degli appartai IT e OT…

La sicurezza informatica è un sottoinsieme della sicurezza delle informazioni? Dunque, la valutazione del rischio ICT è una parte della valutazione del rischio per la sicurezza delle informazioni?

Non è proprio così, ma quasi: la sicurezza informatica riguarda gli apparati ICT che normalmente trattano informazioni digitali. Ora un problema tecnico, dovuto ad un attacco informatico deliberato oppure ad un evento accidentale, comporta anche un rischio per la sicurezza delle informazioni? In teoria non è sempre così perché un attacco informatico ad una infrastruttura critica (ad es. un acquedotto o una rete elettrica) generalmente non comporta conseguenze sulla sicurezza delle informazioni, ovvero sulla sua declinazione in riservatezza, integrità e disponibilità. Perciò non costituisce un rischio per la sicurezza delle informazioni? Ma le apparecchiature informatiche e le infrastrutture ICT cosa trattano? Non trattano byte, ovvero informazioni? Facciamo un esempio su un fatto accaduto di recente: il blocco del traffico aereo alcuni giorni fa negli Stati Uniti è stato provocato da un incidente informatico, pare fosse colpa di un file “corrotto” (ma anche se fosse stato un attacco di hacker Russi, cosa che non ci diranno mai, la sostanza non cambierebbe): ebbene è considerato un incidente sulla sicurezza delle informazioni, ovvero si è concretizzato un rischio sulla sicurezza delle informazioni? Apparentemente no perché le conseguenze sono state il blocco dei voli con disagi per i passeggeri, maggiori costi per Compagnie Aeree e passeggeri e così via. Ma la causa di tutto questo non è stata la mancanza di informazioni (= mancata disponibilità di informazioni) sulla sicurezza dei voli che ha fatto prudentemente mantenere a terra molti aeromobili?

Ovviamente tutto dipende dal contesto in cui si trova l’organizzazione che deve valutare i rischi e qual è il campo di applicazione del sistema di gestione ISO 27001 che, nel caso, ci chiede la valutazione del rischio.

Il viceversa – ovvero che la sicurezza informatica non copra tutta la sicurezza delle informazioni – è dimostrabile in modo più semplice: le informazioni su supporto cartaceo devono essere protette e la loro protezione generalmente non riguarda la sicurezza informatica.

La valutazione del rischio sulla sicurezza delle informazioni

Fatta questa premessa andiamo ad esaminare cosa ci dice la teoria e la letteratura sul risk assessment per l’information security, ovvero per il SGSI ISO 27001.

In principio fu la vecchia versione della ISO 27005 a guidare queste valutazioni del rischio sulla sicurezza delle informazioni. In sintesi, questa norma ci diceva di partire dal censimento degli asset dell’organizzazione, di andare a vedere quali informazioni essi trattano (information asset) e, quindi, fare una valutazione del valore degli asset riguardo alle caratteristiche di sicurezza, ovvero riservatezza, integrità e disponibilità.

Poi occorreva identificare le minacce alla sicurezza delle informazioni (gli attacchi hacker, gli incendi, gli errori di configurazione dei sistemi, ecc.) e le vulnerabilità presenti negli asset (sistemi non aggiornati, assenza di protezione fisica del CED, mancanza di consapevolezza del personale, ecc.).

Una combinazione di questi elementi, ovvero una minaccia che sfrutta una vulnerabilità per far concretizzare un rischio su un determinato asset veniva ponderata in base alla probabilità di accadimento (in realtà viene usato il termine verosimiglianza) x la gravità delle conseguenze/danno potenziale x il valore dell’asset, al fine di ottenere un determinato livello di rischio quali-quantitativo.

Oggi l’ultima versione della medesima norma prende in considerazione due approcci:

• Approccio basato sugli eventi: i rischi possono essere identificati attraverso le considerazioni della Direzione e il contesto dell’organizzazione. Questo permette di concentrare gli sforzi sui rischi più critici, senza disperdersi nella valutazione di numerosi rischi che poi giudicherò minori e non degni di essere considerati con azioni di trattamento.
• Approccio basato sugli asset: i rischi possono essere identificati attraverso l’ispezione di asset, minacce e vulnerabilità. È quello già previsto dalla precedente edizione della ISO 27005.

Altri metodi di valutazione del rischio possono essere utilizzati, classificati in genere in metodi quantitativi (basati su un calcolo più o meno “preciso” del rischio, a fronte di valutazioni della probabilità matematica di accadimento dell’evento negativo e di valutazione quantitativa del danno, ad es. in termini economici) e qualitativi (il valore del rischio: “Alto”, “Medio”, “Basso”, ecc. non è espresso in valori assoluti, ma rappresenta solo un metodo di confronto fra i vari rischi).

In generale questi metodi qualitativi, secondo alcuni esperti, portano sempre ad un calcolo del rischio basato sulla formula:

r(m, a, v) ∝ p(m) ⋅ i(m, a) ⋅ g(v)

dove r rappresenta la funzione “rischio” che dipende da m= minacce, a= asset, v= vulnerabilità in modo proporzionale alla probabilità di accadimento della minaccia, all’I=impatto della minaccia sull’asset e alla g=gravità della vulnerabilità.

Un approccio completamente diverso, proposto da altri esperti, non prende in considerazione le minacce, ma parte dalle vulnerabilità presenti per determinare i rischi concreti che dovranno essere valutati attraverso la classica formula Rischio =Possibilità di accadimento x Gravità del danno o delle conseguenze provocate dal concretizzarsi del rischio.

Le fasi successive del processo di valutazione dei rischi, dopo la loro identificazione, sono sempre le stesse: analisi dei rischi, ponderazione dei rischi, scelta delle opzioni di trattamento, determinazioni dei controlli/contromisure necessari, confronto con i controlli dell’Annex A della ISO 27001 e definizione della Dichiarazione di Applicabilità (S.o.A.).

Tra i modelli disponibili per il calcolo del rischio sulla sicurezza delle informazioni secondo la ISO 27001 segnaliamo il tool VERA di Cesare Gallotti (https://www.cesaregallotti.it/Pubblicazioni.html ) che prevede l’identificazione di una serie di Minacce/Rischi per le quali sono attribuiti una probabilità di accadimento ed un impatto fino a costituire il c.d. “rischio puro” o “rischio intrinseco”. Quindi vengono stabilite le vulnerabilità che non sono altro che l’inversamente proporzionale ai controlli, ovvero all’efficacia degli stessi. Combinando il rischio intrinseco con le vulnerabilità/controlli si ottiene il valore del rischio calcolato sulla sicurezza delle informazioni. Tale modello comprende anche una parte legata alla privacy (comunque cogente anche in ambito SGSI) nella quale si valutano i soli rischi (minacce) attinenti alla privacy e le relative conseguenze.

Altri esperti definiscono il “rischio inerente” come il rischio derivante dalla combinazione di probabilità/possibilità di accadimento dell’evento e dalla gravità delle conseguenze. Applicando i controlli di sicurezza, ovvero le contromisure (le misure di sicurezza tecniche ed organizzative in termini privacy) si ottiene il “rischio residuo”, che dovrà poi essere confrontato con i criteri di accettabilità per stabilirne le opzioni di trattamento.

Altri schemi e standard prevedono valutazioni dei rischi sulla sicurezza ICT, che oggi costituisce parte preponderante della sicurezza delle informazioni. Gli approcci possono essere leggermente diversi, ma sostanzialmente non si discostano dalla seguente metodologia-

1. Identifico le minacce che incombono sui sistemi e sui dati (es. virus ransomware o, più in dettaglio le tecniche che rendono possibile un attacco ransomware: phishing, social engineering, attacchi di forza bruta a siti web per la ricerca di credenziali di accesso, ecc.)
2. Identifico gli eventi che, se si concretizza la minaccia, possono costituire un rischio per i miei dati
3. Valuto le misure di mitigazione che sono state implementate per fronteggiare il rischio.
4. Valuto la probabilità di accadimento dell’evento.
5. Valuto l’impatto che comporta tale rischio per i dati e tutto quel che ne consegue.
6. Calcolo il valore del rischio (residuo).
7. Definisco le azioni di trattamento del rischio (accettare il rischio oppure adottare ulteriori misure di prevenzione o protezione per ridurre il rischio o addirittura eliminarlo.

La valutazione del rischio privacy

Quando si valuta il rischio relativo alla privacy, è possibile identificare minacce specifiche per la privacy. Tra di esse vi sono:

• rappresentazione scorretta, se i dati relativi a una persona sono errati, oppure presentati o elaborati in modo non corretto possono provocare danni all’interessato; questa minaccia può anche riguardare i risultati della profilazione di una persona (che, ad esempio, potrebbe essere esclusa da programmi sanitari o economici), eventualmente anche con strumenti basati sull’intelligenza artificiale;
• distorsione, ossia l’interpretazione volutamente o inavvertitamente scorretta dei dati, con potenziali impatti negativi sulla singola persona; questa minaccia è, in pratica, quella del pettegolezzo e della maldicenza, che può portare al biasimo, alla stigmatizzazione, all’isolamento e anche alla perdita di libertà di una persona;
• sorveglianza, attraverso l’uso dei dati, soprattutto in ambito informatico; è necessario riconoscere la differenza tra logging (ossia la raccolta di dati per assicurare la sicurezza delle persone e della proprietà) e la sorveglianza (che porta, anche se non sempre per scelta deliberata, a discriminazione, perdita di fiducia, autonomia o libertà, danni fisici o materiali);
• blocco alla conoscenza dei dati trattati, ossia segretezza in merito al fatto che i dati personali sono trattati e alle modalità con cui lo sono; questo può portare all’uso dei dati personali iniquo e, per le singole persone fisiche, alla mancanza di autodeterminazione, alla perdita di fiducia e a perdite economiche;

In pratica le minacce per la privacy potrebbero essere diverse da quelle per la sicurezza delle informazioni, o meglio alcune (la maggioranza) coincidono, altre sono differenti. Ma se consideriamo che l’informazione è anche un dato personale e che la stessa ISO 27001 comprende un controllo denominato “Privacy e protezione dei dati personali” (controllo A.18.1.4 della versione 2013 della ISO 27001-27002) capiamo bene che – nella valutazione del rischio per la sicurezza delle informazioni – dobbiamo considerare anche gli impatti che una determinata violazione di dati personali può avere sui diritti e le libertà dell’interessato e non solo sul business dell’organizzazione.

Dunque un medesimo evento rischioso, ad esempio un data breach sul portale web dell’azienda oppure un ransomware che non comporta un’esfiltrazione di dati (anche personali), ma “soltanto” un blocco dei sistemi per un paio di giorni, potrebbe portare ad una valutazione e, quindi, ad un indice (livello) di rischio differente semplicemente perché – a parità di probabilità di verificarsi dell’evento – l’impatto sui diritti e le libertà dell’interessato, piuttosto che sul business dell’organizzazione, può essere sensibilmente diverso.

Quindi la valutazione dei rischi potrebbe essere unica a patto di considerare i differenti effetti a fronte del verificarsi di medesimi eventi.

Naturalmente ogni organizzazione avrà i suoi parametri e le sue specificità: dal punto di vista dell’interessato: un conto è un blocco dei sistemi informativi per un paio d giorni di un Ospedale ed un conto è il medesimo blocco per un’azienda manifatturiera dove probabilmente il fatto di non poter accedere ai dati dei dipendenti per un paio di giorni non costituirebbe un gran problema (salvo che non sia il giorno di pagamento degli stipendi…).

Tuttavia, alcuni esperti della materia privacy potrebbero obiettare: ma per il GDPR devo valutare i rischi sui trattamenti di dati personali, quindi considerare i rischi per ogni trattamento! Allora bisognerebbe riprendere il concetto di “Asset” dove i dati personali (dei dipendenti, dei clienti, ecc.) costituiscono un “asset informativo” con un certo valore, dato dalla combinazione delle diverse caratteristiche di sicurezza (Riservatezza, Integrità e Disponibilità).

Spesso, però, si può semplificare considerando il caso peggiore (worst case), ovvero dato un determinato evento rischioso (ad es. un data breach sul portale web) consideriamo lo scenario peggiore per tutti i trattamenti di dati personali. Allora per i trattamenti dei dati personali dei dipendenti avrò un determinato impatto, mentre per i dati personali dei clienti avrò un impatto di tipo e valore diverso: nel nostro caso di esempio per l’Ospedale il rischio maggiore sarebbe sui dati dei pazienti e dei relativi trattamenti (es. prenotazioni, refertazione visite ed esami, ecc.), mentre per l’azienda manifatturiera il rischio più elevato sarà sui trattamenti dei dati dei dipendenti (elaborazione paghe, ecc.).

Evidentemente la valutazione del rischio privacy per ogni singolo trattamento di dati personali che abbiamo inserito nel Registro delle Attività di Trattamento (ai sensi dell’art. 30 del GDPR) potrebbe risultare parecchio oneroso e non giustificato per una medio-piccola organizzazione. È comunque sempre opportuno raggruppare più trattamenti sui quali incombono i medesimi fattori di rischio. Ad esempio in un’organizzazione che gestisce tutti i dati in formato digitale attraverso file di Office conservati in un file Server ed un unico applicativo gestionale è perfettamente inutile replicare le medesime minacce ed eventi di rischio legati all’IT su diversi trattamenti. Eventuali vulnerabilità o misure di sicurezza non completamente efficaci legate al controllo degli accessi degli utenti, agli strumenti anti-malware, ai backup o alla (scarsa) consapevolezza del personale impattano su tutti i trattamenti di dati personali e basterà considerare solo il caso peggiore, ovvero l’impatto di gravità più alta su tutti i trattamenti per “risolvere” il problema della valutazione del rischio privacy. Infatti, ai fini della protezione dei dati personali, il trattamento del rischio che andremo ad attuare sarà finalizzato a prevenire il rischio (abbassare la probabilità che la minaccia si concretizzi) oppure a proteggere il dato dall’evento che non può essere completamente evitato (ridurre la gravità dell’impatto), dunque miglioreremo la protezione dei dati personali su tutti i trattamenti effettuati.

In conclusione il problema non è pensare di coprire anche la valutazione del rischio privacy attraverso una valutazione più ampia sulla sicurezza delle informazioni, ma fare quest’ultima valutazione in modo incompleto, senza considerare nel modo corretto i rischi associati alla protezione dei dati personali.

Come spesso accade, se si fanno le cose per bene si può fare (quasi) tutto.

Con l’avvento del GDPR si è complicata la gestione della privacy dei destinatari delle azioni di web marketing, attraverso strumenti quali mail-marketing, newsletter, social network, cookie, pixel, beacon, ecc.. Con l’evoluzione della tecnologia legata ai cookie ed altre tecnologie similari anche una semplice navigazione di un sito internet a scopo puramente informativo sta diventando sempre più complicata, sia per il gestore del sito, sia per i “naviganti” che si trovano a dover accettare cookie policy, informative privacy e trattamenti consentiti che se si leggesse tutto si impiegherebbe più tempo rispetto a quello dedicato alla lettura dei contenuti veri del sito.

La confusione che si è generata è in parte causata da una normativa non completamente definita e certa, fra vecchia Direttiva ePrivacy, Cookie Law, GDPR e – per il nostro Paese – Provvedimenti del Garante Privacy italiano precedenti al Regolamento 679/2016, ma comunque ritenuti validi, seppur necessitino di aggiornamento per la revisione del Codice Privacy italiano (D.Lgs 196/2003 novellato dal D. Lgs 101/2018) a fronte del GDPR.

Ma cerchiamo di far chiarezza su alcuni punti esaminando cosa dice la normativa e come essa viene intrepretata da fonti autorevoli, senza la pretesa di fornire soluzioni valide in tutte le situazioni e contesti, ma semplicemente fornire utili spunti di riflessione per gestire ogni caso nel modo corretto.

Un contesto classico è costituito da un’azienda, magari medio-piccola, che commissiona il rifacimento e/o la gestione del proprio sito web ad una società specializzata in comunicazione, web marketing e sviluppo di siti internet. Oppure a due diverse organizzazioni che curano la comunicazione online e offline e la gestione del sito.

In entrambe le situazioni la struttura (singolo professionista o società) che effettuerà le attività di mail-marketing (invio di newsletter e altro) attraverso strumenti web (es. Mail-up, Mailchimp, Voxmail,…. il panorama è vasto) che raccolgono l’insieme degli indirizzi e-mail (e forse anche nome, cognome, azienda, ecc.) dei destinatari si configura come Responsabile (esterno) del trattamento ai sensi dell’articolo 28 del Regolamento UE 679/2016. Questo, naturalmente, se tratta dati personali di clienti e contatti vari dell’azienda che gli ha commissionato il servizio, ovvero se anche solo uno degli indirizzi e-mail contiene i riferimenti del tipo nome.cognome@nomeazienda.com. Tale ruolo implica precise responsabilità in capo al soggetto che svolge il servizio di marketing diretto, necessariamente definiti attraverso un contratto o un atto di nomina a responsabile del trattamento a valenza contrattuale.

Le piattaforme utilizzate per inviare newsletter si configurano anch’esse come responsabili del trattamento perché conservano i dati dei destinatari e le relative azioni conseguenti in database in cloud. Generalmente questo è già formalizzato nel contratto di licenza d’uso dell’applicativo o documenti ad esso correlati. I principali players del mercato – se si legge con attenzione i relativi contratti – si sono anche ben cautelati contro la possibile accusa di trattamento illecito di dati personali, scaricando sul cliente-utilizzatore ogni responsabilità sulla fonte dei dati memorizzati nei loro cloud e sull’eventuale necessità di consenso.

La mancata formalizzazione del ruolo della società di web marketing lascia in capo al titolare del trattamento (l’azienda che commissiona il servizio) ogni responsabilità in caso di violazioni di dati personali che potrebbero verificarsi nel processo gestito dal fornitore.

Se l’attività di web marketing si spinge anche sulla gestione dei c.d. social (Linkedin, Facebook ed altri) occorre fare ancora più attenzione alla gestione di eventuali dati personali di terzi utilizzati. Le posizioni di Facebook, Linkedin, Instagram e Twitter rispetto alla gestione della privacy sono documentate nei rispettivi siti, ma attenzione alla gestione di alcuni social emergenti. Certamente se semplicemente postiamo contenuti promozionali sulla nostra pagina Facebook non c’è da preoccuparsi, ma se postiamo un video di un evento con persone riconoscibili su Tik Tok qualche problema in più dobbiamo porcelo.

Anche l’utilizzo di plugin social (i classici pulsanti di condivisione su Facebook, Linkedin, Twitter, ecc. dei contenuti del nostro blog) richiede un minimo di attenzione, anche se nel momento che un visitatore del nostro sito clicca sul pulsante di condivisione per pubblicare sul suo profilo Facebook un nostro articolo sta entrando a casa Facebook con tutti i consensi privacy che ha accettato quando si è iscritto al social network e le successive modifiche.

Quando utilizziamo cookie e tecnologie similari (pixel, beacon, plugin social, ecc.) legate a connessioni social ricordiamoci che sono già state comminate, dalle Autorità di Controllo dei vari Paesi, sanzioni molto elevate (a volte forse anche spropositate) per l’utilizzo troppo disinvolto di queste tecnologie. E ricordiamoci anche che il sig. Zuckenberg ha le spalle robuste ( ed un discreto patrimonio) per sopportare sanzioni stratosferiche, noi probabilmente no.

Prima di affrontare il problema dei cookie e delle tecnologie similari appena introdotto è però opportuno affrontare anche il ruolo del gestore del nostro sito web, ovvero del fornitore a cui abbiamo commissionato il rifacimento del sito e/o la sua manutenzione. Anch’esso si configura come responsabile esterno del trattamento dei dati personali se effettivamente “tratta” dati personali. Questo avviene se gestisce credenziali amministrative del sito web (ovvero può vedere e modificare qualsiasi informazione presente sul sito) e all’interno del medesimo sono presenti dati personali (nomi, cognomi, telefoni, e-mail personali, …). Questo può avvenire semplicemente se nel sito è presente un classico form di richiesta contatto nel quale l’utente può inserire dati personali. Apparentemente arriva solo una e-mail all’indirizzo aziendale inserito, ma per i siti gestiti attraverso un CMS (Content Management System, ad es. WordPress o Joomla per citare i più diffusi) questi dati rimangono nel database del CMS del sito, ospitato presso il provider scelto. Per non parlare poi dei siti che gestiscono registrazione di utenti per ricevere newsletter o l’accesso ad un’area riservata: anche tali informazioni naturalmente vengono conservate nel database del CMS.

La formalizzazione del contratto come responsabile del trattamento per la web agency che ci fornisce questi servizi è molto importante perché comporta la definizione delle misure di sicurezza sul sito o portale web. Il coltello sta dalla parte del manico per il committente che può imporre alla web agency misure di sicurezza che lui ritiene adeguate, o meglio dovrebbe approvare le misure di sicurezza che il fornitore intende implementare. L’adeguatezza di tali misure è un aspetto di una certa importanza perché in caso di violazioni di dati personali (i c.d. data breach) la responsabilità ricade sul titolare del trattamento e sul responsabile del trattamento (il gestore del sito) se nominato.

Naturalmente occorre sempre valutare l’impatto di un data breach per i diritti e le libertà delle persone fisiche: un conto è avere sul sito un elenco di contatti che hanno compilato il form di contatto fra cui figurano solo nomi e cognomi, molti dei quali di fantasia, ed indirizzi e-mail dal prefisso “.ru” di spammers o hacker; un altro è gestire sul portale i dati di esami diagnostici di pazienti di un poliambulatorio medico.

Anche in questo caso esistono due elementi della sicurezza: la sicurezza della piattaforma di hosting del sito e la sicurezza del sito medesimo. Nel primo caso le scelte più popolari di hosting presso fornitori specializzati internazionali e italiani (da Microsoft Azure ad Aruba) non devono preoccupare, sono tutti fornitori certificati ISO 27001 con datacenter provvisti di certificazioni specifiche e quant’altro per dormire sonni tranquilli. Viceversa il sito va gestito ed aggiornato: i CMS più popolari come WordPress vengono continuamente aggiornati per garantire maggior sicurezza ed esistono numerosi plugin per migliorare la sicurezza contro attacchi di forza bruta, spammers ed altro, ma bisogna installarli ed aggiornarli per garantire la protezione rispetto alle ultime vulnerabilità conosciute. Stesso discorso vale per il software di base della piattaforma di hosting (es. PHP, MySQL, ecc.). Non fare nulla per anni sul sito e subire una violazione non ci permette di dimostrare di aver adottato misure di sicurezza adeguate e di evitare le sanzioni conseguenti.

Ma di chi è la responsabilità della conformità del sito alla normativa applicabile? Quindi ci ricolleghiamo al discorso recedente sui cookie perché spesso solo chi ha sviluppato e gestisce il sito sa esattamente quali e quanti cookie vengono gestiti nel sito. Chi acquista il prodotto/servizio si aspetterebbe di riceverlo conforme alle norme, come quando si acquista un prodotto elettrico o si installa un impianto. Il sito o portale web soddisfa i requisiti di privacy by design come sancito dall’art. 25 del GDPR?

Il discorso sui cookie è diventato abbastanza complesso, sia dopo l’avvento del GDPR, sia con l’introduzione di nuove tecnologie atte a monitorare il comportamento sul web degli utenti; il tutto condito dal fatto che il nuovo Regolamento e-Privacy non è ancora stato pubblicato (doveva esserlo insieme al GDPR).

Quindi oggi il quadro è il seguente:

• l’uso dei cookie è regolato dalla (vecchia) Direttiva e-Privacy (Cookie Law) e non dal GDPR;
• la Cookie Law pone in capo al titolare l’obbligo di raccogliere un consenso da parte degli utenti prima di installare cookie sui loro dispositivi e di avviare il tracciamento delle attività tramite gli stessi cookie;
• il consenso ai cookie deve essere “informato” e basato su un’esplicita azione positiva; tali azioni possono includere, in base alle disposizioni previste dalle singole autorità locali – e quindi anche dal Garante Privacy italiano-, il proseguimento della navigazione, come un click su un link o lo scorrimento della pagina, o altre modalità che richiedano all’utente di procedere attivamente;
• la Cookie Law non richiede che il gestore del sito fornisca agli utenti la possibilità di gestire le preferenze di ogni singolo cookie direttamente dal sito o app, ma solo che si preveda un sistema chiaro per ottenere un consenso informato, oltre a un mezzo per la revoca del consenso e che garantisca, attraverso un blocco preventivo, che non venga effettuato alcun trattamento mediante cookie prima che il consenso sia stato effettivamente acquisito;
• la Cookie Law non richiede di elencare in dettaglio i cookie di terza parte utilizzati, ma solo di indicarne la categoria di appartenenza e la finalità di trattamento;
• sebbene la Cookie Law non imponga al gestore del sito di offrire all’utente la possibilità di gestire il consenso per i cookie di terza parte direttamente dal proprio sito o app, è necessario informare gli utenti dell’utilizzo di tali cookie e delle finalità di trattamento, insieme con un riferimento alle relative privacy/cookie policy ed alle eventuali modalità di revoca del consenso (disabilitazione dei cookie).

Dal punto di vista normativo la difficoltà nell’interpretazione della corretta gestione dei cookie e di altre tecnologie similari risiede nel fatto che l’attuale normativa di riferimento, la direttiva ePrivacy (Direttiva 2002/58/CE del Parlamento Europeo e del Consiglio, del 12 luglio 2002, relativa al trattamento dei dati personali e alla tutela della vita privata nel settore delle comunicazioni elettroniche) è in fase di aggiornamento e non è stata abrogata direttamente dal Regolamento UE 2016/679 (GDPR). Quindi, la normativa precedente e il GDPR devono convivere nella regolamentazione di molti aspetti tra cui la problematica dei cookie. Dal punto di vista tecnico, i cookie sono in veloce e rapida evoluzione e spesso si fatica a individuarne la corretta gestione dal punto di vista normativo.

Anche recenti sentenze a livello europeo hanno fatto temere i gestori di alcuni siti di non essere a norma secondo la normativa privacy vigente.

Mentre da alcune parti si leggono interpretazioni più restrittive secondo le quali ogni sito che utilizzi non solo cookie tecnici, ma anche cookie analitici e di terze parti in grado di monitorare in qualche modo il comportamento degli utenti, inoltre dovrebbe richiedere esplicito consenso all’utente per ogni singola categoria di cookie e dare la possibilità di modificare tale consenso; altri continuano a gestire i cookie con un consenso per l’impiego di tutti i cookie basato su un semplice movimento del mouse sulla pagina web oppure del tipo “se continui a navigare nel sito accetti l’uso dei cookie”. I siti che hanno interpretato in maniera più restrittiva la normativa sui cookie legandola al consenso richiesto dal GDPR sono comunque davvero pochissimi. Tale sistema di gestione dei cookie e dei relativi consensi è davvero pesante, lato sito web, ma potrebbe essere demotivante anche per i “naviganti”. Non a caso sono nati plugin quali “I don’t care about cookies” di Chrome.

Considerando che gran parte dei cookie sono di fatto anonimi, in quanto non permettono l’identificazione di una persona fisica che naviga sul nostro sito web, ma solo di un identificativo di un utente anonimo, forse dire semplicemente che il sito utilizza dei cookie e se vuoi disabilitarli ti leggi la cookie policy che ti spiega dove trovare le istruzioni per disabilitare i vari tipi di cookie nei diversi browser non è poi un approccio così sbagliato.

Interessante è la Guida ai cookie e tecnologie similari pubblicata dall’ICO che esamina nel dettaglio la situazione normativa sui cookie in questo momento di transizione, con numerosi riferimenti a normative – tra cui ovviamente il PECR (The Privacy and Electronic Communications – EC Directive- ) Regulations) del 2003 – e linee guida sull’argomento. Tra l’altro, si legge nella guida, che il responsabile della corretta gestione del sito è identificabile nel gestore del sito, non nel titolare del trattamento, ovvero il proprietario del sito, colui che lo ha registrato e ne paga il relativo canone.

Questa interpretazione aumenta le responsabilità in capo al web developper e al web manager, come prospettato in precedenza.

Ma la difficile interpretazione di aspetti che sono normati dalla Direttiva e-Privacy e dal GDPR non riguarda solo i cookie, ma tutto l’ambito del digital marketing. E purtroppo anche le interpretazioni dell’EDPB (Opinion 05/2019 e Statement 03/2019) non chiariscono in pratica come operare in modo conforme. Questa confusione potrà portare a sanzioni limitate oppure a sanzioni fortemente contestabili e, quindi, che non saranno rese effettive.

Altro aspetto non proprio chiaro è quello del marketing diretto svolto rifacendosi al legittimo interesse come base giuridica del trattamento a fronte di quanto scritto nel Considerando 47 del GDPR.

L’invio di newsletter a clienti e contatti vari (i cui nominativi sono stati raccolti chissà quando in situazioni varie quali incontri commerciali, fiere ed altri eventi e così via) è lecito sulla base del legittimo interesse del titolare del trattamento? È necessario richiedere il consenso dell’interessato? Ma se non lo riesco ad ottenere per pigrizia dell’interlocutore non posso più inviare le mie newsletter? Ma i miei concorrenti lo fanno!

Ecco alcune frasi tipiche degli uffici commerciali e del marketing di diverse organizzazioni.

Probabilmente in tema di accountability un CRM che è in grado di raccogliere varie informazioni sui nostri contatti commerciali – tra cui la data e le modalità di acquisizione dei dati personali, lo stato di cliente o prospect a cui è stata fatta un’offerta in passato, ecc. – potrebbe aiutare molto per dimostrare di aver seguito procedure coerenti con i principi del GDPR.

In attesa della pubblicazione della versione definitiva del Regolamento e-Privacy occorre pertanto orientarsi in questa disciplina con le dovute cautele e, soprattutto, documentando ogni decisione presa coerentemente con la propria interpretazione della normativa.

ICO - Indicazioni per l’uso dei cookie e di similari tecnologie

EDPB - Opinion 5/2019 on the interplay between the ePrivacy Directive and the GDPR

[Download non trovato]

Il principio di limitazione dei tempi di conservazione dei dati personali è stato incluso nel Regolamento UE 679/2016 (il c.d. GDPR) ed è ribadito in diversi punti del Regolamento stesso. Ad esempio, al considerando 39 troviamo scritto:

“…Da qui l’obbli­go, in particolare, di assicurare che il periodo di conservazione dei dati personali sia limitato al minimo necessario. I dati personali dovrebbero essere trattati solo se la finalità del trattamento non è ragionevolmente conseguibile con altri mezzi. Onde assicurare che i dati personali non siano conservati più a lungo del necessario, il tito­lare del trattamento dovrebbe stabilire un termine per la cancellazione o per la veri­fica periodica. È opportuno adottare tutte le misure ragionevoli affinché i dati per­sonali inesatti siano rettificati o cancellati.”

Tale principio prevede delle eccezioni, anche quando l’interessato ha esercitato il diritto all’oblio; al considerando 65, infatti, troviamo scritto:”… Tuttavia, dovrebbe essere lecita l’ulteriore conservazione dei dati personali qualora sia necessaria per esercitare il diritto alla libertà di espressione e di informazione, per adempiere un obbligo legale, per eseguire un compito di interesse pubblico o nell’esercizio di pubblici poteri di cui è investito il titolare del trattamento, per motivi di interesse pubblico nel settore della sanità pubblica, a fini di archivia¬zione nel pubblico interesse, di ricerca scientifica o storica o a fini statistici, ovvero per accertare, esercitare o difendere un diritto in sede giudiziaria.”

La limitazione della conservazione dei dati personali è un obbligo in capo al Titolare del trattamento, ma anche al Responsabile (cfr. considerando 81: “Dopo il completamento del trattamento per conto del titolare del trattamento, il responsabile del trattamento dovrebbe, a scelta del titolare del trattamento, restituire o cancellare i dati personali salvo che il diritto dell’Unione o degli Stati membri cui è soggetto il responsabile del trattamento prescriva la conservazione dei dati personali.”).

Il principio di limitazione alla conservazione è comunque esposti in maniera tassativa all’articolo 5 (Principi applicabili al trattamento di dati personali), punto c), quando il GDPR ci informa che i dati personali sono: “conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati; i dati personali possono essere conservati per periodi più lunghi a condizione che siano trat¬tati esclusivamente a fini di archiviazione nel pubblico interesse, di ricerca scientifica o storica o a fini statistici, conformemente all’articolo 89, paragrafo 1, fatta salva l’attua¬zione di misure tecniche e organizzative adeguate richieste dal presente regolamento a tutela dei diritti e delle libertà dell’interessato («limitazione della conservazione»);”.

I limiti temporali di conservazione dei dati personali sono citati anche all’articolo 6 (Liceità del trattamento), relativamente al fatto che la base giuridica del trattamento potrebbe regolamentare anche i tempi di conservazione.

Il periodo di conservazione massimo (ovvero il termine per la cancellazione dei dati personali) deve essere anche documentato, come ci indica l’articolo 13 – relativamente alle informazioni da fornire all’interessato, ovvero la c.d. “Informativa privacy” – al comma 2 a): “il periodo di conservazione dei dati personali oppure, se non è possibile, i criteri utilizzati per determinare tale periodo;”.

Infine, all’articolo 30 (Registri delle attività di trattamento), il GDPR impone di documentare – al comma 1 f) – “ove possibile, i termini ultimi previsti per la cancellazione delle diverse categorie di dati;”.

Se da un lato il principio di limitare la conservazione dei dati personali allo stretto necessario per espletare le finalità del trattamento è abbastanza chiaro e se ne comprende la ratio, non fosse altro che per il fatto che una conservazione eccessiva di archivi di dati personali espone tali dati a maggiori rischi di perdita di riservatezza degli stessi, dall’altro non è sempre facile soddisfare “alla lettera” tale principio.

Passati i primi tempi di attuazione del GDPR, nei quali molti hanno indicato nelle informative (peraltro sollevando diversi dubbi – anche da parte di chi scrive – sulla correttezza dell’affermazione) che i dati personali sono conservati per il tempo necessario a completare il trattamento per il quale ne è stata prevista la raccolta, si è iniziato a porsi parecchi interrogativi. Vediamo quali.

Relativamente ai dati del personale dipendente di un’azienda, chiaramente i dati relativi alle buste paga, al versamento dei contributi e tutte le evidenze di aver adempiuto a tutti gli obblighi di legge da parte del Datore di Lavoro è corretto che vengano mantenuti per 10 anni dopo la rescissione del rapporto di lavoro. Viceversa, come ci si deve comportare relativamente a tutte le registrazioni presenti in azienda relative alle attività svolte dal dipendente e dalle sue competenze? Mi riferisco a schede di formazione del personale o attestanti le specifiche competenze; registrazioni di attività, verifiche e controlli svolti, partecipazioni a riunioni; redazione, verifica ed approvazione di documenti emessi e così via. Per non parlare della posta elettronica: se la casella di posta elettronica personale deve essere disattivata appena possibile dopo l’interruzione del rapporto contrattuale del dipendente o collaboratore con l’azienda (è utile impostare un inoltro delle e-mail in ingresso verso altra casella, con risposta automatica al mittente comunicando che la persona non è più in forza all’azienda, ma non tutti lo fanno), che ne sarà degli archivi di posta elettronica?

Qui si apre un altro problema: gli archivi di posta spesso contengono informazioni di business, oltre a dati personali di dipendenti, collaboratori, persone che rappresentano clienti e fornitori (effettivi o potenziali) ed applicare un criterio di retention massima a tutta la posta potrebbe causare la perdita di informazioni importanti. Questo problema è spesso dovuto alle cattive abitudini delle aziende di conservare i documenti e le informazioni di business negli archivi di posta elettronica anziché impiegare sistemi di gestione documentale e applicativi gestionali specifici (CRM, software pe la gestione dei progetti, applicativi di issue & bug tracking/management nello sviluppo software, sistemi di ticketing per gestire le richieste di assistenza, ecc.). In tal caso il problema è organizzativo, non è la privacy che impone regole strane poco gestibili!

Cancellare selettivamente dalle e-mail le informazioni relative ad un numero circoscritto di persone fisiche è comunque infattibile con gli strumenti attualmente disponibili. Dunque che ne è dei diritti alla cancellazione dei propri dati personali esercitabili dall’interessato? In questo caso forse chi ha scritto il Regolamento ha mancato di senso pratico e tuttora nessuno ha pubblicato delle linee guida al riguardo.

Da un punto di vista strettamente teorico è possibile soddisfare la richiesta di un cliente (più probabilmente un privato) che chiede la cancellazione dei propri dati dagli archivi aziendali: fatti salvi gli obblighi di conservazione dei dati relativi a fatture ed ordini per adempiere ad obblighi contabili e fiscali, potrebbe essere semplice cancellare i dati del cliente nell’anagrafica del gestionale e/o del CRM. Ma come si fa a cancellare i dati personali del cliente da tutta la documentazione prodotta internamente e presente in altri archivi del file system, all’interno di file di Office, compresa la posta elettronica? Al momento non credo ci siano applicazioni in grado di gestire una cancellazione così selettiva, tenendo anche presente che nei documenti aziendali sono presenti dati personali di uno o più soggetti interessati, ma anche altre informazioni di business. Non sarebbe dunque opportuno cancellare un documento, magari recente, perché contiene i dati personali di una persona che ha esercitato il diritto all’oblio; infatti si cancellerebbero anche altre informazioni importanti. Viceversa, la cancellazione specifica dei soli dati personali dell’interessato (ad esempio sostituendoli con la stringa “XXXXX”) non è praticabile in modo automatico su grandi moli di documenti con i software a disposizione oggi.

Sempre relativamente ai dati personali dei clienti i termini di cancellazione potrebbero essere giustamente allungati dal titolare del trattamento per cautelarsi a fronte di richieste di risarcimento danni, anche da parte di terzi, contenziosi o indagini dell’Autorità Giudiziaria. In buona sostanza per poter dimostrare di aver svolto il proprio compito con diligenza e rispettando le regole. Infatti, al di là dei tempi di prescrizioni previsti dalla legge, in certi settori – ad esempio quello delle costruzioni o quello sanitario – potrebbe essere necessario garantire la bontà del proprio operato per parecchi anni dopo lo svolgimento del servizio.

 

In certi casi la conservazione dei dati oltre il periodo strettamente necessario potrebbe costituire semplicemente un vantaggio per l’interessato. Ad esempio nel settore della sanità privata, se escludiamo i dati sanitari relativi a ricoveri ed interventi chirurgici – per i quali la legge prevede la conservazione a tempo illimitato -, il fatto di conservare gli esiti di un esame svolto presso la struttura sanitaria potrebbe costituire un indubbio vantaggio per il paziente che si reca nella medesima struttura per svolgere nuovamente il medesimo esame o altri esami o visite di controllo per i quali sarebbe utile disporre delle informazioni relative all’anamnesi del paziente: l’eventuale smarrimento del referto passato da parte dell’interessato potrebbe non essere deleterio per lo stesso paziente. Certamente, in questo caso aumentano i rischi di perdita di riservatezza dei dati personali (appartenenti a particolari categorie di dati), ma quale principio deve prevalere? Il rispetto della privacy o il servizio al cliente? In assenza di una legislazione specifica che imponga limiti di cancellazione determinati o consenta la conservazione per periodi lunghi dei dati personali la scelta resta difficile.

Nel settore del direct-marketing, poi, la presenza di dati personali in un CRM o in una mailing-list per l’invio di newsletter potrebbe costituire un trattamento illecito di dati personali senza il consenso dell’interessato o in assenza di altre basi giuridiche per il trattamento. Fermo restando l’obbligo di consentire la cancellazione dalla mailing-list ad ogni invio di comunicazioni, quanto tempo possiamo mantenere i dati nel nostro database per l’invio di newsletter commerciali? Per sempre se l’interessato non esprime la volontà di non ricevere più comunicazioni? Quando cessa di essere valida la finalità del trattamento in oggetto?

Per le attività promozionali legate alle fidelity card esistevano – prima del GDPR – dei provvedimenti del Garante italiano che fissavano i limiti di conservazione dei dati e delle relative campagne promozionali in due anni, salvo deroghe concesse in settori particolari.

Come citato all’inizio del presente articolo, tali regole si applicano anche a chi opera come Responsabile del Trattamento secondo l’articolo 28 del GDPR, ma quanti consulenti del lavoro cancelleranno i dati dei dipendenti di un proprio cliente (Titolare del Trattamento) dagli archivi del proprio applicativo per la gestione delle paghe una volta che si è interrotto il rapporto di collaborazione?

Come si può intuire da quanto esposto finora il problema non è solo definire i limiti di conservazione temporale dei dati personali, ma anche attuare i criteri stabiliti.

Dal punto di vista informatico non so quali software sono in grado di cancellare selettivamente i dati in base ad un determinato criterio di conservazione? Probabilmente alcuni applicativi non permettono neanche la cancellazione di una scheda anagrafica per problemi di “integrità referenziale” (se cancello un’anagrafica di una persona si dovrebbero cancellare anche tutte le informazioni dipendenti legate alla medesima anagrafica, ma ciò non sempre è opportuno per evitare di cancellare altre informazioni necessarie). Sicuramente chi svilupperà i programmi software che gestiscono dati personali dovrà considerare anche questo aspetto legato alla privacy, nelle specifiche che renderanno il prodotto “privacy by design”.

In generale la necessità di dover soddisfare un determinato criterio di cancellazione dei dati comporta l’adozione di criteri di archiviazione delle informazioni, sia in digitale, sia su supporto cartaceo, adeguati di conseguenza. Facciamo un semplice esempio per chiarire meglio il concetto.

Se un’impresa conserva le fatture emesse ai clienti nel fascicolo della commessa, dove la commessa si può protrarre per diversi anni, oppure le conserva nella cartella del cliente, si troverà in difficoltà quando si tratterà di cestinare le fatture più vecchie di 10 anni. Dovrà andare a cercare le fatture in tutte le cartelle delle commesse o del cliente per ricercare i documenti obsoleti!

Viceversa, l’impresa che archivierà le fatture in ordine cronologico, per anno di competenza, potrà più agevolmente distruggere (non gettare nei rifiuti in modo indiscriminato) i documenti relativi ad ogni anno di competenza.

Chiaramente il GDPR è entrato in vigore quando le organizzazioni di ogni tipo avevano già impostato criteri di “data retention” ed ora si trovano a dover gestire il principio di limitazione del periodo di conservazione dei dati personali anche sul passato. Naturalmente il Regolamento non dice nulla sull’applicabilità di questo principio anche sui dati già presenti negli archivi delle organizzazioni titolari del trattamento al momento dell’entrata in vigore del Regolamento.

Indubbiamente ci sarebbe estremo bisogno di chiarimenti sui criteri di conservazione da adottare per i dati personali al tempo del GDPR, in primis da parte del nostro Garante per la Protezione dei Dati Personali (si ricorda che si attende ancora la nomina del nuovo Garante Privacy da parte del Governo, in quanto il mandato precedente è già scaduto), poi anche da parte delle istituzioni europee.