Negli ultimi anni, le farmacie hanno ampliato la gamma di servizi offerti ai cittadini, evolvendo da semplici punti di dispensazione di farmaci a veri e propri presidi sanitari di prossimità. Questa trasformazione ha portato a una maggiore gestione di dati personali anche appartenenti a categorie particolari, imponendo ai farmacisti il dovere di rispettare rigorosamente la normativa sulla protezione dei dati personali, in particolare il Regolamento Generale sulla Protezione dei Dati (GDPR), il Codice Privacy novellato (D.Lgs 196/2002 aggiornato dal D.Lgs 101/20218) e le linee guida nazionali.

L’Importanza del GDPR nella Gestione dei Dati Sanitari

Il GDPR ha introdotto principi chiave che i farmacisti devono seguire nella gestione dei dati personali, tra cui:

• Liceità, correttezza e trasparenza: I dati devono essere raccolti con il consenso esplicito dell’interessato e trattati in modo chiaro, ma solo nei casi in cui tale consenso è necessario, oppure in base ad altra base giuridica come stabilito dal GDPR (ad esempio non per la dispensazione di farmaci dietro presentazione di ricetta medica). Il tutto supportato da adeguata informativa all’interessato.
• Limitazione delle finalità: Le informazioni devono essere utilizzate esclusivamente per gli scopi dichiarati, come la fornitura di servizi sanitari o la gestione delle prescrizioni mediche e non per finalità di marketing.
• Minimizzazione dei dati: Devono essere raccolti solo i dati strettamente necessari per l’erogazione del servizio (ad esempio nella raccolta punti per ottenere sconti o per le carte fedeltà).
• Integrità e riservatezza: Devono essere adottate misure tecniche e organizzative per garantire la sicurezza dei dati ed evitare accessi non autorizzati.

Nuovi Servizi Farmaceutici

L’introduzione di servizi innovativi, come la telemedicina, la prenotazione online di farmaci e la consulenza tramite strumenti digitali (whatsapp, e-mail, sito web), ha reso ancora più cruciale il rispetto della normativa sulla protezione dei dati.

Questi servizi spesso richiedono l’acquisizione e la conservazione di informazioni sanitarie sensibili, aumentando il rischio di violazioni della privacy. Ad esempio, piattaforme web che offrono il ritiro di farmaci su prenotazione o servizi di consulto devono garantire che i dati siano trasmessi e conservati in modo sicuro, evitando la condivisione non autorizzata con terze parti.

Obblighi dei Farmacisti nella Protezione dei Dati

I farmacisti hanno la responsabilità di garantire la conformità alle normative vigenti attraverso:

• Formazione continua: Aggiornarsi costantemente sulla normativa (GDPR, Codice Privacy, Linee Guida EDPB, Provvedimenti del Garante Privacy nazionale) e sulle migliori pratiche per la protezione dei dati.
• Adozione di misure di sicurezza: Implementare sistemi di protezione informatica per evitare attacchi hacker e accessi non autorizzati.
• Gestione dei consensi: Assicurarsi che i pazienti siano pienamente informati su come vengono trattati i loro dati e ottenere il consenso esplicito quando necessario, in particolare nei servizi di telemedicina.
• Registrazione e tracciabilità: Mantenere documentazione sulle procedure adottate per la protezione dei dati e garantire la tracciabilità di ogni operazione effettuata.

Il rispetto della normativa sulla protezione dei dati non è solo un obbligo legale, ma anche un elemento fondamentale per tutelare la fiducia dei pazienti nei confronti delle farmacie. La crescente digitalizzazione dei servizi richiede un approccio consapevole e responsabile nella gestione dei dati personali, per garantire la sicurezza e la riservatezza delle informazioni sanitarie. I farmacisti devono quindi adottare tutte le misure necessarie per proteggere la privacy dei loro clienti e operare nel pieno rispetto della normativa vigente.

Il rischio nella gestione dei nuovi servizi

Oggi le farmacie italiane offrono una vasta gamma di servizi, tra cui la dispensazione di farmaci con e senza ricetta, la telemedicina (ECG a distanza, Holter pressorio e Holter sanguigno), la prenotazione online di farmaci, l’accettazione di campioni biologici per lo svolgimento di esami di laboratorio e il ritiro dei referti di esami di laboratorio, la misurazione della pressione, test diagnostici rapidi (emocromo, profilo lipidico, ecc.), vaccinazioni e servizi di assistenza personalizzata per i pazienti cronici, analisi della pelle e del capello, nonché vendita di prodotti on-line (e-commerce).

Nel rapporto fra farmacia e fornitore di servizi, i ruoli soggettivi in materia di privacy possono variare in base alle attività svolte. La farmacia, generalmente, agisce come Titolare del trattamento dei dati personali, in quanto determina le finalità e i mezzi del trattamento. Il fornitore di servizi, invece, può assumere il ruolo di Responsabile del trattamento quando tratta i dati per conto della farmacia, seguendo le istruzioni ricevute. Spesso, tuttavia, è il fornitore stesso che determina mezzi e finalità del trattamento dei dati personali, poiché gestisce la parte fondamentale del processo di erogazione del servizio: si pensi ai servizi di telemedicina come l’ECG o l’esecuzione di esami di laboratorio a seguito di campioni prelevati in farmacia.

È fondamentale che tra le parti venga stipulato un accordo chiaro per garantire la conformità al Regolamento UE 679/2019 (GDPR) e la protezione dei dati personali dei pazienti. Tale accordo per i servizi dove è il fornitore a determinare mezzi (ad esempio strumenti informatici) e finalità del trattamento (ad esempio esecuzione di esami di laboratorio) deve riportare esplicitamente la nomina della Farmacia a Responsabile del Trattamento e investire il fornitore del ruolo di Titolare. Diversamente la Farmacia sarà esposta a rischi di sanzione e risarcimento danni in caso di violazioni di dati perpetrate nei sistemi del fornitore.

In particolare, per quanto riguarda i servizi svolti per conto di ASL o del Servizio Sanitario Nazionale (SSN) le farmacie agiscono come Responsabili del Trattamento. Negli ultimi anni, oltre ai servizi più propriamente sanitari, hanno iniziato a svolgere anche servizi come l’attivazione dello SPID (per conto di Lepida nella Regione Emilia-Romagna) e del Fascicolo Sanitario.

Altro aspetto critico è l’esecuzione di esami sanguigni con apparecchiature automatiche (in autoanalisi), oggetto di recenti polemiche sulla qualità degli esiti a seguito di un’inchiesta di Milena Gabbanelli sulla base di uno studio effettuato dalla National Library of Medicine. Spesso le farmacie non hanno consapevolezza di quali dati vengono raccolti e conservati dal software e se il fornitore dell’apparecchiatura ha accesso ai dati dei referti, mentre il Regolamento UE 679/2016 richiede un’informativa chiara da fornire al paziente con garanzia del rispetto di tutti i suoi diritti.

Le stesse criticità sono presenti nell’erogazione di servizi di analisi varie (analisi della pelle, analisi del capello, densitometria, intolleranze alimentari, ecc.), spesso proposti in partnership con il fornitore dell’apparecchiatura di analisi o del kit di raccolta campioni con analisi svolta dal laboratorio del fornitore. Per questi servizi il fornitore dovrebbe fornire al farmacista un servizio con trattamento di dati personali privacy-by-design, ma sovente così non è, facendo ricadere sulla farmacia l’onere di fornire al paziente un’informativa privacy con richiesta di consenso adeguata e di disciplinare il rapporto con il fornitore che sovente è poco collaborativo dal punto di vista della gestione dei dati personali.

Anche le diffuse carte fedeltà (fidelity card) delle farmacie sono spesso gestite in modo non conforme ai requisiti normativi con informative carenti o addirittura assenti e conservazione dei dati personali del cliente oltre quanto indicato dal Garante Privacy.

Proprio in virtù dell’enorme mole di dati personali che le farmacie trattano, devono adottare una serie di misure di sicurezza per proteggere i dati personali dei propri clienti. Tra queste rientrano l’uso di software aggiornati e certificati per la gestione dei dati, l’adozione di sistemi di autenticazione a più fattori per limitare l’accesso non autorizzato, la crittografia delle informazioni sensibili, la formazione continua del personale sulle best practice in materia di protezione dei dati e la stipula di accordi di riservatezza con eventuali fornitori di servizi esterni. Inoltre, è fondamentale effettuare controlli periodici e audit per verificare la conformità alle normative vigenti e garantire la sicurezza delle informazioni trattate.

Infine, i siti web delle farmacie non sono più dei siti solo di presentazione a scopo pubblicitario, ma sono diventati – in alcuni casi – veri e propri portali web – talvolta anche associati ad app per dispitivi mobili – dove si possono prenotare i servizi sopra indicati, prenotare farmaci trasmettendo anche la ricetta medica o addirittura acquistare prodotti attraverso siti di e-commerce. Adottare questi strumenti, magari associati a servizi di digital marketing come l’invio di newsletter promozionali, amplia enormemente gli adempimenti privacy della farmacia e il parco dei fornitori coinvolti nel trattamento dei dati personali che spesso non forniscono adeguato supporto nell’implementare servizi conformi alla normativa privacy.

Oggi, con i le nuove minacce provenienti da internet, come i ransomware, il phishing e gli attacchi mirati di hacker che cercano non solo di cifrare, rendendoli inaccessibili, i dati della vittima, ma anche di esfiltrarli, rendendo maggiormente efficace la c.d. “double extortion”: «se vuoi accedere nuovamente ai tuoi dati devi pagare il riscatto, ma se non lo paghi posso pubblicare sul web i dati personali dei tuoi clienti… ».

Contro queste minacce, e con un perimetro nel quale operano i sistemi informatici molto esteso, non basta più dichiarare di avere l’antivirus, le password e di fare il backup per garantirsi l’immunità rispetto alle eventuali sanzioni del Garante Privacy. È necessario dimostrare di aver attuato misure di sicurezza adeguate a seguito di una valutazione dei rischi.

Per dimostrare di aver adempiuto ai requisiti del GDPR non basta aver redatto il registro dei trattamenti, ma è necessario anche documentare la valutazione dei rischi (da aggiornare periodicamente), le misure di sicurezza tecniche ed organizzative adottate, gli accordi per la protezione dati con i fornitori/partner come responsabili del trattamento, le istruzioni al personale sull’utilizzo dei sistemi informatici e così via.

Purtroppo oggi è facile trovare farmacie che non sono in grado di dimostrare di aver adottato adeguate misure di sicurezza perché tali misure non sono documentate e sono note solo a qualche consulente informatico che le ha implementate senza avere un idoneo contratto per la gestione sistemistica dei sistemi della farmacia ed una nomina di Amministratore di Sistema.

I rischi che si corrono ignorando questa normativa sono importanti: oltre alle eventuali sanzioni del Garante per la Protezione dei Dati Personali (fino al 4% del fatturato annuo nei casi più gravi), un attacco ransomware potrebbe bloccare l’attività della farmacia per diversi giorni (con annesso rischio reputazionale) e l’eventuale violazione della riservatezza dei dati personali dei clienti potrebbe comportare richieste di risarcimento del danno molto onerose.

Ecco qui https://www.teleperformanceitalia.it/attacchi-informatici-hacker-rubano-gli-account-delle-farmacie-con-i-bot/?utm_source=chatgpt.com un esempio di attacchi hacker registrate contro farmacie.

Sicuramente l’Intelligenza Artificiale è uno (se non il primo) degli argomenti più in vogha e dibattuti di questi ultimi mesi.

Dall’uscita di ChatGPT, seguita da Microsoft Copilot e Google Bard, in poi si è dibattuto su diversi aspetti dell’IA: aspetti etici, di privacy, perdita di posti di lavoro, strumento utile per le imprese e così via.

Proprio per questo la Commissione Europea è voluta intervenire in gran fretta emanando il c.d. “AI Act” di cui si parla molto in questi giorni.

L’AI non è una novità degli ultimi anni, ma il passaggio epocale si è avuto con il passaggio all’AI generativa che si differenzia da altre applicazioni di AI. Ma cos’è l’IA generativa?

L’intelligenza artificiale generativa (AI generativa) è una categoria di intelligenza artificiale (IA) che si concentra sulla creazione di dati o contenuti, come immagini, musica, testo, o altri tipi di informazioni, invece che sull’analisi o sull’interpretazione di dati esistenti.

Ci sono diverse modalità attraverso le quali l’IA generativa può operare:

1. Reti neurali generative (GANs): Le reti neurali generative sono uno dei metodi più diffusi per l’IA generativa. Le GANs sono composte da due reti neurali: il generatore e il discriminatore. Il generatore crea nuovi dati, mentre il discriminatore cerca di distinguere i dati generati da quelli reali. Le due reti vengono addestrate insieme in modo che il generatore possa migliorare continuamente nella creazione di dati realistici.
2. Reti neurali ricorrenti (RNNs) e reti neurali trasformative (TNNs): Questi tipi di reti sono utilizzate per generare sequenze di dati, come testo o musica. Le RNNs sono particolarmente efficaci nel generare dati sequenziali poiché possono tenere conto del contesto temporale. Le TNNs, d’altra parte, utilizzano trasformatori per elaborare sequenze di dati in parallelo, rendendo il processo più efficiente.
3. Altri approcci: Ci sono anche altri approcci all’IA generativa che utilizzano tecniche diverse, come le reti neurali Bayesiane o i modelli di Markov nascosti.

Le principali differenze tra l’IA generativa e altre tipologie di intelligenza artificiale, come l’IA basata su regole o l’IA di apprendimento supervisionato, risiedono nel loro scopo e nella modalità di funzionamento:

1. Scopo: L’IA generativa si concentra sulla creazione di nuovi dati o contenuti, mentre altre forme di IA possono essere utilizzate per compiti come la classificazione, la previsione o l’ottimizzazione.
2. Modalità di funzionamento: Mentre altre forme di IA spesso lavorano con dati esistenti per estrarre informazioni o fare previsioni, l’IA generativa crea nuovi dati dall’interno del sistema, spesso senza dipendere direttamente dai dati di addestramento.

In sintesi, l’IA generativa è un ramo dell’intelligenza artificiale che si occupa della creazione di nuovi dati o contenuti, utilizzando una varietà di tecniche e approcci, come le reti neurali generative o le reti neurali ricorrenti. Le sue principali differenze risiedono nel suo scopo e nella modalità di funzionamento rispetto ad altre forme di IA.

Ma quali sono le applicazioni dell’intelligenza artificiale che possono essere utili per le imprese?

Le applicazioni dell’intelligenza artificiale (IA) per le imprese sono molteplici e sempre più diffuse in diversi settori. Alcuni esempi includono:

1. Automatizzazione dei processi: L’IA può automatizzare una vasta gamma di processi aziendali, riducendo il carico di lavoro manuale e migliorando l’efficienza. Questo può includere l’automatizzazione dei processi di produzione, gestione delle scorte, fatturazione, supporto clienti e molto altro.
2. Analisi dei dati: L’IA può analizzare grandi quantità di dati aziendali per estrarre insight significativi e informazioni utili per prendere decisioni informate. Questo può includere l’analisi predittiva per prevedere tendenze di mercato, la segmentazione dei clienti per personalizzare le offerte, l’individuazione di anomalie per la sicurezza informatica e molto altro.
3. Servizi clienti intelligenti: L’IA può essere utilizzata per migliorare l’esperienza del cliente attraverso chatbot intelligenti che forniscono supporto immediato e personalizzato, sistemi di raccomandazione per suggerire prodotti o servizi pertinenti e analisi dei sentimenti per comprendere meglio le esigenze e le opinioni dei clienti.
4. Manutenzione predittiva: L’IA può essere impiegata per prevedere guasti o problemi di manutenzione in anticipo, consentendo alle imprese di effettuare interventi preventivi e ridurre i costi di manutenzione e i tempi di inattività.
5. Ottimizzazione delle risorse: L’IA può ottimizzare l’utilizzo delle risorse aziendali, come la gestione delle flotte di veicoli, l’allocazione delle risorse umane e la pianificazione della produzione, per massimizzare l’efficienza e ridurre i costi operativi.
6. Personalizzazione dei servizi: L’IA può aiutare le imprese a offrire servizi altamente personalizzati ai propri clienti, utilizzando algoritmi di apprendimento automatico per adattare le offerte in base alle preferenze individuali e al comportamento passato dei clienti.
7. Sicurezza informatica: L’IA può migliorare la sicurezza informatica attraverso sistemi di rilevamento delle minacce basati sull’apprendimento automatico che identificano e rispondono in tempo reale alle potenziali minacce alla sicurezza dei dati aziendali.
8. Produzione di contenuti: Produzione di contenuti: L’IA può generare contenuti scritti, come post per siti web o pubblicità personalizzate.
9. Ottimizzazione delle operazioni di inventario: L’IA aiuta a gestire gli stock in modo efficiente

