La sicurezza del sito web: le regole per realizzare un sito conforme

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 extraUE: 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 privacy: lo schema ISDP©10003

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.




Luci ed ombre del contratto di trattamento dati con il Responsabile del trattamento

man and a woman on a business meeting
Photo by Artem Podrez on Pexels.com

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?

crop businessman signing contract in office
Photo by Andrea Piacquadio on Pexels.com

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




Valutazione del rischio per la sicurezza delle informazioni vs. valutazione del rischio privacy

Tischio per le informazioni

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.




Le nuove Linee Guida del GPDP sui cookie

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 5/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.




La valutazione del rischio Privacy

Perché valutare il rischio per la protezione dati

Sebbene il Regolamento UE 679/2016 (ormai più noto con l’acronimo inglese, GDPR) indichi diverse volte la necessità di effettuare una valutazione dei rischi che incombono sui dati personali, in molte organizzazioni non c’è una chiara evidenza di un processo documentato di valutazione dei rischi che abbia portato ad intraprendere determinate azioni e misure di sicurezza.

Già all’art. 25 (Privacy-by-design & privacy-by-default), comma 1, il GDPR ci indica la necessità di effettuare una valutazione dei rischi:

Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, come anche dei rischi aventi probabilità e gravità diverse per i diritti e le libertà delle persone fisiche costituiti dal trattamento, sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso il titolare del trattamento mette in atto misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte ad attuare in modo efficace i principi di protezione dei dati, quali la minimizzazione, e a integrare nel trattamento le necessarie garanzie al fine di soddisfare i requisiti del presente regolamento e tutelare i diritti degli interessati.



E all’art. 32 (Sicurezza del trattamento), comma 1, riprende:

Tenendo conto dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, il titolare del trattamento e il responsabile del trattamento mettono in atto misure tecniche e organizzative ade-guate per garantire un livello di sicurezza adeguato al rischio, che comprendono, tra le altre, se del caso: ….

Ancora all’art.35 (Valutazione di impatto), comma 1, viene indicata la necessità di valutare un rischio:

Quando un tipo di trattamento, allorché prevede in particolare l’uso di nuove tecnologie, considerati la natura, l’oggetto, il contesto e le finalità del trattamento, può presentare un rischio elevato per i diritti e le libertà delle persone fisiche, il titolare del tratta¬mento effettua, prima di procedere al trattamento, una valutazione dell’impatto dei trattamenti previsti sulla protezione dei dati personali. Una singola valutazione può esaminare un insieme di trattamenti simili che presentano rischi elevati analoghi.

Per non parlare poi della “Notifica delle violazioni dati”, del trasferimento di dati extra-UE e di tutti i considerando che citano i rischi.

Ma come dare evidenza della valutazione dei rischi? E di quali rischi stiamo parlando?

Il processo di valutazione dei rischi sul trattamento dei dati personali è orientato a valutare – e mitigare, se non ridurre al minimo – tutti i rischi per i diritti e le libertà dell’interessato che si possono verificare a fronte di un trattamento di dati personali.

Se poi, a valle di una valutazione dei rischi si ottiene un rischio elevato per i diritti e le libertà dell’interessato, allora sarà necessario condurre anche una valutazione di impatto sul trattamento che è risultato di rischio elevato. Questo al netto delle altre condizioni che possono portare a condurre comunque una valutazione di impatto, come imposto dal GDPR stesso e dalle indicazione dei Garanti nazionali.

Per essere coerenti con quanto disposto dal Regolamento occorre valutare i rischi analizzandone gravità delle conseguenze e probabilità di accadimento, come ci indica l’articolo 32.

Un buon modo per affrontare la valutazione dei rischi è sicuramente costituito dall’opportunità di riferirsi a standard internazionali per la valutazione dei rischi, come le norme della serie ISO 31000 (cfr. UNI ISO 31000:2018 – Gestione del rischio – Principi e linee guida).

Dunque, scartando le valutazioni dei rischi privacy svolte un po’ “a sentimento” ed in modo discorsivo e piuttosto sbrigativo, come se ne vedono in diverse organizzazioni, vediamo come condurre una valutazione dei rischi che possa metterci al sicuro da sanzioni. Se non altro per aver seguito un ragionamento coerente, basato su dati di fatto e valutazioni oggettive giustificabili.

Premesso che la valutazione dei rischi (o risk assessment) è per lo più una valutazione soggettiva che non pretende di misurare in maniera oggettiva il livello di rischio assoluto, ma semplicemente di stabilire le priorità, mettere in fila i rischi per stabilire, poi, su quali agire con azioni di mitigazione e quali reputare accettabili.

La metodologia di valutazione del rischio

Nel processo di risk assessment privacy vengono considerati i seguenti attributi dei dati personali (o degli archivi, banche dati di dati personali):

  • RISERVATEZZA: il dato deve essere accessibile solo a chi è autorizzato a conoscerlo.
  • INTEGRITÀ: i dati devono essere integri, esatti e coerenti.
  • DISPONIBILITÀ: i dati devono essere sempre disponibili alle persone autorizzate quando necessario.

Pertanto, tutti i rischi che possono derivare da trattamenti non conformi ai requisiti normativi sulla protezione dei dati personali possono essere indirizzati ad una o più dei suddetti attributi delle informazioni personali gestite.

In ambito privacy sono considerati solo i rischi relativi al trattamento dei dati personali che hanno impatto sugli interessati (danni materiali ed immateriali). Sono escluse dal contesto tutte le conseguenze di rischi che non hanno impatti sui dati personali.

Le sorgenti di rischio nell’ambito del trattamento di dati personali possono riguardare:

  • personale interno all’organizzazione: dipendenti, collaboratori, ecc.
  • persone esterne all’organizzazione: fornitori, concorrenti, terze parti, ecc.
  • risorse tecnologiche: virus informatici, malfunzionamenti e crash di sistemi, ecc.
  • eventi naturali e non naturali (causati dall’uomo): terremoti, incendi, alluvioni, ecc..

Il processo di valutazione dei rischi comprende le seguenti fasi, descritte nel seguito del presente documento:

  1. Identificazione dei rischi
  2. Analisi e ponderazione dei rischi
  3. Identificazione e valutazione delle opzioni per il trattamento dei rischi
  4. Attuazione di controlli per il trattamento dei rischi
  5. Accettazione/Trattamento dei rischi residui.

