Perché la sentenza Schrems II sta avendo un impatto significativo sulla gestione dei dati personali effettuati dalle aziende dell’Unione Europea? Chi si deve preoccupare di questa sentenza? Quali azioni dovranno essere intraprese dalle aziende, soprattutto le piccole e medie, per capire se e come adeguarsi? In questo articolo faremo il punto della situazione dopo circa sei mesi dalla sentenza Schrems II.

Una breve premessa per chi non conoscesse la sentenza Schrems II.

Lo scorso luglio la Corte di Giustizia Europea ha giudicato non valido il c.d. Privacy Shield, ovvero l’adeguatezza della protezione offerta dalle condizioni previste nel suddetto accordo, detto anche “Scudo per la Privacy”, relativamente ai trasferimenti di dati personali tra la UE e gli Stati Uniti. Poiché moltissimi trasferimenti di dati personali fra UE ed USA – di base, ricordiamo, sono possibili solo sotto determinate condizioni – erano basati sul Privacy Shield, capite che tutti questi trasferimenti extra UE verso gli USA, dopo la sentenza Schrems II, in assenza di altre condizioni di adeguatezza, diverrebbero illegali.

Il tutto, infatti, è disciplinato dal Capo V (artt. Da 46 a 50) del Regolamento UE 679/2016 (GDPR) che, come principio, sancisce il divieto di “esportare” dati personali fuori UE, salvo il soddisfacimento di determinate condizioni. Tra queste ultime, le decisioni di adeguatezza della Commissione Europea (cfr. art. 45 del GDPR), ovvero esportazioni di dati in Paesi per i quali la Commissione Europea ha giudicato adeguate le garanzie sulla protezione dei dati personali del Paese “importatore” di dati personali (tra cui ad es. la Svizzera). Nel momento in cui – a causa di Schrems II – è “saltata” la condizione di adeguatezza stabilita dal Privacy Shield, si è reso necessario identificare un’altra base giuridica valida per il trasferimento dei dati fra UE e Stati Uniti d’America.

Ma perché il Privacy Shield è stato invalidato?

Secondo la Corte, le limitazioni della protezione dei dati personali che risultano dalla normativa interna degli Stati Uniti in materia di accesso e di utilizzo, da parte delle autorità statunitensi, di siffatti dati trasferiti dall’Unione verso tale Paese terzo, e che sono state valutate dalla Commissione nella decisione 2016/1250, non sono inquadrate in modo da rispondere a requisiti sostanzialmente equivalenti a quelli richiesti, nel diritto dell’Unione, dal principio di proporzionalità, giacché i programmi di sorveglianza fondati sulla suddetta normativa non si limitano a quanto strettamente necessario. Fondandosi sulle constatazioni che compaiono in tale decisione, la Corte rileva che, per taluni programmi di sorveglianza, da detta regolamentazione non emerge in alcun modo l’esistenza di limiti all’autorizzazione, in essa contenuta, dell’attuazione di tali programmi e neppure l’esistenza di garanzie per gli stranieri che possono esserne potenzialmente oggetto. La Corte aggiunge che la stessa normativa, pur se prevede requisiti che devono essere rispettati dalle autorità statunitensi nell’attuare i programmi di sorveglianza considerati, non conferisce agli interessati diritti nei confronti delle autorità statunitensi azionabili dinanzi ai giudici.

Se non fosse chiaro quanto asserito dalla Corte UE si consiglia la visione del film “Snowden” per capire meglio di cosa stiamo parlando. In sintesi, ricordiamo che il “Cloud Act” emanato dagli USA consente alle autorità statunitensi, forze dell’ordine e agenzie di intelligence, di acquisire dati informatici dagli operatori di servizi di cloud computing a prescindere dal luogo dove questi dati si trovano; quindi, anche se sono su server fuori dagli USA. La sola condizione è che questi operatori siano sottoposti alla giurisdizione degli Stati Uniti, oppure anche siano società europee che hanno una filiale negli Stati Uniti o che operano nel mercato americano.

In realtà la questione di esportazione dei dati personali extra UE va distinta nei seguenti punti:

1. Trasferimenti di dati personali – in formato digitale o analogico – fra UE e USA
2. Trasferimenti di dati personali – esclusivamente in formato elettronico – fra UE ed aziende statunitensi o comunque aventi una sede in USA
3. Trasferimenti di dati personali fra UE e Paesi extra UE diversi dagli USA per i quali non esiste una decisione di adeguatezza.

La sentenza Schrems II, con la conseguente invalidazione del Privacy Shield, riguarda strettamente il punto 1 sopra elencato, mentre il CLOUD Act (Clarifying Lawful Overseas Use of Data Act, approvato a marzo 2018) è relativo al punto 2 e per il momento è soggetto a Schrems II solo la parte riguardante i dati trasferiti dalla UE verso Società statunitensi nel territorio degli USA.

Non vorrei scendere in ulteriori considerazioni su altri aspetti oltre a quelli strettamente inerenti Schrems II, se non altro per motivi di spazio, sebbene da un lato sia auspicabile che non si ripetano situazioni in cui la digitalizzazione di consistenti archivi cartacei contenenti dati personali (anche della P.A.) venga svolta – essenzialmente per motivi di costo – in Paesi dell’Est Europa o dell’Africa, dall’altro comunque bisogna pensare anche alle aziende europee che svolgono attività commerciali e di assistenza in Paesi del Medio Oriente o del Sud Est Asiatico dove la privacy è considerata l’ultimo dei problemi.

Una scappatoia alla cancellazione del Privacy Shield, per consentire il trasferimento di dati personali, potrebbe essere costituita dall’applicazione delle c.d. Clausole Contrattuali Tipo (Standard Contractual Clause o SCC, in base all’art. 46 del GDPR), approvate dalla Commissione Europea prima dell’avvento del GDPR e confermate successivamente, ma purtroppo le SCC sono affette dal medesimo vizio del Privacy Shield:. Infatti, essendo clausole contrattuali fra il titolare (o responsabile) del trattamento entro la UE e l’importatore (titolare o responsabile del trattamento) negli USA, non possono prevedere garanzie sui diritti degli interessati che impediscano a enti governativi USA di accedere – per motivi di sicurezza – a dati personali memorizzati in datacenter del proprio territorio (e non solo, come abbiamo visto a causa del CLOUD Act).

Perché Schrems II ha una portata così estesa? Occorre considerare che l’oggetto del trasferimento dati non riguarda solo archivi cartacei, ma naturalmente anche dati in formato digitale memorizzati in cloud presso datacenter ubicati fuori UE, nello specifico negli USA. Poiché questa è la situazione in cui ricadono i più importanti provider di servizi cloud del mondo, ovvero Microsoft, Google, Amazon e così via (Apple non ha propri datacenter ma si rivolge agli altri provider noti) è chiaro che la problematica riveste una grandissima quantità di dati gestiti in cloud da numerose aziende europee.

La prima risposta di molti Provider è stata l’adesione alle Clausole Contrattuali Tipo, che però, come abbiamo visto, hanno il medesimo problema che ha invalidato il Privacy Shield, per cui sarebbero necessarie ulteriori garanzie di sicurezza nel trasferimento di dati (Le Linee Guida EDPB 02/2020 citano …«a condizione che siano messe in atto misure tecniche e organizzative adeguate per salvaguardare i diritti e le libertà degli interessati, come misure tecniche supplementari (ad esempio misure di sicurezza, pseudonimizzazione e restrizioni di accesso»).

Secondo le opinioni di molti esperti a livello internazionale tali ulteriori garanzie potrebbero essere fornite da misure di sicurezza ulteriori quali la pseudonimizzazione e la cifratura. Da un punto di vista concettuale è chiaro che se il titolare o responsabile del trattamento che desidera esportare i dati personali in un cloud negli Stati Uniti, attraverso la pseudonimizzazione o la cifratura degli stessi si garantirebbe contro ingerenze di apparati governativi degli Stati Uniti, poiché i dati a cui avrebbero eventualmente accesso sarebbero non identificabili, ovvero non sarebbe comunque possibile identificare le persone fisiche proprietarie dei dati in questione. Soluzione giuridicamente valida, ma poco applicabile dal punto di vista pratico.

Immaginiamo, infatti, applicazioni in cloud utilizzate da tempo che memorizzano i loro database in piattaforme cloud ospitate in datacenter in USA: a parte il fatto che i contratti con i fornitori sono stati sottoscritti pre GDPR e pre Schrems II, e dunque difficilmente emendabili a costi contenuti, come possiamo pensare di cifrare il database che non è stato predisposto in tale ottica? Oggi parleremmo di privacy-by-design, ma il discorso potrebbe essere valido per i nuovi applicati, fermo restando che la scelta si riduce molto se imponiamo questo vincolo.

Tantomeno parlare di pseudonimizzazione degli archivi digitali, ubicando tabelle diverse in datacenter diversi. Occorrerebbe una riprogettazione di tutto il sistema informatico… certamente si può fare tutto, ma a quali costi? E poi su campi anagrafici come ci si deve comportare? Se la mail è del tipo nome.cognome@dominio.it il dato personale resta, i campi contenenti nome e cognome non è che li possiamo dividere a piacimento.

Personalmente ho assistito a diversi eventi (naturalmente rigorosamente “webinar” on line in questo periodo) nei quali alcuni esperti giuristi hanno fornito indicazioni su come le aziende dovrebbero procedere per adeguarsi al post Schrems II e, francamente, ho sentito anche molti pareri e risposte alle domande dei partecipanti, per così dire, “poco pragmatiche” e di non semplice applicazione, soprattutto per le piccole  e medie organizzazioni del nostro Paese.

Tra le risposte più paradossali ricordo la seguente: “se un collaboratore di un’azienda sita nella UE con dati in cloud nella UE accede, da una postazione di lavoro negli USA, a dati (personali) memorizzati negli archivi digitali dell’azienda, si tratta di trasferimenti di dati extra UE?” La risposta è stata “si, perché il collaboratore accedendo ai dati tratta dati personali”.

Ora, chiaramente non si può estrapolare una domanda dal contesto in cui avviene l’elaborazione dei dati, che presuppone probabilmente un’azienda multinazionale che magari dovrebbe aver stabilito delle c.d. “norme vincolanti d’impresa” (o binding corporate rules) come disciplinato dall’art. 47 del GDPR, ma prescindiamo da ciò (l’argomento meriterebbe una trattazione separata più ampia) e facciamo un ragionamento. Se la mia organizzazione – sita nella UE con Server nella UE – pubblica, attraverso un portale web ad accesso riservato (tralasciamo per un momento le misure di sicurezza implementate per il controllo degli accessi), alcune informazioni contenenti anche dati personali, probabilmente il portale web sarà accessibile anche fuori dallo Spazio Economico Europeo, salvo aver implementato particolari controlli (comunque aggirabili accedendo attraverso VPN che geolocalizzano l’indirizzo IP in Europa). Si tratta di trasferimento di dati personali extra UE? Non può essere, perché in tal caso qualunque dipendente o collaboratore di un’azienda ubicata nella UE che va in trasferta in un Paese terzo, per il quale non esistono decisioni di adeguatezza sulla regolamentazione a protezione dei dati personali, e che accede anche semplicemente alla posta elettronica di lavoro tramite dispositivo mobile effettuerebbe un trattamento di dati personali con trasferimento extra UE! Allora bisogna guardare soltanto a dove i dati sono conservati, anche se questo principio non è stato definito in modo preciso e se qualche esperto di privacy vi dicesse che è sufficiente una visualizzazione dei dati su un dispositivo in U.S. per rientrare nel trasferimento dei dati extra UE o ha interpretato male il Regolamento oppure c’è una falla nel regolamento UE 679/2016 stesso.

Ma torniamo al problema del cloud negli Stati Uniti, che si estende a tutti i cloud gestiti da società americane (ma qui non siamo nell’ambito di trasferimenti extra-UE).

Alcuni autorevoli esperti della materia indicano questi passi per affrontare e gestire il problema a livello aziendale:

1. Identificare gli archivi contenenti dati personali conservati e/o gestite da fornitori al di fuori dello Spazio Economico Europeo (SEE); ma questo avrebbe dovuto essere già stato fatto.
2. Fra questi vanno identificati gli archivi che attualmente sono gestiti negli Stati Uniti sfruttando, come base giuridica, il Privacy Shield.
3. Esaminare i relativi contratti di gestione dei dati in cloud con i fornitori coinvolti e richiedere ai medesimi su quali nuove condizioni sono resi possibili i trattamenti di dati personali fuori dallo SEE.
4. Contrattare con i fornitori nuove condizioni contrattuali per rendere lecito il trasferimento di dati extra UE (es. SCC integrate con misure di garanzia aggiuntive, ecc.).
5. In alternativa al punto precedente migrare il cloud storage in datacenter nella UE.
6. Adeguare le informative privacy ed il Registro delle attività di trattamento di dati personali nei punti relativi al trasferimento dei dati in un Paese Terzo o Organizzazione internazionale.

In generale, se il trasferimento dei dati non riguarda gli Stati Uniti, ma un altro Paese per il quale non è presente una decisione di adeguatezza della Commissione Europea, si consiglia – prima del punto 4 – di approfondire quali requisiti legislativi relativi alla protezione dei dati personali sono in vigore nel Paese ove vengono esportati i dati, al fine di decidere se il trasferimento può essere adeguatamente tutelato da clausole contrattuali stipulate con il fornitore.

Le procedure indicate sono formalmente corrette, ma alcune di queste attività sono estremamente difficoltose ed onerose per le nostre PMI. Oltre ad un eventuale cloud nel quale può essere “appoggiato” un sistema informatico, occorrerebbe valutare:

• l’eventuale piattaforma web utilizzata dal consulente del lavoro per elaborare le paghe (che difficilmente quest’ultimo ha gestito in conformità al GDPR con una gestione in qualità di sub-responsabile del trattamento);
• i servizi di office automation in cloud forniti da Microsoft (Office 365, ora Microsoft 365 e OneDrive) o Google /Gmail, GDrive, ecc.), ma anche le tanto diffuse piattaforme di web-meeting o videoconferenza quali Microsoft Teams o Skype, Google Meet, GoToMeeting, ecc. che si servono di datacenter collocati negli USA ed altrove.
• Io servizi di invio mail e newsletter basati sul web.