Questi sono solo alcuni esempi delle molte applicazioni dell’IA per le imprese. In generale, l’IA può essere utilizzata per migliorare l’efficienza operativa, ottimizzare le decisioni aziendali, migliorare l’esperienza del cliente e creare nuove opportunità di business.

Dai di addestramento dell’AI

Questo, però, solo in teoria, perché l’IA deve essere addestrata con informazioni reali e, come avviene per altri processi di elaborazione computerizzata di dati, il risultato di un algoritmo deterministico produce dati che dipendono dall’input e si può ricordare il principio “garbage in – garbage out”. Ovvero se i dati in input sono una schifezza, i dati in output lo saranno altrettanto!

Ho sentito parlare di grandi opportunità per le imprese di utilizzare i dati in loro possesso attraverso l’intelligenza artificiale, ma molte imprese, soprattutto le medio-piccole, non hanno dati validi da analizzare. Questo perché anche molti progetti della c.d. Industria 4.0 sono stati unicamente finalizzati ad acquistare macchinari ed apparecchiature varie con sgravi fiscali, ma l’interconnessione e la raccolta dati è stata solo virtuale, ovvero non si sono impiegati software per la raccolta e la gestione dei dati provenienti dalle macchine. Dunque, molte aziende hanno acquistato macchinari moderni, in grado di acquisire deti sulla produzione, sui fermi macchina, sulla qualità dei prodotti e molto altro, ma non hanno investito nell’integrazione con sistemi MES, schedulatori, sistemi di Business Intelligence in grado di sfruttare i dati che le macchine potevano acquisire.

In queste situazioni l’IA non serve a nulla, bisogna fare un passo indietro e ricominciare daccapo con la raccolta dati.

La qualità dei risultati ottenuti dall’Intelligenza Artificiale dipende, pertanto, sia dalla programmazione dello strumento – realizzata dai tecnici che progettano e realizzano sistemi di IA – , sia dall’entità e dalla qualità dei dati per l’addestramento. Ecco, quindi, che diventa sempre più importante avere il controllo sui dati.

Rischi operativi

Possiamo citare diversi casi di IA oggi fallimentare: i chatbot ed alcuni sistemi di previsione delle esigenze dei clienti che ti propongono offerte di acquisto in base alle tue preferenze.

I chatbot che dovrebbero fornire assistenza ai clienti in realtà fanno spesso perdere tempo al cliente perché nella stragrande maggioranza dei casi non risolvono i problemi del cliente che sarà quasi sempre costretto a contattare un essere umano (possibilmente competente, magari anche che capisca bene la nostra lingua, ma questo è un altro discorso…) dopo aver accumulato una buona quantità di frustrazioni ed essersi indispettito per il rapporto intercorso con il chatbot.

Tra l’altro recentemente si è verificato un caso in cui una Compagnia di Assicurazione si è vista dover risarcire un cliente dei costi sostenuti per un’errata risposta di un chatbot sull’applicazione di uno sconto. Se aggiungiamo a questi rischi operativi anche i rischi privacy (che vedremo dopo), allora dovremmo riflettere bene prima di “ingaggiare” un chatbot per rispondere ai clienti. Si risparmieranno risorse, ma il livello di insoddisfazione del cliente crescerà sicuramente.

Anche sulla validità dei suggerimenti di acquisto proposti dall’AI ci sarebbe molto da obiettare e il passaggio da algoritmi deterministici poco efficaci e applicazioni dell’AI nel marketing digitale dovrebbe portare un valore aggiunto tangibile.

Altre ipotesi di applicazione dell’AI sono presenti nel campo della sanità. Facciamo un esempio.

L’AI potrebbe analizzare una mole considerevole di dati di esami diagnostici e prevedere una diagnosi per un paziente, se non addirittura una cura. Potrebbe essere sicuramente utile sfruttare il lavoro dell’IA per ipotizzare una diagnosi, ma poi la decisione la deve prendere un medico competente e deve anche assumersene le responsabilità. Riguardo alla cura il problema potrebbe non essere tutto sulle previsioni dell’IA, ma sui dati di addestramento, i dati in input. Per fare un esempio ormai noto a tutti, di fronte ad un caso di Covid-19 l’IA potrebbe suggerire una cura secondo i c.d. “protocolli ufficiali”, ovvero “tachipirina e vigile attesa”, tanto per intenderci. Ma molti medici – in forza di diversi studi – ritengono che tale cura sia non adeguata. Per cui torniamo sempre alla responsabilità del medico sulla decisione da prendere, senza potersi rivalere sull’IA in caso di errore.

Stesso discorso potrebbe essere fatto per la scelta di un farmaco: incrociando i dati del paziente, la diagnosi e i farmaci disponibili per la cura l’IA potrebbe suggerire il farmaco più adatto, ma parliamo sempre di un ausilio al medico, che potrebbe aiutarlo anche a non commettere errori (ad esempio valutando i possibili effetti avversi), ma non un esonero di responsabilità.

Passando ad altri impieghi dell’AI si è molto discusso delle possibili applicazioni – anche semplicemente di ChatGPT e dei suoi “cugini” – per generare testo su determinati argomenti e sulla possibilità che un tale impiego provochi l’eliminazione di posti di lavoro.

Evidentemente CHatGPT può essere utilizzato per redigere un articolo o un post di un Blog, per riassumere un testo o un libro noto ed anche per predisporre un questionario con un certo numero di domande con risposta multipla di cui una sola corretta su un determinato argomento non troppo specifico.

In tutti questi casi, per un utilizzo professionale (ovvero ad es. non per svolgere i compiti di scuola), è comunque necessaria una supervisione di una persona esperta dell’argomento per evitare di lasciar passare errori di contenuto.  Anche la semplice sintesi di un documento normativo effettuata da un tool di AI potrebbe evidenziare rischi di interpretazione errata di alcuni passi fondamentali.

Infine, bisogna considerare che l’IA (ad es. Chat GPT) non esprime pareri, dunque se un autore volesse analizzare un argomento fornendo il proprio punto di vista, dovrebbe comunque rielaborare la risposta di ChatGPT, Copilot, Bard o altre IA.

Molto utile si prospetta l’impiego dell’IA per sviluppare codice, ma anche qui vedremo in seguito che esistono dei rischi di sicurezza, dunque la revisione e test approfonditi di un programmatore esperto è fortemente consigliata.

Rischi Privacy

Ci sono due tipi di rischi sulla protezione dei dati personali legati all’IA:

• I dati raccolti dagli utenti che chiedono informazioni all’IA potrebbero non essere utilizzati con finalità lecite (con il consenso dell’utente dove richiesto) e tutto questo insieme di dati raccolti, se non anonimizzato, potrebbe – in caso di violazione degli archivi (data breach) – apportare danni significativi agli utenti stessi, in modo indefinito, perché non sappiamo quali domande pone e quali informazioni fornisce un utente all’IA. Ad es. un chatbot di una Banca o di una Assicurazione potrebbe raccogliere dati sensibili (dati relativi alla salute, dati finanziari, credenziali di accesso, ecc.);
• Se un determinato processo è governato dall’IA esso potrebbe portare a decisioni che comportano rischi per i diritti e le libertà dell’interessato. Anche qui gli esempi sono molteplici: dall’errata diagnosi di una malattia di un paziente, all’assegnazione o non assegnazione di un lavoro a un candidato, alla mancata erogazione di un premio, ecc.

Non voglio qui trattare rischi dovuti ad un uso illecito dell’IA, salvo quanto riportato a proposito dell’IT Security; naturalmente come qualsiasi strumento – fisico o informatico – anche l’IA se usata per scopi criminali può arrecare danni alle persone, sia fisici che morali, compresi quelli disciplinati dalla normativa privacy (GDPR in UE).

Sicurezza informatica

Un discorso a parte va fatto sulla sicurezza informatica.

Da un lato l’AI aiuta le difese dagli attacchi hacker per riconoscere in tempo reale un attacco, un’intrusione nascosta nei sistemi, un tentativo di phishing e molto altro; dall’altro l’IA è uno strumento a disposizione anche dei criminali informatici per preparare virus, e-mail di phishing e altro in tempi più ridotti-

La sicurezza informatica dell’applicazione di IA è fondamentale per evitare risultati inattesi e potenzialmente dannosi per l’utente dell’applicazione di IA, qualunque essa sia.

L’opportunità di sfruttare l’IA per sviluppare codice sorgente (software) presenta anche la possibilità, per l’IA manomessa, di inserire codice malevolo in grado di infettare i computer che eseguiranno il programma software oppure di inserire vulnerabilità che poi potranno essere sfruttate dai criminali informatici per  introdursi nel sistema dell’utente.

Aspetti etici

Dunque, l’AI potrebbe agevolare e velocizzare molte attività, ma la supervisione ed il controllo di umani competenti è sempre necessario, sia nella progettazione del modello e dell’applicazione di IA, sia nella verifica dei risultati. Proprio perché i risultati dell’AI non dipendono da algoritmi deterministici, come devono essere testati i risultati di una comune applicazione software, a maggior ragione devono essere verificati i risultati di un’applicazione di AI prima di impiegarli per qualsiasi scopo, anche se nella maggiornaza dei casi l’IA ci fornirà un servizio migliore di qualsiasi essere umano, soprattutto in termini di tempo.

Non mi sembra ci siano tante differenze rispetto ad altre novità ed invenzioni tecnologiche del passato: dalle macchine automatiche per la produzione industriale ai programmi di elaborazione elettronica dei dati che hanno evitato di compiere azioni manuali, dalle e-mail al cloud computer, dalle auto elettriche al BIM. Tutte le innovazioni hanno portato alla scomparsa di posti di lavoro ed alla creazione di altri.

Chiaramente l’uso dello strumento deve rispettare le regole dell’etica ed in questo dovrebbero venire in aiuto le leggi che si sta cercando di introdurre, dall’AI Act in poi.

Come molti degli strumenti ed innovazioni che sono state introdotte negli ultimi decenni,  anche l’AI può essere utilizzata per compiere attività illecite, reati e provocare danni – morali e materiali –  a persone e cose, ma non per questo deve essere vietata od ostacolata. In fondo anche un coltello da cucina o un’automobile possono essere impiegati per uccidere persone!

L’AI cancellerà posti di lavoro? Ne creerà di altri? Una risposta positiva ad entrambe queste domande non deve preoccupare. In fondo ci sono già diverse decisioni e regolamentazioni, introdotte almeno a livello europeo, che potrebbero creare effetti economici negativi per alcune imprese e lavoratori e positivi per altre: gli obblighi introdotti dal legislatore UE sull’immatricolazione di sole auto elettriche e l’eliminazione delle caldaie a gas sono solo alcuni esempi significativi che impatteranno il mondo del lavoro forse più dell’introduzione dell’AI.

La sicurezza di un sito web è fondamentale per proteggere i dati e le informazioni degli utenti e dei gestori.

Sappiamo (dalla ISO 27001 e dal GDPR in primis) che la sicurezza va declinata nelle sue proprietà: Riservatezza, Integrità e Disponibilità. Dunque, non solo è importante garantire la riservatezza dei dati, ma anche la loro integrità (esattezza, correttezza) e la loro disponibilità in tempi idonei laddove attraverso il sito web si fornisce un servizio a clienti effettivi e potenziali. Inoltre, l’indisponibilità del sito web a causa di un attacco hacker (attacco DDOS, defacement del sito web) comporta un grave rischio reputazionale per il suo proprietario.

L’impresa deve dunque assicurarsi che il gestore del sito lo mantenga adeguatamente protetto, perché la sicurezza di un sito web è fondamentale per proteggere i dati personali e le informazioni degli utenti e dell’impresa proprietaria del sito. Tuttavia, esistono diverse vulnerabilità che possono compromettere la sicurezza di un sito web e renderlo esposto agli attacchi informatici. Alcune di queste vulnerabilità sono:

• L’iniezione di codice, che consiste nell’inserire dei comandi o delle query malevoli nel sito web, sfruttando le sue interfacce di input. Questo può portare a modificare, cancellare o rubare i dati del sito web o ad eseguire azioni indesiderate.
• Il cross-site scripting (XSS), che consiste nell’inserire dei codici JavaScript nel sito web, sfruttando le sue pagine web dinamiche. Questo può portare a manipolare il contenuto del sito web o a rubare le informazioni degli utenti, come i cookie o le credenziali di accesso.
• Il cross-site request forgery (CSRF), che consiste nell’indurre gli utenti a eseguire delle richieste non autorizzate al sito web, sfruttando la loro sessione attiva. Questo può portare a modificare le impostazioni del sito web o a effettuare delle operazioni dannose, come il trasferimento di denaro o l’invio di e-mail spam.
• Il furto di identità, che consiste nell’ottenere le informazioni personali degli utenti, come il nome, l’e-mail, il numero di telefono o i dati bancari. Questo può portare a utilizzare queste informazioni per scopi fraudolenti, come l’accesso ai loro account online o l’effettuazione di acquisti non autorizzati.

Per prevenire queste vulnerabilità e rendere il sito web più sicuro, esistono diverse misure di sicurezza che possono essere adottate. Alcune di queste misure sono le seguenti:

• Utilizzare un protocollo HTTPS per criptare le comunicazioni tra il sito web e i visitatori. Questo impedisce che i dati possano essere intercettati o modificati da terze parti malintenzionate. Inoltre, i siti “non https” vengono considerati come pericolosi dai browser e dagli antivirus e indicizzati con priorità bassa da Google, per cui risultano meno accessibili.
• Mantenere aggiornato il software del sito web, compresi i temi, i plugin e il sistema di gestione dei contenuti (CMS quali WordPress, Joomla od altri). Questo riduce il rischio di vulnerabilità e bug che potrebbero essere sfruttati dagli hacker.
• Impostare delle regole di accesso al sito web, come l’utilizzo di password forti, l’autenticazione a due fattori e il blocco degli indirizzi IP sospetti. Questo limita le possibilità di accesso non autorizzato al sito web e ai suoi dati.
• Effettuare dei backup regolari del sito web e dei suoi dati, in modo da poter ripristinare il tutto in caso di danni o perdite. Questo garantisce la continuità del servizio e la salvaguardia delle informazioni.
• Monitorare il traffico e le attività sul sito web, per individuare eventuali anomalie o tentativi di intrusione. Questo permette di intervenire tempestivamente in caso di problemi e di prevenire ulteriori danni.

Queste sono solo alcune delle misure di sicurezza che possono essere adottate per rendere un sito web più sicuro. Ogni sito web ha delle esigenze specifiche e richiede una valutazione personalizzata delle minacce che incombono su di esso, delle sue vulnerabilità e delle sue soluzioni. Per questo, è consigliabile affidarsi a dei professionisti del settore, che possano offrire una consulenza qualificata e un supporto tecnico adeguato.

Talvolta, infatti, le web agency sono molto preparate sulle tecniche di digital marketing e di pubblicità on-line, ma lo sono meno gli sviluppatori del sito web dal punto di vista della sicurezza.