Il regolamento ci invita a valutare il rischio con l’ormai nota formula R= f(G, P) dove spesso la funzione è semplicemente una moltiplicazione dei parametri Gravità e Probabilità, misurati attraverso una scala quali-quantitativa (1, 2, 3,… valori che corrispondono a valutazioni del tipo Basso, Medio, Alto…). Tuttavia, restano ancora molti dubbi su come approcciare la valutazione dei rischi per essere ragionevolmente tranquilli della conformità del processo.

Al di là della teoria molto estesa disponibile sull’argomento (le metodologie di risk assessment sono molto diffuse in diversi settori ed ambiti), sono stati pubblicati dei modelli pratici per valutare il rischio privacy. Si va dal Modello VERA (Very easy risk assessment) ideato da @Cesare Gallotti per la gestione del rischio ISO 27001 (sicurezza delle informazioni) da cui è stato mutuato un “modello VERA Privacy”, al modello di risk assessment dell’ENISA, poi modificato da @Stefano Posti e @Cristina Cecere (Metodologia Smart).

Proviamo ad esaminare quanto di buono hanno questi modelli e quanto possono essere applicabili nelle organizzazioni anche di medio-piccole dimensioni che però trattano dati personali abbastanza critici.

Quali sono i rischi privacy?

Tenuto conto che il Regolamento UE indica di tenere in considerazione i rischi derivanti da:

  • Distruzione
  • Perdita
  • Modifica
  • Rivelazione o divulgazione
  • Accesso non autorizzato

in modo illegale o accidentale, a dati personali trasmessi, conservati o comunque elaborati. Possiamo fermarci a queste macro categorie di rischio? In alcune situazioni la risposta può essere affermativa, ma va inquadrato con l’approccio giusto tutto il processo di valutazione del rischio.

Occorre pertanto partire dai trattamenti di dati personali, ovvero dal registro dei trattamenti, la cui definizione è un prerequisito per la definizione di una valutazione dei rischi privacy.

Alcuni modelli di risk assessment privacy partono dai trattamenti e, per ogni trattamento, elaborano una valutazione del rischio in funzione di minacce, vulnerabilità, probabilità di verificarsi delle minacce e relativo impatto/conseguenza.

Il modello ENISA (e la sua revisione Smart di @Stefano Posti) partono proprio dai trattamenti, formulando un esempio relativo al trattamento dei dati del personale dipendente, comune a tutte le organizzazioni.

Prima di illustrare la metodologia è bene evidenziarne subito le criticità: partendo dai trattamenti dovremo elaborare una valutazione dei rischi – piuttosto articolata – per ogni singolo trattamento; ovvero l’analisi dovrà essere ripetuta con i medesimi step per tutti i trattamenti. Va da sé che se i trattamenti individuati sono molteplici, l’analisi dei rischi diventa un esercizio piuttosto dispendioso di energie. Da un lato bisognerebbe avere un Registro con pochi trattamenti, ovvero raggruppare singole attività di trattamento in processi di trattamento più generali (ad es. la “gestione del personale” deve costituire un unico trattamento senza scomporlo in tante attività che lo compongono: elaborazione buste paga, organizzazione del personale, gestione formazione del personale, assunzione nuovo personale, ecc.), dall’altro si rischia di replicare le stesse considerazioni ed analisi su rischi di origine ICT che incombono su tutti i trattamenti o quasi. Questo perché le minacce che provengono dagli strumenti informatici (virus, attacchi hacker, violazione di dati…dovuti a vulnerabilità della gestione dei dati digitali) probabilmente sono le medesime per diversi trattamenti che prevedono la gestione attraverso la stessa infrastruttura IT, gli stessi software gestionali.

Altra carenza del modello ENISA sopra citato è il seguente: lo schema per la valutazione del rischio ENISA vale principalmente per i rischi in materia di sicurezza dei dati, ma il GDPR fa riferimento, in modo più generale, ai “rischi per i diritti e le libertà delle persone fisiche”. Dunque – come evidenziato nel “Manuale del RPD” del progetto T4DATA – ci potrebbero essere rischi per i diritti e le libertà dell’interessato che non sono legati alla sicurezza del dato, ovvero alla sua perdita di riservatezza/integrità/disponibilità, bensì sono insiti in un trattamento particolarmente a rischio.

Tale trattamento potrebbe essere uno di quelli compresi fra quelli per i quali è necessaria una valutazione di impatto (DPIA) che, seppur svolto seguendo buone prassi di protezione dei dati, per sua natura, potrebbe comportare ugualmente rischi per i diritti e le libertà dell’interessato. Tra essi vi sono, ad es. la sorveglianza sistematica di zone accessibili al pubblico, il trattamento su larga scala di dati particolari, specialmente se si utilizzano nuove tecnologie (app mobili, sistemi di geolocalizzazione, ecc.), profilazione, ecc.

Dunque, abbiamo dei rischi legati alla sicurezza del trattamento e rischi legati alla valutazione di impatto sui diritti e le libertà dell’interessato. Nello specifico quali potrebbero essere questi rischi? Alcuni esempi possono essere dedotti dalle varie Linee Guida sulla Valutazione d’impatto:

  • Discriminazione
  • Furto d’identità
  • Decisioni ingiuste derivanti da profilazione
  • Mancata concessione di un credito
  • Limitazione all’esercizio della libertà di espressione
  • Spamming
  • Telefonate indesiderate

Per tutti i trattamenti che ricadono sotto la valutazione di impatto secondo l’art. 35 del GDPR occorre comunque effettuare una valutazione di impatto.

Altri rischi, non necessariamente legati alla sicurezza dei dati, possono incombere sui diritti e le libertà dell’interessato e, di conseguenza, costituire un rischio di compliance privacy per il titolare/responsabile del trattamento. Tra essi ricadono:

  • L’impossibilità – per l’interessato – di esercitare i propri diritti di accesso, modifica e cancellazione dei dati personali
  • Il trasferimento dati personali fuori UE senza adeguate garanzie
  • La raccolta di dati eccedente le finalità
  • La conservazione di dati per un tempo eccessivo
  • Le informative e consensi incomplete, inesatte o comunque inadeguate

Tutte situazioni che possono comportare reclami dell’interessato oppure istanze al GPDP con eventuale richiesta di risarcimento danni.