Alcuni di questi servizi possono essere “spostati” su datacenter in Europa, altri no. Ma sono servizi che molte aziende utilizzano da tempo!

Ad aggravare la situazione occorre notare che le piattaforme Google Classroom e Microsoft for Education, tanto importanti in questo periodo di Didattica A Distanza e che hanno parzialmente salvato l’istruzione scolastica in questi mesi, sono state ufficialmente approvate dall’AGID (Agenzia per l’Italia Digitale) in quanto ritenute “sicure”, soprattutto rispetto ad altre che hanno registrato violazioni di dati importanti (es. Zoom). Ma non solo: il Ministero della Giustizia ha autorizzato lo svolgimento di udienze dei processi civili e penali in modalità “a distanza”, durante l’emergenza Covid-19, attraverso la piattaforma Microsoft Teams. Cosa facciamo? Cambiamo tutto in questo momento particolare di emergenza?

Tra le risposte che ho sentito fornire da diversi legali in alcuni webinar è che i provider – quali Microsoft e Google – forniscono la possibilità di scegliere l’ubicazione del datacenter in Europa… ma a quale prezzo? Gli abbonamenti, ad es. a Google Workspace Enterprise, che consentono di scegliere l’ubicazione del datacenter costano molto di più della semplice licenza business per i medesimi servizi!

Perché una piccola o media organizzazione, che probabilmente sta facendo fatica a reggere l’effetto devastante di questa pandemia, dovrebbe sostenere questi ulteriori costi?  Solo perché esiste la recondita possibilità che l’FBI o l’NSA vadano un domani a leggere i dati personali trattati da società statunitensi? Al proposito il Dipartimento del Commercio degli Stati Uniti ha pubblicato, a settembre 2020, un Whitepaper denominato “Information on U.S. Privacy Safeguards Relevant to SCCs and Other EU Legal Bases for EU-U.S. Data Transfers after Schrems II” dove la portata del problema viene significativamente sminuita, possono essere reperiti altri articoli sul web che minimizzano la possibilità che enti governativi USA possano violare diritti sulla protezione dei dati dei cittadini dell’Unione. Come in altre questioni bisogna “sentire tutte le campane”.

Se valutiamo correttamente questo rischio per gli interessati (i nostri dipendenti e/o i nostri clienti o persone fisiche che li rappresentano, ad esempio) possiamo facilmente capire che è ampiamente compensato dal fatto che i datacenter di Google e Microsoft sono molto più sicuri di un datacenter dislocato nella UE, in più le società di Mountain View e di  Redmond possono garantire, oltre a svariate certificazioni sulla sicurezza delle informazioni (ISO 27k) e sui datacenter, anche una ridondanza dello storage ineguagliabile. I nostri dati, infatti, non sono memorizzati in un unico datacenter, in Irlanda o negli Stati Uniti, ma sono replicati in altri datacenter, magari in Australia o in Sudamerica, garantendoci così la disponibilità dei dati anche in caso di grandi cataclismi localizzati quali terremoti, incendi o alluvioni, o emergenze pandemiche che impediscono al personale di svolgere le normali attività di manutenzione ICT.

Purtroppo, in questo caso, il GDPR non richiede di basarsi su una valutazione dei rischi, ma su basi giuridiche che possono essere valide o meno. Infatti, se leggete le FAQ dell’EDPB tradotte dal nostro Garante per la Protezione dei Dati Personali potrete notare asserzioni molto forti, ovvero che il trasferimento di dati personali negli USA, in assenza di adeguate garanzie, è illegale e che non è previsto un periodo di transizione.

La questione, credo, non sia solo legale ed etica (protezione dei diritti delle persone fisiche relativamente ai loro dati personali), ma anche politica. La UE punta a un cloud europeo? Vogliono contrastare lo strapotere delle società americane in questo settore?

Di conseguenza credo che una soluzione – concreta e praticabile da tutti – debba essere trovata a livello politico, fra UE e USA, con la partecipazione di EDPB e/o altri Enti competenti in tema di privacy a livello internazionali. L’importante è che questi enti non perdano il buon senso e si calino nella realtà industriale e dei servizi delle organizzazioni di ogni tipo che operano nell’Unione.

Nel frattempo, quale consiglio dare alle piccole e medie imprese del nostro Paese? Sicuramente quello di percorrere gli step precedentemente indicati guidati dal buon senso. Ossia di fermarsi nel caso emergessero ostacoli insormontabili o comunque si configurassero soluzioni eccessivamente costose, e di aspettare che a livello più alto siano trovate delle soluzioni perseguibili.

Non vorrei che qualche organizzazione, perseguendo le strade più “rigoriste”, decida di abbandonare servizi efficienti e discretamente sicuri a fronte di soluzioni meno efficienti e soprattutto meno sicure, ad esempio eliminando un backup in cloud a fronte di un backup in locale.

Da un punto di vista formale l’escamotage potrebbe essere quello di ricorrere alle deroghe previste dall’art. 49 del Regolamento UE 679/2016, tra cui ad esempio il consenso dell’interessato, purché adeguatamente informato sui rischi che corrono i suoi dati personali (difficile far capire come stanno le cose realmente, impraticabile in molti casi) e modificare nel modo più generico possibile Informative privacy e Registro dei trattamenti.

Se nelle realtà di medio-piccole dimensioni al momento si trovano tutte le posizioni possibili, dal non prendere nemmeno in considerazione il problema, a reimpostare i sistemi informatici in modalità più “autarchiche”, nelle Aziende più ci si pone anche la domanda: quali alternative credibili ci sono ai servizi di Microsoft, Google, ecc.? Se dobbiamo lavorare in diversi Paesi del mondo dobbiamo adeguarci anche alla normativa vigente in quel Paese, privacy compresa.

Vedi anche: le FAQ EDPB su Schrems II tradotte dal Garante Privacy, il Whitepaper del Governo USA e le Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data.

Il Garante per la Protezione dei Dati Personali ha recentemente pubblicato delle “Linee Guida sull’utilizzo dei cookie ed altri strumenti di tracciamento” in consultazione pubblica. Quindi, in base ai commenti ricevuti da diverse fonti, emanerà successivamente le Linee Guida definitive.

In questo articolo, pertanto, fornisco alcune considerazioni personali sulle Linee Guida stesse ed in generale sull’argomento “cookie ad altre tecnologie traccianti”, che normalmente sono presenti sui siti web – ma anche su app per dispositivi portatili -, ad integrazione ed aggiornamento di quanto riportato in un mio precedente articolo. Si consideri anche che, nel frattempo, alcune Autorità di Controllo Europee (ICO, CNIL,…) hanno pubblicato proprie linee guida e l’EDPB ha più recentemente pubblicato le Linee Guida sul Consenso, che riportano anche alcuni esempi sulla gestione dei cookie.

Nel panorama generale dei siti web gestiti dalle imprese italiane si possono identificare due grandi categorie:

1. Siti basici, di tipo istituzionale e/o divulgativo, che rappresentano una sorta di pubblicità via web, brochure digitale online, priva di funzionalità dinamiche attive (ad eccezione, in alcuni casi, di un blog con articoli divulgativi su argomenti inerenti all’attività dell’impresa o dello studio professionale). In siti di questo genere non ci sono aree riservate a cui accedere previa registrazione, è solo presente un form di contatto per porre domande e richieste di informazioni al proprietario del sito. In alcuni casi è possibile iscriversi alla newsletter fornendo il proprio indirizzo e-mail, al fine di rimanere informati sulle novità, nuove proposte e nuovi articoli del blog. Li chiameremo siti del primo tipo.
2. Siti che prevedono attività di direct-marketing anche molto invasive; dunque, non solo cookie traccianti, ma anche raccolta di informazioni aggiuntive degli utenti, profilazione degli stessi con attività di re-marketing e marketing targettizzato in funzione delle preferenze degli utenti, registrazione al sito – anche con account social – ed eventuali attività di e-commerce. Li chiameremo siti del secondo tipo.

Fra queste due macro-categorie ci possono essere, ovviamente, situazioni intermedie, che si avvicinano più al primo o secondo tipo.

Al momento le interpretazioni prevalenti – soprattutto a livello europeo – dell’applicazione del GDPR e delle Linee Guida EDPB sul consenso – ed in parte anche queste Linee Guida del Garante Privacy italiano – rendono l’applicazione della normativa sui cookie piuttosto difficoltosa per le PMI, gli Studi Professionali e i singoli liberi professionisti che possiedono un sito web del primo tipo. Una gestione dei cookie granulare, fornendo la possibilità all’utente di decidere quali (tipi di) cookie accettare e quali no, costringerebbe queste organizzazioni a aderire ad uno dei servizi di gestione dei cookie e delle relative cookie policy e/o rivolgersi all’assistenza specialistica di un webmaster o società specializzate nello sviluppo e la gestione di siti web. Paradossalmente la creazione e manutenzione di un sito web per una piccola organizzazione – al netto del tempo necessario per creare ed aggiornare i contenuti – potrebbe costare meno di 100 euro l’anno (costi di registrazione del dominio, web hosting, database per ospitare CMS come WordPress, caselle di posta incluse), mentre la gestione dei cookie sarebbe più onerosa, anche semplicemente volendo gestire cookie tecnici e cookie analitici di prima parte e di terza parte (es. Google Analytics).

Dal punto di vista dell’utente medio, gli elementi più fastidiosi nella navigazione sul web sono possono invece essere classificati nei seguenti:

1. Subire banner pubblicitari molto invasivi, anche di argomenti non pertinenti con il sito internet che si sta consultando, con il rischio abbastanza frequente di cliccare involontariamente sul banner pubblicitario e, quindi, vedersi proiettati in siti non pertinenti e talvolta inappropriati, se non si sono impostati determinati filtri a livello di browser o di anti-malware.
2. Subire spamming e campagne pubblicitarie particolarmente invasive (a volte anche tramite telefonate commerciali indesiderate, se è stato in qualche modo carpito il numero di telefono) per il solo fatto di aver consultato un determinato sito o aver ricercato o visionato un determinato prodotto in un sito di e-commerce.
3. Dover continuamente accettare, rifiutare i cookie (o scegliere quali accettare e quali no) per ogni accesso ad una nuova pagina web, considerando anche la reiterazione dell’operazione ad ogni nuovo accesso allo stesso dominio effettuato in tempi diversi o tramite dispositivi diversi.

Il nuovo approccio alla gestione dei cookie ed altre tecnologie traccianti introducono sistematicamente il terzo elemento nell’elenco sovrastante, ma non eliminano a priori i disagi ed i disturbi dei primi due casi.

D’altro canto occorre considerare la seguente domanda: quanti utenti conoscono l’esatto significato delle diverse tipologie di cookie? Le informative che si vedono nella maggior parte dei siti, anche quelle gestite in modo automatico dai servizi specialistici di cookie management, non aiutano certamente l’utente a capire cosa egli potrebbe escludere e cosa accettare.

In altre parole, credo che anche l’approccio più rigoroso e garantista per la protezione dei dati personali dell’utente nella gestione dei cookie non cauteli adeguatamente l’utente stesso, soprattutto se minore, dalle situazioni di cui ai punti a) e b) sopra citati. L’applicazione delle regole sancite dalle linee guida a livello europeo ha finora portato ad aumentare la difficoltà dell’utente che volesse non accettare tutti i cookie di un sito o un servizio che utilizza a scopo di lucro i dati personali degli utenti (es. Google, Microsoft, Facebook, Amazon ed altri). Inevitabilmente i rischi per l’interessato nella gestione dei cookie di siti del primo tipo di piccole organizzazioni, ad eccezione di quelle che trattano dati sanitari, sono infinitamente inferiore ai rischi che corrono navigando su siti del secondo tipo. Purtroppo, il Regolamento e le Linee Guida pubblicate recentemente non recepiscono questa differenziazione e le relative cookie policy/privacy policy non sembrano evidenziare le enormi differenze per l’utente in queste due situazioni tipiche. Perché le scelte sulla gestione dei cookie non possono discendere da una valutazione dei rischi per i relativi trattamenti di dati personali? Tale valutazione potrebbe prendere in considerazione la gravità del rischio, ovvero delle conseguenze per l’interessato del trattamento dei cookie effettuato dal sito e dalle terze parti, e della probabilità che tale evento si verifichi (si consideri che cookie e indirizzi IP, ad esempio, non sono sempre dati personali, in molti casi non è possibile risalire da essi a persone fisiche individuabili).