In questo ambito, poi, si inserisce il rispetto del GDPR. Il General Data Protection Regulation (GDPR) è la normativa europea che stabilisce le regole sulla protezione dei dati personali dei cittadini dell’Unione Europea. Il GDPR (Regolamento UE 2016/679) ha un impatto diretto sulla gestione dei dati personali dei visitatori del sito web. Infatti, se il sito web che raccoglie dati personali dei visitatori, è importante che rispetti il GDPR. Ecco alcune delle caratteristiche che il sito web dovrebbe avere per essere conforme al GDPR:

1. Politica sulla privacy: Il sito web deve avere una privacy policy facilmente accessibile e comprensibile per i visitatori. La politica sulla privacy dovrebbe spiegare come i dati personali verranno raccolti, elaborati e utilizzati. Inoltre, dovrebbe essere indicato chi è il titolare del trattamento dei dati personali e come i visitatori possono esercitare i loro diritti di protezione dei dati.
2. Cookie banner e Cookie policy: in conformità alle disposizioni relative ai cookie e tecnologie similari il sito deve presentare, all’apertura, un c.d. banner che permette di accettare o rifiutare, oppure personalizzare, la gestione dei cookie non necessari (cookie tecnici), richiamando la cookie policy (spesso inclusa nella privacy policy generale). Tale funzionalità può essere efficacemente attuata tramite appositi plugin dei CMS, progettati allo scopo.
3. Consenso informato: I visitatori del sito web devono essere informati in modo chiaro e trasparente sui dati personali che verranno raccolti e su come verranno utilizzati. Inoltre, i visitatori devono essere invitati ad accettare o rifiutare l’utilizzo dei loro dati personali in modo esplicito e inequivocabile. Questo processo di consenso – necessario se i dati raccolti verranno utilizzati per finalità di marketing – dovrebbe essere documentato in modo che si possa dimostrare di aver ottenuto il consenso informato dei visitatori. Anche i moduli di contatto, form nei quali l’utente compila alcuni dati personali e formula una richiesta, dovranno comprendere un riferimento all’informativa privacy con un flag di spunta che attesta, almeno formalmente, che l’utente ha letto e compreso tale informativa.
4. Protezione dei dati: Il sito web deve garantire la sicurezza e la protezione dei dati personali dei visitatori. Ciò significa che deve utilizzare misure di sicurezza tecniche e organizzative per proteggere i dati personali da accessi non autorizzati, perdite o danni. Inoltre, si dovrebbe implementare un piano di gestione dei dati personali che preveda la cancellazione dei dati personali una volta che non sono più necessari.
5. Diritti degli interessati: I visitatori del sito web hanno diritti specifici in relazione ai loro dati personali. Questi diritti includono il diritto di accesso, il diritto di rettifica, il diritto all’oblio, il diritto di limitazione del trattamento, il diritto alla portabilità dei dati e il diritto di opposizione. Il sito web dovrebbe fornire ai visitatori un modo semplice ed efficace per esercitare questi diritti.
6. Responsabile del trattamento dei dati: Il proprietario del sito web dovrebbe nominare un responsabile del trattamento dei dati personali nella figura del fornitore della gestione del sito (normalmente la web agency). Questo soggetto dovrebbe essere responsabile di garantire che il tuo sito web rispetti le regole del GDPR e dovrebbe essere in grado di rispondere alle istanze dei visitatori sulla gestione dei dati personali. Si ricorda che anche siti dinamici semplici, realizzati con CMS quali WordPress, memorizzano in un database del sito i dati di coloro che si iscrivono alla newsletter o compilano form di richiesta contatto. Dunque, chi gestisce il sito ha accesso ai dati personali memorizzati nel database del sito.
7. Trasferimento dati extra–UE: i dati personali memorizzati nel sito potrebbero essere ospitati in un servizio cloud collocato al di fuori dello Spazio Economico Europeo e dunque soggetto a decisioni di adeguatezza della UE oppure ad altri meccanismi atti  a garantire la conformità dei trattamenti di dati svolti fuori UE. Anche se la recente decisione della Commissione Europea (Data Protection Framework USA-UE) dovrebbe regolarizzare l’esportazione di dati personali negli Stati Uniti, occorre comunque tenere in considerazione questo aspetto, anche in considerazione dell’utilizzo di plugin specifici.

In sintesi, per essere conforme al GDPR, il sito web deve rispettare le regole sulla protezione dei dati personali dei visitatori. Ciò significa che occorre garantire la trasparenza nella raccolta e nel trattamento dei dati personali, la sicurezza dei dati e il rispetto dei diritti degli interessati. Se il sito web rispetta queste regole, i visitatori avranno maggiore fiducia nella gestione dei loro dati personali e il proprietario del sito potrà evitare pesanti sanzioni.

Normalmente i soggetti che entrano in gioco nella progettazione, sviluppo e gestione del sito web sono i seguenti:

• Impresa committente che vuole realizzare un nuovo sito web, proprietaria del dominio internet;
• Web Agency che gestisce le attività di digital marketing;
• Sviluppatori software del sito
• Cloud Service Provider che ospita il sito (hosting)

La prima risulta titolare del trattamento, gli altri nella maggior parte delle situazioni sono Responsabili del Trattamento e devono avere un apposito atto ai sensi dell’art. 28 del Reg. UE 679/2016 che li vincola al titolare del trattamento. Questo aspetto deve essere visto da entrambe i punti di vista: del committente e del fornitore. Da un lato il committente dovrà predisporre un contratto coerente con i requisiti del Regolamento UE 679/2016 e che fornisca sufficienti garanzie al proprietario del sito che ne risponde nei confronti della legge, dall’altro il fornitore potrà proporre il proprio contratto a tutti i propri clienti per semplificare la gestione e regolarizzare il rapporto definendo compiti e responsabilità di ciascuno. Per quest’attività spesso è opportuno rivolgersi ad un consulente legale affiancato da un esperto delle tecnologie utilizzate.

Chiaramente se attraverso il sito web si vendono prodotti (e-commerce) le cose si complicano e le responsabilità aumentano, per non parlare dei siti di e-commerce per la vendita di farmaci, parafarmici, cosmetici ed altri prodotti che possono far presumere uno stato di salute dell’acquirente.

L’azienda titolare del dominio è direttamente responsabile di eventuali violazioni del sito (data breach) che possono comportare conseguenze negative ai diritti e alle libertà delle persone che hanno i propri dati memorizzati nel sito, ma spesso da un lato è spinta dalla web agency che vorrebbe attuare azioni di marketing non rispettose della normativa privacy, dall’altro non riesce a controllare l’efficacia delle misure di sicurezza del sito web.

Spesso capita che l’impresa committente non si preoccupi della corretta gestione dei consensi raccolti per l’invio delle newsletter, delle c.d. “fidelity card” o di altri concorsi a premi gestiti attraversò il sito web ed eventuali app per mobile collegate ad esso e nemmeno dei corretti tempi di conservazione dei dati degli utenti nelle diverse situazioni.

Dal punto di vista del fornitore del sito è invece opportuno puntualizzare che cosa ne farà l’azienda del sito web e chi sarà responsabile della predisposizione delle informative privacy.

In conclusione, i rischi per l’impresa che commissiona la realizzazione e gestione di un sito web sono molteplici, ma anche il ruolo del fornitore deve essere correttamente inquadrato, infatti diverso è il caso di chi progetta, realizza e mantiene il sito – azioni di marketing digitale annesse – e quello del fornitore che realizza il sito, lo avvia presso un cloud provider qualsiasi e poi lo consegna all’impresa che dovrà mantenere tutto secondo normativa privacy.

La certificazione ai sensi dell’art. 42 del Regolamento Generale sulla Protezione dei Dati (General Data Protection Regulation, GDPR) è un processo che dimostra l’impegno di un’azienda a proteggere i dati personali gestiti (ad es. dei propri clienti e dipendenti), relativamente ad un processo, prodotto o servizio.

La certificazione GDPR non è obbligatoria, ma può essere un’ottima opportunità per le aziende che desiderano dimostrare il loro impegno verso la conformità alle normative sulla protezione dei dati personali e, quindi, aumentare la loro reputazione sul mercato, magari accedendo, in un prossimo futuro, a gare di appalto particolarmente significative.

Il processo di certificazione GDPR prevede una valutazione dettagliata dei sistemi e dei processi di protezione dei dati dell’organizzazione da parte di un organismo di certificazione accreditato. Questo Organismo esaminerà le procedure interne dell’azienda, le tecnologie utilizzate per proteggere i dati e la formazione del personale in materia di sicurezza dei dati. Se l’azienda supera la valutazione, verrà rilasciata una certificazione che dimostra che il prodotto, processo o servizio dell’organizzazione oggetto di certificazione è conforme ai requisiti del GDPR.

La certificazione GDPR non è permanente e deve essere rinnovata regolarmente ogni 3 anni. Questo significa che l’azienda deve continuare a monitorare e migliorare i propri sistemi e processi per garantire che rimangano conformi alle norme sulla protezione dei dati personali. Inoltre, le organizzazioni devono essere in grado di dimostrare la loro conformità in caso di controlli da parte dell’Autorità di Controllo per la protezione dei dati personali. Controlli nei confronti dei quali la certificazione non è esimente, ma può costituire un motivo per attenuare le eventuali sanzioni.

Gli standard che comprendono la protezione dei dati personali nel loro ambito di applicazione sono diversi, a partire dalla ISO 27001 sulla sicurezza delle informazioni che ha comunque un controllo specifico sulla privacy, il controllo A.18.1.4), la ISO 27701 che è un’estensione della ISO 27001 per le organizzazioni che vogliono certificare il loro sistema di gestione della privacy, la UNI PdR 43.2 ed altri. Ricordiamo però che la più completa ISO 27701 riguarda il sistema di gestione della sicurezza delle informazioni ed in particolare delle informazioni personali e pertanto è fuori dallo scopo del Regolamento UE 679 che prevede una certificazione di prodotto, processo o servizio ai sensi della ISO 17065 e non della ISO 17021 (accreditamento degli Organismi di certificazione sui sistemi di gestione). Anche la PdR 43 ha un difetto: si applica solo ai sistemi informatici, dunque l’organizzazione che la adotta non riuscirebbe a dimostrare la conformità dei trattamenti effettuati su supporto analogico/cartaceo.

Gli schemi attualmente approvati dall’European Data Protection Board (EDPB) sono CARPA (Schema del Lussemburgo), EUROPRISE (applicabile solo in Germania) ed EURROPRIVACY. Per motivi diversi solo quest’ultimo è applicabile in Italia, anche se risulta molto impegnativo ed orientato solo alle medio-grandi aziende.

In Italia, però, esiste uno schema di certificazione sul GDPR, che è in procinto di essere approvato dall’Autorità Garante per la Protezione dei Dati Personali e successivamente dall’EDPB. Si tratta dello schema ISDP©10003 di Inveo (scheme owner), accreditato da ACCREDIA, che è attualmente impiegato per la certificazione della protezione dei dati personali di prodotti, processi e servizi, anche se non ha ancora l’imprimatur ufficiale di certificazione ai sensi dell’art. 42.5 del Regolamento UE 679/2016.

Il processo di certificazione ISDP©10003 prevede una valutazione dettagliata dei sistemi e dei processi di protezione dei dati dell’organizzazione da parte di un Organismo di Certificazione accreditato. Il percorso di certificazione si articola in due passi successivi (come le altre certificazioni di sistema o prodotto): la verifica documentale e l’audit in campo. Non ci sono particolari differenze rispetto ad altri schemi di certificazione su iter di certificazione, classificazione dei rilievi e conferimento del certificato. Quello che differenzia sostanzialmente la certificazione ISDP©10003 – come le altre certificazioni sul GDPR – dalle certificazioni dei sistemi di gestione a cui molte organizzazioni sono abituate è il fatto che qui l’ambito di certificazione è un prodotto, processo o servizio di trattamento dati e, quindi, la normativa di riferimento per l’accreditamento è la ISO 17065, non la ISO 17021 come per le altre certificazioni di sistema.

L’organizzazione può, quindi, certificare un suo prodotto (ad es. un software), un processo di trattamento dati o un servizio erogato oppure una combinazione di essi.

Passando ad esaminare in dettaglio lo schema ISDP©10003 (scaricabile liberamente dal sito di INVEO) si notano comunque diverse analogie con altri schemi di certificazione. Infatti, la struttura dello standard è allineata alla struttura HLS dei sistemi di gestione (ISO 9001, ISO 14001, ISO 27001), ma comprende anche, nell’Appendice A, gli obiettivi di controllo da osservare, sulla falsariga della ISO 27001 sui sistemi di gestione per la sicurezza delle informazioni.

 I punti dello schema sono illustrati nel seguito:

INTRODUZIONE