Nella determinazione dei rischi privacy ci si potrebbe fermare ad alto livello, identificando i fattori di rischio suggeriti dal Regolamento UE 679 all’art. 32 (vedi sopra: Distruzione, Perdita, Modifica, Divulgazione…) oppure individuare l’effetto finale per la persona fisica provocato dall’evento avverso: discriminazione, ricatti, danni morali, furto d’identità, impossibilità di accedere ad un servizio per indisponibilità dei dati,…

Il primo approccio è, tutto sommato, quello adottato dal modello VERA privacy precedentemente citato, anche se i suddetti fattori di rischio sono “incrociati” con una serie di minacce che incombono sui dati, sia in formato digitale, sia su supporto cartaceo.

Un approccio intermedio potrebbe essere basato sulla determinazione di 10-15 rischi “classici” che derivano da un’analisi delle minacce e delle vulnerabilità possibili, calcolando il valore del livello di rischio per ogni rischio, indipendentemente dai trattamenti sui quali impatta o, meglio, considerando globalmente tutti i trattamenti che possono essere affetti dal rischio, considerando il caso peggiore.



La valutazione del rischio secondo i modelli ENISA e SMART

Il modello ENISA, rielaborato nel modello Smart, prevede la valutazione del rischio secondo il medesimo schema, che andremo a descrivere, per ogni trattamento individuato nel Registro dei trattamenti.

Per prima cosa al trattamento vengono assegnati dei livelli di criticità dell’impatto (da 1 a 4) relativi ai consueti attributi di Riservatezza, Integrità e Disponibilità. Tale valutazione viene poi giustificata con note esplicative, caratterizzazione delle tipologie di dati trattati, tempo massimo di indisponibilità dei dati ritenuto ammissibile e così via.

Vi sono analogie col modello di risk assessment proposto dalla Linea Guida ISO 27005 per la sicurezza delle informazioni, dove, però, la criticità delle informazioni viene valutata sugli asset (asset fisico o information asset, tradotto con il termine “bene” in italiano); sommando i valori di R + I + D (da 1 a 3) si ottiene un valore dell’asset dal punto di vista dell’impatto sulle informazioni gestite.

Nel modello di rischio presentato, invece, si prende il “caso peggiore” – ovvero il valore più alto fra R, I e D – come valore dell’impatto sul trattamento di dati personali considerato.

I livelli di impatto (gravità) sugli attributi di Riservatezza, Integrità e Disponibilità sono determinati secondo i criteri esposti nella seguente tabella

Livello di impatto Descrizione
1 = Basso Piccoli inconvenienti superabili senza particolari problemi (tempo necessario per re-inserire informazioni, irritazione, ecc.)
2 = Medio Inconvenienti significativi, superabili con alcune difficoltà (costi aggiuntivi, mancato accesso a servizi aziendali, timori, difficoltà di comprensione, stress, piccoli disturbi fisici, ecc.)
3 = Alto Conseguenze significative che si dovrebbero poter superare ma con gravi difficoltà (sottrazione di liquidità, inserimento in elenchi negativi da parte di istituti finanziari, danni a beni materiali, perdita dell’impiego, ordinanze o ingiunzioni giudiziarie, compromissione dello stato di salute, ecc.)
4 = Molto alto Conseguenze significative o irreversibili, non superabili (perdita capacità lavorativa, disturbi psicologici o fisici cronici, decesso, ecc.)
Criteri di definizione della gravità dell’impatto

A questo punto il modello in esame prevede un questionario per la determinazione della Verosimiglianza (probabilità) che uno o più eventi avversi si verifichino.

Le domandesono suddivise in quattro aree principali di valutazione in termini di sicurezza dei dati, ossia:

  1. Risorse di rete e tecnologiche (hardware e software)
  2. Processi/procedure connessi al trattamento
  3. Soggetti e persone coinvolti nel trattamento
  4. Settore di attività e scala del trattamento

Per ciascuna area di valutazione, vengono poste cinque domande la cui risposta può essere “Si”, “No” oppure “Non so”. In base alle risposte date l’algoritmo che sta alla base del calcolo (si veda il Manuale ENISA, il Manuale degli RPD e il Modello SMART di @Stefano Posti per i dettagli). In realtà il modello ENISA non illustra un metodo matematico di calcolo della probabilità per ogni area, ma definisce una probabilità – per ognuna delle quattro aree sopra identificate – suddivisa come segue:

  • Basso: è improbabile che la minaccia si materializzi.
  • Medio: c’è una ragionevole possibilità che la minaccia si materializzi.
  • Alto: la minaccia potrebbe materializzarsi

La probabilità finale delle minacce viene calcolata sommando i valori della probabilità per ogni singola area, riconducendo il totale ai medesimi 3 livelli.

Invece il modello presentato nel Manuale del DPO presenta un metodo deterministico dei suddetti valori, per ogni area, in base al numero di risposte affermative alle domande poste per ogni categoria.

Il modello di @Stefano Posti parrebbe più dettagliato, sebbene a fronte delle risposte “Non so” non si determini una probabilità maggiore che si concretizzi una minaccia rispetto alla risposta “Si”. Comunque, il file Excel reso disponibile è modificabile e personalizzabile quindi, a fronte delle risposte dubitative, si potrebbe (e dovrebbe) approfondire l’argomento in quanto esiste una maggiore aleatorietà della valutazione.

Il modello SMART, inoltre, permette di correggere il valore della Verosimiglianza determinato dall’algoritmo, nel caso si ritenga non rispecchi fedelmente quanto presente nella realtà.

Il punteggio così ricavato (i valori vengono ricondotti alla scala 1 = Basso, 2 = Medio, 3 = Alto) può essere associato al punteggio relativo all’impatto delle conseguenze, precedentemente calcolato, per arrivare a un punteggio complessivo per il calcolo del rischio.

Il modello SMART prevede il calcolo di un livello di rischio per ognuna delle quattro categorie sopra stabilite (Risorse di rete e tecnologiche, Processi/procedure connessi al trattamento, Soggetti e persone coinvolti nel trattamento, Settore di attività e scala del trattamento) secondo la formula Rischio = Max (Verosimiglianza x Max (Impatto), per ogni categoria), dunque si considera ancora il c.d. “worst case” (caso peggiore).

Il punteggio calcolato viene poi associato ad una descrizione secondo la seguente tabella (il valore del rischio può variare fra 1 e 12):