In attesa che la normativa a livello europeo non sancisca le regole sui cookie e tecnologie similari in modo definitivo, attraverso il nuovo Regolamento e-Privacy, occorre prudenza nel definire regole prescrittive troppo severe a partire da interpretazioni del GDPR del concetto di consenso, quando la gestione di un consenso off-line (ad es. su un modulo cartaceo) è ben diversa da un consenso on-line (su un sito internet). E soprattutto la gestione dei diritti dell’interessato, come li prevede il RGPD, è alquanto complicata.

Relativamente all’inadeguatezza dello scrolling ad attestare il consenso dell’interessato, da un lato sono d’accordo, ma dall’altro viene da chiedersi perché certi banner pubblicitari possono essere talmente ingannevoli che l’utente facilmente finisce per essere veicolato su un sito indesiderato, senza che nessuno gli abbia chiesto se veramente avesse voluto navigare su tale sito. Dunque, occorrerebbe più coerenza nello stabilire regole omogenee in diversi contesto e, soprattutto, nel farle rispettare.

Riguardo all’uso, ritenuto illecito, dei c.d. cookie wall, mi permetto di dissentire in via generale, almeno per i siti del primo tipo. In particolare, mi riferisco a siti web che forniscono informazioni utili su diversi argomenti, tramite articoli del blog o sezioni specifiche (community, documenti da scaricare, ecc.): per i gestori di tali siti mi sembra legittimo richiedere l’accettazione di cookie analitici per il monitoraggio degli accessi al sito al solo fine di elaborare statistiche, necessariamente elaborate da terze parti, quali Google, per fornire informazioni a titolo gratuito. Il bilanciamento fra il servizio fornito a titolo gratuito e il minimo trattamento dei cookie mi sembra adeguato.

 Diverso potrebbe essere il caso in cui si subordina l’accesso al sito ad attività di profilazione più invasive, sebbene ci si potrebbe chiedere che differenza c’è rispetto alla sottoscrizione di fidelity card nei negozi fisici, che prevedono l’attivazione di raccolte punti con sconti e premi subordinate ad attività di profilazione a fini di marketing. Ancora una volta il cittadino e l’impresa richiedono coerenza a 360° nei diversi ambiti.

Un aspetto non completamente chiarito dalle linee guida è quello costituito dai plugin social presenti in molti siti web per la condivisione di contenuti su Facebook, Linkedin, Twitter, ecc.. In tal caso se l’utente intende condividere un articolo o una pagina di un sito web su un social network è bene comprendere che tale attività viene svolta attraverso l’account dell’utente nel social network, dunque la condivisione dei dati (utente X che condivide un articolo del sito Y sul social network Z tramite il proprio account social) avviene nella piena consapevolezza dell’utente, dunque non dovrebbe essere richiesto alcun consenso per mantenere questi plugin social nel proprio sito, a condizione che svolgano solo questo compito.

Analogamente un utente che naviga su un sito tramite Chrome dopo essersi autenticato con il proprio account Google, e magari aver effettuato una ricerca per arrivare proprio a quel sito, dovrebbe essere pienamente consapevole che la sua attività nel sito – e nelle pagine consultate prima e dopo – è stata completamente tracciata da Google, in maniera del tutto indipendente.

In generale credo possa essere accettabile, sempre per siti del primo tipo, richiamare alcune istruzioni generali per disabilitare i cookie direttamente nel browser, in base alle funzioni messe a disposizione da Firefox, Chrome, Edge, Safari, Opera ed altri browser, sebbene comunque alcuni siti richiederanno l’abilitazione dei cookie, anche quelli più invasivi per la privacy, per funzionare. Alleviando così l’onere in capo al proprietario del sito di implementare complicate gestioni dei consensi per tipologie di cookie.

L’obbligo di mantenere evidenza documentata del consenso obbligherebbe ancora una volta i proprietari dei siti di primo tipo a rivolgersi ai rispettivi gestori con attività onerose dal punto di vista economico. Ancora una volta dal punto di vista dell’utente che ha implementato nel browser funzionalità di cancellazione automatica dei cookie al termine della sessione si troverebbe a dover nuovamente acconsentire ai cookie ad ogni nuovo accesso al medesimo sito, benché il consenso sia già stato dato, magari il giorno precedente.

Meno oneroso sarebbe in ogni caso dimostrare un comportamento corretto da parte del proprietario del sito, ovvero l’applicazione di una procedura di accettazione o rifiuto dei cookie ad ogni accesso al sito, nella consapevolezza che la registrazione del precedente consenso sarebbe inutile laddove l’utente abbia cancellato automaticamente i cookie. Anche in questo caso occorre differenziare il consenso prestato on-line da quello off-line essenzialmente su modulistica cartacea, a vantaggio di una gestione semplificata e più snella per le piccole e medie organizzazioni, senza inutili sprechi di risorse economiche a fronte di modesti vantaggi e limitatissimi rischi per l’utente in termini di privacy.

Più in generale il contesto nel quale si trova l’utente comprende siti nei quali è impossibile disabilitare tutti i cookie e app su smartphone che richiedono genericamente l’accesso a risorse del dispositivo senza chiarire in quali casi vengono utilizzati i dati personali dell’utente (nome, numero di telefono, e-mail, le immmagini e i video memorizzati, ecc.) e dei suoi contatti.

Pur apprezzando il lavoro dell’Autorità Garante per la Protezione dei Dati personali che sta prendendo in considerazione anche le esigenze delle piccole e medie imprese del nostro tessuto economico, credo che molti aspetti di questo complicato argomento debbano ancora essere chiariti e resi applicabili in modo più snello.

Aggiornamento relativamente al Regolamento e-Privacy del 04/03/2021

Il Regolamento e-Privacy ha ottenuto dal Consiglio UE parere favorevole sulla versione finale del testo, con un mandato negoziale per la revisione definita delle regole in materia di tutela della riservatezza nell’uso di servizi di comunicazione elettronica. Ora ci si attende l’emanazione del nuovo Regolamento – che abrogherà la vecchia Direttiva e tutta la legislazione precedente in materia di cookie – entro qualche mese, al massimo entro l’anno 2021.Al momento della pubblicazione sulla G.U. Europea il Regolamento diverrà operativo (dunque sarà applicabile), ma sarà concesso un periodo transitorio di due anni per adeguarsi.

Si precisa che il Regolamento e-Privacy si applicherà a tutte le comunicazioni elettroniche, non solo ai dati personali, e pertanto riguarderà non solo le persone fisiche, ma anche le persone giuridiche.

Riguardo ai cookie la proposta pervenuta durante la presidenza portoghese dell’Unione ha portato alcune soluzioni di compromesso, tra cui la possibilità di utilizzare cookie analitici di terze parti per la raccolta di statistiche di navigazione senza esplicito consenso da parte dell’utente. Anche relativamente al c.d. “cookie wall” viene ammessa la possibilità di permettere l’accesso al sito solo concedendo l’installazione e l’utilizzo di cookie, ma sotto determinate condizioni: l’utente deve poter accedere a servizi equivalenti senza dover necessariamente concedere il consenso ai cookie, eventualmente pagando un compenso. Ma tale postilla è frutto di interpretazioni varie, per cui occorre attendere l’approvazione del Regolamento per saperne di più.

Il GPDP al momento non ha ancora concluso l’iter di consultazione ed approvazione delle nuove Linee Guida.

Nella gestione della privacy di un’organizzazione talvolta ci si trova a valutare la conformità al GDPR (Regolamento UE 2016/679) di una applicazione web o web application fornita, spesso con modalità SaaS (Software As A Service) da un fornitore esterno.

Da un lato l’art. 28 del GDPR ci chiede di affidarci solo a responsabili del trattamento che garantiscano adeguate misure di sicurezza e la conformità al GDPR stesso, dall’altro l’art. 25 ci chiede che gli applicativi software che trattano dati personali siano “privacy by design” e “privacy by default”, ma cosa significa tutto ciò? Cosa dobbiamo realmente chiedere al fornitore di una web application? Anzi cosa dobbiamo pretendere per garantirci la conformità al GDPR?

Al di là degli obblighi del GDPR, molti imprenditori si pongono queste domande:

1. Dove sono conservati i miei dati?
2. Chi li può visionare?
3. Saranno sempre nella mia disponibilità?

Le responsabilità in capo al Titolare del trattamento in caso di violazione dei dati personali gestiti attraverso un sito web sono pesanti se esso non ha provveduto, da un lato a garantirsi contrattualmente la conformità del responsabile del trattamento e dall’altro ad assicurarsi che l’applicazione web sia adeguatamente sicura. In pratica il titolare rischia di essere accusato di “culpa in eligendo” e “culpa in vigilando”, relativamente al rapporto con il responsabile del trattamento.

Il più elevato livello di garanzie che un titolare del trattamento può ottenere è la certificazione ai sensi dell’articolo 42 (e 43) del gdpr del fornitore responsabile del trattamento per il prodotto utilizzato. Al momento tale certificazione non è ancora pienamente disponibile, ma manca veramente poco perché i primi schemi di certificazione ai sensi dell’articolo 42 del GDPR siano abilitati da Accredia (o da altri enti di accreditamento europei mutuamente riconosciuti nella UE) attraverso l’accreditamento dei primi Organismi di Certificazione ai sensi della norma ISO 17065 per la certificazione del GDPR. Ad esempio, lo schema ISDP©10003 è l’unico schema di certificazione italiano accreditato e, quindi, potrà costituire uno strumento per poter certificare processi, prodotti o servizi sotto accreditamento ISO 17065 e, quindi, certificare la conformità di un prodotto software come un applicativo web al Regolamento Europeo sulla Protezione dei Dati Personali 679/2016.

Ma in assenza di un prodotto software certificato quali sono i requisiti di sicurezza che possiamo ragionevolmente richiedere ad una web application si tratta dati personali di dipendenti, clienti e fornitori dell’organizzazione titolare del trattamento?

Vediamo un elenco non esaustivo di possibili misure di sicurezza, suddivise per categorie.

1. Controllo degli accessi: il sistema web deve prevedere un’autenticazione mediante credenziali del tipo username e password univoche (o rese tali). Devono essere implementati criteri di sicurezza per le password come ad esempio una lunghezza minima (almeno 8 caratteri sono indispensabili), una complessità minima della password (ad esempio potrebbe essere richiesta la presenza di almeno un carattere alfabetico maiuscolo, alfabetico minuscolo, un numero ed un carattere speciale), la password dovrebbe essere cambiata al primo accesso dell’utente e a frequenza prestabilita, sebbene la variazione della password non sia più un must della sicurezza informatica; infatti sistemi come l’autentificazione a due fattori richiesta anche saltuariamente  (ad esempio in caso di collegamento da un nuovo dispositivo ) potrebbe rendere maggiormente sicuro il portale web. Poi dovrebbe comunque essere impedito l’accesso contemporaneo con il medesimo codice utente da due dispositivi differenti. Inoltre, l’utente dovrebbe essere automaticamente scollegato dalla sessione dopo un certo periodo di tempo. Infine, le password dovrebbero essere mantenute in forma cifrata nel database dell’applicativo per evitare hacker possano appropriarsi delle credenziali degli utenti.
2. Anti-malware: il portale web dovrebbe implementare sistemi antivirus attivi e firewall per contrastare eventuali attacchi dall’esterno.
3. Profilazione degli utenti: tutti gli utenti dovrebbero avere accesso alle sole risorse di cui necessitano e le utenze amministrative ovvero quelle di amministratore di sistema dovrebbero essere utilizzate soltanto per necessità specifiche.
4. Log degli accessi: dovrebbe essere implementato un sistema di raccolta di log degli accessi degli amministratori di sistema (mantenuti almeno sei mesi in formato non modificabile come richiesto dal provvedimento del Garante Privacy) e degli utenti.
5. Aggiornamento software: dovrebbero essere mantenuti costantemente aggiornati contro minacce alla sicurezza i sistemi operativi ed i software di base della piattaforma nella quale opera l’applicativo web; dunque aggiornamenti costanti delle versioni di mySQL, PHP ed Apache nella piattaforma open source LAMP, aggiornamenti di MSSQL e relativi componenti software della piattaforma Microsoft, ecc..  
6. Comunicazioni sicure: le connessioni fra client e web devono essere crittografate (protocollo SSL/TLS) con certificati validi, prassi ormai consolidata per siti web che applicano le connessioni “https”.
7. Politica di backup: dovrebbe essere attuata una policy di backup adeguata alle esigenze di disponibilità dei dati, in termini di tempi di ripristino dei dati e massima perdita dei dati ammissibile. I tempi di retention dei backup dovrebbero essere coerenti con le esigenze di ripristino di dati passati ed eventuali cancellazioni. Le copie di backup dovrebbero essere protette contro il ransomware, attraverso cifratura, conservazione off-line, esecuzione dei backup con profili utente separati. Per garantirsi contro disastri ambientali e causati dall’uomo almeno una copia di backup periodica dovrebbe essere conservata in un’ubicazione remota (oltre 50-100 km dal datacenter).
8. Disaster recovery: il fornitore dei servizi cloud dove è installato l’applicativo dovrebbe fornire un piano di disaster recovery adeguato alle esigenze dell’organizzazione cliente.
9. Piano di Business Continuity: il fornitore dei servizi cloud deve prevedere un piano di continuità operativa che contempli, oltre al piano di DR, contromisure per garantire la disponibilità dei servizi a fronte di disastri ed altre situazioni di crisi non legate all’infrastruttura IT (come ad es. una pandemia, un incendio, un’alluvione, un terremoto, ecc.).
10.  Monitoraggio di log di accesso e sistemi antintrusione: dovrebbero essere implementate attività di monitoraggio dei log di accesso degli utenti e degli amministratori e di sistemi antintrusione (Intrusion Prevention System) e dei relativi log.
11. Sicurezza fisica ed ambientale del datacenter: il datacenter ove risiede il cloud dell’applicativo dovrebbe essere dotato di misure di sicurezza fisica ed ambientale come impianti antincendio e antiallagamento, sistemi di allarme e di videosorveglianza, controllo degli accessi fisici del personale, ecc..
12. Sicurezza informatica del datacenter: devono essere previste, a protezione dei dati ,misure quali firewall e anti-malware, gestione delle utenze amministrative/privilegiate e MFA sulla piattaforma cloud, monitoraggi/audit sulla sicurezza, censimento degli asset, ecc..
13. Sicurezza delle apparecchiature e dei servizi accessori: l’infrastruttura del datacenter deve essere dotata di adeguati sistemi di raffreddamento, sicurezza fisica dei cablaggi, misure di alimentazione di emergenza quali gruppi elettrogeni, ecc..
14. Conformità al GDPR dell’ubicazione del datacenter: i dati personali conservati in cloud dovrebbero comunque risiedere all’interno della UE o in un Paese per il quale esistono adeguate garanzie secondo quanto previsto dal Reg. UE 679/2016 e dalla Commissione Europea.