Nella sezione introduttiva si illustra gli aspetti generali dello schema, la sua struttura (oltre ai requisiti generali si introduce l’Allegato A che rappresenta i criteri di controllo già menzionato e l’Allegato B che riporta la “tabella di corrispondenza” fra requisiti e controlli dello schema, con gli articoli e i considerando del GDPR, le linee guida dell’EDPB e dell’Autorità Garante Nazionale (GPDP).

Inoltre, si indica la ISO 19011 come normativa di riferimento per la conduzione degli audit, unitamente alla ISO 17065 e alle linee guida EDPB 4/2018 Allegato 1. Tale norma rappresenta, infatti, la linea guida per la conduzione di audit di sistemi di gestione, ma può essere tranquillamente applicata anche ad altri tipi di audit, come quelli su prodotti, processi e servizi.

Questa sezione richiama anche l’approccio per processi, comune a tutte le norme sui sistemi di gestione. Infatti, occorre vedere i trattamenti di dati personali (oggetto di certificazione) come processi, al fine di gestirli in modo più efficace ed efficiente, oltre che conforme ai dettami normativi.

Inoltre, in questa sezione vengono esplicitati gli “aspetti di conformità” che caratterizzano lo schema e la valutazione della conformità allo stesso, con riferimento alla sopra citata Linea Guida EDPB 4/2018, evidenziato anche attraverso una chiara tabella di corrispondenza.

Infine, viene dichiarata la compatibilità (denominata “interoperabilità”) con altre norme che condividono la struttura HLS.

SCOPO E CAMPO DI APPLICAZIONE

In questa sezione si definisce un ambito di applicazione generale e specifico dello standard che può essere applicato a prodotti, processi e servizi erogati dall’organizzazione in qualità di titolare o responsabile del trattamento. Nell’ambito di applicazione generale tutti i controlli dell’Allegato A devono essere applicati, nel caso, invece di ambito di applicazione specifico – a un prodotto, un processo o un servizio specifico – alcuni controlli potrebbero essere esclusi. Come in quasi tutte le altre norme certificabili il perimetro può essere personalizzato.

RIFERIMENTI NORMATIVI

La sezione riporta i riferimenti normativi ISO richiamati nel testo, oltre al GDPR, ma l’organizzazione certificanda dovrebbe acquisire conoscenze anche sulla normativa italiana (D.Lgs 196/2003 aggiornato al D.lgs 101/2018 oltre ai numerosi provvedimenti del GPDP), sulle Linee Guida EDPB e su altre normative e direttive UE eventualmente applicabili all’attività svolta.

TERMINI E DEFINIZIONI

Sono riportati numerosi termini e definizioni, alcune proprie del Regolamento UE 679, altre definite nell’ambito dello schema stesso. Sezione molto utile anche per coloro che, pur non mirando alla certificazione, vogliono costruire un modello organizzativo privacy utilizzando termini appropriati.

PRINCIPI E QUADRO DI RIFERIMENTO

In questa sezione sono illustrati e sviluppati i principi base del GDPR ed alcuni concetti chiave per la corretta comprensione dello schema e della normativa europea.

CONSAPEVOLEZZA E RESPONSABILIZZAZIONE

In questa sezione, come in altre norme ISO, si espongono requisiti come l’impegno della Direzione (persone fisiche che rappresentano il Titolare/Responsabile del Trattamento), la definizione di una politica per la protezione dei dati personali e la definizione di una struttura organizzativa che comprenda ruoli e responsabilità ben precise per la data protection.

OBIETTIVI E PIANIFICAZIONE DELLA GESTIONE DEL RISCHIO

L’obiettivo primario dell’applicazione dello schema ISDP©10003, come peraltro quello del GDPR, è il rispetto dei diritti e delle libertà dell’interessato nel trattamento di dati personali. In questa sezione si enfatizza il fatto che deve essere sempre analizzato il contesto del trattamento e nel quale opera l’organizzazione e che prima di intraprendere un nuovo trattamento deve essere condotta una valutazione dei rischi che preveda la determinazione del  rischio inerente e, a fronte dell’attuazione di ulteriori misure di sicurezza, il titolare/responsabile del trattamento dovrà calcolare il rischio residuo, da poter confrontare con il livello di rischio giudicato accettabile.

La politica del rischio dell’organizzazione deve poi comprendere tutte le fonti di rischio che possono compromettere la riservatezza, l’integrità e la disponibilità dei dati personali, tipiche proprietà che caratterizzano la sicurezza dell’informazione, a cui lo schema aggiunge anche la qualità del dato. Questo concetto è molto caro allo standard ISDP©10003 che definisce la qualità del dato nelle sezioni precedenti, prevedendone anche la misurazione. Evidentemente si tratta di un concetto superiore all’integrità del dato, che presuppone la sua correttezza. Garantire la sicurezza in termini di integrità del dato significa che se un dato è memorizzato in un campo di un sistema informativo quel dato rimane sempre uguale se non viene modificato volontariamente. Garantire la qualità del dato, invece, significa garantire che quel dato sia sempre esatto ed aggiornato rispetto alla fonte che lo ha generato; ad esempio, che un indirizzo o un numero telefonico sia quello aggiornato alla data. Ciò presuppone un comportamento proattivo dell’organizzazione titolare o responsabile del trattamento finalizzato a preoccuparsi che tutti i dati raccolti siano corretti ed aggiornati. Naturalmente ciò si applica solo quando la qualità del dato risulta essere importante per i diritti e le libertà dell’interessato.

Nel processo di valutazione del rischio lo schema introduce, come sopra esposto, il c.d. rischio inerente (Ri), definito in una nota come il rischio relativo al trattamento prima delle eventuali mitigazioni (rischio lordo) (cons. 83 riga 2 Reg. UE 20161679). Letto anche il Considerando 83 verrebbe da chiedersi cos’è il “rischio inerente al trattamento”.

Una definizione corretta potrebbe essere la seguente: Il rischio inerente è il rischio attuale e potenziale cui il soggetto è esposto in ragione dell’attività concretamente svolta nel suo complesso. Quindi il rischio inerente va calcolato a prescindere dai controlli, presidi o misure di sicurezza applicate per mitigare il rischio. Dopo l’applicazione dei controlli e delle misure di mitigazione il rischio si attenua e diventa il rischio residuo.

Tra le varie metodologie di valutazione del rischio lo schema ISDP impone dei vincoli, quello di determinare il rischio inerente ed il rischio residuo attraverso un metodo (un algoritmo) oggettivo e ripetibile.

Come si calcola il rischio inerente? Anche ChatGPT potrebbe fornirci una risposta attendibile.

Il rischio inerente si calcola valutando la probabilità di una possibile violazione dei dati personali e il possibile impatto che questa violazione potrebbe avere sulle persone interessate.

Per calcolare il rischio inerente, si possono utilizzare diverse metodologie e framework, come ad esempio quello proposto dal NIST (National Institute of Standards and Technology), che prevede una valutazione basata su tre fattori principali:

1. Probabilità: la probabilità di una violazione dei dati personali in base alle minacce esistenti e alle vulnerabilità presenti nei sistemi e nei processi di trattamento dei dati.
2. Impatto: l’impatto che una violazione dei dati personali potrebbe avere sulle persone interessate, come la perdita di informazioni sensibili, la violazione della privacy o l’uso improprio dei dati personali.
3. Magnitudine del rischio: la gravità del rischio inerente, che dipende dalla combinazione della probabilità e dell’impatto.

La valutazione del rischio inerente può essere effettuata utilizzando un punteggio numerico o una scala di valutazione per ogni fattore, in modo da ottenere una valutazione complessiva del rischio.  Il calcolo può essere fatto moltiplicando i valori di Probabilità ed Impatto, introducendo un eventuale fattore correttivo di ponderazione.

Lo schema ISDP, inoltre, prevede un monitoraggio delle misure di sicurezza adottate a seguito della valutazione del rischio ed un monitoraggio dei risultati della valutazione del rischio stessa. Tale monitoraggio va effettuato anche attraverso audit interni ed audit sui Responsabili del trattamento.

SUPPORTO

In questa sezione lo standard stabilisce che il Titolare/Responsabile deve mettere in atto misure tecniche ed organizzative adeguate a garantire la sicurezza e l’esattezza dei dati personali e deve essere in grado di dimostrarlo.

Nel resto della sezione c’è di tutto un po’: definizione ed attuazione di policy per la protezione del dato personale, predisposizione di procedure documentate, adeguatezza delle risorse umane, formazione e consapevolezza del personale, vincoli di riservatezza, istituzione di audit interni e verso i responsabili del trattamento e così via.

Vengono poi anche stabiliti alcuni elementi per verificare l’adeguatezza dei processi interni, tra cui la verifica della minimizzazione dei dati trattati, dei rapporti fra contitolari, fra titolare e responsabile, ecc.

Nella medesima sezione vi è anche un punto specifico sulla nomina del Responsabile della Protezione Dati (DPO), necessario, peraltro, quando il GDPR stesso lo richiede.

Alla “Formazione” viene dedicato un punto specifico nel quale si enfatizza la necessità di attuare un processo di formazione pianificato e puntuale, del quale occorre dare evidenza attraverso opportune registrazioni dell’avvenuta formazione ed eventuali test di valutazione delle competenze se del caso.

Gran parte di questi compiti sono assegnati al RPD, che deve anche definire le competenze minime per il personale.

Il successivo punto “Documentazione” esplicita tutti i documenti (lo schema non cita il termine “informazioni documentate”) che è necessario predisporre per la certificazione, comprendente

1. Modello organizzativo privacy o documento equivalente: di fatto una sorta di Manuale di Gestione della Privacy, eventualmente costituito da una serie di documenti.
2. Registro dei trattamenti
3. Valutazione del rischio e relativa metodologia adottata
4. Procedure che regolano la raccolta ed il trattamento dei dati, l’esercizio dei diritti dell’interessato, la gestione dei data breach, la valutazione delle misure di sicurezza, la gestione della Privacy-by-Design e Privacy-by-default, gli audit interni, ecc.
5. Relazione annuale del DPO e Relazione dell’Amministratore di sistema.
6. Documentazione tecnica specifica del prodotto, processo o servizio oggetto di certificazione.

ATTIVITÀ OPERATIVE

Il titolare deve dimostrare la propria responsabilizzazione (accountability) nel conformarsi al GDPR attraverso scelte motivate ed adeguata documentazione del Modello Organizzativo Privacy (MOP) adottato.

La documentazione minima richiesta per dimostrare la conformità al regolamento UE 679 è costituita da:

• Mappatura dei trattamenti di dati personali (occorre scendere in un elevato livello di dettaglio, lo schema cita l’esempio dell’invio di allegati a messaggi di posta elettronica).
• Registro dei trattamenti
• Valutazione del rischio
• Valutazione di impatto (se necessario)

In questa sezione viene richiesta l’applicazione dei princìpi di Privacy by Design e Privacy by Default prima dell’avvio di nuovi prodotti e servizi (è implicito che rientrino nel campo di applicazione della certificazione) attraverso definizione di politiche, processi e misure di sicurezza.

Viene poi introdotto il requisito del “Controllo dei processi, prodotti e servizi forniti dall’esterno”, del tutto analogo all’omonimo requisito delle norme sui sistemi di gestione ISO 9001 e ISO 27001. Il fornitore deve essere sottoposto ad un processo di valutazione e qualifica, nel quale si dovrebbe tenere in considerazione la classificazione dei dati personali che dovranno essere trattati nella sua attività.

MONITORAGGIO

L’efficacia delle politiche e delle misure di sicurezza attuate deve essere valutata in primis attraverso audit interni ed esterni, per i quali vigono le stesse regole dei sistemi di gestione (programmazione in base all’importanza e alla criticità dei trattamenti, definizione dei criteri, registrazione dei risultati).

Nelle attività di monitoraggio occorre valutare la puntuale applicazione delle procedure, il Documento di mappatura dei trattamenti, il Registro dei trattamenti, il Documento aggiornato di valutazione dei rischi, il monitoraggio della Valutazione d’Impatto, Informazioni e statistiche puntuali o a campione di controllo sulla qualità ed esattezza dei dati contenuti negli archivi di dati personali, lo stato delle eventuali azioni correttive, l’analisi delle procedure relative ad informative e consenso, l’analisi del corretto rispetto dei diritti degli interessati e le modalità di campionamento interno dei trattamenti per il controllo.

Infine la sezione tratta le modalità di valutazione delle procedure dei responsabili (del trattamento) per la conduzione di audit di seconda parte (riscontro di garanzie sufficienti per assicurare la conformità dei processi di trattamento a loro affidati, misure di sicurezza tecniche ed organizzative adottate, ecc.).

MIGLIORAMENTO

Il titolare o il responsabile deve valutare continuamente le procedure di valutazione del rischio, mantenendo un registro dei rischi, al fine di identificare quei rischi che richiedono interventi migliorativi delle misure di sicurezza.

Il monitoraggio deve prevedere alcune azioni minime, tra cui flussi informativi costanti don il RPD (DPO) e la Direzione, la valutazione dell’efficacia delle azioni di trattamento dei rischi, il coinvolgimento del personale e così via.

Nel requisito “Rilievi e azioni correttive” è prescritta una procedura per registrare i rilievi che dovranno essere classificati (lo schema ISDP©10003 definisce non conformità/carenze, osservazioni e commenti) ed affrontati con azioni finalizzati ad eliminarne le cause, attraverso, se del caso, idonee azioni correttive che dovranno essere gestite come avviene negli altri sistemi di gestione (analisi delle cause, pianificazione dell’azione correttiva, attuazione, verifica di efficacia, secondo il classico ciclo PDCA).

L’unica cosa che si discosta da altre norme su sistemi di gestione (ISO 9001 in primis) è che le azioni correttive dovrebbero esistere solo per affrontare non conformità o problemi effettivamente verificatisi, mente ad es. un rilievo classificato come commento necessiterebbe di un’azione “preventiva” secondo quanto era definito nelle versioni precedenti della ISO 9001 (dal 2008 indietro) o nella specifica IATF 16949 per l’automotive.

OBIETTIVI DI CONTROLLO

L’appendice A dello schema ISDP©10003, in completa analogia con la norma ISO 27001, riporta un nutrito elenco di obiettivi di controllo e controllo che un’organizzazione certificanda dovrebbe adottare. Essi, organizzati in 7 macroprocessi, consentono di analizzare gli elementi forndamentali che caratterizzano i trattamenti di dati personali: caratteristiche dei dati personali, procedure e processi, sistemi tecnici e tecnologici (hardware e software) per il trattamento dati.

Dagli obiettivi di controllo discendono i controlli (oltre 130) che coprono tutti gli elementi del GDPR ed includono anche elementi di tipo organizzativo e gestionale, come l’istituzione di un Comitato Privacy e la conduzione di un riesame della direzione. Tali controlli possono essere tranquillamente trasformati in una check-list per verificare la conformità di un modello organizzativo privacy. Anzi una check-list in Excel con alcuni automatismi per determinare una valutazione ponderata dell’organizzazione auditata è reperibile sul sito INVEO previa registrazione (https://www.in-veo.com/privacy-tools-new/16-compliance-checklist-isdp-10003-2020) ed utilizzabile con qualche limitazione.

CONCLUSIONI

Sebbene lo schema presenti qualche ridondanza dovuta alla ripetizione di requisiti in punti diversi dello standard è sicuramente un modello completo al fine di perseguire la conformità al GDPR.

In conclusione, lo schema di certificazione ISDP©10003 è un ottimo strumento per le organizzazioni che desiderano dimostrare il loro impegno nella protezione dei dati personali e aumentare la loro reputazione sul mercato. La certificazione ISDP©10003 può aiutare le organizzazioni a identificare eventuali vulnerabilità nei loro sistemi e processi di protezione dei dati e a implementare misure per prevenirle, garantendo al tempo stesso la conformità alle normative internazionali sulla protezione dati.

L’ottenimento della certificazione sul GDPR costituisce comunque un obiettivo ambizioso, poiché sono ben poche le organizzazioni che dispongono di un sistema di gestione o modello organizzativo privacy pienamente conforme alle normative, tuttavia l’ISDP©10003 rappresenterà, una volta approvato come standard di certificazione sul GDPR, una strada più agevole – per costi e impatto – di altre per qualificarsi nel settore della protezione dati, anche per organizzazioni medio piccole. La stessa ISO 27701, pur non costituendo una certificazione specifica sul GDPR, non può prescindere da una certificazione ISO 27001, di per sé piuttosto impegnativa.

La possibilità di certificare soltanto un prodotto, processo o servizio e di restringerla alle attività svolte anche solo come Responsabile del Trattamento, apre le porte a soluzioni più snelle per qualificare determinate forniture di prodotti e/o servizi in certi ambiti (es. sanità). Al di là dell’obiettivo di perseguire ed ottenere una certificazione specifica sul GDPR, questo schema può fornire numerosi spunti per progettare e/o migliorare il proprio modello organizzativo privacy, indipendentemente dal fatto che la certificazione ISDP©10003 è orientata prodotti, processi e servizi, lo schema può essere tranquillamento adattato e preso a riferimento per il proprio “sistema di gestione privacy” volontario.

Gli accordi fra Titolare del trattamento e Responsabile del Trattamento sono probabilmente uno dei punti più difficili da gestire nell’applicazione del GDPR, sia perché i requisiti del GDPR sono diversi dalla vecchia nomina del responsabile esterno del trattamento del Codice Privacy, sia perché le responsabilità, in capo sia al Titolare, sia al Responsabile sono più pesanti che in passato.

Spesso tale accordo è imposto dal Titolare al Responsabile che non gradisce e troppo spesso il Titolare evita contrasti con il Responsabile, magari fornitore già scelto da tempo, e desiste. In altri casi – come quelli dei colossi del web, fornitori di servizi cloud – il Titolare non ha nemmeno modo di discutere le clausole contrattuali dell’accordo per la protezione dati imposto dal Responsabile.

L’articolo 28 del regolamento UE 679/2016 /GDPR), al comma 1, indica che:

Qualora un trattamento debba essere effettuato per conto del titolare del trattamento, quest’ultimo 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.

Inoltre, il suddetto Regolamento – al comma 3 -prevede anche che:

I trattamenti da parte di un responsabile del trattamento sono disciplinati 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 e che stipuli la materia disciplinata e la durata del trattamento, la natura e la finalità del trattamento, il tipo di dati personali e le categorie di interessati, gli obblighi e i diritti del titolare del trattamento

Da questi requisiti e dal prosieguo del comma 3 discendono le clausole che normalmente vengono imposte nei contratti fra titolare e responsabile, ovvero nei contratti di “nomina del responsabile del trattamento”. Al di là delle discussioni sull’opportunità di denominare ancora questi accordi “nomina del responsabile del trattamento” retaggio della precedente normativa italiana (D.Lgs. 196/2003), di fatto si tratta di un accordo o contratto che impegna le due Parti nei rispettivi ruoli, ma soprattutto è il Responsabile nominato che dovrà adempiere ad alcuni obblighi.

Nel corso di questi oltre  quattro anni di applicazione del GDPR ho riscontrato diverse situazioni difficili nel finalizzare la sottoscrizione di questo accordo di nomina del Responsabile, da entrambe le parti.

Il problema principale che si riscontra è quello che il nominando Responsabile non accetta la nomina/accordo perché ritiene di non ricoprire il ruolo di Responsabile, ma piuttosto quello di Titolare autonomo o di soggetto autorizzato al trattamento dei dati personali.

È ormai noto il caso dei consulenti del lavoro o studi/società che elaborano le buste paga per aziende e organizzazioni di ogni tipo: il loro ruolo era chiaramente quello di Responsabile del trattamento, ma finché il Garante Privacy non si è espresso hanno “resistito” anche in forza di una interpretazione di parte del loro Ordine Professionale.

Per altri soggetti il ruolo non è sempre ben definito e, anche quando è stato definito il ruolo di Responsabile del Trattamento, spesso le clausole contrattuali sono contestate.

Mi riferisco ai Responsabili del Servizio di Prevenzione e Protezione (RSPP), naturalmente se professionisti esterni all’organizzazione Titolare del trattamento, ai Commercialisti e Consulenti Fiscali, ai Consulenti legali, ai Revisori Contabili, all’Organismo di Vigilanza (OdV), ai membri del Collegio Sindacale, ai consulenti di servizi di assistenza informatica e così via.

È importante capire che non è il semplice incarico a determinare il ruolo soggettivo privacy del consulente/professionista esterno o fornitore. Dipende da quali dati tratta e come li tratta.

Emblematico è il caso del RSPP che può trattare i dati del personale dipendente (solo dati anagrafici e di contatto, talvolta – ma non sempre – anche dati su infortuni, dunque dati personali appartenenti a categorie particolari di dati ai sensi dell’art. 9 del GDPR) solo presso la sede dell’azienda su sistemi informatici della stessa (alla stregua di un RSPP interno), oppure può trattare i medesimi dati su propri dispositivi e sistemi informatici, anche presso il proprio Studio. A mio parere nel primo caso il suo ruolo si avvicina più a quello del soggetto autorizzato a trattare dati personali, nel secondo a quello di Responsabile esterno del trattamento ex art. 28 del Regolamento Ue 679/2016.

Ma non vorrei qui soffermarmi sulle numerose casistiche che si possono verificare nei rapporti fra Titolare e fornitore e sulla conseguente determinazione del ruolo soggettivo privacy di quest’ultimo, ma piuttosto sui contratti che vengono stipulati (o che si cerca di proporre) fra le parti.

Il caso tipico è quello nel quale il Titolare, tramite il suo consulente privacy o DPO propone un contratto standard per quasi tutti i fornitori che trattano dati personali. Qui se l’autore del contratto/accordo per il trattamento dei dati personali è stato predisposto da un giurista o proviene da una fonte similare (es. modello di DPA dell’Autorità di Controllo della Danimarca oppure le Clausole Contrattuali tipo emanate dalla Commissione Europea) è possibile che alcune clausole siano giustamente rifiutate dal Responsabile designato. In generale un contratto con nomina a Responsabile troppo esteso e dettagliato, scritto in “legalese” potrebbe essere respinto nella sua interezza dal fornitore. Come spesso capita la ragione sta nel mezzo, infatti alcune clausole non fanno che ribadire quello che è già scritto nel GDPR e responsabilizzano il responsabile, se mi è consentito il gioco di parole.

Veniamo a trattare alcuni elementi specifici.

Natura del trattamento, tipi di dati personali trattati e categorie di interessati

Su questo aspetto l’accordo sulla protezione dati potrebbe richiamare il contratto con il fornitore/responsabile, ma talvolta tale contratto non specifica in modo corretto queste informazioni per cui bisogna sopperire nell’accordo di nomina a responsabile. È evidente che senza disporre del contratto che origina il rapporto non si può redigere un accordo di nomina a responsabile completamente corretto.

Personalmente sconsiglio di scendere troppo nel dettaglio dei tipi di dati personali trattati dal Responsabile: è sufficiente indicare dati anagrafici anziché nome, cognome, indirizzo di residenza, ecc.; dati fiscali anziché codice fiscali, partita IVA, dati di fatturazione, ecc.; dati di contatto anziché numero di telefono fisso e cellulare, indirizzo e-mail, PEC, ecc.. Altrimenti ci si troverebbe facilmente a discutere con il Responsabile e, a fronte di nuovi dati l’accordo sarebbe da integrare.

Riguardo ad eventuali dati appartenenti a categorie particolari si può opportunamente distinguere tra i dati sanitari (dati relativi alla salute) da altre categorie di dati particolari come idee politiche, credo religioso e così via.

Regolamentazione di un eventuale sub-responsabile o altri responsabili del trattamento

Il Responsabile può essere autorizzato ad impiegare suoi fornitori (sub-responsabili) nel trattamento dei dati personali del titolare oppure può essere vincolato a richiedere l’autorizzazione per ogni nuovo sub- responsabile o altro responsabile che intende coinvolgere. In ogni caso il nome dell’eventuale “altro responsabile” deve essere reso noto al Titolare.

Se da un lato il fornitore che gestisce una piattaforma di elaborazione delle paghe dei dipendenti in modalità SaaS è sicuramente un Responsabile del Trattamento dello Studio di Consulenza sul Lavoro e, quindi, un Sub-Responsabile dell’azienda che ha la titolarità dei dati dei dipendenti di cui ha esternalizzato la gestione delle paghe, dall’altro ci sarebbe da discutere sul ruolo dei consulenti informatici dello Studio di Consulenza sul Lavoro che occasionalmente possono venire  a conoscenza di alcuni dati personali dei dipendenti del titolare in occasione di interventi di assistenza sui sistemi informatici – in questo caso client-server – dello Studio.

Consideriamo che a ogni Sub-Responsabile dovrebbero essere applicate le medesime clausole contrattuali in essere fra Titolare e Responsabile.

Qui evidentemente c’è un problema nel Regolamento UE 679/2016 che non chiarisce fino a che punto considerare la catena degli altri responsabili del trattamento. Il paradosso sarebbe quello che un sub-responsabile che opera per un determinato Responsabile si dovrebbe veder applicate clausole contrattuali diverse a seconda delle clausole imposte al Responsabile da ogni Titolare per cui esso fornisce il servizio. Ma non solo: il nostro Sub-Responsabile forse non lavorerà per un unico cliente che opera come Responsabile… e allora a quali contratti e clausole contrattuali deve fare riferimento?

Credo che se chi ha ideato questo articolo 28 del GDPR (e relativo Considerando 81) non ha pensato a queste casistiche bisognerebbe che il Legislatore Europeo, piuttosto che l’EDPB o le Autorità di Controllo dei singoli Paesi chiariscono la situazione.

Una situazione emblematica è quella che riguarda le misure di sicurezza tecniche ed organizzative (le vedremo in seguito) che il Titolare può imporre – a termini di Regolamento – al Responsabile: che succede se un Titolare chiede al Responsabile di adottare delle password di almeno 8 caratteri variate ogni 180 gg. e un altro chiede le password di almeno 12 caratteri variate ogni 90 giorni e un altro ancora chiede la MFA?

I dati devono essere trattati dal Responsabile solo su istruzione documentata del Titolare

Spesso le istruzioni dettagliate non esistono, sono verbali oppure ripercorrono il testo del GDPR. Chiaramente il Titolare non può e non deve dare istruzioni al fornitore come fare il suo lavoro (non può indicare al consulente del lavoro come elaborare le paghe, che evidentemente devono rispettare requisiti di legge che il consulente del lavoro ben conosce), ma solo quali misure adottare per mantenere la protezione dei dati personali. Ad esempio non trasmettere dati riservati in chiaro tramite e-mail, consegnare documenti in busta chiusa tramite corriere piuttosto che Raccomandata A.R. o posta ordinaria. O adottare determinate misure di sicurezza…

Il Responsabile deve adottare misure di sicurezza adeguate come previsto dall’art. 32 del GDPR

Un’indicazione al Responsabile che richiami semplicemente di adottare misure di sicurezza adeguate come prescritto dall’articolo 32 del GDPR non ci dice nulla. L’art. 32 non ci indica quali misure di sicurezza adottare, ma solo quelle ritenute adeguate a fronte di una valutazione del rischio!

Imporre al Responsabile determinate misure di sicurezza può costituire un rischio, ossia che non vengano accettate. Ad esempio l’imposizione della variazione della password periodicamente è ormai appurato che non può essere considerata sempre una misura di sicurezza pienamente efficace, purché il mancato obbligo di modifica della password sia affiancato da altre tecniche (criteri di complessità elevati, notifiche di accesso, MFA, …).

Alcuni contratti, poi, richiamano a titolo esemplificativo (come il GDPR) la cifratura e la pseudonimizzazione come misure di sicurezza. Mentre la prima dovrebbe essere contestualizzata e meglio dettagliata (collegamenti VPN, area dati cifrata sui dischi, dischi dei notebook cifrati, dati in cloud cifrati…), la seconda è molto impegnativa, se non impraticabile, nella stragrande maggioranza dei casi se i dati non sono pseudonomizzati all’origine.

Forse la soluzione migliore è quella di chiedere al Responsabile, attraverso un apposito questionario, quali misure di sicurezza tecniche ed organizzative sta adottando. In tal modo, oltre a stimolare il fornitore sul tema, si può decidere se accettare o meno le misure di sicurezza proposte dal fornitore, ritenendole più o meno adeguate al contesto in cui opera il fornitore. In tal modo si si assicura di aver valutato anche l’adeguatezza del fornitore prima di affidargli l’attività di trattamento dati.

Clausole che descrivono come il Responsabile deve assistere il Titolare in caso di violazione dei dati personali

Il c.d. Data Breach deve essere notificato al GPDP entro 72 ore da quando si è venuti a conoscenza del fatto. Imporre al Responsabile tempistiche molto ridotte per segnalare al Titolare eventuali violazioni di dati personali non ha molto senso, anche perché i tempi non si sommano! Mi spiego meglio: se il Responsabile del trattamento si accorge di un data breach che coinvolge i dati del Titolare alle ore 12 del 10 febbraio e lo comunica al Titolare il12 febbraio alle ore 12 (ovvero dopo 48 ore), il Titolare del trattamento ha 72 ore per fare la notifica al GPDP a partire dalle ore 12 del 12 febbraio, non dalle ore 12 del 10 febbraio, dunque non ha solo 24 ore dalla comunicazione del Responsabile, semplicemente perché prima non lo sapeva del data breach!

Conservazione ovvero cancellazione dei dati personali trattati al termine del contratto

Anche questo punto è molto discutibile: non può essere sempre imposto al Responsabile di cancellare o restituire tutti i dati personali trattati al termine del contratto o dopo un breve periodo da esso, ad es. 30/60 giorni. Per certe attività o prestazioni professionali è ammissibile che il Responsabile trattenga alcuni dati, non solo per adempiere a requisiti di legge, ma anche per dimostrare la correttezza della prestazione svolta, soprattutto se questa deve rispondere a particolari normative.

Occorre poi precisare che qualunque fornitore-responsabile tratta solo determinati dati, per determinate finalità,  del cliente-titolare in qualità di Responsabile. Dunque, i dati di contatto delle persone di riferimento del Titolare, i dati che rientrano nella fatturazione ed in altri obblighi contabili e fiscali sono trattati in qualità di Titolare (autonomo), dunque non rientrano nei termini di cancellazione del contratto di nomina a responsabile, ma saranno quelli indicati nell’Informativa al trattamento dati ai sensi dell’art. 13 del GDPR come titolare del trattamento.

Premesso ciò, diversi consulenti includono inevitabilmente dati anagrafici di dipendenti o persone che rappresentano i clienti o altri fornitori nei loro documenti. Non è pensabile che essi restituiscano e cancellino ogni copia di tali elaborati che costituiscono know-how personale o aziendale e nemmeno che oscurino/cancellino tutti i riferimenti a persone fisiche in tali documenti (sarebbe un lavoro spropositato). Non parliamo poi dei documenti ed altre informazioni scambiate via e-mail!

Anche in questo caso se il legislatore non sopperisce a chiarire queste assurdità dovrebbero essere i contratti fra Titolari e Responsabili ad adeguarsi.

Diritto di audit da parte del Titolare sul Responsabile

Il GDPR prevede che il Responsabile:

h) metta a disposizione del titolare del trattamento tutte le informazioni necessarie per dimostrare il rispetto degli obblighi di cui al presente articolo e consenta e contribuisca alle attività di revisione, comprese le ispezioni, realizzati dal titolare del trattamento o da un altro soggetto da questi incaricato.