Livello di rischio
Basso < 3
3 < Medio < 6
5 < Alto < 9
 Molto Alto > 8

Questa tabella differisce dal criterio proposto dal metodo ENISA (riportato anche nel Manuale dell’RPD) che prevede la seguente matrice di rischio:

Matrice di rischio modello ENISA

Si noti che il rischio Basso (in verde) è asimmetrico, nel senso che se il punteggio 2 viene ottenuto da un Impatto Basso (=1) e una Probabilità Media (=2) il Rischio sarà giudicato Basso, viceversa se il medesimo valore sarà ottenuto da un Impatto Medio (=2) e da una Probabilità Bassa (=1), il Rischio sarà Medio (colore giallo).

Sia il modello ENISA che il modello SMART prevedono, successivamente al calcolo del rischio sul trattamento, la definizione dei controlli di sicurezza (alias “misure di sicurezza tecniche ed organizzative”) necessari per mitigare il rischio.

A questo punto è necessario aprire una parentesi sulla metodologia di risk assessment adottata.

Il rischio che è stato calcolato è un rischio potenziale o rischio inerente che incombe sul trattamento a prescindere dalle misure di sicurezza (controlli) implementati. Infatti, se andiamo ad esaminare le domande del questionario per la determinazione della verosimiglianza (o probabilità) delle minacce viene chiesto, ad esempio, se si svolgono operazioni di trattamento tramite internet e se i sistemi IT sono interconnessi con altri sistemi interni o esterni all’organizzazione, non se si dispone di antivirus aggiornati, firewall, sistemi di controllo degli accessi con password complesse e così via. Dunque, la probabilità che una minaccia si concretizzi è valutata in termini assoluti, senza considerare le misure di prevenzione e protezione adottate.

Facendo una valutazione sulle misure di protezione, anziché di prevenzione come nel caso degli antivirus, andiamo a calcolare la probabilità che si verifichi un terremoto di magnitudo elevata (è diversa la probabilità se siamo in Sardegna o in Abruzzo), ma non consideriamo se l’edificio aziendale è di recente costruzione ed antisismico oppure no.

Quindi il rischio intrinseco lo dobbiamo mitigare con le misure di sicurezza (i controlli) di cui disponiamo, al fine di ottenere il c.d. rischio residuo. Se il rischio residuo sarà reputato troppo elevato, o comunque non accettabile per il profilo di rischio del titolare del trattamento, allora dovremo implementare ulteriori misure di sicurezza.

Dunque, il modello SMART ed il modello ENISA, da cui discende, prevedono la determinazione delle misure di sicurezza, in funzione del livello di rischio intrinseco calcolato precedentemente.

Il foglio Excel del modello SMART riporta tutti i punti di controllo della ISO 27001, raggruppati per un totale di 20 elementi, e per ognuno di essi ne viene data una valutazione a 4 livelli (1- Inadeguato, 2- Parzialmente adeguato, 3- Quasi adeguato, 4- Adeguato, oppure Non Applicabile). Viene quindi calcolato un livello di efficacia dei controlli medio (da 1 a 4) e un livello di vulnerabilità media (calcolato come l’inverso dell’efficacia delle misure di sicurezza, ovvero 5 – valore medio dei controlli). Infatti, il concetto è il seguente: quanto più sono efficaci i controlli di sicurezza (le misure di sicurezza), quanto meno i miei dati sono vulnerabili a fronte del concretizzarsi di una minaccia.