In sé la web application dovrebbe essere progettata con maschere video e funzioni che permettano di gestire il minor numero di dati personali possibile, consentendo agli utenti di visionare solo i dati effettivamente necessari per operare e prevedere la pseudonimizzazione dei dati nelle tabelle del database, separando i dati più sensibili dagli altri e rendendoli associabili all’individuo attraverso codici anonimi. Questi aspetti richiedono, però, una progettazione dell’applicativo già orientata alla protezione dei dati personali ed ai principi del GDPR, cosa non certo comune.

Naturalmente ognuna di queste misure di sicurezza potrà rivestire un’importanza diversa a seconda del tipo di dati gestiti nell’applicativo in cloud e della loro importanza o valore in termini di Riservatezza, Integrità e Disponibilità.

In conclusione, prima di adottare un software web per trattare dati riservati occorre esaminare bene anche questi aspetti per non trovarsi cattive sorprese in futuro.

Il Responsabile del trattamento, ai sensi dell’art. 28 del Regolamento UE 679/2016 (GDPR), è una figura molto ostica da gestire nell’ambito di un adeguamento della gestione della privacy di un’organizzazione italiana.

Moltissimi punti del GDPR definiscono prescrizioni applicabili ai titolari e/o ai responsabili del trattamento, ovvero alle figure che hanno determinate responsabilità nel trattare dati personali. Altri soggetti identificati dal GDPR (contitolari, “titolari autonomi” e soggetti autorizzati al trattamento) o sono riconducibili ad essi oppure hanno responsabilità di gran lunga inferiori.

Il considerando 81 introduce il ruolo del Responsabile del Trattamento:

(81) Per garantire che siano rispettate le prescrizioni del presente regolamento riguardo al trattamento che il responsabile del trattamento deve eseguire per conto del titolare del trattamento, quando affida delle attività di trattamento a un responsabile del trattamento il titolare del trattamento dovrebbe ricorrere unicamente a responsabili del trattamento che presentino garanzie sufficienti, in particolare in termini di conoscenza specialistica, affidabilità e risorse, per mettere in atto misure tecniche e organizzative che soddisfino i requisiti del presente regolamento, anche per la sicurezza del trattamento. L’applicazione da parte del responsabile del trattamento di un codice di condotta approvato o di un meccanismo di certificazione approvato può essere utilizzata come elemento per dimostrare il rispetto degli obblighi da parte del titolare del trattamento. L’esecuzione dei trattamenti da parte di un responsabile del trattamento dovrebbe essere disciplinata da un contratto o da altro atto giuridico a norma del diritto dell’Unione o degli Stati membri che vincoli il responsabile del trattamento al titolare del trattamento, in cui siano stipulati la materia disciplinata e la durata del trattamento, la natura e le finalità del trattamento, il tipo di dati personali e le categorie di interessati, tenendo conto dei compiti e responsabilità specifici del responsabile del trattamento nel contesto del trattamento da eseguire e del rischio in relazione ai diritti e alle libertà dell’interessato. Il titolare del trattamento e il responsabile del trattamento possono scegliere di usare un contratto individuale o clausole contrattuali tipo che sono adottate direttamente dalla Commissione oppure da un’autorità di controllo in conformità del meccanismo di coerenza e successivamente dalla Commissione. 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.

Successivamente l’articolo 28 ne disciplina il rapporto con il titolare e le relative condizioni.

In questi oltre due anni di applicazione del GDPR si sono viste diverse forme di “nomina” del responsabile del trattamento da parte del titolare. Spesso tali nomine venivano rifiutate dal fornitore responsabile, che non voleva assumersi tali oneri, con motivazioni inconsistenti. Purtroppo anche alcune linee guida, check-list, questionari ed anche app sul GDPR hanno fornito indicazioni fuorvianti sull’applicabilità di questa figura. Alla domanda: “determini le finalità ed i mezzi del trattamento?” molti rispondono “sì” e pertanto anche l’algoritmo più autorevole risponde “sei titolare del trattamento”. Invece la situazione è un po’ diversa. Laddove si verifica un outsourcing, un’esternalizzazione, di attività che comportano anche il trattamento di dati personali, allora si configura un rapporto fra un titolare del trattamento ed un responsabile che esegue “per conto del titolare”, un trattamento di dati personali.

Molte organizzazioni hanno, purtroppo, voluto “smarcare” in modo troppo rapido questo punto del GDPR, secondo una moda del tutto italiana: della serie “prepariamo le nomine ai responsabili del trattamento e mandiamogliele…” poi se nessuno risponderà a tali istanze, pazienza!

Spesso si è trascurato il fatto che il titolare

“ricorre unicamente a responsabili del trattamento che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del presente Regolamento e garantisca la tutela dei diritti dell’interessato”.

Dunque, prima di effettuare una nomina, occorre verificare che il fornitore/responsabile sia affidabile dal punto di vista della protezione dati. Come? Ad esempio tramite un questionario da somministrare al fornitore per poter verificare che stia applicando i principi e le regole del GDPR e che abbia implementato misure di sicurezza, tecniche ed organizzative, adeguate a tutelare i dati personali che gli facciamo trattare. Nella maggior parte dei casi tali dati personali si riferiscono a dipendenti e clienti del titolare, pertanto presentano alcune criticità, se si dovessero perdere i requisiti di riservatezza, integrità e disponibilità degli stessi.

Molte organizzazioni saltano questo punto, ma allora come dimostrano che il responsabile del trattamento fornisce adeguate garanzie lato privacy? Spesso si tratta di rapporti consolidati da anni, mai messi in discussione. Ora la mancata risposta ad un questionario ed il rifiuto (magari non palese, ma semplicemente “dimenticandosi” di rispondere all’istanza ed ai solleciti) di sottoscrivere la c.d. nomina espone il titolare a importanti responsabilità sui dati affidati all’esterno. In caso di problemi (ispezioni del Nucleo Privacy della Guardia di Finanza, Data Breach, reclami di interessati) il titolare non è in grado di dimostrare di aver agito “responsabilmente”, contravvenendo al principio di accountability (art. 5, comma 2 del Regolamento UE 679/2016).

Teniamo presente che il rapporto tra titolare e responsabile “deve essere disciplinato da un contratto”, dunque a rigore non si tratta solo di “nominare” il responsabile esterno, ma di stabilire – con un atto a valenza contrattuale – quali sono le condizioni per il trattamento di dati personali da parte del responsabile. Dunque, le soluzioni sono due:

• Si predispone una nomina del responsabile sottoscritta da entrambe le parti, che fa riferimento al contratto già esistente (es. per rapporti consolidati) che integra e che deve contenere gli elementi richiesti dal Regolamento UE 679/2016, oppure
• Si definisce un nuovo contratto fra le parti che disciplini anche la gestione dei dati personali.

A seconda delle competenze professionali di chi lo ha redatto, questa nomina, accordo o contratto per il trattamento dei dati personali, può essere di un paio di pagine o di parecchie pagine scritte in “legalese” e, pertanto, di difficile comprensione da parte del fornitore, che potrebbe essere diffidente di fronte ad un articolato complesso..

Bisognerebbe discutere a lungo sull’utilità reale di stipulare contratti di responsabile del trattamento molto lunghi e ricchi di clausole che potrebbero risultare ostiche al responsabile ed indurlo a non firmarlo. D’altro canto, si vedono nomine o contratti da responsabile che riportano essenzialmente solo quanto riportato dal Regolamento UE 679/2016 all’art. 28, ma bisognerebbe altresì  capire cosa significa pretendere che il responsabile adotti misure di sicurezza “adeguate” (per chi?) o si attenga alle “istruzioni del titolare” (quali?).

Nella catena delle subforniture che si inquadrano come rapporti fra titolare e responsabile è difficile pensare che un fornitore responsabile del trattamento debba assoggettarsi a misure specifiche determinate da ogni titolare del trattamento suo cliente. Pensiamo, ad esempio, a studi di consulenza del lavoro o centri di elaborazione paghe, a fornitori di servizi informatici quali software in cloud e così via, che hanno decine di clienti. Per questo motivo si è verificato che molti di questi soggetti hanno proposto in maniera unilaterale un proprio accordo di trattamento dei dati personali che li individua come responsabili. A questo punto il titolare/cliente si vede portato ad accettare quanto proposto dal fornitore/responsabile, che dovrà comunque essere in linea con quanto stabilito dal GDPR ed è comunque opportuno verificare che le condizioni non siano troppo favorevoli al responsabile del trattamento.

Come anticipato sopra, nel contratto da responsabile del trattamento, o nomina che dir si voglia, si dovrà comunque prescrivere al fornitore l’adozione di misure di sicurezza adeguate, ma quali sono queste misure adeguate? Adeguate per chi? Per il fornitore/responsabile o per il titolare/cliente?

Torniamo alla “qualifica” preliminare del fornitore che può essere ispirata alla normativa ISO 9001 ed ai sistemi di gestione per la qualità. A seconda di quello che sarà il trattamento effettuato dal fornitore potremmo valutare le misure di sicurezza intraprese da esso per proteggere i dati personali oppure di imporgli delle nostre misure in qualità di titolare del trattamento. Facciamo qualche esempio. I tipici casi di trattamenti effettuati esternamente nelle imprese italiane sono:

• Elaborazione paghe e consulenza del lavoro
• Tenuta della contabilità e consulenza fiscale
• Fornitura di software e servizi in modalità Saas (software as a service), compresa la gestione di siti web
• Fornitura di servizi cloud.

Le ultime due situazioni hanno poi diverse variazioni sul tema, spesso i programmi software gestionali sono installati in modalità client/server su Server interni all’azienda, ma tenuti sotto controllo dal fornitore che può fare qualsiasi cosa, anche da remoto.

Naturalmente possono verificarsi situazioni più critiche in settori particolari, ad esempio quello della sanità pubblica e privata.

Le misure di sicurezza che chiederemo al consulente del lavoro o allo studio di commercialisti dovranno riguardare sia la sicurezza fisica ed ambientale degli archivi cartacei (e degli storage ove sono memorizzati i nostri dati), sia la sicurezza informatica per proteggere i dati da accessi non autorizzati. Dunque, potremmo richiedere al fornitore se e come applica determinate misure di sicurezza, ad esempio, per quanto riguarda la sicurezza fisica e le misure di sicurezza organizzative:

• Archivi chiusi a chiave fuori dall’orario di lavoro;
• Sistema di allarme ed eventuale videosorveglianza;
• Designazione dei soggetti autorizzati/incaricati al trattamento con obbligo di riservatezza;
• Formazione del personale;
• Tecniche di pseudonimizzazione;
• Ecc.

Mentre per quanto riguarda la sicurezza informatica dovremo chiedere se sono applicate le seguenti misure di sicurezza:

• Accesso ai dati con credenziali di autenticazione univoche;
• Profilazione degli utenti nei sistemi informatici per garantire l’accesso solo alle informazioni necessarie;
• Gestione delle password (segretezza, cambio al primo accesso e periodicamente, complessità delle password, ecc.);
• Sistemi anti-malware su tutti i dispositivi;
• Firewall hardware e software ed eventuali altri sistemi antintrusione;
• Sistemi di cifratura dei dati;
• Procedure di backup/restore ed eventuale disaster recovery garantito anche da copie in remoto;
• Nomina degli amministratori di sistema;
• E così via.

Poi naturalmente si pone il problema dei software utilizzati dal fornitore per elaborare i nostri dati (dati personali dei dipendenti, dei clienti, dei fornitori…). Occorrono le nomine dei sub-responsabili del trattamento (o “altri responsabili”) con garanzie analoghe a quelle sopra esposte, dal punto di vista ICT, che devono essere ribaltate sul fornitore del software.

Nel caso in cui il nostro fornitore sia un fornitore di servizi ICT occorre altresì essere garantiti su tutta la catena di fornitura del software e dei servizi ICT, compresi eventuali servizi cloud di terze parti.

In questo caso, oltre alla valutazione sulle misure di sicurezza adottate dal fornitore del software e dei servizi di assistenza ad esso correlati (accesso ai nostri dati con credenziali univoche, gestione delle password, utilizzo di anti-malware e firewall quando i tecnici del fornitore accedono ai nostri database con dispositivi propri e così via) occorrerebbe valutare le caratteristiche del software che acquistiamo o che abbiamo “noleggiato”: soddisfa il requisito di privacy by design e privacy by default? Si apre un altro capitolo che potrebbe non riguardare strettamente il contratto/accordo da responsabile del trattamento, se il software è stato acquistato o dovrà essere acquistato dall’azienda. Viceversa, le forniture di software e servizi SaaS, PaaS, IaaS, ecc. rientrano generalmente nel contratto per il trattamento di dati personali.

Ad esempio, a differenza di un software di tipo client/server installato in azienda ed accessibile solo dall’interno di essa, per un software in cloud dovremmo richiedere misure di sicurezza aggiuntive per garantirci da accessi fraudolenti (autenticazione a due fattori, numero massimo di login falliti oltre il quale viene bloccato l’account, complessità minima della password…).

In questo quadro si colloca anche l’eventuale nomina degli Amministratori di Sistema, che sono figure non disciplinate dal GDPR (sebbene costituiscano una misura di sicurezza), ma dalla normativa privacy italiana, in base ad una disposizione ancora in vigore. Normalmente chi opera in qualità di Amministratore di Sistema, se esterno all’organizzazione, ricopre anche il ruolo di responsabile del trattamento (come persona giuridica).

Veniamo, infine, all’atto di nomina del responsabile del trattamento che – come anticipato sopra – potrebbe essere un atto integrativo del contratto tra le parti oppure potrebbe essere compreso nel contratto stesso revisionato. In esso devono essere regolamentati i seguenti punti:

• Materia disciplinata;
• Durata del trattamento;
• Natura del trattamento;
• Finalità del trattamento;
• Tipo di dati personali;
• Categorie degli interessati;
• Misure di sicurezza adottate;
• Istruzioni operative.

Premesso che – in caso di nomina o atto integrativo rispetto al contratto preesistente – alcuni dei suddetti punti potrebbero e dovrebbero essere già disciplinati dal contratto (ad es. materia disciplinata, durata del contratto, ecc.), occorre precisare che:

• Il tipo di dati personali trattati può essere esplicitato in forma generale, ad es. dati personali comuni o dati particolari, dati anagrafici, dati di natura fiscale, dati relativi alla salute e così via; senza scendere in un dettaglio che poi sarebbe difficile mantenere aggiornato,
• Le categorie degli interessati possono essere dipendenti, clienti, fornitori, potenziali clienti o contatti commerciali, e così via.
• Le misure di sicurezza potrebbero essere richiamate da un questionario o check-list preliminare compilata a monte dal fornitore ed accettata dal cliente oppure potrebbero essere definite esplicitamente in un allegato o altro documento condiviso fra le parti, tenendo presente che potrebbero essere soggette ad aggiornamento per evolversi della tecnologia o altro.
• Le istruzioni operative potrebbero essere disciplinate nel dettaglio, eventualmente a partire da uno schema come segue.
• Trattare i dati suddetti per le sole finalità indicate;
• Predisporre e mantenere aggiornato un registro dei trattamenti – se previsto – in conformità all’art. 30 del Regolamento UE 679/2016;
• Valutare i rischi che incombono sui dati trattati sopra riportati;
• Adottare le idonee misure di sicurezza, tecniche ed organizzative, per garantire la riservatezza, l’integrità e la disponibilità dei dati trattati;
• Nominare ed istruire adeguatamente il personale incaricato del trattamento dei dati sulle procedure da adottare e sulle misure di sicurezza;
• Garantire che le persone autorizzate al trattamento dei dati personali si siano impegnate alla riservatezza o abbiano un adeguato obbligo legale di riservatezza;
• Vigilare sulla puntuale osservanza, da parte degli incaricati del trattamento dei dati, delle disposizioni di legge e delle proprie istruzioni, anche tramite verifiche periodiche;
• Assistere il titolare del trattamento – tenendo conto della natura del trattamento – con misure tecniche e organizzative adeguate, nella misura in cui ciò sia possibile, al fine di soddisfare l’obbligo del titolare del trattamento di dare seguito alle richieste per l’esercizio dei diritti dell’interessato di cui al capo III “Diritti dell’interessato” del Regolamento UE 679/2016;
• Assistere il titolare del trattamento nel garantire il rispetto degli obblighi di cui agli articoli da 32 a 36 del Regolamento UE 679/2016, tenendo conto della natura del trattamento e delle informazioni a disposizione del responsabile del trattamento;
• Su scelta del titolare del trattamento, cancellare o restituire tutti i dati personali dopo che è terminata la prestazione dei servizi relativi al trattamento in oggetto e cancellare le copie esistenti, salvo che il diritto dell’Unione o degli Stati membri preveda la conservazione di tali dati;
• Mettere a disposizione del titolare del trattamento tutte le informazioni necessarie per dimostrare il rispetto degli obblighi di cui all’articolo 28 del Regolamento UE 679/2016 e consentire e contribuire alle attività di revisione, comprese le ispezioni, realizzate dal titolare del trattamento o da un altro soggetto da questi incaricato;
• Comunicare al titolare del trattamento le misure tecniche d organizzative adottate per garantire la sicurezza dei dati, in particolare riguardo alle misure di sicurezza informatica (gestione delle credenziali di autenticazione, procedure di backup e restore, protezioni contro il malware, ecc.), eventuale nomina di un Amministratore di Sistema, misure di sicurezza fisica, eventuale nomina di un Responsabile della Protezione dei Dati (RPD o DPO, Data Protection Officer).

Sulla questione di eventuali sub-responsabili l’elenco approvato potrebbe essere gestito a parte in modo più efficiente, ma il problema più rilevante è quello legato ai dati in cloud, ovvero dove sono i datacenter? Quali misure di sicurezza garantiscono? Dispongono di certificazioni?

Sulla territorialità in UE o fuori UE con adeguate garanzie la responsabilità rimane del titolare del trattamento si possono riscontrare diversi problemi in prima istanza nascosti. Senza voler entrare troppo nel merito di quest’argomento, molto articolato, si può precisare il fatto che il cliente deve sapere dove il fornitore archivia i suoi dati personali, ovvero quelli di cui è titolare.

Infine, il Titolare dovrebbe avere il diritto di effettuare un audit sul responsabile del trattamento per verificare il rispetto del contratto, in assenza di certificazioni specifiche del responsabile ai sensi del GDPR (ad es. ISPD©10003) o comunque che offrono adeguate garanzie sulla sicurezza delle informazioni (ISO 27001, ISO 27701). Il responsabile del trattamento non potrebbe sottrarsi a tale obbligo. Su quest’ultimo aspetto e su quant’altro riportato nell’atto di nomina del responsabile è bene non dimenticare che il titolare del trattamento è il cliente ed il fornitore nominato responsabile dovrebbe essere sostituito se non adempie a quanto previsto dal GDPR, ovvero certi rapporti contrattuali non devono per forza proseguire se non forniscono adeguate garanzie sul trattamento dei dati personali in conformità al GDPR.

Soprattutto in questo periodo è estremamente attuale essere
in grado di pianificare la continuità operativa delle imprese, almeno per
quanto possibile.

Anche le aziende più preparate a gestire la business
continuity, forse, non hanno previsto una pandemia come quella del Covid-19,
o forse si erano prefigurati scenari diversi, nei quali le persone non sono in
grado di andare al lavoro a causa di epidemie di influenza o altre cause. In
questa fase che stiamo attraversando l’assenza di personale non è dovuta –
nella maggior parte dei casi – allo stato di malattia delle persone, ma alla
necessità di “isolamento sociale” delle risorse umane di un’intera azienda. Per
certi aspetti, dunque, il panorama è meno catastrofico, in quanto le persone
sono quasi tutte operative ed in grado di lavorare, ma non possono accedere
ai locali aziendali per un periodo di tempo che potrebbe essere considerevole.

Come potrebbe (o poteva) l’azienda lungimirante e preparata,
affrontare situazioni di emergenza come questa che stiamo attraversando? O
meglio, come potrà pensare di affrontarle in futuro se si verificheranno?

Ci viene in soccorso lo standard UNI EN ISO 22301 (Sicurezza e resilienza – Sistemi di gestione
per la continuità operativa – Requisiti titolo originale “Security
and resilience – Business continuity management systems – Requirements”),
recentemente revisionato (edizione 2019) e tradotto in italiano dall’UNI e
pubblicati a febbraio 2020.

Come già visto in un precedente articolo sulla vecchia versione della norma (pubblicata dall’ISO nel 2012) , lo standard specifica i requisiti per progettare, implementare e gestire efficacemente un Sistema di gestione della continuità operativa.

Le modifiche alla norma non hanno aggiunto nuovi
requisiti, ma solamente chiarito quelli già presenti, allineato la
norma alle altre norme sui sistemi di gestione e riorganizzato il capitolo 8,
vero cuore dello standard.

Il sistema di gestione della continuità operativa (business continuity management system o BCMS)
enfatizza l’importanza di:

• comprendere le esigenze dell’organizzazione e le necessità per
  stabilire la politica e gli obiettivi per la continuità operativa;
• gestire e mantenere processi, capacità e
  strutture di risposta per garantire che l’organizzazione sopravviva a
  interruzioni;

• implementare e rendere operativi controlli e misure per gestire la
  capacità di un’intera organizzazione nella gestione delle interruzioni (discontinuità)
  dell’operatività dovute a cause accidentali;
• monitorare e riesaminare le
  prestazioni e l’efficacia del sistema di gestione della continuità
  operativa;
• migliorare in modo continuo
  il BCMS basato su metriche qualitative e quantitative (obiettivi misurabili).

Si ricorda che anche la norma ISO/IEC 27031 “Information technology — Security techniques
— Guidelines for information and communication technology readiness for
business continuity” tratta la business continuity, ma nel contesto dell’ICT
e delle tecniche di sicurezza strettamente correlata alla ISO 27001 che
contiene i requisiti per la
certificazione dei sistemi di gestione della sicurezza delle informazioni.

La ISO 22301 evidenzia i componenti chiave del sistema di
gestione della continuità operativa, peraltro presenti anche in altri sistemi
di gestione. Tra essi la politica,
le persone con le loro responsabilità definite, la gestione dei processi correlati a
politica, pianificazione, attuazione e funzionamento del BCMS, valutazione
delle prestazioni, riesame di
direzione e miglioramento,
nonché le informazioni documentate in grado di fornire evidenze
verificabili anche tramite audit sul
sistema di gestione della continuità operativa.

Il vantaggio di disporre di un BCMS correttamente
funzionante è quello di far sì che l’organizzazione sia preparata – attraverso
processi, procedure, responsabilità, risorse, controlli, competenze, ecc. – a
mantenere l’operatività a seguito di un’interruzione, ovvero di un evento
destabilizzante (in inglese viene utilizzato il termine “disruption”) che
mina i processi operativi critici.

Anche questa norma recepisce il metodo del “PLAN DO CHECK ACT” già noto da altre
norme dei sistemi di gestione.

Per questa norma il concetto di “parti interessate” o stakeholders è molto importante in
quanto una discontinuità (interruzione) nell’operatività dell’organizzazione,
una indisponibilità dei servizi essenziali per i clienti, un fermo delle
attività produttive per un periodo più o meno lungo, possono causare danni, sia
dal punto di vista commerciale, sia da quello finanziario, ma anche da quello
delle altre parti interessate, quali personale interno, individui della
collettività che subiscono danni anche fisici, fornitori, ecc..