Questo è stato tradotto da molti accordi con il diritto di effettuare audit al Responsabile. Anche se il contenuto del Regolamento è un po’ più sfumato non è pensabile che il Titolare abbia il diritto di effettuare un audit, come e quando vuole, presso la sede del Responsabile. Premesso che tale attività ha senso solo per trattamenti particolarmente critici e per fornitori che non si dimostrino pienamente attendibile nelle loro risposte ad un eventuale questionario, le modalità di svolgimento di tali audit andrebbero regolamentate contrattualmente.

Impegno alla riservatezza del personale del Responsabile

Tutto il personale del Responsabile del trattamento deve aver sottoscritto un impegno alla riservatezza, probabilmente inserito nella designazione a soggetto autorizzato al trattamento dei dati personali. Questa è un’evidenza che il Titolare potrebbe chiedere al responsabile.

Altre  evidenze potrebbe giustamente richiedere il Titolare al Responsabile, come il Registro dei Trattamenti del responsabile (dopo la tipula dell’accordo), solamente, però, per le informazioni riguardanti il trattamento dei dati personali svolto per conto del medesimo Titolare.

In conclusione, i contratti standard fra Titolare e Responsabile mal si applicano a tutte le realtà ed andrebbero personalizzati altrimenti i rischi sono due:

1. Che il responsabile si rifiuti di sottoscrivere l’accordo
2. Che il responsabile non consideri tutte le clausole contrattuali e le firmi senza neanche leggerle.

Nella gestione di tutto il processo di esternalizzazione di un’attività che comprende il trattamento di dati personali sarebbe opportuno seguire quanto indicato dalla norma ISO 9001 in relazione al controllo dei processi affidati all’esterno: a partire dalla valutazione iniziale e qualifica dei fornitori, pass

Molte imprese si sono trovate a dover nominare il Responsabile della Conservazione (RdC) per ottemperare ai requisiti delle nuove Linee Guida AgiD sulla conservazione dei documenti digitali. Tale adempimento non riveste, infatti, solo le Pubbliche Amministrazioni, ma tutte le imprese che utilizzano sistemi di conservazione “a norma” (archiviazione sostitutiva), compresi i sistemi di fatturazione elettronica, ormai divenuti obbligatori per tutte le organizzazioni.

Chi è il Responsabile della Conservazione?

Il Responsabile della Conservazione Digitale è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali, in particolare per quanto riguarda le pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile della Conservazione Digitale (Responsabile della Conservazione) ha il compito di garantire che i documenti digitali prodotti o conservati dall’ente siano adeguatamente gestiti e conservati nel rispetto delle norme e delle linee guida stabilite a livello nazionale.

Il Responsabile della Conservazione deve essere un professionista con conoscenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di gestire le complessità tecniche e normative legate alla gestione dei documenti digitali. Deve essere in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale, garantendo che siano rispettati i criteri di completezza, integrità, accessibilità e leggibilità dei documenti.

Il Responsabile della Conservazione è anche responsabile di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, di assicurare la corretta gestione dei sistemi di conservazione digitale e di gestire la sicurezza delle informazioni digitali.

Inoltre, il Responsabile della Conservazione deve essere in grado di collaborare con altre figure professionali all’interno dell’ente, come l’archivista o il responsabile dell’informatica, per garantire la massima efficienza e integrità delle attività di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di garantire che i documenti siano conservati in modo sicuro, completo e accessibile, in conformità con le norme e le linee guida stabilite.

Il Responsabile del Servizio di Conservazione è una figura chiave nell’ambito della conservazione e gestione dei documenti digitali delle pubbliche amministrazioni. Secondo l’Agenzia per l’Italia Digitale (AgID), il Responsabile del Servizio di Conservazione (RSC) è responsabile della definizione, implementazione e gestione delle politiche e delle attività relative alla conservazione digitale all’interno dell’ente.

Chi è il Responsabile del Servizio di Conservazione?

Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di pianificare, coordinare e controllare tutte le attività relative alla conservazione digitale. Deve anche essere in grado di garantire la conformità alle norme in materia di privacy e protezione dei dati personali, e di gestire la sicurezza delle informazioni digitali.