A questo punto viene calcolato il rischio ponderato (ovvero il rischio residuo) come il prodotto del rischio inerente calcolato precedentemente per la vulnerabilità media diviso 4 (per normalizzare il nuovo livello di rischio alla scala definita in precedenza. Così il livello di rischio potrà essere attenuato e riportarsi ad un livello Basso, Medio, Alto o Molto alto in base al quale dovranno essere prese delle decisioni sul trattamento, ovvero stabilire:

  • Azioni volte ad evitare il rischio, azzerando la possibilità che esso si concretizzi;
  • Azioni volte a proteggere i dati dalle conseguenze del rischio;
  • Azioni finalizzate a ridurre la probabilità che il rischio si concretizzi, attraverso l’intensificazione dei controlli preventivi;
  • Azioni di trasferimento del rischio a terzi (fornitori, assicurazioni,…);
  • Accettazione del rischio, in quanto non è stato ritenuto opportuno intervenire in base al rapporto costi/benefici delle eventuali azioni di trattamento esaminate.

Se a fronte di azioni di mitigazione non si riesce ancora a ridurre un livello di rischio elevato occorrerà procedere con la Valutazione di Impatto (DPIA) ed eventualmente con la consultazione del Garante per la Protezione dei Dati Personali prima di avviare il trattamento.

Il modello ENISA, a differenza del modello SMART, prevede una serie di misure di sicurezza (controlli) mutuate anch’esse dai controlli della ISO 27001/27002, ma prevede necessariamente l’applicazione di alcune misure (minime) per i trattamenti con livello di rischio Basso, altre misure previste per i trattamenti con livello di rischio Medio e ulteriori misure tassativamente richieste per i trattamenti con livello di rischio Alto. In pratica la scelta delle misure di sicurezza ritenute adeguate è determinata automaticamente in base al rischio calcolato.

In conclusione, i pregi e difetti di questi metodi:

Pro:

  • Riferimenti a normative e linee guida che permettono di dimostrare l’accountability del Titolare;
  • Metodologia che recepisce quanto richiesto dal Regolamento in merito alla valutazione della Gravità dell’impatto e della Probabilità del rischio;
  • Metodo analitico di calcolo del rischio completo, volendo personalizzabile (file Excel reso disponibile da @Stefano Posti);
  • Definizione delle aree/categorie di minacce che permette di esaminare tutti gli aspetti del trattamento;
  • Flessibilità nel calcolo del rischio residuo sulla base dei controlli applicati (solo metodo SMART) e nella possibilità di ripetere la valutazione dei controlli a seguito dell’implementazione di ulteriori misure di sicurezza;
  • Evidenza dell’effetto di mitigazione dei controlli sul rischio inerente (solo metodo SMART).

Contro:

  • Necessità di ripetere la valutazione per ogni trattamento, ma la parte relativa al questionario di assessment della verosimiglianza (calcolo della probabilità) e quella relativa ai controlli è duplicabile se applicabile a più trattamenti
  • Definizione poco dettagliata delle minacce e della relativa probabilità di accadimento
  • Definizione troppo deterministica delle misure di sicurezza da adottare per ogni livello di rischio, peraltro piuttosto severe per una PMI (solo modello ENISA)
  • Determinazione del rischio in base ad una matrice di rischio asimmetrica (solo modello ENISA).



Il Metodo VERA

Il primo passo, supportato dal relativo foglio Excel, prevede la valutazione delle minacce (ne sono state individuate 42) in termini di probabilità di accadimento (da 1 a 5) e di attributo R I D su cui impattano.

Per ogni minaccia viene anche determinato se sussiste un rischio privacy afferente alle categorie: distruzione accidentale, distruzione illegale, perdita, modifica, divulgazione non autorizzata, accesso non autorizzato ai dati personali.

Parallelamente viene data una valutazione di adeguatezza per tutti i 114 controlli ISO 27001/27002 (in una scala da 1 a 4, stessi criteri del modello SMART). Conseguentemente il valore della vulnerabilità viene definito come pari a 5 – valore di adeguatezza del controllo (come nel caso precedente).

La vulnerabilità di ogni controllo viene moltiplicata per il valore base di ogni rischio per ogni minaccia. Quest’ultimo è calcolato come il valore massimo dell’impatto dei valori R I D (applicabili alla minaccia) per la relativa probabilità di accadimento della minaccia ovvero

Base di rischio = verosimiglianza minaccia x valore dato personale (il parametro RID con impatti sulla minaccia e valore più alto)

Quindi:

Rischio (per ogni minaccia e controllo) = Base di rischio x vulnerabilità

(“inverso” del valore del controllo)

Si consideri che non tutte le celle all’incrocio fra controlli e minacce sono valorizzate, in quanto alcune sono ritenute non applicabili a determinati controlli.

Nel foglio specifico “Rischio Privacy”, per ogni minaccia viene prelevato solo il valore massimo per tutti I controlli (worst case). Dunque, volendo mitigare il rischio bisogna agire o sulla verosimiglianza (probabilità) della minaccia oppure sul controllo meno efficace (vulnerabilità maggiore).

Il tutto, naturalmente, va adeguatamente commentato e giustificato.

Questo metodo da un lato prevede una valutazione molto dettagliata sui controlli (sono esplicitati tutti i 114 controlli della ISO 27001), mentre la valutazione sui dati personali è fatta in modo globale, ovvero viene definito un valore per i parametri R/I/D valido per tutti i dati personali. Sicuramente se dovessero emergere rischi elevati, bisognerebbe scomporre la valutazione per diverse tipologie di dati personali trattati (es. dati del personale dipendente, dati dei clienti, dati dei fornitori e così via).

Dunque, è un metodo “controlli oriented”, non pienamente allineato alla metodologia suggerita (o solo intuita) dal GDPR, che prevede di partire dai trattamenti di dati personali e calcolare i rischi conseguenti. Valgono le stesse considerazioni evidenziate per il metodo ENISA ed il metodo SMART riguardo al focus sulla protezione dei dati e non su tutti i rischi per i diritti e le libertà dell’interessato.

Infine, per applicare questo modello occorre una buona conoscenza della norma ISO 27001 e della linea guida ISO 27002 sui controlli di sicurezza per poter valutare in modo ragionevolmente corretto tutti questi controlli.

Un approccio semplificato “risk oriented” alla valutazione del rischio

I rischi che incombono sui dati che sono identificati afferiscono alle seguenti categorie (conseguenze del danno):

  1. Perdita di riservatezza di dati personali;
  2. Perdita di riservatezza di dati particolari;
  3. Perdita di integrità dati particolari;
  4. Perdita di integrità dati personali;
  5. Indisponibilità temporanea di dati personali;
  6. Perdita (distruzione) di dati personali;
  7. Non ottemperanza al principio di liceità, correttezza e trasparenza del trattamento;
  8. Non ottemperanza al principio di minimizzazione e di limitazione del trattamento dei dati.

Dalle suddette categorie dipendono i rischi potenziali seguenti:

  1. Accessi non autorizzati a dati personali su supporto durevole da parte di personale interno;
  2. Accessi non autorizzati a dati personali su supporto durevole da parte di personale esterno;
  3. Accessi non autorizzati dati personali su supporto elettronico da parte di personale interno;
  4. Accessi non autorizzati a dati personali su supporto elettronico da parte di personale esterno;
  5. Malfunzionamento degli strumenti informatici con alterazione o perdita di dati;
  6. Malfunzionamenti degli impianti e dei servizi accessori con indisponibilità o perdita dei dati;
  7. Atti di criminalità informatica con rivelazione o perdita di dati;
  8. Atti di criminalità comune con rivelazione o perdita di dati;
  9. Eventi distruttivi (naturali, artificiali o dolosi) con perdita o indisponibilità temporanea di dati;
  10. Raccolta di dati eccedente la finalità del trattamento;
  11. Elaborazione di dati eccessiva rispetto alle finalità, consensi ottenuti, informative, tempi di conservazione e necessità;
  12. Impossibilità di garantire l’esercizio dei diritti dell’interessato.

Come si vede i vari rischi raggruppano una serie di eventi (ad es. tra gli eventi distruttivi naturali o artificiali vi sono terremoti, incendi, inondazioni, esplosioni, atti di terrorismo…) e l’accesso non autorizzato ai dati personali viene declinato sia per il formato dei dati (digitale o su supporto cartaceo o durevole per comprendere anche supporti plastici come badge, lastre di esami diagnostici, ecc.), sia per il fatto che l’accesso non consentito sia da parte di soggetti interni all’azienda o esterni, in quanto il livello di riservatezza richiesto può essere differente.

Di conseguenza gli eventi (minacce) che possono far sì che tali rischi si concretizzino sono stati identificati nei seguenti:

  • sottrazione di credenziali di autenticazione da parte di personale interno;
  • sottrazione di credenziali di autenticazione da parte di personale interno;
  • attacchi informatici diretti da parte di malintenzionati (es. ransomware, phishing);
  • furti, rapine ed altri eventi malavitosi;
  • comportamenti sleali o fraudolenti di personale interno;
  • comportamenti sleali o fraudolenti di personale esterno;
  • disastri naturali ed artificiali (alluvioni, inondazioni, terremoti, incendi, ecc.)
  • azione di malware non finalizzato;
  • intercettazione di informazioni in rete;
  • guasto ai sistemi ed impianti complementari (impianto elettrico, climatizzazione, ecc.)
  • malfunzionamento dei sistemi informatici gestionali e dei software applicativi;
  • inadeguatezza della gestione dei dati personali da parte dei software applicativi e gestionali;
  • guasti o malfunzionamenti hardware;
  • perdita di dispositivi portatili;

Tali minacce possono concretizzarsi in rischi nel caso in cui incontrino una vulnerabilità nelle misure tecniche ed organizzative di protezione e prevenzione adottate dall’azienda, in particolare:

  • carenza di consapevolezza da parte degli operatori;
  • disattenzione o incuria da parte degli operatori;
  • carenza di conoscenza dei principi del Regolamento UE 679/2016 da parte del personale;
  • errore materiale da parte degli operatori;
  • inadeguatezza o errata configurazione degli applicativi di protezione software (antimalware, firewall,…);
  • inadeguatezza/obsolescenza/malfunzionamento o errata configurazione delle protezioni hardware (firewall hardware, router, WLAN, IDS,…);
  • inadeguata configurazione del controllo degli accessi logici ai dati
  • errata gestione (configurazione, utilizzo) dei dispositivi portatili;
  • errata gestione del controllo degli accessi all’azienda;
  • inefficacia delle misure di sicurezza fisica (controllo accessi, ecc.);
  • inefficacia dei sistemi di prevenzione incendi;
  • inefficacia dei sistemi di sicurezza fisica (antifurto, porte, armadi chiusi a chiave, ecc.);
  • inefficacia dei sistemi di protezione da calamità naturali;
  • accessi da parte di esterni non autorizzati (errata applicazione delle regole di accesso fisico al sito);
  • insufficiente sorveglianza di strumenti contenenti dati;
  • mancata cifratura di dati accessibili a terzi;
  • mancata pseudonimizzazione di dati particolari;
  • errori umani nella gestione della sicurezza fisica;
  • procedure organizzative inadeguate.

A titolo di esempio in Figura sotto sono rappresentati graficamente le minacce, le vulnerabilità ed i rischi legati ad un attacco informatico tipo ransomware (es. Cryptolocker, wannacry, ecc.). 

In sostanza si fa un’analisi delle minacce e delle vulnerabilità e poi si fa una valutazione dei rischi ponderata sui rischi potenziali indicati nell’elenco numerato sopra riportato.

Partendo dall’approccio basato sull’identificazione dei rischi privacy che incombono sui dati personali sopra esposto si può procedere al calcolo del rischio come segue.

Ad ogni rischio (minaccia) identificato può essere associato un impatto su ogni trattamento di dati personali (ad es. in una scala da 0 a 3), oppure, semplificando ad ogni categoria di interessato di cui sono trattati i dati personali (es. clienti, fornitori, dipendenti, terzi). Evidentemente per ognuna di tali categorie va considerato il caso peggiore, ovvero la categoria di dati personali più sensibile (dati relativi alla salute, dati economico-finanziari, dati relativi alla religione, piuttosto che dati anagrafici comuni).

A questo punto viene stabilita, sempre per ogni rischio, la gravità delle conseguenze nel caso in cui il rischio si concretizzi, in una scala da 1 (impatto trascurabile) a 5 (impatto critico). Naturalmente a fronte ad es. di un accesso non autorizzato a dati personali di un dipendente da parte di personale interno oppure esterno all’organizzazione occorre considerare il caso peggiore di tutti gli effetti possibili (es. furto di identità).

Successivamente, per ogni rischio, va determinata la probabilità di accadimento – sempre in una scala da 1 (molto bassa) a 5 (molto alta). Quindi con la classica formula R = P x G si ottiene il calcolo del livello di rischio. I valori ottenuti – da 1 a 25 – saranno poi suddivisi in fasce per stabilire, secondo criteri definiti in una matrice di rischio, quali rischi saranno di livello Basso, Medio oppure Alto. Oltre una certa soglia di rischio andranno poi intraprese azioni di trattamento del rischio come indicato in precedenza.

In questo modello, semplificato, prevede che le misure di sicurezza siano ricomprese nella determinazione della Gravità dell’impatto (Misure di Protezione) e della relativa Probabilità (Misure di Prevenzione). In pratica il ragionamento è il seguente: la probabilità di subire un attacco ransomware non viene determinata in modo assoluto (è molto probabile che un attacco ransomware si verifichi), ma in funzione delle misure di sicurezza implementate; per cui si definirà la probabilità che un attacco ransomware abbia successo nonostante le misure di prevenzione attuate (antimalware, sistemi anti ransomware specifici, firewall, formazione del personale per sensibilizzarlo a comportamenti prudenti). La corrispondente gravità sarà determinata considerando le misure di protezione attuate, ad es. la disponibilità di un backup giornaliero cifrato scollegato dal sistema centralizzato.

Volendo mantenere separati gli effetti delle misure di sicurezza dalla probabilità e dalla gravità di un rischio si potrebbe calcolare i valori di probabilità e gravità considerandoli in assoluto, a prescindere dalle misure di prevenzione e protezione adottate, come nei metodi precedentemente illustrati. In tal caso l’effetto di mitigazione delle misure di sicurezza sul rischio potenziale sarebbe definito attraverso un terzo parametro M, che rappresenta l’efficacia delle misure di sicurezza, espressa in una scala da 1 (Misure molto efficaci) a 5 (Nessuna misura di sicurezza). Il valore per il Livello di Rischio (o indice di rischio) verrà dunque calcolato nel modo seguente:

LR = P x G x M (Probabilità x Gravità x Efficacia delle Misure di Sicurezza)

La scala del rischio sarà conseguentemente da 1 a 125.

In alternativa l’efficacia delle misure di sicurezza potrebbe essere considerata come un fattore di mitigazione del rischio definito dal prodotto P x G, sulla falsariga del modello SMART. Quindi, anziché definire una scala da 1 a 5 per il parametro M, si potrebbe definire una scala di valori del tipo 0.2, 0.4, 0.6….1; ovvero si inverte la scala dell’efficacia delle misure di sicurezza (1 sta per “Nessuna misura”, 5 sta per “Misure molto efficaci”) e si trasforma la formula precedente nella seguente LR = P x G / M.

Conclusioni

Naturalmente possono essere elaborate diverse variazioni sul tema e altri metodi di calcolo del rischio privacy (ad es. mutuandoli dalla metodologia FMEA); il limite è probabilmente solo la fantasia dell’autore del nuovo modello. L’importante è restare legati ad una base normativa standard (ISO 31000 per il processo di valutazione del rischio, Linee Guida ENISA o altre Linee Guida per il calcolo del rischio) e definire una formula corretta per il calcolo del rischio. Alcuni, infatti, anziché moltiplicare i contributi di Gravità, Probabilità e Misure di sicurezza (Controlli) li sommano e ciò non è propriamente corretto.

Diversi applicativi software per la gestione della privacy e dei sistemi per la gestione delle informazioni ISO 27001 hanno implementato un sistema di valutazione dei rischi più o meno articolato e, dunque, possono soddisfare allo scopo.

Riferimenti

  1. ENISA – Manuale sulla Sicurezza nel trattamento dei dati personali (dicembre 2017) – § 2 Valutazione del rischio e misure di sicurezza per i dati personali
  2. Manuale RPD – Compito 3: Valutazione dei rischi posti dalle attività di trattamento di dati personali
  3. VERA 5.0 https://www.cesaregallotti.it/Pubblicazioni.html
  4. Metodologia Smart 1.0 https://it.linkedin.com/pulse/strumenti-disponibili-per-la-valutazione-dei-rischi-stefano-posti



Commenti alle nuove Linee Guida del Garante Privacy sui cookie

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Misure di sicurezza di un’applicazione web per essere conformi al GDPR

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

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

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

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



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

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

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

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

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

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

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

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




Come gestire il Responsabile del trattamento ai sensi del GDPR

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

crop businessman signing contract in office

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



Il considerando 81 introduce il ruolo del Responsabile del Trattamento:

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

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

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

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

Spesso si è trascurato il fatto che il titolare

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

crop businessman signing contract in office

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Audit da remoto ai tempi del Covid-19

Dopo l’introduzione – da parte di ACCREDIA su indicazioni IAF (si veda il documento IAF ID03 “Management of Extraordinary Events or Circumstances Affecting  ABs”,  CABs  and  Certified  Organization e la circolare ACCREDIA DC 02/2020) – della modalità di effettuazione degli audit a distanza legati alla certificazione dei sistemi di gestione, il recente articolo L’AUDIT A DISTANZA. CONSIDERAZIONI GENERALI, MODALITÀ DI GESTIONE E SPUNTI  OPERATIVI pubblicato sul sito ACCREDIA, fornisce alcuni spunti di riflessione sulle modalità operative di gestione degli audit da remoto che gli Organismi di Certificazione (OdC) hanno iniziato a svolgere per mantenere il ritmo delle attività di sorveglianza e rinnovo delle certificazioni dei sistemi di gestione.

L’attività di auditing ha evidentemente un discreto impatto sui contatti interpersonali: interviste a varie persone, consultazione di documenti cartacei, visualizzazione di documenti digitali e siti internet, visione di reparti produttivi, ecc..

Per non bloccare per molto tempo queste attività, soprattutto in questa Fase 2 dell’emergenza Coronavirus nella quale quasi tutte le attività produttive sono riprese, anche se molte persone continuano giustamente a lavorare in smartworking, gli audit in campo sarebbero comunque difficili da condurre nel rispetto dei vari protocolli aziendali che prevedono misure molto rigide nei confronti dei fornitori che potrebbero avere accesso all’azienda, compresi i consulenti e gli auditor degli OdC. Sebbene le regole applicate siano molto disomogenee e i protocolli approvati dal Governo siano oggi esagerati se applicati a singole persone che accedono ai locali aziendali, quali auditor e consulenti, l’approccio degli OdC sembra sia fortemente orientato a svolgere comunque gli audit pianificati con le modalità “a distanza”, come previsto da ACCREDIA.

L’articolo sopra menzionato – sebbene non costituisca una regola da seguire da parte degli OdC – fornisce molti interessanti spunti di riflessione per comprendere se svolgere gli audit a distanza, quando svolgerli e come svolgerli.

Questa opportunità, commercialmente molto favorevole per gli OdC che altrimenti si vedrebbero bloccate le attività ed i conseguenti ricavi per diverso tempo, dovrebbe essere sfruttata cum grano salis, effettuando preliminarmente una valutazione dei rischi basata su diversi elementi, che comprendono la tipologia dell’organizzazione auditata, il tipo di verifica, la norma di riferimento, la complessità dell’organizzazione e del suo sistema di gestione, ecc.

Il rischio che si corre nell’attuare questa nuova modalità è quello di non svolgere un audit efficace, ovvero di effettuare delle valutazioni non sufficientemente esaustive e corrette, ovviamente a tutto “vantaggio” dell’organizzazione auditata che si vedrebbe così ad essere certificata, ovvero a continuare ad esserlo, con una certa facilità.

L’analogia con la Didattica a Distanza (DAD) è pienamente calzante: come la verifica delle competenze degli alunni deve cambiare modalità per garantire un giusto livello di severità della scuola, così devono cambiare le modalità di raccolta e valutazione delle evidenze dell’audit.

Il rischio vero, però, è quello di sminuire ulteriormente un settore (quello delle certificazioni del sistema di gestione) che già ha perso molta credibilità a causa di audit troppo soft.

Certe tecniche estremamente efficaci utilizzate negli audit degli anni novanta, e non sempre riprese nel corso degli anni 2000, potrebbero non essere applicabili negli audit a distanza. Ad esempio prendere un DDT a caso di un prodotto in fase di spedizione e ripercorrere tutta la vita del prodotto “all’indietro”, ovvero richiedere evidenza dei controlli di produzione, dei controlli sulla materia prima, dei controlli sulle lavorazioni esterne, della qualifica dei relativi fornitori, degli ordini/contratti con i fornitori, della gestione dell’ordine del cliente (e relativi termini di consegna), dell’offerta e magari anche della progettazione del prodotto, se applicabile. Oppure scegliere a caso una commessa, un ordine o un prodotto e poi verificare tutti gli annessi e connessi.

Anzitutto bisognerebbe stabilire con precisione modalità e mezzi di conduzione di un audit a distanza. Ad esempio, quale piattaforma collaborativa utilizzare: quella stabilita dall’OdC o quella utilizzata dal cliente/organizzazione. La scelta non può essere dettata dal caso o dall’auditor di turno, spesso un consulente esterno, che magari sceglie a sua discrezione una piattaforma che conosce meglio. Infatti, nel corso dell’audit possono transitare anche informazioni di una certa riservatezza e l’impiego di una piattaforma che garantisca adeguate misure di sicurezza e rispetto per la privacy dei dati personali usata in modo corretto è sicuramente un requisito necessario. Recentemente si sono verificate violazioni di dati su piattaforme molto diffuse e, inoltre, la conservazione dei dati in cloud ubicati fuori UE non garantisce sempre il rispetto del Regolamento UE 679/2016 (GDPR).

Dato che l’audit è svolto sotto la responsabilità dell’OdC è il medesimo a dover assicurare la sicurezza dei dati che vengono trasmessi dall’organizzazione, la quale potrebbe avere qualcosa da obiettare nel fornire direttamente su file alcune informazioni riservate: un conto è far visionare un’offerta commerciale ad un auditor che viene presso la mia sede e che neanche volendo riuscirebbe a ricordarsi i dettagli una volta uscito dall’azienda, un conto è fornire direttamente all’auditor il file completo dell’offerta con prezzi, codici di articoli, modalità di fornitura, ecc. Se anche solo per superficialità o per inadeguatezza delle misure di sicurezza del notebook dell’auditor la stessa offerta finisse nelle mani di un concorrente quali sarebbero le conseguenze? Normalmente gli auditor esterni all’Ente di Certificazione utilizzano propri notebook, non controllati dall’OdC stesso, che vengono portati in viaggio e possono essere smarriti o rubati…. dovrebbero avere tutti gli hard disk cifrati.

Probabilmente sarebbe opportuno che certi documenti contenenti informazioni più riservate (o comunque classificati) non siano trasmessi dall’organizzazione auditata all’auditor via e-mail o condivisi attraverso la piattaforma di comunicazione, ma semplicemente visualizzati condividendo uno schermo, come tutti i software di videoconferenza consentono, da Microsoft Teams a Google Meet, da Skyoe a GoToMeeting, a Webex, ecc.

Alcune informazioni raccolte dall’auditor sono contenute in documenti digitali (es. verbali di riesame della direzione, rapporti di audit interni, procedure, ecc.) altri sono invece reperibili da un sistema informatico, dunque si può tranquillamente prevedere la condivisione dello schermo da parte di un responsabile dell’organizzazione che apre un sistema gestionale e mostra – esattamente come farebbe durante un audit in presenza – gli ordini del cliente, gli ordini di produzione, la pianificazione della produzione, i controlli eseguiti, ecc.. In questo modo l’auditor può mantenere il controllo dell’audit e farsi mostrare l’elenco di tutti gli ordini o commesse e scegliere autonomamente quella/a da visionare. In molte realtà aziendali il sistema gestionale produce offerte, conferme d’ordine del cliente, ordini di acquisto, ordini di produzione ed altro già in formato pdf pronto da essere stampato per i reparti interni o per essere trasmesso via e-mail al cliente o al fornitore, dunque trasmettere o semplicemente visualizzare nella video-riunione (per i motivi di riservatezza di cui sopra) questi documenti all’auditor dovrebbe essere molto semplice.

Le classiche riunioni di apertura e chiusura e le interviste a responsabili normalmente svolte negli uffici possono essere tranquillamente condotte in conference call con il supporto della condivisione dello schermo per visionare documenti in formato digitale oppure documenti cartacei opportunamente scansionati al momento, ma come svolgere le verifiche nei reparti produttivi?

La valenza di un audit in un’azienda manifatturiera è fortemente in dubbio: l’audit della produzione è praticamente obbligatorio in tutte le aziende produttive e potrebbe essere condotto efficacemente solo in certe realtà, connettendosi a terminali dell’ufficio produzione e controllo qualità, ma anche attraverso smartphone connessi con la videocamera accesa per poter visionare i reparti produttivi, intervistare operatori in produzione, raccogliere evidenze di strumenti utilizzati, macchine di produzione, materiale immagazzinato e così via. È evidente che l’azienda potrebbe “guidare” l’audit un po’ più del solito rispetto all’audit in presenza.

Uno degli elementi che ACCREDIA invita a considerare nella valutazione del rischio sulla conduzione dell’audit è costituito dalla conoscenza dell’organizzazione da parte dell’auditor: naturalmente un auditor che ha visitato già l’azienda due o tre volte è in grado di valutare anche da remoto cosa è opportuno visionare e cosa no. Nelle indicazioni di ACCREDIA si invita gli OdC a visionare anche i layout/planimetrie degli stabilimenti dell’organizzazione per decidere quali reparti sarebbe opportuno visionare, se sono stati visionati in passato e così via.

Il documento IAF MD4:2018 (IAF MANDATORY DOCUMENT FOR THE USE OF INFORMATION AND COMMUNICATION TECHNOLOGY FOR AUDITING/ASSESSMENT PURPOSES) costituisce la guida per gli OdC per la conduzione degli audit da remoto, così come la circolare ACCREDIA e il documento IAF ID03, ma poiché permangono molti dubbi sull’applicabilità di questa modalità in diversi contesti sono state pubblicate anche delle FAQ sul sito IAF (https://iaffaq.com/).

Certamente permangono alcune perplessità sull’applicazione degli audit a distanza nella verifica di sistemi di gestione ISO 14001, ISO 27001 e altri, piuttosto che di sistemi ISO 9001. Oltre che all’applicabilità ad aziende di produzione, imprese di costruzione, installatori e manutentori di impianti, società di ingegneria con direzioni lavori.

Infine, resta da valutare la competenza dell’auditor nel gestire le tecnologie utilizzate per la conduzione dell’audit a distanza ed eventualmente a colmarle.

Sicuramente l’audit a distanza o da remoto è una grossa opportunità per mantenere la continuità operativa degli Organismi di Certificazione e di tutto il mondo delle certificazioni e dell’accreditamento (anche ACCREDIA ha attuato gli audit da remoto), contenendo anche i costi di spostamento degli auditor, ma è importante mantenere alta l’attenzione affinché questa metodologia non riduca l’audit di certificazione ad una mera formalità, minacciando l’attendibilità di tutto il sistema delle certificazioni.