Scopo della norma per la gestione della business continuity
è quello di specificare i requisiti atti proteggere l’organizzazione da interruzioni
quando accadono, ma non solo. Il BCMS ha anche l’obiettivo di ridurre la
probabilità che tali eventi negativi avvengano, prepararsi ad essi e rispondere
in modo adeguato a ripristinare l’operatività nel più breve tempo possibile
qualora si verifichi un evento che provoca l’interruzione dell’operatività.
Naturalmente non si può pensare che un’azienda metta in atto azioni volte a
prevenire calamità naturali o pandemie, ma – facendo un esempio estremamente
attuale – una volta che sia stata conclamata un’epidemia su larga scala,
potrebbe porre in essere misure volte a prevenire il contagio fra i dipendenti e,
quindi, volte ad evitare che si verifichi un’interruzione totale dell’operatività
aziendale causata da un contagio interno molto diffuso. Questo, naturalmente,
al di là delle decisioni e delle disposizioni governative che hanno limitato l’operatività
di molte attività, ma non di tutte. Addirittura alcune aziende dovevano porsi l’interrogativo
se chiudere anticipatamente in base alla probabilità di contagio nella propria
zona fra personale dipendente.

La norma ISO 22301 definisce alcuni termini specifici sulla
materia tra cui il termine di continuità operativa (business continuity),
piano di continuità operativa (business continuity plan), analisi di
impatto operativo (business impact
analysis o BIA).

Oltre ad altri termini consueti delle norme della serie ISO
9000, altro termine significativo mutuato dalle norme della serie ISO 27000 è
quello di incidente che è definito
come “evento che può o potrebbe condurre ad un’interruzione, a una perdita,
a un’emergenza o a una crisi” Al proposito la norma utilizza spesso il
termine interruzione che
rappresenta “un incidente che causa una deviazione negativa, non pianificata
dell’erogazione prevista dei prodotti e servizi secondo gli obiettivi di un’organizzazione”;
modificando significativamente la definizione della precedente versione della
norma, forse più concreta e facilmente comprensibile ai più.

Verranno successivamente introdotti dalla norma degli
indicatori specifici per questa tematica come:

• Maximum
  Tolerable Period of Disruption (MTPD) ovvero
  il tempo massimo accetabile che può trascorrere a fronte degli impatti
  negativi conseguenti ad una interruzione come risultato della mancata
  fornitura di un prodotto, erogazione di un servizio o svolgimento di un’attività
  operativa.
• Recovery Time Objective (RTO):
  periodo di tempo entro il quale – dopo l’interruzione – i servizi erogati,
  la produzione, i servizi di supporto e le funzionalità operative devono
  essere ripristinati ad un livello minimo accettabile.

Il capitolo 4 della norma denominato “Contesto dell’organizzazione” contiene
gli elementi per comprendere il contesto dell’organizzazione, tra cui i fattori
interni ed esterni che influenzano la sua capacità di conseguire i risultati
del BCMS. La norma stabilisce che nell’ambito del Sistema di gestione per la
continuità operativa debbano essere identificati i requisiti dell’organizzazione e delle sue parti interessate, che
dovranno essere tenuti in debito conto nella progettazione del sistema di
gestione dell’organizzazione

Tra i requisiti da prendere in considerazione viene dedicato
un punto specifico ai requisiti legali e regolamentari, ovvero quei
requisiti cogenti che determineranno gli obiettivi di minima del BCMS e dei
piani di continuità operativa. Ciò aiuterà nella definizione dello scopo e campo di applicazione del sistema di gestione
di continuità operativa. A tale riguardo la norma stabilisce le modalità
attraverso le quali l’organizzazione deve stabilire i confini del BCMS e quali
processi, prodotti e servizi sono compresi nel sistema di gestione e quali
parti dell’organizzazione agiscono all’interno di esso, dettagliando eventuali
esclusioni che, comunque, non possono influenzare negativamente i risultati del
sistema di gestione ed i livelli di operatività stabiliti nell’analisi di
impatto.

Al punto 4.4 la norma stabilisce che l’organizzazione deve
implementare, mantenere attivo e migliorare continuamente un sistema di
gestione della continuità operativa, inclusi i processi necessari e le relative
interazioni fra essi, in accordo con i requisiti di questo standard
internazionale (ISO 22301).

Il capitolo 5 della norma è denominato “Leadership”. In esso la norma
stabilisce che l’alta direzione (ovvero il top
management) deve possedere leadership e dimostrare un impegno preciso
rispetto al sistema di gestione per la continuità operativa. L’impegno del management
viene poi esplicitato attraverso una serie di responsabilità della direzione
relative al sistema di gestione quali, ad esempio, assicurare che politiche ed obiettivi
siano stabiliti, che le risorse necessarie siano messe a disposizione e che vi
sia un’adeguata comunicazione all’interno dell’organizzazione relativamente ai
requisiti del sistema di gestione della continuità operativa.

Sono poi stabiliti requisiti relativi alla definizione della
politica per la continuità operativa
e la definizione della struttura
organizzativa dell’organizzazione, quindi la definizione di ruoli
responsabilità ed autorità.

Il capitolo 6, denominato “Pianificazione” stabilisce che:

• L’organizzazione deve attuare
  azioni rivolte ad affrontare i
  rischi ed alle opportunità, in particolare assicurando che il sistema riesca
  a perseguire gli obiettivi ed i risultati stabiliti, prevenire o ridurre
  gli effetti indesiderati sul BCMS e mirare al miglioramento continuo.
• Vengano definiti obiettivi per la business continuity e soluzioni/piani per raggiungerli;
  tale aspetto, con le dovute modifiche, è del tutto analogo ad altri
  sistemi di gestione: gli obiettivi devono essere misurabili, devono essere
  monitorati, occorre stabilire chi è responsabile, che cosa deve fare,
  quali risorse sono richieste, quando dovranno essere completate le azioni
  finalizzate al perseguimento degli obiettivi e come dovranno essere
  valutati i risultati. Unica differenza rispetto ad altri sistemi di
  gestione è che nella definizione degli obiettivi bisognerà tenere conto di
  un livello minimo di servizio o di prodotto fornito ritenuto accettabile
  dall’organizzazione nel raggiungimento dei suoi obiettivi.

Viene anche chiarito, in una nota, che i rischi di questa
sezione sono quelli che influenzano l’intero BCMS, non i rischi che minacciano
la continuità operativa, trattati al successivo punto 8.2.

Il capitolo 7 della norma denominato “Supporto” stabilisce i requisiti per
alcune attività e processi di supporto, quali – in generale – la gestione delle risorse, le competenze del personale, la consapevolezza dello stesso personale
relativamente al sistema di gestione della continuità operativa e la comunicazione, sia essa interna che
esterna. In particolare, per questo tipo di sistema di gestione, le modalità ed
i mezzi di comunicazione sono molto importanti per garantire la continuità del
servizio anche durante i periodi di indisponibilità delle risorse critiche.

Infine, l’ultima parte di questo capitolo è dedicato alle informazioni documentate, i cui
requisiti relativi riguardano le modalità di gestione di documenti, dei dati e
delle registrazioni richieste dalla norma.

A questo riguardo è opportuno precisare che, nell’ambito
della business continuity, i
documenti – in particolare i piani, le procedure e le istruzioni operative –
necessarie per ripristinare nel più breve tempo possibile i servizi richiesti
durante i periodi di crisi successivi ad un’interruzione, dovrebbero essere
accessibili dai responsabili nominati, dunque occorre prevedere supporti
alternativi per i documenti che potrebbero non essere disponibili nel formato
originario, su supporto elettronico o cartaceo. Pertanto, tali documenti
dovrebbero essere resi disponibili su supporti ed ubicazioni realmente
utilizzabili in funzione del tipo di crisi (scenario) previsto in fase di pianificazione.

Il capitolo 8 della norma, denominato “Attività operative”, è quello che è
stato maggiormente modificato rispetto alla versione precedente della norma e rappresenta
il cuore della ISO 22301 in quanto tratta gli aspetti di pianificazione e controlli
operativi, l’analisi di impatto e la valutazione dei rischi e, infine, la strategia di business continuity e le
relative soluzioni adottate, ovvero tutto ciò che l’organizzazione intende fare
per garantire la continuità operativa, compresa la definizione dei business
continuity plan o piani di continuità operativa, la loro applicazione e
test/esercizio.

Nei suddetti paragrafi sella sezione 8 vengono specificate,
tra l’altro, le modalità di effettuazione e documentazione della analisi di impatto operativo e della valutazione del dei rischi, per la quale può essere preso come
riferimento quanto indicato nella ISO 31000 (UNI ISO 31000 – Gestione del rischio – Principi e linee guida). Occorre
precisare che sia l’analisi di impatto sia la valutazione dei rischi dovranno
prendere in considerazione i rischi che possono impattare la continuità
operativa, quindi i rischi che si verifichino incidenti distruttivi che portino
a situazioni di crisi o di interruzione dell’operatività e, conseguentemente, a
situazioni insostenibili per i requisiti stabiliti di continuità operativa e
per la propensione al rischio dell’organizzazione. A fronte di tali situazioni,
in base ai risultati della valutazione dei rischi, dovranno essere determinate
e poste in essere le azioni conseguenti per mantenere la continuità operativa.

Le soluzioni per garantire la continuità operativa
devono essere finalizzate a:

• rispettare i requisiti di continuità e di
  recupero delle attività prioritarie entro le tempistiche prestabilite e
  capacità concordate;
• proteggere le attività prioritarie dell’organizzazione;
• ridurre le probabilità di un’interruzione;
• accorciare la durata di un’interruzione entro
  limiti tollerabili;
• limitare l’impatto di un’interruzione sui
  prodotti e servizi dell’organizzazione;
• provvedere alla disponibilità di risorse
  adeguate a poter affrontare le situazioni di crisi.

Le soluzioni identificate devono essere scelte in base ai
requisiti da soddisfare, i rischi ritenuti accettabili, i costi ed i benefici. Per
attuarle dovranno essere stabiliti i requisiti e le necessità di risorse umane,
tecnologiche, infrastrutturali, ecc.

Il punto 8.4 della norma fornisce indicazioni su come progettare
i piani di continuità operativa e le procedure da mettere in atto per
garantire la continuità operativa dell’organizzazione a fronte di un’interruzione.

Il capitolo 9 della norma tratta la “Valutazione delle prestazioni”. Vengono
qui illustrati i requisiti relativi al monitoraggio,
alle misurazioni, all’analisi ed
alla valutazione dei processi che
hanno un impatto sulla continuità operativa; in particolare vengono esplicitati
i requisiti relativi ad indicatori e
metriche finalizzate al monitoraggio
dell’efficacia del BCMS.

Nel capitolo 9 vengono anche trattati i requisiti
standard per i sistemi di gestione riguardanti gli audit interni ed il riesame di
direzione. Anche qui, rispetto alle altre normative sui sistemi di gestione,
il focus è sui rischi risultanti dall’analisi di impatto e sul risk assessment.

Nel capitolo 10, denominato “Miglioramento”, sono trattati le non conformità, le azioni correttive ed il miglioramento
continuo. Relativamente a non conformità ed azioni correttive la gestione è
analoga ai sistemi gestionali descritti nelle altre normative sui sistemi di
gestione (ISO 9001 in primis). Sono inoltre introdotte le azioni che vengono
messe in atto al fine di perseguire il miglioramento continuo del sistema e
delle sue prestazioni.

Premesso ciò, le non conformità relative al sistema di
gestione della continuità operative – normalmente incidenti ed altri eventi che hanno generato interruzioni oltre
ad altre situazioni nelle quali si verifica il non soddisfacimento dei
requisiti procedurali – dovranno essere identificate e dovranno essere attuate
prontamente correzioni per eliminare, quando possibile, gli effetti della non
conformità stessa e le relative conseguenze. Inoltre, si deve valutare la
necessità di intraprendere azioni correttive finalizzate ad eliminare le cause
della non conformità.

In conclusione, le organizzazioni che vorranno adeguarsi a tale
normativa e certificarsi secondo le proprie esigenze di business, quasi
certamente avranno già messo in atto e certificato un sistema di gestione per
la qualità ISO 9001, ma probabilmente alcune di queste organizzazioni avranno
anche già implementato il sistema di
gestione della sicurezza delle informazioni ISO 27001, pertanto lo sforzo
per conformarsi a questa norma sulla business
continuity non sarà eccessivo. Infatti, molti requisiti sono comuni fra la
norma ISO 22301 e la norma ISO 27001 nella quale esiste già un obiettivo di
controllo riguardante la continuità operativa che impone di predisporre uno o
più business
continuity plan per garantire la continuità nell’erogazione del
servizio o nella produzione, ma a fronte di interruzioni dovute a
indisponibilità di informazioni.

Al proposito occorre notare che la norma tratta la gestione
di tutti i tipi di discontinuità o interruzioni di servizio, non
necessariamente solo quelli legati all’indisponibilità dei sistemi informatici,
anche se quasi tutte le organizzazioni vedono come principale pericolo per la
propria continuità operativa il blocco dei sistemi informatici che ormai
governano quasi tutte le attività aziendali.

Gli esempi di situazioni nelle quali la continuità operativa
non è minacciata da interruzioni e disastri legati ai sistemi informatici sono
sotto i nostri occhi in questo periodo.

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 Ministero dello Sviluppo Economico (MISE) ha pubblicato nei giorni scorsi l’Elenco degli Innovation Manager, ovvero dei consulenti liberi professionisti e delle società di consulenza che potranno aiutare le aziende che ne faranno domanda a sviluppare l’innovazione tecnologica ed organizzativa dei loro processi usufruendo di importanti agevolazioni statali.