Il Responsabile del Servizio di Conservazione è anche responsabile di assicurare la completezza, l’integrità, l’accessibilità e la leggibilità dei documenti digitali conservati, e di collaborare con altre figure professionali all’interno dell’ente per garantire la massima efficienza e integrità delle attività di conservazione digitale.

Inoltre, il Responsabile del Servizio di Conservazione deve essere in grado di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire che i documenti digitali siano conservati in modo sicuro e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

In sintesi, il Responsabile del Servizio di Conservazione è un professionista chiave per la conservazione e gestione dei documenti digitali delle pubbliche amministrazioni, con il compito di pianificare, coordinare e gestire le attività di conservazione digitale in modo da garantire che i documenti siano conservati in modo sicuro, completo e accessibile, e che siano rispettati i criteri stabiliti dalle norme e dalle linee guida.

Secondo la normativa italiana, tutte le pubbliche amministrazioni devono nominare un Responsabile del Servizio di Conservazione (RSC) per la gestione dei documenti digitali. Questo include enti locali, regioni, amministrazioni centrali, enti pubblici non economici e altre organizzazioni pubbliche.

Inoltre, anche alcune organizzazioni private che gestiscono informazioni sensibili o documenti di interesse pubblico possono essere tenute a nominare un Responsabile del Servizio di Conservazione.

La nomina del Responsabile del Servizio di Conservazione deve essere effettuata con un atto formale da parte dell’organizzazione interessata e deve essere pubblicata sul sito web dell’ente. Il RSC deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente.

Il Responsabile del Servizio di Conservazione (RSC) deve possedere alcuni requisiti specifici per garantire una gestione corretta e conforme alle norme dei documenti digitali delle pubbliche amministrazioni.

Questi requisiti includono:

1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile del Servizio di Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile del Servizio di Conservazione deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Invece il Responsabile della Conservazione, figura interna all’organizzazione, deve possedere i seguenti requisiti:

1. Competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche.
2. Conoscenza delle norme e delle linee guida in materia di conservazione digitale, privacy e protezione dei dati personali.
3. Capacità di pianificare, coordinare e gestire le attività di conservazione digitale, garantendo la sicurezza, la completezza e l’accessibilità dei documenti digitali conservati.
4. Conoscenza delle tecnologie e delle soluzioni utilizzate per la conservazione digitale, inclusi sistemi di gestione dei documenti digitali e di archiviazione.
5. Capacità di monitorare e valutare costantemente le attività di conservazione digitale e di adottare le misure necessarie per garantire la massima efficienza e integrità.

Inoltre, è importante che il Responsabile della Conservazione abbia una buona conoscenza della lingua italiana e delle norme sulle pubbliche amministrazioni, in modo da garantire la comprensione e l’applicazione delle norme e delle linee guida in materia di conservazione digitale.

In sintesi, il Responsabile della Conservazione Digitale deve essere un professionista con competenze specifiche nel campo della conservazione digitale e delle tecnologie informatiche, in grado di garantire la corretta gestione dei documenti digitali dell’ente e di rispettare le norme in materia di privacy e protezione dei dati personali.

Ma non tutti i responsabili di funzione o direttori di funzione o area possono ricoprire il ruolo di RdC.

Infatti, secondo l’AgiD (Agenzia per l’Italia Digitale), i seguenti responsabili di funzione interne all’organizzazione non possono ricoprire il ruolo di Responsabile della Conservazione Digitale:

1. Il responsabile del trattamento dei dati personali, poiché questa figura ha responsabilità diverse in materia di privacy e protezione dei dati personali.
2. Il responsabile della sicurezza del sistema informatico, poiché questa figura ha la responsabilità di garantire la sicurezza del sistema informatico e non quella della conservazione digitale.
3. Il responsabile del sistema informativo, poiché questa figura ha la responsabilità di gestire il sistema informativo dell’ente e non la conservazione digitale dei documenti digitali.

In sintesi, il Responsabile della Conservazione Digitale deve essere una figura distinta e indipendente da altri responsabili di funzione interne all’ente, in grado di garantire la corretta gestione dei documenti digitali in conformità alle norme in materia di conservazione digitale e di privacy.

Il Manuale della Conservazione

Uno dei compiti non delegabili del RdC è la redazione del Manuale della Conservazione.

Il Manuale della Conservazione Digitale è un documento che definisce le procedure, le politiche e le linee guida per la corretta gestione dei documenti digitali conservati da un’organizzazione. Il manuale è un supporto importante per il Responsabile della Conservazione Digitale (Responsabile della Conservazione) nell’esercizio delle proprie funzioni e nella realizzazione delle attività di conservazione digitale.

Il manuale della conservazione digitale comprende:

1. Le politiche e le linee guida per la gestione dei documenti digitali, inclusi il processo di acquisizione, catalogazione, conservazione e accesso.
2. Le procedure per la verifica dell’integrità e la verifica periodica dei documenti digitali conservati.
3. Le procedure per la gestione delle modifiche e degli eventuali danni ai documenti digitali.
4. Le linee guida per la sicurezza dei documenti digitali, inclusi i requisiti per la protezione dei dati personali e la protezione dei documenti digitali da eventuali perdite o danneggiamenti.

In sintesi, il manuale della conservazione digitale è uno strumento fondamentale per garantire la corretta gestione dei documenti digitali conservati da un’organizzazione, in conformità alle norme e alle linee guida in materia di conservazione digitale e privacy.

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

Cos’è il rischio per la sicurezza delle informazioni?

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

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

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

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

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

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

La valutazione del rischio sulla sicurezza delle informazioni

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La valutazione del rischio privacy

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

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

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

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

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

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

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

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

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

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

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

Fin dagli albori dei sistemi qualità ISO 9001 (ma ai tempi era anche ISO 9002) la qualifica del fornitore è stato un elemento particolarmente significativo, da soddisfare anche attraverso la sottomissione ai fornitori di un questionario di (auto)valutazione e qualifica del fornitore che andava a valutare la sua organizzazione, le sue metodologie di assicurazione qualità e l’eventuale situazione rispetto alla certificazione di qualità (ISO 9001/ISO 9002/ISO 9003, certificazioni di prodotto, ecc.). Tali questionari avevano una loro ratio: se ben strutturati consentivano di valutare numerosi aspetti dei processi operativi del fornitore e spesso lo invitavano a migliorare i suoi controlli qualità. Chiaramente una visita in loco poteva sempre permettere al cliente di verificare la veridicità delle risposte fornite.

Nel corso degli anni i metodi di valutazione dei fornitori si sono evoluti, ma i questionari sono in parte rimasti, almeno per i fornitori di prodotti e servizi critici, magari affiancati da visite presso la loro sede o veri e propri audit di 2a parte.

Negli ultimi tempi questa modalità di valutazione è estesa ad altri settori: la privacy, la sicurezza informatica e la Sostenibilità, tipicamente declinata nei suoi elementi costituenti: Ambiente (Environment), Responsabilità Sociale (Social Accountability) e Governance, nota con l’acronimo ESG.

Purtroppo, grandi aziende hanno distribuito a pioggia questi questionari per valutare tutti i loro fornitori, senza distinzione.

Così molte aziende si sono viste recapitare (via e-mail) un questionario al quale devono tassativamente rispondere, ma non sanno come, soprattutto per quanto riguarda alcune domande.

Spesso, poi, le risposte ai questionari vengono valutate con algoritmi matematici, applicando metodi quali-quantitativi. In altre parole, ad ogni domanda bisogna rispondere con un SI o NO oppure con un Conforme/Parzialmente Conforme/Non Conforme, e così via. Ad ogni risposta è poi assegnato un punteggio (ed eventualmente un peso) che contribuisce al calcolo di un punteggio complessivo (spesso tramite una media pesata).

Dunque, troppe risposte negative o parzialmente negative possono portare ad escludere una PMI dall’Albo Fornitori di un cliente importante per aspetti non strettamente legati al prodotto/servizio fornito.

Ma andiamo ad esaminare le due principali tipologie di questionari:

• quello dedicato alla Sostenibilità (ESG) e
• quello dedicato alla Privacy (Data Protection secondo il GDPR, Reg UE 2016/679) ed alla Sicurezza Informatica (Cybersecurity).

I questionari sulla Sostenibilità riportano domande anche molto specifiche come, ad esempio, richieste sul calcolo della carbon footprint, delle emissioni di CO₂ e/o monitoraggio dei consumi energetici.

Ovviamente a tali domande molte PMI, soprattutto quelle nel settore dei servizi, non sanno cosa rispondere, né pensano di implementare un sistema di misura e monitoraggio di tali elementi.

In molti contesti il questionario non dovrebbe essere applicabile: se il fornitore ha un basso impatto ambientale, non dovrebbe essere valutato su questi aspetti, in quanto non posso trattare allo stesso modo un fornitore di prodotti derivanti da un processo manifatturiero, un semplice rivenditore di prodotti e un fornitore di servizi di sviluppo software ed assistenza software e sistemistica. Se il fornitore appartiene a queste ultime tipologie, dovrebbe poter rispondere: “Caro cliente, siamo un’azienda di servizi che lavora in uffici neanche tanto vasti, il nostro impatto ambientale è limitato e più che cercare di fare la raccolta differenziata e di limitare i consumi energetici (già ridotti) non possiamo”. Del resto i valori di alcuni parametri sopra menzionati non avrebbero senso e non sarebbero comunque comparabili con aziende industriali.

Sugli aspetti Social dei questionari ESG, non ha molto senso richiedere il possesso di una certificazione nell’ambito della Responsabilità Sociale (SA 8000 o altri; ci sono diversi standard, forse troppi, nessuno standard ISO certificabile), soprattutto quando il fornitore non è a rischio di non rispettare i diritti dei lavoratori, soprattutto riguardo al lavoro forzato o al lavoro minorile.

Questi ultimi aspetti, viceversa, spesso risultano difficilmente applicabili a fornitori che producono in Paesi nei quali la normativa sul lavoro non è severa come nel nostro, anzi, lo sfruttamento dei lavoratori e il disconoscimento dei loro diritti è all’ordine del giorno.

In queste situazioni il tipico caso è quello dell’azienda A (grande azienda, anche multinazionale) vuole imporre criteri rigorosi di responsabilità sociale all’azienda B (il nostro fornitore che è un semplice rivenditore) che acquista i prodotti dall’azienda C, che è una grande azienda che opera in mercati del lavoro poco regolamentati (Asia, Africa…). L’azienda B può essere assolutamente compliance a tutte le norme applicabili in Italia e forse più, ma che controllo può imporre su fornitori di altri Paesi che controllano il mercato globale?

Lato Governance spesso viene richiesta l’attuazione di un Modello Organizzativo 231 (per le aziende italiane) che per certi settori non ha senso poiché la probabilità di incappare in uno dei reati previsti dal D.lgs 231/2001 è quasi inesistente. Idem dicasi per la nuova normativa anticorruzione (ISO 37001).

Al di là del consiglio di rispondere con serietà, competenza e massima trasparenza, sarebbe utile instaurare un canale di comunicazione con il cliente per evitare di essere fortemente penalizzati da un algoritmo di valutazione del questionario che non considera adeguatamente nel calcolo il settore di appartenenza del fornitore.

Passiamo al questionario sulla Privacy e/o sulla Cybersecurity.

Il questionario Privacy viene giustamente adottato per qualificare il responsabile (esterno) del Trattamento di Dati personali ai sensi dell’art. 28 del GDPR, ma non solo. Alcune organizzazioni che hanno molto a cuore la tutela dei dati personali che gestiscono, anche perché molto critici (dati sanitari, dati bancari, ecc.), lo mandano a chiunque ha un appalto di servizi. Starà poi al fornitore spiegare che magari il proprio software in cloud non tratta dati personali di cui il cliente è titolare, a parte i dati delle credenziali di accesso degli utenti e, pertanto, non potrà mai essere investito del titolo di Responsabile del Trattamento.

Se, viceversa, il fornitore tratta dati personali occorre fare attenzione ad alcune domande. Ad esempio, spesso il cliente richiede se il fornitore ha svolto una DPIA (valutazione di impatto sui dati personali), che in realtà è applicabile solo in alcuni casi. Ricordiamo infatti che la DPIA è dovuta, oltre ai casi esplicitamente previsti dal Regolamento UE 679/2016 e dalle indicazioni del nostro Garante Privacy, se un trattamento di dati personali – a seguito della valutazione dei rischi – presenta rischi elevati per i diritti e le libertà degli interessati.

 Anche le domande sul DPO (RPD) dovrebbero prevedere la non applicabilità del requisito per determinati tipi di organizzazione, anche se la nomina di un DPO è comunque un’azione volontaria consigliabile in molte realtà.

Per quanto riguarda la nomina dei responsabili del trattamento (sub-responsabili per il trattamento che un fornitore effettua per un cliente titolare del trattamento) con adeguato accordo contrattuale, essa è un atto doveroso, ma è difficile ribaltare al sub-responsabile i medesimi requisiti contrattuali imposti dal titolare (cliente) al responsabile (fornitore). Immaginiamo ad esempio una società di servizi di elaborazione dati relativi alla gestione del personale che ha numerosi clienti che la hanno nominata responsabile del trattamento, ma che ovviamente utilizza il medesimo programma software per elaborare i dati di tutti i clienti ed ha un contratto con i fornitori del software (tipicamente in Saas, ovvero in cloud) unico con la nomina del fornitore del software  a responsabile del trattamento. In tale situazione è difficile che tutti i requisiti, anche quelli particolari, coincidano con quelli richiesti dal cliente titolare del trattamento.

Poi ci sono le misure di sicurezza.

Spesso le check-list comprendono riferimenti a controlli estratti da linee guida ENISA, ISO 27002 e quant’altro di meglio c’è a disposizione. Peccato che talvolta queste misure di sicurezza non sono correttamente declinate.

Ad esempio, il controllo degli accessi logici e le regole di autenticazione non possono essere imposti tu cur dal cliente al fornitore: alcune regole come il cambio password ogni 3 o 6 mesi non ha senso richiederle come obbligo. Ci sono illustri pareri (NIST in primis) che sono contrari al cambio password frequente, a vantaggio di altre misure di sicurezza alternative (es. MFA con elevata complessità della password).

Dunque, sarebbe più corretto chiedere al fornitore quali policy di controllo degli accessi logici ha implementato e non accontentarsi di risposte del tipo: “per accedere ai sistemi informatici abbiamo imposto una password” … che vuol dir tutto e vuol dir niente.

Poi chiaramente il questionario dovrebbe concentrarsi sulle misure di sicurezza relative al trattamento che il fornitore fa per il cliente. Se il responsabile del trattamento fornisce un software i cloud (SaaS) non ha particolare rilevanza come effettua i backup dei propri dati gestionali internamente, ma è importante capire quali misure di sicurezza ha adottato il datacenter che ospita il servizio.

Stesso discorso vale per backup, anti-malware, firewall ed altre misure di sicurezza che dovrebbero essere commisurate all’attività effettivamente svolta dal fornitore per il cliente. Non basta affermare di disporre di queste misure di sicurezza, bisogna capire come sono applicate. Quando l’accesso del fornitore ai dati del cliente avviene sui database installati presso il cliente normalmente le misure di sicurezza importanti sono quelle implementate dal cliente stesso (regole di autenticazione, VPN per accessi dall’esterno, ecc.). In conclusione, occorre essere preparati per rispondere adeguatamente a queste richieste dei clienti e, se si ritiene di essere adeguatamente strutturati ed organizzati su questi aspetti, è opportuno cercare un dialogo con persone competenti appartenenti all’organizzazione del cliente. Nella

Uno degli aspetti fondamentali del Regolamento Europeo per la Protezione dei Dati (Reg. UE 679/2016, noto anche come GDPR) è costituito da Diritti dell’interessato, i cui requisiti sono descritti al Capo III del Regolamento stesso. Ed uno dei principali documenti (forse il principale) che ogni organizzazione ha predisposto per dimostrare il corretto adempimento a questo elemento è costituito dall’Informativa.

In realtà il Regolamento, agli articoli 12, 13 e 14 non cita il termine “Informativa”, ma “informazioni da fornire all’interessato”, ma ciò non cambia la sostanza, per cui quasi tutte le organizzazioni del nostro Paese, forse anche per continuità con la normativa precedente (D. Lgs 196/2003), hanno predisposto una o più informative per il trattamento di dati personali.

Ma vediamo un po’ cosa si vede in giro nelle varie informative che riceviamo ormai tutti i giorni dai siti internet (normalmente chiamate privacy policy), da tutti quelli a cui, per un motivo o per l’altro, lasciamo i nostri dati anagrafici, dagli ambulatori medici dove facciamo visite ed esami e così via.

Purtroppo, il panorama è molto vasto e variegato e talvolta ci mostra quanto il soggetto a cui forniamo i nostri dati personali sa di privacy.

Partiamo dalle informative intitolate “Informativa al trattamento dei dati personali ai sensi dell’art. 13 del D.Lgs 196/2003 e del regolamento UE 679/2016”. Diffidate dai contenuti di tali informative perché probabilmente sono un collage primordiale dell’informativa della vecchia normativa e di quella nuova, infatti il D.Lgs 196/2003 è stato sì novellato dal D. Lgs 101/2018, per cui è rimasto in vigore, ma l’articolo 13 di suddetto decreto è stato abrogato proprio dal D. Lgs 101/2018, evidentemente perché in contrasto con il GDPR che, per una strana combinazione, all’articolò 13 riporta contenuti analoghi.

Passiamo ora a commentare come il testo del Regolamento viene applicato.

Articolo 13 – Informazioni da fornire qualora i dati personali siano raccolti presso l’interessato

1. In caso di raccolta presso l’interessato di dati che lo riguardano, il titolare del trattamento fornisce all’interessato, nel momento in cui i dati personali sono ottenuti, le seguenti informazioni:

a) l’identità e i dati di contatto del titolare del trattamento e, ove applicabile, del suo rappresentante;

I dati del titolare del trattamento sono riportati in praticamente tutte le informative, anche se purtroppo il GDPR non ci indica chiaramente cosa si intende con “dati di contatto”. La normativa prevede che debba essere agevole rivolgersi all’interessato per esercitare i propri diritti e probabilmente il solo indirizzo di posta elettronica non permetterebbe a tutti di contattare il titolare del trattamento, meglio riportare anche un indirizzo fisico e un numero di telefono.

Alcune informative, poi, riportano erroneamente il nome e cognome di una persona fisica (titolare dell’azienda, legale rappresentante, amministratore delegato?) al posto della ragione sociale della società che ricopre il ruolo di titolare del trattamento.

b) i dati di contatto del responsabile della protezione dei dati, ove applicabile;

Su questo punto se ne vedono delle belle: capita che il RPD o DPO sia identificato nella persona che fa le veci del titolare (o legale rappresentante dell’azienda, o amministratore delegato), cosa esplicitamente vietata dalle linee guida sulla figura del DPO (Data Protection Officer).

In realtà il GDPR chiede solo i dati di contatto del RPD, per cui molti indicano solo un indirizzo di posta elettronica (del tipo dpo@azienda.it) come dato di contatto del DPO, un po’ poco per i motivi sopra illustrati relativamente al titolare del trattamento. Comunque, non è espressamente vietato omettere il nome del DPO o la ragione sociale della persona giuridica che ha assunto l’incarico come DPO esterno.

Si consideri che il DPO dovrebbe essere una figura indipendente da poter contattare anche in modo riservato, soprattutto se si tratta di personale dipendente. Dunque, dovrebbe essere messo a disposizione degli interessati un canale con adeguata riservatezza (e-mail dedicata che legge solo il DPO, telefono diretto, anche fornito solo su richiesta, ecc.).

Non sta scritto da nessuna parte che i dati di contatto del DPO debbano stare nell’Informativa, proprio per i motivi indicati inizialmente (si tratta di informazioni da fornire all’interessato), per cui una brillante soluzione potrebbe essere quella di indicare il nominativo ed i dati di contatto del DPO in apposita sezione del sito internet (soprattutto per Pubbliche Amministrazioni). In tal modo si evita di ripeterlo in tutte le informative e, siccome il DPO teoricamente potrebbe cambiare, si evita di modificare tutte le informative allorquando l’incarico di RPD dovesse passare ad altro soggetto.

c) le finalità del trattamento cui sono destinati i dati personali nonché la base giuridica del trattamento;

Su questo punto si ritrovano diverse versioni, alcune più di stampo giuridico, altre più di tipo organizzativo-gestionale.

Occorre anticipare che – per un determinato titolare del trattamento – la scelta di predisporre una o più informative dipende dalle categorie di soggetti interessati (clienti, fornitori, dipendenti,…) e dalle finalità di trattamento (al limite un’informativa per ogni finalità).

Le finalità del trattamento possono essere rese semplicemente indicando a quale scopo sono trattati i dati personali, quindi – ad esempio – “i dati sono trattati per adempiere ad obblighi contrattuali o precontrattuali” e “per adempiere ad obblighi contabili e fiscali”, oppure – nel caso dei dati di dipendenti – “per la gestione del rapporto di lavoro e requisiti di legge ad esso correlati”.

La base giuridica del trattamento fa riferimento ai motivi di liceità del trattamento, riportati all’art. 6 del GDPR:

1. Il trattamento è lecito solo se e nella misura in cui ricorre almeno una delle seguenti condizioni:

a) l’interessato ha espresso il consenso al trattamento dei propri dati personali per una o più specifiche finalità;

b) il trattamento è necessario all’esecuzione di un contratto di cui l’interessato è parte o all’esecuzione di misure precontrattuali adottate su richiesta dello stesso;

c) il trattamento è necessario per adempiere un obbligo legale al quale è soggetto il titolare del trattamento;

d) il trattamento è necessario per la salvaguardia degli interessi vitali dell’interessato o di un’altra persona fisica;

e) il trattamento è necessario per l’esecuzione di un compito di interesse pubblico o connesso all’esercizio di pubblici poteri di cui è investito il titolare del trattamento;

f) il trattamento è necessario per il perseguimento del legittimo interesse del titolare del trattamento o di terzi, a condizione che non prevalgano gli interessi o i diritti e le libertà fondamentali dell’interessato che richiedono la protezione dei dati personali, in particolare se l’interessato è un minore.

Purtroppo, si vedono alcune informative che riportano testualmente che “la base giuridica del trattamento è quella determinata dall’art. 6 paragrafo 1 f) del GDPR” o qualcosa di simile, riportando l’esatta dicitura dell’art. 6 comma 1 e lettera applicabile. Ma che ne è della trasparenza e della chiarezza (“intelligibile”, “linguaggio semplice e chiaro”) delle informazioni da rendere all’interessato?

Anche riportare nello specifico quelli che sono i requisiti di legge che impongono il trattamento pare un esercizio inutile, anche perché non sarebbe certo facile.

Purtroppo, molti autori di informative (responsabili privacy interni, consulenti privacy esterni, ecc.) tendono a far prevalere la loro formazione di tipo legale ed a voler riportare tutti i riferimenti di legge, ma personalmente credo che debba essere dato maggior risalto alla chiarezza dell’informativa, riportando finalità di facile comprensione per chiunque.

Attenzione a non omettere alcune finalità di trattamento non immediate, ma che potrebbero verificarsi nel recente futuro, come ad esempio le finalità di marketing per l’invio di newsletter informative sull’attività del titolare oppure la tutela del credito. Se non comprese nella prima informativa, tali finalità dovranno essere contemplate in una informativa successiva e ciò potrebbe non risultare efficace e nemmeno efficiente.

Chiaramente alcune finalità “accessorie” al rapporto commerciale con un cliente – nella fattispecie le finalità di marketing – normalmente hanno diverse basi giuridiche (legittimo interesse, consenso) per cui ciò va indicato nell’informativa, ma indicare il preciso riferimento dell’art. 6 del GDPR potrebbe da un lato non soddisfare il requisito di chiarezza di cui sopra, dall’altro potrebbe non essere sufficiente a dimostrare la validità della scelta. Probabilmente sarebbe opportuno, in caso di dubbio, giustificare la scelta della base giuridica su altro documento interno. In caso di legittimo interesse del titolare questa scelta di base giuridica va giustificata in un qualche documento interno relativo alla gestione della privacy, anche in relazione al bilanciamento fra questi ed il rispetto dei diritti dell’interessato.

Un aspetto poco chiaro di questi articoli del GDPR si può evincere dal paragrafo b) di cui sopra: “il trattamento è necessario all’esecuzione di un contratto di cui l’interessato è parte o all’esecuzione di misure precontrattuali adottate su richiesta dello stesso”. Ebbene, nel rapporto commerciale fra persone giuridiche (cliente-fornitore) il cliente tratta i dati delle persone fisiche che rappresentano i fornitori (nome, cognome, telefono aziendale, telefono cellulare, indirizzo e-mail,…) e, viceversa, il fornitore tratta dati analoghi delle persone che rappresentano il cliente (suoi dipendenti e collaboratori). In realtà entrambe dovrebbero rendere l’informativa sul trattamento di questi dati alle persone fisiche che rappresentano il cliente/fornitore, ovvero gli interessati, ma essi “sono parte del contratto” o “dell’esecuzione di misure precontrattuali”, come die il Regolamento? Forse solo in modo indiretto, in quanto aventi un legame contrattuale con il cliente/fornitore. Questi dati personali, comunque, potrebbero ricadere nel successivo articolo 14 del GDPR, in quanto non vengono normalmente raccolti presso l’interessato, ma è l’azienda che li comunica alla controparte.

Occorre precisare, infine, che le condizioni di liceità sopra elencate non si applicano alle categorie particolari di dati (ovvero gli ex dati sensibili a cui si aggiungono i dati genetici e biometrici), per i quali ci sono altre basi giuridiche da considerare, ma le considerazioni da fare sono più o meno le stesse.

d) qualora il trattamento si basi sull’articolo 6, paragrafo 1, lettera f), i legittimi interessi perseguiti dal titolare del trattamento o da terzi;

Ancora, in caso di legittimo interesse come motivo di liceità del trattamento, vanno spiegati quali sono questi interessi legittimi. Tra essi vi sono le finalità di marketing diretto, ammesse dal GDPR, ma sotto determinate condizioni.

e) gli eventuali destinatari o le eventuali categorie di destinatari dei dati personali;

Qui l’informativa deve riportare l’indicazione di tutti i possibili soggetti a cui verranno comunicati i dati personali oggetto di trattamento. La scelta dovrebbe senz’altro ricadere sulle categorie di destinatari, perché salvo pochi casi di destinatari Pubbliche Amministrazioni (ad es. INPS e INAIL per i dati dei dipendenti) gli altri destinatari potrebbero cambiare nel corso del tempo (es. commercialista, consulente del lavoro, società fornitrice di servizi di assistenza informatica, ecc.).

Questo punto dell’informativa deve naturalmente essere coerente con l’analogo elemento del registro dei trattamenti ove sono riportati i destinatari o categorie di destinatari a cui i dati possono essere comunicati. È opportuno controllare sempre la corrispondenza di questi due elementi, soprattutto a fronte di modifiche del registro o dell’informativa.

Ricordiamo che alcuni dei destinatari dei dati personali saranno stati nominati Responsabili del trattamento ai sensi dell’art. 28 del GDPR, altri potranno essere Titolari autonomi, altri ancora semplici soggetti autorizzati al trattamento.

Sebbene in alcune informative siano riportate, fra i destinatari dei dati personali, i soggetti autorizzati interni all’organizzazione (dipendenti), a mio avviso questi non rientrano fra i destinatari che intende il GDPR: è ovvio che un’organizzazione faccia trattare i dati personali che raccoglie da personale interno a autorizzato a farlo e questo l’interessato lo sa. Lo scopo dell’informativa – in questo punto – è informare l’interessato a chi altri vengono comunicati/trasmessi i suoi dati personali.

f) ove applicabile, l’intenzione del titolare del trattamento di trasferire dati personali a un paese terzo o a un’organizzazione internazionale e l’esistenza o l’assenza di una decisione di adeguatezza della Commissione o, nel caso dei trasferimenti di cui all’articolo 46 o 47, o all’articolo 49, paragrafo 1, secondo comma, il riferimento alle garanzie appropriate o opportune e i mezzi per ottenere una copia di tali garanzie o il luogo dove sono state rese disponibili.

In questo punto c’è tutto o niente, ovvero: per molte realtà si informa semplicemente l’interessato che i suoi dati personali non verranno trasferiti presso organizzazioni internazionali e/o Paesi al di fuori dello Spazio Economico Europeo, per altre, invece, si apre il capitolo dei trasferimenti di dati fuori dalla UE con tutto quel che consegue, soprattutto dopo la sentenza Schrems II e le Raccomandazioni EDPB che sono seguite. Questo argomento esula dall’obiettivo di questo articolo e, tra l’altro è stato ampiamente trattato in altro articolo di questo sito.

Oltre a sottolineare il fatto che anche questo elemento è presente nel registro dei trattamenti, pertanto bisognerà verificarne la coerenza, vorrei soffermarmi su alcuni testi di informative che di fatto non dicono nulla.

Infatti, in alcune informative ho trovato frasi del tipo: “i suoi dati personali non saranno normalmente trasferiti fuori dallo SEE, ma qualora lo fossero saranno trasferiti solo in Paesi terzi per i quali esiste una decisione di adeguatezza della Commission Europea (ai sensi dell’art. 45 del GDPR), oppure se il trasferimento è soggetto a garanzie adeguate (ai sensi dell’art. 46 del GDPR)”.

Non si dice molto e non si capisce se i dati sono effettivamente trasferiti fuori UE, dove e quali sono le garanzie adeguate (il GDPR e le successive Raccomandazioni EDPB le definiscono, ma l’interessato non deve essere un esperto della materia).

Oltre ai diffusissimi sistemi cloud ubicati fuori UE, sarebbe opportuno informare l’utente in caso di utilizzo di sistemi per l’invio di newsletter, piattaforme di collaborazione e videoconferenza, servizi di posta elettronica, ecc. che sfruttano datacenter in USA.

2. In aggiunta alle informazioni di cui al paragrafo 1, nel momento in cui i dati personali sono ottenuti, il titolare del trattamento fornisce all’interessato le seguenti ulteriori informazioni necessarie per garantire un trattamento corretto e trasparente:

Teoricamente queste informazioni dovrebbe ro essere fornite dopo aver raccolto i dati personali dell’interessato, ma praticamente nessuno le separa nell’informativa.

a) il periodo di conservazione dei dati personali oppure, se non è possibile, i criteri utilizzati per determinare tale periodo;

Qui alcune informative si limitano a riportare criteri estremamente vaghi, del tipo: “i dati vengono conservati per il tempo necessario previsto dalla legge”. Non mi sembra sia questo lo spirito del Regolamento, ma questo è un argomento che dovrebbe essere trattato separatamente in quanto è molto difficile essere precisi nel fornire queste informazioni, soprattutto perché in un rapporto fra cliente e fornitore, ad esempio, i dati personali trattati sono di diversi tipi ed ognuno di essi potrebbe avere tempi di conservazione diversi. In questo punto (come in altri) il GDPR è troppo sintetico nel testo del requisito e sarebbe stata utile un’interpretazione ufficiale.

Anche questo elemento lo ritroviamo nel registro dei trattamenti, per cui attenzione alla congruenza fra i termini di conservazione (massimi).

b) l’esistenza del diritto dell’interessato di chiedere al titolare del trattamento l’accesso ai dati personali e la rettifica o la cancellazione degli stessi o la limitazione del trattamento dei dati personali che lo riguardano o di opporsi al loro trattamento, oltre al diritto alla portabilità dei dati;