Le indicazioni dettagliate per le imprese che desiderano usufruire di questo finanziamento si possono trovare al sito del MISE cliccando QUI.

In pratica una Piccola o Micro Impresa può usufruire di un Voucher per consulenza negli ambiti previsti dal Decreto Ministeriale del 30 agosto 2019 per il 50% delle spese sostenute fino ad un massimo di € 80.000. Per imprese più grandi e Reti di Impresa l’agevolazione è proporzionalmente inferiore.

Un articolo che illustra in modo chiaro e preciso le modalità di erogazione del finanziamento si può trovare a questo link.

Poiché l’occasione è ghiotta per le aziende, ma anche per i consulenti (si può ottenere un contratto di consulenza fino a € 80.000 facendone pagare al cliente solo la metà), occorre fare attenzione – lato impresa che vuole innovare – alla scelta dell’Innovation Manager giusto; infatti facendo una semplice ricerca su Google si trovano diversi siti che parlano dell’argomento, alcuni dei quali che pubblicano elenchi ristretti o vetrine di Innovation Manager con lo scopo di mettere in evidenza solo i profili che si desidera o quelli che hanno pagato per comparire nella vetrina.

Bene l’unico elenco ufficiale e completo degli Innovation Manager (circa 9000) approvati dal MISE è reperibile a questo link Elenco Innovation Manager MISE.

Ogni consulente/società di consulenza è suddiviso per regione dove intende operare e per ambito di specializzazione. Dunque in base al tipo di progetto che l’impresa intende sviluppare dovrà rivolgersi ad uno degli Innovation Manager che presentano i requisiti di specializzazione adeguati.

E’ opportuno chiarire che le specializzazioni dichiarate – ed in generale tutti i requisiti dichiarati dagli Innovation Manager – non sono stati probabilmente verificati dal MISE con ulteriore documentazione oltre ai curriculum vitae presentati, sebbene tutti i candidati abbiano sottoscritto una dichiarazione ai sensi del DPR 445/2000 sulla veridicità di quanto dichiarato.

La cattiva notizia è che i tempi per le Imprese per richiedere il Voucher Innovazione sono strettissimi (scadenza 26/11/2019, salvo proroghe.

Al link seguente Scheda Innovation Manager potrete trovare la scheda del sottoscritto.

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.

Il registro delle attività di trattamento è uno dei pochi adempimenti obbligatori imposti dal Regolamento UE 679/2016, noto anche come GDPR. Anzi, probabilmente è l’unico documento da predisporre obbligatoriamente per quasi tutte le organizzazioni che trattano dati personali, infatti le esclusioni possibili – per interpretazione della stessa Autorità Garante Nazionale – non riguardano le aziende che gestiscono dei dipendenti, in quanto esse trattano dati appartenenti a particolari categorie di dati personali in modo non occasionale.

L’art. 30 del GDPR, oltre a stabilire chi deve redigere il Registro dei trattamenti, ne definisce i contenuti. Il Registro del Titolare contiene le le seguenti informazioni:

• il nome e i dati di contatto del titolare del trattamento e, ove applicabile, del contitolare del trattamento, del rappresentante del titolare del trattamento e del responsabile della protezione dei dati;
• le finalità del trattamento;
• una descrizione delle categorie di interessati e delle categorie di dati personali;
• le categorie di destinatari a cui i dati personali sono stati o saranno comunicati, compresi i destinatari di paesi terzi od organizzazioni internazionali;
• ove applicabile, i trasferimenti di dati personali verso un paese terzo o un’organizzazione internazionale, compresa l’identificazione del paese terzo o dell’organizzazione internazionale e, per i trasferimenti di cui al secondo comma dell’articolo 49, la documentazione delle garanzie adeguate;
• ove possibile, i termini ultimi previsti per la cancellazione delle diverse categorie di dati;
• ove possibile, una descrizione generale delle misure di sicurezza tecniche e organizzative di cui all’art. 32 del Regolamento.

Il Registro del Responsabile, invece, contiene:

• il nome e i dati di contatto del responsabile o dei responsabili del trattamento, di ogni titolare del trattamento per conto del quale agisce il responsabile del trattamento, del rappresentante del titolare del trattamento o del responsabile del trattamento e, ove applicabile, del responsabile della protezione dei dati;
• le categorie dei trattamenti effettuati per conto di ogni titolare del trattamento;
• ove applicabile, i trasferimenti di dati personali verso un Paese terzo o un’organizzazione internazionale, compresa l’identificazione del paese terzo o dell’organizzazione internazionale e, per i trasferimenti di cui al secondo comma dell’articolo 49, la documentazione delle garanzie adeguate;
• ove possibile, una descrizione generale delle misure di sicurezza tecniche e organizzative di cui all’articolo 32 del Regolamento.

Purtroppo il Regolamento UE sulla protezione dei dati non permette di chiarire molti dubbi interpretativi e nemmeno le FAQ del Garante Privacy dello scorso settembre sono particolarmente utili al riguardo.

Alcuni punti fermi sono i seguenti;

• il Registro dovrebbe essere redatto da tutte le organizzazioni commerciali, anche se in alcuni casi interpretando il GDPR si potrebbe evitare di predisporlo, secondo il principio dell’accountability è oltremodo opportuno avere un registro dei trattamenti che formalizza il fatto che il titolare del trattamento ha determinato quali dati personali sta trattando;
• I registri sono due: quello del Titolare – che riporta i trattamenti che l’organizzazione svolge in qualità di Titolare del trattamento – e quello del Responsabile – che riporta i trattamenti che l’organizzazione effettua come Responsabile esterno del trattamento per conto di altro Titolare o Responsabile (secondo l’art. 28 del GDPR) -;
• Il Registro (o i Registri) vanno tenuti in forma scritta, anche elettronica, mantenendo però evidenza delle revisioni avvenute.

All’organizzazione che deve predisporre il registro dei trattamenti si pongono due problemi fondamentali:

• Quale formato adottare per il Registro;
• Quali dati inserire nelle voci del Registro.

Appurato che il Registro dei trattamenti ha due sezioni, una per i trattamenti effettuati come Titolare ed una sezione per quelli effettuati come Responsabile, è chiaro che il Registro del Titolare avrà una intestazione con i dati di contatto del Titolare del trattamento, ovvero l’organizzazione proprietaria del Registro, e tante righe per ogni trattamento svolto.

La scelta della forma per il Registro è importante per la sua alimentazione iniziale e successiva gestione. In generale possono distinguersi tre casi:

• Registro con tante righe quanti sono i trattamenti individuati e, nelle colonne, i campi previsti dal Regolamento, magari con qualche informazione in più. Tale formato è facilmente creabile tramite una tabella di Word o un file di Excel, ma non sempre stampabile agevolmente – anche in formato orizzontale – in quanto le informazioni da includere nelle colonne (i campi) sono diverse e il testo può essere lungo.
• Registro a schede: una scheda per ogni trattamento con due colonne, la prima che identifica i campi delle voci previste dal GDPR per il Registro, la seconda con il relativo contenuto. Tale formato consente di gestire meglio lo spazio a disposizione con un file di Word, ma la stampa richiede più fogli.
• Registro tabellare invertendo il primo formato sopra indicato: nelle colonne sono riportati i trattamenti e nelle righe i contenuti dei vari campi stabiliti dal Regolamento: Tale formato è più agevole da gestire – in formato Excel o Word – se i trattamenti sono in numero limitato, inferiore ai campi delle informazioni da includere nel registro.

Ci sono poi applicativi software specifici che permettono di gestire il Registro dei trattamenti o addirittura tutta la privacy. Tali software, gestendo i trattamenti del registro tramite database, normalmente generano stampe poco compatte del registro, di numerose pagine, proprio perché non premettono la flessibilità di un editor di testo che consente di governare gli spazi in modo ottimale.

Stabilito il formato da adottare per il Registro veniamo al problema principale, quali contenuti andiamo ad indicare nel Registro?

Nel Registro dei trattamenti, ovvero nei campi relativi ad ogni trattamento, dovrebbero essere riportate tutte le informazioni seguenti.

Identificativo del trattamento: è opportuni assegnare un codice identificativo ad ogni trattamento che permetta di richiamarlo in altri documenti in modo immediato ed univoco.

Denominazione del trattamento: quale nome descrittivo assegniamo al trattamento (es. Gestione del personale, gestione fornitori, gestione commerciale, ecc.).

Tipo di supporto: I dati personali relativi al trattamento sono conservati su supporto cartaceo o durevole (es. Plastica di un badge o cartellino identificativo, lastra di un referto di diagnostica per immagini, ecc.) oppure su supporto digitale o entrambe?

Finalità del trattamento. Per quale finalità trattiamo questi dati personali, qual è lo scopo del trattamento?

Qui però bisogna fare una riflessione: come definiamo un trattamento di dati personali appartenente ad una singola riga (record) del registro? Definiamo un unico trattamento la gestione del personale dipendente e dei collaboratori a contratto oppure esplicitiamo come trattamenti i seguenti?

• Amministrazione o contabilità del personale (rilevazione presenze, elaborazione paghe,…)
• Gestione operativa del personale (mansioni, turni, programmazione attività…)
• Gestione dell’assicurazione sanitaria dei dipendenti
• Assicurazione sugli incidenti sul lavoro
• Gestione sicurezza sul lavoro D.Lgs. 81/2008
• Controllo accessi ai locali aziendali
• Sorveglianza sanitaria
• Gestione mensa
• Gestione curriculum/schede del personale/competenze
• Gestione formazione ed addestramento del personale
• Gestione valutazioni ed incentivazione del personale
• Gestione sanzioni disciplinari
• Gestione rimborsi spese
• Gestione dei contratti di collaborazione (a progetto, interinali, ecc.)
• Processo di ricerca e selezione di nuovo personale
• e così via.

Tale elenco potrebbe essere molto lungo, soprattutto in aziende di certe dimensioni.

Per i dati dei clienti quali trattamenti? Solo la “Gestione dei rapporti con I clienti” oppure:

• Gestione delle richieste di offerta
• Gestione delle offerte
• Gestione degli ordini
• Gestione delle attività di marketing diretto
• Gestione dei contatti commerciali da sito web
• …..

Chiaramente se si approccia il Registro nel primo modo il registro dei trattamenti di un’azienda manifatturiera normale sarà di poche righe, mentre nel secondo il numero di righe potrà facilmente superare la cinquantina di record. Ma qual è la strada giusta? La complessità dell’organizzazione potrà sicuramente suggerirci una strada piuttosto che l’altra.

Un approccio più minimalista, ma molto sostanziale ci potrebbe portare a dire che la maggior parte delle organizzazioni trattano dati di clienti, di fornitori, del personale dipendente e di terzi. Ad ognuna di queste macro-categorie possono essere associati più processi aziendali che comportano trattamenti di dati personali.

Se invece di un’impresa manifatturiera tipica consideriamo imprese di servizi, magari del settore sanitario, allora I trattamenti potranno proliferare. Un piccolo ambulatorio medico potrebbe trattare I dati dei pazienti in una decina di apparecchiature medicali, ognuna di esse con le proprie specificità.

Naturalmente né il Regolamento, né le FAQ del Garante ci indicano una strada precisa da intraprendere.

Descrizione delle categorie di interessati: occorre indicare se stiamo trattando dati personali di clienti persone fisiche, di persone fisiche che rappresentano I clienti, dati del personale dipendente e loro familiari, ecc.

Descrizione delle categorie di dati personali (nello specifico se vengono trattati particolari categorie di dati, quali dati che rivelano l’origine razziale, opinioni politiche, convinzioni religiose, appartenenza ad un sindacato, dati sulla salute, dati giudiziari, ecc.). Si potrebbe stabilire una classificazione delle categorie di dati personali, ad esempio:

• Dati anagrafici (nome, cognome, data di nascita, sesso, …)
• Dati di contatto: e-mail, telefono, …
• Dati economico-finanziari e patrimoniali
• Dati relativi allo stato di salute
• Dati relativi ad opinioni politiche, appartenenza sindacale
• Dati relative a convinzioni religiose
• Dati relativi all’orientamento sessuale
• Dati relativi ad origini etniche
• Dati genetici
• Dati biometrici
• Dati relativi alla geolocalizzazione;
• Dati multimediali (foto/immagini/audiovideo), eventualmente legati alla videosorveglianza (e quindi geolocalizzati)
• Dati relativi alla navigazione online (indirizzo IP, dati sulla posizione, dati sulla navigazione internet, ecc.)
• Dati fiscali (CF, Partita IVA per professionisti o ditte individuali)
• Dati di dettaglio della proprietà (proprietà di veicoli e proprietà immobiliari, numeri di targa, ecc.);
• Documenti di identità (Carta identità, patente, passaporto…)
• Dati bancari (IBAN o n° c/c, carta di credito, …)
• Dati sul nucleo familiare (composizione, nominativi coniuge, figli, ecc.)
• Dati relativi a provvedimenti sanzionatori e disciplinari, amministrativi, ecc.
• Dati giudiziari: dati relativi condanne penali e reati (casellario giudiziale, carichi pendenti), dati relativi a procedimenti giudiziari in corso, sia civili che penali, …

Ognuna di queste possibili categorie di dati personali può possedere un diverso livello di riservatezza, non assoluto, ma dipendente dal contesto. Ad esempio, per un dipendente di un’azienda il dato dello stipendio in busta paga può costituire dato maggiormente riservato – all’interno della stessa – rispetto all’appartenenza ad un sindacato; sebbene quest’ultimo sia classificato come “dato particolare” e l’altro no.

Categorie di destinatari a cui verranno comunicati i dati: qui occorre indicare a quali tipologie di soggetti vengono comunicati I dati personali in questione per espletare attività specifiche o per adempiere a requisiti contrattuali o di legge. Ci sarà il consulente del lavoro per I dati del personale dipendete, ma anche gli Enti Previdenziali di competenza, Banche, Assicurazioni e così via. Predisporre un elenco esaustivo non è facile. Bisogna comprendere tutti quelli che trattano I dati in questione o solo quelli a cui vengono comunicati? Nel primo caso ci possono essere società di informatica che gestiscono I sistemi gestionali o l’assistenza sistemistica.

Trasferimento presso Paesi terzi o presso un’organizzazione internazionale: occorre indicare se i dati possono essere trasferiti presso un Paese extra UE (dove non vige il GDPR) e, in tal caso, quali sono le misure adottate per garantire il rispetto della privacy? Ad esempio, si può invocare il Privacy Shield per dati trasferiti negli USA, norme vincolanti d’impresa per dati trasferiti nell’ambito di un’azienda multinazionale o il consenso dell’interessato. In questo caso attenzione ai dati mantenuti in cloud: il datacenter potrebbe essere fuori dalla UE e, dunque, occorre assicurarsi che siano rispettate le regole previste.

Termine ultimo per la cancellazione: questa informazione può essere resa anche in forma di criterio (ad esempio fino al termine del periodo di prescrizione previsto per legge), non necessariamente di anni e mesi. Tuttavia, il rispetto del principio di limitazione temporale del trattamento spesso contrasta con gli interessi dell’organizzazione e la legislazione applicabile non aiuta a determinare periodi di conservazione congrui. Su questo aspetto si potrebbe discutere all’infinito per trovare un giusto compromesso fra le esigenze della privacy (e dei diritti dell’interessato) e quelle del titolare del trattamento che potrebbe voler mantenere certi dati per un tempo molto lungo per eventualmente difendersi in giudizio in caso di contenzioso. I dati conservati da un medico o da una struttura sanitaria relativamente ad un intervento chirurgico o un esame sono solo un esempio di questa problematica.

Base giuridica per effettuare il trattamento: è opportuno stabilire fin da subito qual è la base giuridica che rende lecito il trattamento, da ricercare fra quelle stabilite dall’articolo 6 del GDPR per tutte le tipologie di dati:

• Consenso dell’interessato
• Esecuzione di un contratto
• Esecuzione misure precontrattuali
• Obbligo legale
• Salvaguardia interessi vitali dell’interessato
• Esecuzione compiti di interesse generale
• Esercizio di pubblici poteri
• Legittimo interesse del Titolare

Se invece trattasi di dati appartenenti a particolari categorie di dati occorre ricercare la liceità fra le opzioni dell’articolo 9 del Regolamento UE 679, ovvero:

• Consenso dell’interessato
• Esercizio obblighi in materia di diritto del lavoro
• Esercizio obblighi in materia di protezione sociale
• Esercizio obblighi in materia di protezione sociale
• Tutela interesse vitale dell’Interessato
• Trattamento ex art. 9 lett. d) GDPR
• Dati personali resi pubblici dall’Interessato
• Trattamento in sede giudiziaria
• Trattamento per interesse pubblico rilevante
• Finalità di medicina
• Interesse pubblico per sanità pubblica
• Archiviazione nel pubblico interesse
• Ricerca storica o statistica

Descrizione generale delle misure di sicurezza adottate per garantire la riservatezza, l’integrità e la disponibilità dei dati: questo campo del registro è difficilmente compilabile con una descrizione sintetica che non rimandi ad altri documenti. Ecco che potrebbe essere utile rimandare ad un documento apposito che descriva nel dettaglio quali misure tecniche ed organizzative sono state poste in essere per tutelare i dati personali, ad esempio facendo riferimento ad un capitolo del manuale privacy o procedura di gestione della privacy, relazione sulle misure di sicurezza dei sistemi informatici e così via. Questo serve anche a evitare ridondanze visto che se la conservazione di un archivio cartaceo in armadi e contenitori chiusi a chiave può riferirsi ad alcuni trattamenti, l’implementazione di sistemi anti-malware copre probabilmente tutti i trattamenti effettuati con mezzi elettronici.

Eventuali contitolari e responsabili del trattamento nominati: per ogni trattamento potrebbe esserci un contitolare del trattamento che va indicato nel registro con i relativi dati identificativi e di contatto e riferimenti dell’eventuale DPO, mentre ogni trattamento potrebbe avere un responsabile esterno nominato secondo l’articolo 28 del GDPR in quanto effettua il trattamento “per conto del titolare”. In tal caso una gestione efficiente del Registro potrebbe prevedere un’anagrafica dei responsabili esterni del trattamento nominati con i relativi dati (denominazione, dati di contatto, data dell’atto di nomina, riferimenti contrattuali e relativa scadenza, ecc.) a cui associare ogni trattamento che prevede un responsabile esterno.

Per quanto riguarda il Registro del Responsabile il set di informazioni richieste dal GDPR è inferiore a quello del Registro del Titolare, direi forse troppo ridotto. È comunque opportuno riprendere molti dei campi utilizzati per il registro del Titolare anche per quello del Responsabile, al fine di mantenere una visione coerente dei dati trattati.

La principale problematica che si presenta per il Registro del Responsabile è che un’organizzazione che effettua un medesimo trattamento di dati personali per conto di diversi Titolari dovrebbe avere un Registro del Responsabile con moltissime voci (righe), praticamente tutte uguali se non per il nome del Titolare del trattamento (il Cliente). Questa situazione può essere risolta riportando nel Registro del Responsabile una sola riga con le informazioni identiche che sarebbero ripetute per tutti i trattamenti effettuati per conto di tutti i Titolari, richiamando – nel campo riservato all’identificazione del Titolare – un apposito elenco esterno al Registro nel quale sono riportati tutti i clienti per i quali si effettua il trattamento, con i relativi dati di contatto, ecc.

Questa situazione è comune a diverse categorie di attività, ad esempio consulenti del lavoro, commercialisti, software house e fornitori di SaaS in cloud.

Come tutti ormai sanno la fatturazione elettronica B2B è diventata obbligatoria dallo scorso 1° gennaio per tutti o quasi.

Al di là degli oserei dire inevitabili problemi tecnici che si stanno rilevando per mettere a regime questa rivoluzione contabile e fiscale del nostro Paese, credo sia opportuno capire meglio gli effetti di questa innovazione.

Già perché di una grande innovazione tecnologica si tratta
ed il fatto che il nostro Paese sia tra I primi ad adottarla in Europa deve,
una volta tanto, farci pensare positivo, di essere all’avanguardia. Invece
molti dicono: «ma gli altri Paesi non ce l’hanno!»

Come tutte le innovazioni occorre un po’ di impegno e di
risorse per arrivare a regime, ma questo non deve far ritenere che sia una cosa
sbagliata. Occorrerà “soffrire” un po’ per imparare ed abituarsi a questa nuova
modalità di fatturazione, ma alla fine i vantaggi saranno notevoli.

Da parte dello Stato e del Fisco (Agenzia delle Entrate) ci
saranno innumerevoli vantaggi: comunicazione tempestiva delle fatture emesse,
maggior controllo su potenziali evasioni fiscali ed altri reati, omogeneità dei
dati in formato elettronico standard, maggior possibilità di effettuare
controlli incrociati, ecc.

Ma vorrei analizzare i vantaggi dal punto di vista delle
imprese e dei professionisti, fermo restando che bisogna dare per scontato che
la possibilità di evasioni e truffe ai danni dello Stato non deve essere
considerata una penalizzazione.

Premesso ciò il nuovo sistema obbliga le imprese ed i professionisti
(eventualmente attraverso i rispettivi commercialisti) a dotarsi di un applicativo
web per l’invio delle fatture elettroniche (o di adottare quello messo a
disposizione dalla AE), A parte singoli liberi professionisti o imprese
individuali di imprenditori di ridotte capacità di utilizzo di strumenti
informatici, la scelta di adottare la soluzione proposta dal proprio software
gestionale oppure di dotarsi di un nuovo applicativo dedicato è sicuramente
quella vincente.

Tali soluzioni permetteranno alle aziende di disporre delle
fatture attive già registrate in contabilità al momento dell’emissione e del
relativo pagamento e di registrare le fatture passive al momento della
ricezione, o poco tempo dopo, con un minimo inserimento di dati. Questo
significa eliminazione completa del documento cartaceo e riduzione della
probabilità di commettere errori, ovvero riduzione dei costi del processo
contabile. Soprattutto per le piccole imprese, che magari emettevano le fatture
con un software e poi il consulente fiscale le reinseriva nel proprio
applicativo di contabilità.

Niente più pile di carta di fatture da registrare (e da pagare),
niente più fatture non ricevute con inevitabili solleciti del fornitore, niente
più paure che un’errata registrazione possa comportare sanzioni fiscali.

Per arrivare al processo amministrativo-contabile perfetto
basterebbe rendere automatici i pagamenti in base ai termini pattuiti, ma
questo è un altro discorso… sebbene volendo lo Stato potrebbe ovviare a questa
mala-abitudine di molte imprese italiane di ritardare I pagamenti oltre ogni
limite.

Certamente questa rivoluzione dei processi contabili porterà
dei vantaggi alle aziende che avranno saputo cogliere questa opportunità per
migliorare la propria efficienza. Chi avrà deciso di affidarsi a servizi di
fatturazione elettronica di terzi, ad esempio della Banca o di provider a basso
costo, piuttosto che sposare le soluzioni integrate in un proprio gestionale, pagherà
dazio nei prossimi anni perché si troverà a duplicare le registrazioni o a
pagare uno Studio Commercialista esterno per un servizio in più. A proposito
dei Commercialisti: molti di loro che hanno tenuto la contabilità dei clienti
si vedranno eliminare questo servizio per i clienti che avranno deciso di
seguire il proprio applicativo gestionale, dunque i compensi per le loro
prestazioni dovranno inevitabilmente diminuire, magari non subito, ma nel medio
periodo.

Purtroppo oggi esistono imprese che ancora non dispongono di
un software gestionale, almeno per gestire ordini e fatture, e forse avranno
colto anche loro questa opportunità di informatizzare la gestione di alcuni
processi. Parliamoci chiaro, un’impresa che fattura almeno 500 mila euro
oggigiorno non può non disporre di un software gestionale per la propria
attività.

La rivoluzione dei processi contabili, forzata dalla
fatturazione elettronica, poterà anche ad una rivalutazione nelle risorse umane
e delle relative competenze.

Anche certe abitudini delle nostre imprese di fatturare le
prestazioni a scadenze definite (ad es. metà e fine mese) dovranno essere
riviste; perché a parte il primo periodo di messa a regime della fatturazione
elettronica, fra pochi mesi per emettere una fattura con data ad es. 30 maggio,
non si potrà aspettare il 5 o 6 giugno e i tempi fra consuntivazione delle
vendite di prodotti e servizi e loro fatturazione dovranno essere rivisti.

Da un lato, dunque, cerchiamo di capire bene come funzionerà
questo nuovo sistema, dall’altro pensiamo anche come riprogettare il processo
contabile per non trovarsi in difficoltà e non dover sopportare maggiori costi.

Infine, il problema di privacy, evidenziato dal Garante per
la Protezione dei Dati Personali quando ormai mancava poco tempo all’avvio
della fatturazione elettronica obbligatoria fra privati.

Si potrebbe osservare che ci potevano pensare prima, Agenzia
delle Entrate nel progettare il sistema e Garante nell’esaminare il contesto.

In realtà sono stati posti molti interrogativi, anche
piuttosto inquietanti, sul possibile utilizzo dei dati di fatturazione
elettronica gestiti nelle varie piattaforme software e dai provider di conservazione
sostitutiva.

Mi sembra chiaro che è a prescindere vietato sfruttare i
dati presenti nelle piattaforme per ricavare dati statistici significativi,
salvo che i titolari di tali dati non ne concedano il permesso.

Sul fronte più squisitamente tecnico della sicurezza
informatica ci si pone l’interrogativo se siano sicure tutte queste fatture,
anche contenenti dati sensibili se relative a prestazioni sanitarie, nei
database conservati dai provider dei vari applicativi per la fatturazione
elettronica. E il famigerato SDI dell’Agenzia delle Entrate?

Verrebbe invece da chiedersi quanto siano sicuri i dati
conservati nei software gestionali di contabilità nei vari server aziendali (o
PC di piccole imprese e professionisti della sanità), relativamente alle
fatture gestite informaticamente finora.