L’interessato, proprietario dei dati personali oggetto dell’informativa, deve essere informato dei suoi diritti, magari non citando pedissequamente il testo del regolamento, ma spiegandogli, con parole semplici, che può accedere ai suoi dati personali, li può modificare, ne può chiedere la cancellazione, se non impedito dalla legge, ecc.

c) qualora il trattamento sia basato sull’articolo 6, paragrafo 1, lettera a), oppure sull’articolo 9, paragrafo 2, lettera a), l’esistenza del diritto di revocare il consenso in qualsiasi momento senza pregiudicare la liceità del trattamento basata sul consenso prestato prima della revoca;

L’interessato deve essere informato che, se il trattamento è stato basato sul suo consenso, tale consenso può essere revocato in qualsiasi momento, senza effetti su quello che è avvenuto prima della revoca.

d) il diritto di proporre reclamo a un’autorità di controllo;

è necessario informare l’interessato che può proporre reclamo al Garante Privacy (ora GPDP) e quasi sempre viene indicato il sito internet dello stesso.

e) se la comunicazione di dati personali è un obbligo legale o contrattuale oppure un requisito necessario per la conclusione di un contratto, e se l’interessato ha l’obbligo di fornire i dati personali nonché le possibili conseguenze della mancata comunicazione di tali dati;

Come nella precedente normativa italiana (nella quale occorreva esplicitare se il conferimento dei dati era obbligatorio), anche nel GDPR occorre specificare se l’interessato è obbligato a fornire i suoi dati personali, tutti quelli richiesti o parte di essi, a seconda delle finalità di trattamento.

Naturalmente alcuni dati sono necessari per concludere un contratto, senza i quali il committente non può dar seguito alla richiesta di prodotti o servizi e nemmeno può adempiere ad obblighi legali in materia fiscale.

Si potrebbe discutere a lungo su determinati servizi, gratuiti, che sono subordinati alla fornitura di dati personali per finalità di marketing, ma questo è un altro discorso.

f) l’esistenza di un processo decisionale automatizzato, compresa la profilazione di cui all’articolo 22, paragrafi 1 e 4, e, almeno in tali casi, informazioni significative sulla logica utilizzata, nonché l’importanza e le conseguenze previste di tale trattamento per l’interessato.

In questo punto, se applicabile, il linguaggio dell’informativa dovrebbe essere reso chiaro per l’interessato, in quanto non tutti hanno ben compreso il concetto di “profilazione” e che, comunque, si tratta di una decisione “automatizzata”, ovvero presa da un algoritmo implementato in un software per computer.

Inoltre, gran parte delle informative riportano un capitolo sulle modalità del trattamento, nel quale si enunciano i criteri adottati dal titolare per tutelare i dati personali trattati.

Altro elemento non esplicitamente richiesto dall’informativa è costituito dalla tipologia di dati personali raccolti, sebbene la presenza di dati articolari (art. 9) o dati giudiziari (art.10) implichi una diversa base giuridica del trattamento e spesso la necessità di ottenere un consenso.

L’elencazione dei tipi di dati trattati potrebbe essere legata alla obbligatorietà o meno del conferimento di ogni tipologia di dati (ad es. i dati anagrafici sono necessari, i recapiti cellulare o mail no).

Da ultimo restano due aspetti da considerare:

1. Quante informative predisporre per i vari trattamenti?
2. Come dare evidenza che l’informativa è stata resa all’interessato?

Partiamo da quest’ultimo punto: il Regolamento non richiede la sottoscrizione dell’informativa da parte dell’interessato (sarebbe quasi un consenso) che, pertanto può rifiutarsi di farlo. Allora si può dimostrare di aver reso l’informativa tramite l’invio via e-mail, la pubblicazione su sito internet o comunque dimostrando di avere una procedura che prevede che qualcuno fornisca l’informativa (necessariamente in forma scritta) all’interessato.

Purtroppo, in alcuni casi ci dicono “firmi questo per la privacy” e non ci chiedono nemmeno se ne vogliamo una copia!

In alcuni casi l’informativa può essere suddivisa in un’informativa breve, da fornire verbalmente, magari attraverso un messaggio registrato o in calce ad una e-mail, ed un’informativa completa, disponibile su sito web.

L’altro problema riguarda il proliferare delle informative per ogni trattamento o interessato oppure di cercare di raggrupparle per tipologia di interessati.

Teniamo presente che una buona parte delle informazioni contenute nelle informative vale per tutti i trattamenti o comunque per diversi soggetti di cui si trattano i dati. Di contro più informative si gestiscono, più si genera dell’entropia e si rischia di sbagliare e di essere inefficienti.

Vale un po’ il discorso fatto per il registro dei trattamenti: è opportuno accorpare i trattamenti omogenei in un unico trattamento (riga o record) del registro.

Se consideriamo un unico trattamento la gestione del personale dipendente con tutti i relativi adempimenti (gestione paghe, sicurezza sul lavoro, formazione, eventuale servizio mensa, polizze, ecc.) dall’assunzione alla cessazione del rapporto, analogamente faremo una stessa informativa che comprenda tutti i trattamenti di dati dei dipendenti, avendo cura di elencare tutte le categorie di destinatari a cui possono essere comunicati i dati personali per i vari ambiti. Quest’esempio, semplice e presente praticamente in ogni realtà aziendale, può essere esteso ad altri ambiti di trattamento.

Poi sarebbe utile rappresentare l’informativa in una forma grafica chiara e di facile interpretazione, magari con tabelle e simboli grafici che permettano all’interessato di sapere come vengono gestiti i propri dati personali per ognuna delle finalità riportate nell’informativa.

Il Garante per la Protezione ei Dati Personali (GPDP) ha recentemente emanato un provvedimento (pubblicato in G.U. lo scorso 09/07) denominato “Linee guida cookie e altri strumenti di tracciamento”, facendo seguito alla consultazione pubblica iniziata lo scorso dicembre.

Il presente articolo segue analogo articolo che commentava la versione posta in consultazione delle medesime Linee Guida e che ora sono state ufficialmente approvate, seppur con qualche modifica.

 Tali Linee Guida di fatto aggiornano un provvedimento analogo (n. 229, dell’8 maggio 2014) adottato prima dell’entrata in vigore del Regolamento UE 679/2016.

I riferimenti normativi su cui si basa il provvedimento sono dunque i seguenti:

• Regolamento UE 679/2016 (GDPR)
• Codice Privacy (D.Lgs 196/2003) emendato dal D.Lgs 101/2018, in particolare l’art. 122 del Codice
• Direttiva 2002/58/CE del 12 luglio 2002, relativa al trattamento dei dati personali e alla tutela della vita privata nel settore delle comunicazioni elettroniche (c.d. direttiva ePrivacy), come modificata dalla direttiva 2009/136/CE del 25 novembre 2009
• Parere dell’EDPB n. 05/2019 del 12 marzo 2019 sulle interrelazioni tra la direttiva e-Privacy ed il Regolamento
• Linee guida EDPB 05/2020 sul consenso ai sensi del regolamento (UE) 2016/679

Le Linee Guida dovranno essere recepite da tutti i proprietari di siti web entro sei mesi dalla pubblicazione, ovvero entro il 09/01/2022.

Si fa presente che le Linee Guida in oggetto rientrano in un ambito he verrà regolamentato da nuovo Regolamento e-Privacy – ormai di prossima emissione – che sostituirà la Direttiva e-Privacy sopra elencata.

Classificazione dei cookie ed altri strumenti di tracciamento

I GPDP distingue fra le seguenti tipologie di cookie:

1. i cookie tecnici, utilizzati al solo fine di “effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica, o nella misura strettamente necessaria al fornitore di un servizio della società dell’informazione esplicitamente richiesto dal contraente o dall’utente a erogare tale servizio” (cfr. art. 122, comma 1 del Codice);
2. i cookie di profilazione, utilizzati per ricondurre a soggetti determinati, identificati o identificabili, specifiche azioni o schemi comportamentali ricorrenti nell’uso delle funzionalità offerte (pattern) al fine del raggruppamento dei diversi profili all’interno di cluster omogenei di diversa ampiezza, in modo che sia possibile al titolare, tra l’altro, anche modulare la fornitura del servizio in modo sempre più personalizzato al di là di quanto strettamente necessario.

I cosiddetti “cookie analytics”, che normalmente servono ad elaborare statistiche sulle visite al sito web attraverso servizi di terze parti (ad es. Google Analytics) possono essere equiparati ai cookie tecnici solo se il gestore del sito, attraverso apposite tecniche di anonimizzazione (ad es. mascheramento delle ultime cifre dell’indirizzo IP) rende non identificabile l’utente da parte delle terze parti a cui vengono trasmessi i dati a fini statistici (il GPDP ritiene che siano possibili solo statistiche aggregate per ricadere in questa tipologia). Viceversa, i cookie analitici ricadono fra i cookie di profilazione.

Informativa e consenso

Il consenso dell’utente all’impiego dei cookie è ritenuto necessario solamente per i cookie di profilazione (compresi i cookie analitici di terze parti che presentano tali caratteristiche), mentre in ogni caso deve essere resa all’utente un’informativa sull’uso dei cookie.

In caso di utilizzo non solo di cookie tecnici il consenso all’installazione di cookie sul device dell’utente deve essere richiesto all’accesso al sito web, tramite apposito banner ben visibile. Tale banner deve avere le seguenti caratteristiche:

• riportare un’informativa breve sull’utilizzo dei cookie;
• richiamare tramite link un’informativa estesa – denominata privacy policy – che comprenda tutti i contenuti previsti dagli articoli 13 e 14 del GDPR;
• presentare all’utente un pulsante per poter rifiutare tutti i cookie;
• presentare all’utente un pulsante per accettare tutti i cookie e/o gestire diverse opzioni di scelta sui cookie, tramite link ad apposita area;
• riportare in alto a destra un pulsante a forma di X che permette la chiusura del banner; in tal caso la scelta di default sarà quella di rifiutare tutti i cookie;
• l’avvertenza che la chiusura del banner mediante selezione dell’apposito comando contraddistinto dalla X posta al suo interno comporta il permanere delle impostazioni di default e dunque la continuazione della navigazione in assenza di cookie o altri strumenti di tracciamento diversi da quelli tecnici.

Non sono ammesse forme di consenso tramite il semplice scrolling della pagina web.

Non è normalmente lecito implementare i c.d. cookie wall ovvero un banner che permette l’accesso al sito solo previa accettazione di tutti i cookie.

Il consenso raccolto deve essere documentabile e l’utente deve aver la possibilità di revocarlo successivamente, anche perché il sito deve mantenere traccia delle scelte effettuate dall’utente al primo accesso al sito (anche e soprattutto se ha rifiutato i cookie) e fornirgli la possibilità di aggiornare successivamente tali scelte (sempre che ciò sia possibile, salvo l’utente non sia identificabile, l’impiego dei cookie sia stato modificato, ecc.).

I consensi e le scelte relative all’utilizzo dei cookie devono essere mantenuti dal sito per sei mesi.

La privacy policy, che deve essere facilmente accessibile da tutte le pagine del sito, deve contenere, tra l’altro:

• l’indicazione circa gli eventuali altri soggetti destinatari dei dati personali raccolti tramite i cookie o tecnologie similari ed i tempi di conservazione delle informazioni acquisite;
• l’indicazione delle modalità previste dalle terze parti per esercitare i propri diritti in termini di modifica/revoca del consenso;
• l’elenco dei cookie – raggruppati in categorie omogenee – utilizzati dal sito.

Conclusioni

Premesso che il presente articolo rappresenta solo una sintesi del Provvedimento del GPDP in oggetto e che, pertanto, è necessario che siano letti attentamente sia le Linee Guida, sia l’allegata Scheda di Sintesi per provvedere all’aggiornamento dei siti web in conformità alle Linee Guida, si sottolinea il fatto che il documento del GPDP ha contenuti tecnici che dovrebbero essere esaminati dal gestore del sito o dal responsabile del suo sviluppo (in caso di nuovi siti).

Poiché i siti web sono pubblici e, quindi, facilmente ispezionabili dall’Autorità di Controllo, le eventuali non conformità rispetto alla normativa sono facilmente identificabili.

Ricordiamo che eventuali sanzioni sono sempre a carico del proprietario del sito web (facilmente individuabile – anche per siti “dimenticati” – dalle funzionalità Whois presenti sul web), mentre lo sviluppatore del sito o il suo gestore/manutentore è responsabile solo di adempiere al contratto fra le parti, nel quale il Titolare del trattamento dovrà prevedere appositi impegni di conformità alle Linee Guida in oggetto.

L’impatto su molti siti web i cui proprietari desidereranno adeguarsi alle nuove Linee Guida non sarà ininfluente, in quanto richiederà un intervento tecnico da parte di personale specializzato. Anche nel caso di siti realizzati con CMS (Content Management System) quali WordPress o Joomla, solo per citarne alcuni, si dovrà intervenire con appositi plugin o servizi specializzati, per lo più a pagamento, che permettono di gestire i cookie in modo guidato.

Prevedo già che alcuni fornitori se ne approfitteranno, richiedendo cifre esagerate per ottenere la conformità dei cookie.

In ogni caso ci sarà un aggravio di costi anche per siti di aziende senza particolari velleità di marketing digitale spinto e qualcuno accuserà la privacy di creare solo costi aggiuntivi per le imprese e questo non è bello.

Viceversa i siti che utilizzano pesantemente le tecnologie di tracciamento a fini di marketing ne subiranno le conseguenze più significative. Il Digital Marketing dovrà rivedere alcuni approcci, in quanto l’opzione di default, preimpostata come evidenziata, “Accetta tutti cookie” non potrà più essere contrapposta al classico pulsante “Personalizza” o “Gestisci le tue preferenze” che spesso ci porta in percorsi molto articolati nei quali è difficile districarsi (provate a gestire le preferenze sui cookie in Facebook per credere). Il default sarà “Rifiuta tutti i cookie non tecnici” e persino la chiusura del banner porterà automaticamente ad una scelta di rifiuto dei cookie.

Restano possibili, di default, le pure statistiche aggregate sulle visite al sito tramite Google Analytics, ma a condizione che l’indirizzo IP nel cookie sia mascherato, procedimento non certo immediato.

Francamente poco condivisibile è la necessità di conservare la scelta sul consenso o rifiuto dei cookie in sessioni successive, perché appesantisce la gestione dei cookie, soprattutto in siti molto trafficati, e di limitata utilità per l’utente che non si collega sempre con lo stesso dispositivo ad un certo sito web o che ha implementato procedure di cancellazione periodica dei cookie dal proprio terminale attraverso funzioni specifiche del browser o utility di pulizia del PC.

Permangono alcune perplessità sull’approccio non proprio omogeneo di diverse Autorità di Controllo sulla Protezione dei Dati a livello europeo (in ambito UE e di Paesi appena usciti dalla UE), vista l’internazionalità dei siti web: un sito deve seguire la normativa italiana se è di proprietà di un titolare del trattamento italiano, se è un sito .it, se è un sito ospitato su server in Italia?

Anche se non citate esplicitamente nel provvedimento, le Linee Guida sui cookie comprendono anche altre tecnologie di tracciamento che dominano il mondo del digital marketing.

Molte imprese vorranno vedere prima Facebook, Amazon e Google mettere i pulsanti “Rifiuta tutti i cookie” in bell’evidenza prima di adeguare i loro siti.

Il divieto del c.d. cookie wall – da cui si può prescindere in casi non proprio chiarissimi – pone un interrogativo di fondo: perché non poso fornire un servizio informativo gratuito solo a chi è disposto a subire una profilazione ed un po’ di pubblicità mirata? In fondo nel mondo analogico non è quello che avviene con le fidelity card?

Tutti i siti di informazione e notizie – quelli delle testate giornalistiche in primis – non potranno più contare su banner pubblicitari mirati, ma solo su pubblicità generica e questo porterà sicuramente a introiti inferiori. Vedremo però se tutto questo porterà vantaggi tangibili agli utenti di internet, soprattutto tramite smartphone e relative app, che dovrebbero vedere ridursi i banner/pop-up pubblicitari, per lo meno quelli derivanti da profilazione dell’utente stesso.