In quest’articolo andremo a commentare le nuove revisioni delle due più importanti norme della famiglia ISO 27k, avvenute nel corso del 2022:

• ISO/IEC 27001:2022 – Information security, cybersecurity and privacy protection — Information security management systems — Requirements
• ISO IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls

La seconda è stata anche pubblicata dall’UNI con il prefisso UNI CEI EN alcuni mesi fa, ma di fatto l’Ente di Normazione Italiano si è astenuto dal tradurre le 170 pagine di norma, limitandosi alla traduzione del titolo (“Sicurezza delle informazioni, cybersecurity e protezione della privacy – Controlli di sicurezza delle informazioni”) e poco più, lasciando molti delusi visto che la precedente versione era stata tradotta. Ora ci si aspetta la pubblicazione della UNI CEI EN ISO 27001 con traduzione in italiano che dovrebbe costare pochi sforzi viste le limitate differenze rispetto alla versione precedente e le similitudini con altre norme con struttura HLS. Aspettative che non dovrebbero andare eluse visto che la ISO 27001 è anche una norma certificabile.

Le modifiche alla ISO 27001, oltre al recepimento dei “corriggendum” della precedente versione della norma e l’allineamento alla struttura HLS delle altre norme sui sistemi di gestione, sono veramente minime. I cambiamenti che hanno un impatto sui sistemi di gestione della sicurezza delle informazioni (SGSI) sono sostanzialmente:

• Definire quali requisiti delle parti interessate saranno affrontate nel SGSI (punto 4.2)
• Esplicitazione dei processi necessari al sistema di gestione (punto 4.4)
•  Pianificazione dei cambiamenti – al punto 6.3, completamente nuovo – in piena analogia con le altre norme sui sistemi di gestione
• Al punto 7.4 deve essere stabilito “come si deve comunicare”, ma i sottopunti d) ed e) precedenti eliminati non dicevano cose tanto diverse
• I riferimenti ai controlli di sicurezza al punto 6.1.3 e nell’Annex A.

Proprio quest’ultimo è il cambiamento più significativo della norma in quanto stabilisce che l’elenco dei controlli dell’Annex A (e della ISO 27002) sono solo una possibile lista di controlli di sicurezza sulla quale basare il SGSI e la Dichiarazione di Applicabilità (S.o.A.).

Poiché, salvo alcune realtà particolari, non credo che la gran parte delle organizzazioni si rivolga a framework diversi da quello proposto dalla ISO 27002, direi che è proprio questa norma che apporta modifiche sostanziali al SGSI.

Dunque, i controlli della ISO 27001, che sono diventati 93 (dai 114 precedenti) restano i capisaldi della SoA e per ognuno di essi si dovrà esplicitare le eventuali motivazioni di non applicabilità e le motivazioni di applicabilità (requisiti cogenti, requisiti contrattuali o di business, esigenza derivante dalla valutazione del rischio…).

La ISO 27002, oltre ad essere stata modificata – in parte – nei contenuti dei controlli di sicurezza, è anche stata completamente cambiata nella sua struttura che risulta semplificata.

Ora, infatti, i controlli sono suddivisi in 4 (macro) temi:

• controlli organizzativi (37 controlli);
• controlli sulle persone (8 controlli);
• controlli fisici (14 controlli);
• controlli tecnologici (34 controlli)-

Anche se la maggior parte dei controlli sono classificati come “organizzativi”, fra di essi vi sono molti controlli di forte caratterizzazione tecnologica ed ICT, ad esempio:

• A.5.7    Threat intelligence (Monitoraggio delle minacce)
• A.5.11  Return of assets (Restituzione degli asset)
• A.5.15  Access control (Controllo degli accessi)
• A.5.16  Identity management (Gestione delle identità)
• A.5.17  Authentication information (Informazioni di autenticazione)
• A.5.21  Managing information security in the information and communication technology (ICT) supply-chain (Sicurezza delle informazioni nella filiera di fornitura ICT)
• A.5.23  Information security for use of cloud services (Sicurezza delle informazioni per l’uso dei servizi cloud)
• ….

Appare evidente che non solo alcuni controlli riguardano, nella stragrande maggioranza di casi, “oggetti” ICT (A.5.11: per lo più si restituiscono dispositivi elettronici, A.5.17: stiamo parlando di username e password…), ma alcuni riguardano proprio solamente informazioni in formato digitale (A.5.23). Evidentemente l’Ente normatore (ovvero il Gruppo di lavoro che ha preparato la norma) ha inteso enfatizzare la componente “gestionale” di tali controlli.

Per analogia con le “misure di sicurezza tecniche ed organizzative” richieste dal GDPR si dovrebbe – ad esempio – comprendere il “controllo degli accessi (logici)” fra le misure di sicurezza organizzative e così via.

Al di là della numerosità dei controlli nelle 4 tematiche, è interessante la suddivisione dei controlli tenendo chiaramente separati i controlli relativi alla sicurezza fisica ed ambientale, dai controlli che mettono al centro il fattore umano, dai controlli organizzativi a quelli legati alla sicurezza informatica.

Dal pinto di vista contenutistico i cambiamenti nei controlli possono essere così riassunti

• 11 nuovi controlli
• 35 invariati
• 24 accorpati da controlli esistenti
• 58 aggiornati.

In realtà se andiamo a leggere con attenzione i 93-11= 82 controlli che non sono “nuovi” troviamo molte novità, non solo dovute ad aggiornamenti tecnologici e dello stato dell’arte della cybersecurity e della data protection. Pertanto, in fase di transizione dei SGSI esistenti occorre fare molta attenzione anche ai controlli i cui contenuti non sono apparentemente variati.

Altre novità interessanti della norma riguardano la terminologia e l’introduzione degli attributi.

La norma, infatti, riporta un ampio spettro di termini, definizioni e glossario di abbreviazioni che integrano i contenuti della ISO 27000. Peccato che sia mancata la traduzione nella nostra lingua.

Ma la novità forse più rilevante è stata l’introduzione di una serie di attributi associati ad ogni controllo, una sorta di tag o metadati che caratterizzano i controlli stessi.

Ogni controllo viene caratterizzato, infatti, dai seguenti attributi:

• Tipo di Controllo: Preventivo, di Monitoraggio (detective) o Correttivo
• Proprietà: Riservatezza, Integrità, Disponibilità
• Cybersecurity concepts: Identify, Protect, Detect, Respond, Recover
• Operational capabilities: Governance, Asset management, Information protection, Human resource security, Physical security, System and network security, Application security, Secure configuration, Identity and access management, Threat and vulnerability management,         Continuity, Supplier relationships security, Legal and compliance, Information security event management, Information security assurance
• Security domains: Governance and Ecosystem, Protection, Defense, Resilience.

Quindi, a parte le Proprietà dei Controlli (Confidentiality, Integrity e Availability in inglese) che costituiscono una mezza novità in quanto le stesse proprietà della Sicurezza delle Informazioni sono note da tempo, ma non erano state ufficialmente associate ai controlli, gli altri attributi costituiscono una grossa novità della norma al fine di classificare/categorizzare i controlli.

A fini puramente statistici possiamo notare che i controlli sono classificati in 83 Preventivi, 13 di Monitoraggio (Detective) e 14 Correttivi, da cui appare chiaro che ogni controllo può essere classificato in più di un solo tipo. Emerge anche il fatto che prevale l’ottica di prevenzione degli incidenti e delle violazioni di sicurezza. Ci si aspetterebbe che i controlli preventivi siano focalizzati alla riduzione della probabilità che una minaccia si concretizzi in un rischio di sicurezza delle informazioni, ad esempio attraverso l’eliminazione di vulnerabilità. Per i controlli classificati come Detective (o di monitoraggio) ci si aspetterebbe un indicatore di monitoraggio dell’efficacia delle misure di sicurezza adottate.

Più equilibrio c’è sulle proprietà dei controlli (R I D) dove si hanno 87 controlli che impattano la Riservatezza, 84 l’Integrità, 85 la Disponibilità: dunque sono pochi i controlli che non mirano a tutelare tutte e tre le Proprietà di sicurezza dell’informazione.

Curiosamente l’attributo Physical Security del gruppo di attributi “Operational capabilities” comprende 16 controlli di cui 2 non appartenenti al tema dei “controlli fisici”: “Procedure operative documentate” e “Lavoro da remoto”. Naturalmente ciò si giustifica per il fatto che devono essere presenti procedure documentate sui controlli fisici e che il lavoro da remoto (lavoro agile e/o smartworking) comprende aspetti che riguardano i controlli fisici (dove svolgo il lavoro da remoto? Come proteggo la postazione di lavoro da accessi fisici non autorizzati?).

Lasciando da parte queste statistiche sulla classificazione dei controlli nei vari attributi, la cui importanza ed utilità probabilmente si evidenzierà nelle fasi applicative della norma, veniamo ad esaminare alcuni aspetti pratici.

Cosa deve fare un’organizzazione certificata ISO 27001 per migrare alla nuova versione della norma?

Come anticipato le modifiche alla ISO 27001 sono davvero poco significative e il grosso del lavoro riguarderà i controlli dell’Annex A ovvero della ISO 27002:2022.

Sono reperibili, anche nella norma ISO 27002:2022 stessa, delle tabelle di conversione tra i vecchi controlli (114) ai nuovi controlli (93). Alcuni esperti consigliano di partire da qui per “convertire” la vecchia S.o.A. nella nuova S.o.A., cercando di coprire i nuovi controlli.

Questo approccio è valido nella maggior parte dei casi e ci permette di fare una gap analysis che comunque sarà richiesta anche dagli enti di certificazione nell’eventuale audit di sorveglianza 2024 laddove l’organizzazione non sia già pronta per la migrazione alla nuova norma.

È comunque opportuno valutare se non sia il caso di ristrutturare completamente il sistema di gestione della sicurezza delle informazioni, partendo dalla valutazione dei rischi. Questo requisito, infatti, è stato rielaborato dalla norma ISO 27005:2022 che ora considera due diversi approcci e molti esperti ritengono che modelli di risk assessment diversi da quello proposto dalla linea guida ISO 27005 siano migliori, perché più snelli e più facilmente applicabili nelle nostre imprese.

Dunque, si potrebbe passare dall’approccio classico, basato su asset – minacce – vulnerabilità – probabilità – gravità, ad un approccio basato sugli scenari o solo sulle vulnerabilità, intese come assenza o inefficacia dei controlli. Al proposito si segnala la disponibilità del tool gratuito VERA di Cesare Gallotti per la valutazione dei rischi ISO 27001:2022.

Dopo la valutazione dei rischi occorre riprogettare la S.o.A., evidentemente riconsiderando solamente i documenti che descrivono l’implementazione dei vari controlli di sicurezza.

Se le policy di sicurezza e le istruzioni operative relative ai controlli erano legate alla vecchia nomenclatura dei controlli sarebbe opportuno modificare la struttura del SGSI.

Se esiste un Manuale del Sistema di Gestione (che magari copre anche altre normative, ISO 9001, ISO 14001…)  si potrebbe partire da esso per richiamare i documenti di secondo livello del SGSI, ovvero le policy o le procedure. Esse dovrebbero riportare la descrizione dei processi e delle policy di sicurezza nei vari ambiti (controlli relativi alle persone, controlli di sicurezza fisica, controllo degli accessi logici, protezione dal malware, continuità operativa, gestione relazioni con i fornitori, ecc.), comprendenti le responsabilità ed i principi generali di scurezza delle informazioni.

Tali procedure potrebbero poi richiamare delle istruzioni operative di dettaglio che descrivono le modalità operative di attuazione dei controlli, richiamando eventuali documenti di consultazione, database o prospetti consultabili da sistema informatico (applicativi, funzioni del sistema operativo, tabelle Excel o Word, ecc.).

Procedure/policy ed istruzioni operative dovrebbero poi essere richiamate nella Dichiarazione di Applicabilità (SoA) in corrispondenza dei vari controlli.

Non è efficiente predisporre una procedura o una istruzione per ogni controllo della ISO 27002, ma determinate procedure potrebbero comprendere più controlli assimilabili ad una medesima attività.

Chiaramente esisteranno documenti prodotti ed aggiornati periodicamente che dovranno rispondere ad uno o più controlli nella SoA, ad es. il Business Continuity Plan.

Una struttura con dettagli crescenti a partire dal vertice della cosiddetta “Piramide della Documentazione”, nota nei sistemi qualità da alcuni lustri, costituito dal Manuale del Sistema di Gestione, favoriscono anche una classificazione dei documenti del SGSI. Infatti Manuale e Procedure/Policy avranno un livello di astrazione tale da poterli trasmettere anche all’esterno a clienti e partner che lo richiedono, mentre le istruzioni operative ed i documenti ad essa allegati o richiamati – quali ad esempio l’elenco degli asset informatici, la mappa della rete, l’elenco degli utenti con le relative autorizzazioni, le configurazioni ICT, ecc. – dovrebbero essere classificati come documenti riservati, accessibili, anche internamente, ad un numero limitato di persone.

Naturalmente, come avviene per qualunque sistema di gestione ed a maggior ragione per i SGSI, la struttura modulare della documentazione deve essere progettata in modo che le modifiche più frequenti ai documenti riguardino un piccolo insieme di documenti a livello più basso nella Piramide della Documentazione, in quanto si tratta dei documenti di maggior dettaglio.

Per quelle organizzazioni che dispongono anche di una certificazione ISO 27017 e/o ISO 27018 la cattiva notizia è che i controlli di queste normative saranno allineati successivamente alla ISO 27002:2022, dunque, in attesa che ciò avvenga, bisogna cercare di barcamenarsi alla meglio fra nuovi e vecchi controlli e ciò non sarà poco complicato.

Infine, per chi si approccia con questa nuova versione della norma alla progettazione di un nuovo SGSI il consiglio è quello di non farsi condizionare dall’approccio minimalista della documentazione dei sistemi qualità ISO 9001 di questi tempi: nel SGSI ISO 27001 è necessario documentare molto di più, soprattutto gli aspetti di dettaglio; non solo perché sono richiesti dagli Organismi di Certificazione, ma anche perché per una gestione interna efficace ed efficiente solo mantenendo un elevato livello di documentazione delle attività operative – soprattutto quelle in ambito ICT – si riesce a mantenere il controllo delle stesse a fronte di cambiamenti di tecnologie e di persone e a garantire l’accountability del sistema, anche lato privacy (il GDPR docet).

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.

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

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

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

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

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

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

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

Ma andiamo ad esaminare le due principali tipologie di questionari:

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

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

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

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

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

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

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

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

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

Passiamo al questionario sulla Privacy e/o sulla Cybersecurity.

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

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

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

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

Poi ci sono le misure di sicurezza.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Da ultimo restano due aspetti da considerare:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quindi oggi il quadro è il seguente:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Download non trovato]

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

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

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

Il Registro del Responsabile, invece, contiene:

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

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

Alcuni punti fermi sono i seguenti;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Il GDPR è divenuto pienamente attuativo dal 25 maggio scorso, anche se in realtà era stato pubblicato due anni prima, però il processo di adeguamento delle imprese italiane al GDPR è ancora in corso. Questo perché da un lato, come è consuetudine nel nostro Paese, le Imprese affrontano le scadenze legislative solo all’ultimo momento, non preoccupandosi di capire prima quanto tempo è necessario per l’adeguamento legislativo. Dall’altro anche le Istituzioni (Stato Italiano e Garante Privacy) stanno impiegando molto più tempo del previsto per rendere completo, ed auspicabilmente di chiara interpretazione, il panorama legislativo in materia di protezione dei dati personali.

Il fatto che molti punti del GDPR non sono di facile interpretazione e, anzi, gli approcci sono talvolta differenti, non ha fatto altro che rallentare il percorso di adeguamento.

Tra gli effetti collaterali di questo lento percorso di adeguamento c’è la difficoltà di interfacciarsi con i soggetti esterni all’impresa o allo studio professionale, perché il mondo perfetto in cui i miei clienti ed i miei fornitori sono già adeguati al GDPR – e lo hanno interpretato in modo uniforme – al momento non esiste, e non si sa quando ci si arriverà.

Passiamo ad esaminare le principali problematiche – e possibili soluzioni – delle prime applicazioni del GDPR in organizzazioni di diverso tipo e dimensioni.

1) Informative e consensi

L’informativa è lo specchietto delle allodole della nuova normativa sulla privacy; non bisogna credere che basta trovare un modello di informativa, magari gratuitamente dal web o da amici e colleghi, per aver risolto il problema privacy: uno su mille ce la fa! Solo pochi singoli (ditte individuali, professionisti singoli) senza dipendenti possono accontentarsi della nuova informativa.

Inoltre, l’informativa ha un contenuto che non può essere redatto in modo completo solo partendo da un modello standard e conoscendo l’art. 13 (e seguenti) del Regolamento UE 679/2016; occorre conoscere come funzionano i flussi di trattamento dei dati personali nell’organizzazione. Magari attraverso un’assessment ed una gap analysis approfondita, soprattutto nelle organizzazioni più complesse.

Infine, c’è il problema di come comunicare l’informativa agli interessati. Occorre analizzare bene requisiti normativi, processi gestionali ed esigenze organizzative per scegliere le modalità più opportune. Probabilmente un’informativa pubblicata su una pagina web ed una e-mail ai clienti (effettivi e potenziali) e fornitori, che comunica l’aggiornamento dell’informativa privacy, reperibile al sito www…. è la soluzione migliore nella maggior parte delle organizzazioni, soprattutto se operano B2B.

2) Responsabili esterni del trattamento

Il GDPR ci dice di identificare i soggetti esterni all’organizzazione che trattano per “suo conto” dati personali e di designarli come responsabili del trattamento attraverso un atto a valenza contrattuale.

In primo luogo occorre stabilire quali fornitori (e non solo) operano come responsabili del trattamento perché trattano dati personali di cui l’organizzazione è titolare del trattamento: società e studi che forniscono servizi contabili e fiscali, società e studi che forniscono servizi di elaborazione buste paga e consulenza del lavoro, società che forniscono servizi informatici (servizi di assistenza sistemistica, fornitori di software gestionale ed applicativo, fornitori di servizi cloud, ecc.) sono solo alcuni candidati… occorre anche qui capire come si svolgono le varie attività internamente ed esternamente ed è necessario valutare l’affidabilità del fornitore in termini di garanzie relative alla protezione dei dati personali.

Per gestire correttamente questo punto bisogna essere in due ed essere d’accordo sulla nomina di responsabile del trattamento e sui relativi obblighi contrattuali del responsabile.

Questa attività di “regolarizzazione” dei responsabili del trattamento è spesso lunga e non priva di ostacoli, anche per l’inerzia dei fornitori in questione a rispondere a semplici questionari nei quali si va a chiedere loro quali misure di sicurezza sono state implementate al loro interno (ad es. nella gestione operativa dello studio e/o nel software). Se poi il fornitore non accetta la nomina a responsabile del trattamento (e dei relativi obblighi contrattuali) perché si sente titolare autonomo o semplice soggetto autorizzato a trattare dati personali, ecco che il processo di adeguamento al GDPR si complica enormemente. Se si prende spunto dai sistemi di gestione qualità ISO 9001 si comprende che i fornitori dovranno essere “qualificati” per fornire la nostra organizzazioni e situazioni nelle quali il fornitore tiene “in scacco” il cliente in tema di privacy sono da evitare.

3) Registro delle attività di trattamento

È un adempimento non solo formale (praticamente l’unico richiesto alla stragrande maggioranza delle organizzazioni), ma sostanziale: per redigere il registro dei trattamenti (del titolare e del responsabile) bisogna conoscere quali dati personali vengono trattati, in quali processi dell’organizzazione e con quali modalità. Anche in questo caso occorre un’analisi dei processi dell’organizzazione precisa e puntuale. Effetto collaterale di questa attività di mappatura dei flussi di dati dell’organizzazioni potrebbe essere quello, gradito, di individuare gestioni di dati ridondanti e inefficienti, da eliminare in prospettiva, non solo di privacy.

Ci sono diverse interpretazioni nella composizione del Registro dei trattamenti, francamente non credo che le diverse interpretazioni possano costituire un rischio di compliance del registro dei trattamenti a fronte di ispezioni del Garante, dato che in fondo non esistono linee guida chiare sulle corrette modalità di alimentazione dei registri dei trattamenti (le recenti FAQ del Garante in merito non aiutano più di tanto).

Un registro completo anche di informazioni non necessariamente richieste dal GDPR, ma utili nella gestione dei dati personali (es. software gestionali ed applicativi che trattano i dati personali, funzioni aziendali autorizzate a trattare i dati, ecc.) risulta utile per comprendere come sono gestiti i dati personali.

Da ultimo, per completare i registri dei trattamenti occorre sapere per quali attività di trattamento l’organizzazione è titolare del trattamento e per quali è solo responsabile: e ciò si lega alle problematiche del punto precedente, anche in senso opposto, relativamente ai ruoli di titolare e responsabile del trattamento, o magari di contitolare.

4) Misure di sicurezza tecniche ed organizzative

La definizione delle misure di sicurezza adeguate è uno dei punti più difficili del GDPR. Propedeutica a questa attività c’è la valutazione dei rischi che incombono sui dati personali e soprattutto sulle persone fisiche cui si riferiscono.

Al di là della criticità o meno dei trattamenti effettuati dalle diverse organizzazioni occorre stabilire un livello minimo di sicurezza nei sistemi di protezione dei dati personali, coerente con gli standard nazionali ed internazionali e le best practice di sicurezza informatica. Il problema è che non esistono più le misure minime di sicurezza stabilite per legge, anche se alcune di esse (non tutte) rimangono valide a livello di standard minimo di sicurezza sostenibile davanti ad un Giudice. Infatti, dobbiamo pensare al caso peggiore: l’ispezione del Nucleo Privacy della Guardia di Finanza (magari a seguito di un data breach) e le richieste di risarcimento danni di un interessato che si ritiene danneggiato da una violazione dei suoi dati personali.

Allora occorre documentare lo stato dei sistemi informatici con riferimento alle misure di sicurezza implementate e documentare anche le misure organizzative attuare. È il minimo per dimostrare l’accountability, ma può essere solo un punto di partenza se le misure implementate non sono convincenti per essere sostenute nei confronti di terzi.

Nelle PMI talvolta la gestione sistemistica dei sistemi informatici è delegata ad un soggetto esterno (singolo professionista o società di servizi informatici). In questi casi il titolare dei trattamenti come minimo dovrebbe pretendere una descrizione dettagliata delle logiche di funzionamento dei sistemi e delle misure di sicurezza implementate, ma spesso il fornitore è restio a documentare una prassi non completamente sicura, implicitamente accettata dalla Direzione aziendale che non intendeva sobbarcarsi ulteriori costi per rendere maggiormente sicuri i sistemi.

Una misura di sicurezza (organizzativa) è costituita proprio dalla disponibilità di relazioni e dichiarazioni scritte da parte del fornitore di servizi IT.

Tra le misure organizzative di sicurezza rientrano anche nomine ad amministratore di sistema (secondo il provvedimento del Garante per la Privacy del 2008 ancora valido) di coloro che di fatto svolgono tali mansioni, contratti con fornitori che garantiscono sicurezze adeguate sui dati personali da essi gestiti, compresa una designazione a responsabile esterno del trattamento, la formazione del personale, procedure e istruzioni interne.

Su quest’ultimo aspetto risulta molto utile istituire una sorta di “Regolamento informatico interno”, che descriva le regole da seguire da parte del personale quando utilizza i dispositivi ITC messi a disposizione dall’azienda e non solo. Tale Regolamento dovrebbe trattare – coerentemente con le misure di sicurezza effettivamente implementate – argomenti quali: gestione delle password, gestione delle postazioni di lavoro, gestione dei dispositivi portatili, misure di sicurezza da adottare in viaggio, modalità di utilizzo dei dispositivi elettronici assegnati (cosa si può fare e cosa no), regole da seguire nella navigazione internet e nell’utilizzo della posta elettronica e così via.

Tali disposizioni, oltre che per la protezione dei dati personali, sono utili alla Direzione aziendale per garantirsi in caso di atti illeciti commessi da un dipendente tramite strumenti ICT dell’azienda.

Tornando alle misure di sicurezza informatica implementate, le principali carenze che si rilevano, soprattutto nelle piccole e microimprese, sono legate all’utilizzo di antivirus free (che talvolta non lo sono per utilizzo a fini commerciali), indirizzi di posta elettronica gratuiti, piattaforme in cloud gratuite, servizi di trasmissione di file di grandi dimensioni, ecc. Come noto il termine “gratis” è estremamente gradito a molti piccoli imprenditori, ma per chi tratta dati personali, specie se di tipo sanitario o giudiziario, i sistemi gratuiti offerti anche da importanti player mondiali quali Google, Microsoft, ecc. potrebbero non rappresentare una misura di sicurezza adeguata. Se i dati personali sono critici dal punto di vista della riservatezza, sistemi che non la garantiscono a priori (il servizio gratuito è generalmente fornito in cambio dell’utilizzo dei dati) non costituiscono la scelta migliore. Inoltre la conservazione di dati personali in cloud storage che fisicamente risiedono fuori dalla UE è ammessa solo sotto determinate condizioni.

Il Decreto Legislativo 10 agosto 2018, n. 101 “Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati)” è stato pubblicato in Gazzetta Ufficiale il 04/09/2018 ed entra in vigore dal 19/09/2018.

Il tanto atteso (da chi si occupa di GDPR e privacy in generale) documento normativo permette di inquadrare meglio la materia “protezione dati personali” nel panorama legislativo italiano dopo l’entrata in vigore del Regolamento UE 679/2016 (RGPD o GDPR).

Come previsto dalle letture delle precedenti versioni dello schema di Decreto, approvato dal C.d.M. lo scorso 8 agosto, il testo di legge non fuga molti dubbi che sono emersi dall’applicazione del GDPR in questi primi mesi (in realtà il Regolamento è noto da oltre due anni).

In particolare, non viene trattato il tema delle nomine dei Responsabili esterni del Trattamento (quando si rientra in questo caso? Che fare se la nomina viene rifiutata dal fornitore?), ma questo forse potrà essere argomento delle Linee Guida per le PMI del Garante Privacy, che di fatto riguarderanno la quasi totalità delle organizzazioni italiane per come è strutturato il nostro panorama industriale e dei servizi. Non vengono nemmeno fugati i molti dubbi circa l’applicazione di determinate misure di sicurezza o relativamente al concetto di “larga scala”.

Purtroppo il concetto di accountability (responsabilizzazione) è lontano dall’animo degli imprenditori italiani, che hanno sempre necessitato di regole certe e ben definite: o bianco o nero, permesso o vietato. È come se nel Codice della Strada scomparissero i limiti di velocità e comparisse una regola generale che preveda che “in ogni strada ogni automobilista deve mantenere una velocità adeguata a garantire la sicurezza di persone e cose, minimizzando i rischi di provocare incidenti”.

Oltre alle misure di semplificazione per le PMI, che il Garante Privacy italiano dovrà emanare prossimamente (i tempi previsti sono piuttosto lunghi, visto anche che il GDPR è pienamente attuativo già da oltre tre mesi ed è stato pubblicato nel 2016), farà certamente piacere a molte organizzazioni sapere che tra le disposizioni transitorie e finali, contenute all’art. 22 del nuovo D.Lgs 101/2018, è invece previsto che “per i primi otto mesi dalla data di entrata in vigore, il Garante per la protezione dei dati personali tiene conto, ai fini dell’applicazione delle sanzioni amministrative (…), della fase di prima applicazione delle disposizioni sanzionatorie”. Dunque, fino al 19 maggio 2019 il Garante sarà clemente? Cosa significa? Vuol dire che non ci saranno sanzioni, se non nei casi più gravi (o che costituiscono violazioni della normativa sulla privacy già da tempo), fino a maggio 2019, ma non si può dire ufficialmente per non subire la reprimenda della UE?

Il nuovo D. Lgs 101/2018 in realtà va a modificare il vecchio D. Lgs 196/2003 che, però, vede abrogati la maggior parte dei suoi articoli e, di fatto, viene riscritto tenendo conto delle prescrizioni del GDPR Europeo. In pratica il D. Lgs 101/2018 è poco leggibile, se non si dispone di una versione del D. Lgs 196/2003 modificata e integrata. Ampiamente criticabile è la scelta di novellare il Codice Privacy (D. Lgs 196/2003 con le sue successive modifiche ed integrazioni intercorse negli anni) anziché abrogarlo in toto ed emanare un nuovo Decreto.

Tutto ciò non fa che rendere il panorama normativo in materia di privacy sempre più complesso, oltre che ancora fluido. Si pensi anche ai provvedimenti del Garante Privacy preesistenti all’entrata in vigore del Regolamento 679/2016, che sono stati ritenuti ancora validi, fatto salvo che il Garante stesso potrà modificarli per aggiornarli alla normativa attuale.

Ma veniamo ai punti salienti trattati dal nuovo Decreto Legislativo 101 del 2018:

• Inquadramento dei compiti di interesse pubblico che riguardano i trattamenti dei dati personali, attività della Pubblica Amministrazione e tutto ciò che concerne i trattamenti di dati personali effettuati dagli apparati Statali e dalla Sanità Pubblica. Nel GDPR tali situazioni erano correttamente rimandate a regolamentazioni nazionali.
• Chiarimenti sulle modalità di trattamento di particolari categorie di dati, quali dati relativi alla salute, dati genetici e dati biometrici.
• Definizione più dettagliata dei criteri di applicazione delle sanzioni ed introduzione delle sanzioni penali (solo per situazioni molto gravi).
• Introduzione dei soggetti “designati” al trattamento dei dati personali, con particolari compiti e responsabilità, non solo soggetti “istruiti” e non più “responsabili interni al trattamento”.
• Disposizioni per settori specifici (anche semplificazioni per la gestione dei curriculum ricevuti dalle organizzazioni).
• Regole per il settore delle comunicazioni elettroniche e per il giornalismo.
• Conferimento di poteri al Garante per la Protezione dei Dati Personali per l’aggiornamento di provvedimenti e disposizioni varie, comprese le misure semplificate per le PMI e la definizione dei ruoli nei confronti di ACCREDIA relativamente alla certificazione.
• Criteri di applicazione delle sanzioni.

In conclusione il percorso di rinnovamento del “sistema privacy” non si è ancora concluso e le problematiche attuative, soprattutto per le organizzazioni che trattano in modo significativo dati personali, anche appartenenti alle “particolari categorie di dati” individuate dal GDPR, restano abbastanza complesse, soprattutto a fronte di un meccanismo sanzionatorio incerto che potrebbe portare a parecchie contestazioni. Vedremo come il Garante potrà svolgere il gravoso compito demandatogli dal Governo.

Decreto Legislativo 101/2018 - Modifiche al Codice Privacy

Chi è realmente il Responsabile della protezione dei dati (RPD) o Data Protection Officer (DPO), figura prevista dal Regolamento UE 679/2016 (GDPR)?

Forse sarebbe meglio rispondere anche ad altre domande:

• Cosa fa il DPO?
• Quali requisiti deve possedere?
• A chi serve il DPO?

Il Garante italiano per la Protezione dei Dati Personali e le Linee-guida del WP243, sviluppate dall’apposito Gruppo di Lavoro Articolo 29 a livello europeo, ci vengono in aiuto, ma non bastano a disperdere il polverone che si sta facendo da ogni parte attorno a questa figura.

Si legge da varie fonti di “Corsi specialistici per DPO”, “Esami per qualifiche da DPO”, “migliaia di posti di lavoro come DPO” e così via. È tutto al vero?

Vediamo anzitutto quali sono i requisiti di un DPO o RPD che dir si voglia.

Il Responsabile della Protezione dei Dati (RPD o DPO), nominato dal titolare del trattamento o dal responsabile del trattamento, dovrà:

1. Possedere un’adeguata conoscenza della normativa e delle prassi di gestione dei dati personali, anche in termini di misure tecniche e organizzative o di misure atte a garantire la sicurezza dei dati. Non sono richieste attestazioni formali o l’iscrizione ad appositi albi professionali, anche se la partecipazione a master e corsi di studio/professionali può rappresentare un utile strumento per valutare il possesso di un livello adeguato di conoscenze.
2. Adempiere alle sue funzioni in piena indipendenza e in assenza di conflitti di interesse. In linea di principio, ciò significa che il RPD non può essere un soggetto che decide sulle finalità o sugli strumenti del trattamento di dati personali.
3. Operare alle dipendenze del titolare o del responsabile oppure sulla base di un contratto di servizio (RPD/DPO esterno).

Il titolare o il responsabile del trattamento dovranno mettere a disposizione del Responsabile della Protezione dei Dati le risorse umane e finanziarie necessarie all’adempimento dei suoi compiti.

Leggendo queste righe si evince che non possono esistere corsi per DPO che qualifichino per questo ruolo, né elenchi o albi. Ovviamente tutti i “corsi per DPO” possono essere più o meno validi per svolgere questa mansione in futuro, ma non forniscono la “patente” per farlo.

Le competenze del DPO (insieme di livello di istruzione, conoscenze, capacità/abilità ed esperienza…) devono svariare fra competenze legali, informatiche ed organizzativo-gestionali. Naturalmente il RPD deve conoscere bene il Regolamento UE 679/2016, ma anche il D.Lgs 196/2003 che costituisce tuttora la normativa sulla privacy italiana da oltre 13 anni ed i vari provvedimenti del Garante italiano su videosorveglianza, Amministratori di Sistema, ecc..

Quali saranno le competenze prevalenti? Fino a che livello un DPO deve sapere di sicurezza informatica?

Sicuramente sono più importanti competenze di base consolidate a 360° negli ambiti legale, informatico e gestionale, piuttosto che essere esperti di una materia e non conoscere nulla delle altre. Infatti il DPO non dovrà configurare un firewall (attività che potrà delegare a tecnici sistemisti), ma dovrà sapere cos’è e conoscere i suoi principi di funzionamento.

Per capire quali competenze precise dovrà possedere il DPO occorre comprendere che il DPO è un ruolo da ricoprire in una determinata organizzazione, dunque sarà importante che il DPO conosca discretamente i processi gestionali dell’organizzazione in cui dovrà operare ed in funzione del tipo di organizzazione dovrà possedere requisiti minimi differenti. Per esempio il DPO di un Ospedale o di una organizzazione della Sanità Privata non dovrà necessariamente avere le stesse competenze del DPO di un Comune, di un Ufficio Giudiziario o di una Società che sviluppa software per la profilazione di utenti. Quindi ad ognuno il suo DPO.

Infine sottolineiamo il fatto che il DPO deve essere indipendente dalle altre funzioni aziendali e dipendere solo dal titolare del trattamento, dunque in molte organizzazioni difficilmente una figura interna possiede questi requisiti.

 

Quindi, quali sono i compiti del DPO?

Il Responsabile della Protezione dei Dati dovrà, in particolare:

• sorvegliare l’osservanza del Regolamento, valutando i rischi di ogni trattamento alla luce della natura, dell’ambito di applicazione, del contesto e delle finalità;
• collaborare con il titolare/responsabile, laddove necessario, nel condurre una valutazione di impatto sulla protezione dei dati (DPIA);
• informare e sensibilizzare il titolare o il responsabile del trattamento, nonché i dipendenti di questi ultimi, riguardo agli obblighi derivanti dal Regolamento e da altre disposizioni in materia di protezione dei dati;
• cooperare con il Garante e fungere da punto di contatto per il Garante su ogni questione connessa al trattamento;
• supportare il titolare o il responsabile in ogni attività connessa al trattamento di dati personali, anche con riguardo alla tenuta di un registro delle attività di trattamento.

Esaminando i suddetti punti emerge un ruolo un po’ da consulente e un po’ da auditor, ma con contorni non ben definiti. In base al tipo di organizzazione il DPO o RPD che dir si voglia dovrà svolgere compiti più o meno estesi, potrà essere supportato da un team di altre persone, interne o esterne all’organizzazione, che potranno essere specialisti in ambito informatico, legale o altro a seconda del settore di appartenenza. Ad esempio in una organizzazione sanitaria il DPO potrebbe essere supportato da esperti nel settore sanitario, ad esempio medici.

Anche un DPO esterno potrebbe assumere l’incarico avvalendosi di un team di collaboratori, anche per far fronte alle numerose richieste da parte degli interessati che potrebbero porre quesiti sulle modalità di trattamento dei propri dati personali.

Inoltre è da sottolineare il fatto che il DPO deve disporre anche di autonomia e risorse sufficienti a svolgere in modo efficace i compiti cui è chiamato ed è il titolare (o responsabile) del trattamento che ha l’onere di garantire ciò.

In definitiva il perimetro dei compiti del DPO andrebbe definito bene di caso in caso in apposito contratto o delega del titolare.

Si osserva che il GDPR impone al titolare o al responsabile del trattamento di pubblicare i dati di contatto del DPO e di comunicare i dati di contatto del DPO alle pertinenti autorità di controllo; dunque è un incarico ufficiale e pubblico, affinché tutti gli interessati al trattamento di dati personali effettuato dall’organizzazione possano contattare il DPO per richiedere informazioni sul trattamento dei dati che li riguardano.

Da ultimo, ma non di minore importanza: i DPO non rispondono personalmente in caso di inosservanza del GDPR, ma tale responsabilità ricade sempre e solo sul titolare o sul responsabile del trattamento.

 

 

Vediamo, infine, in quali casi è previsto il DPO, ovvero quando una organizzazione è obbligata a nominare un DPO.

Dovranno designare obbligatoriamente un RPD:

1. amministrazioni ed enti pubblici, fatta eccezione per le autorità giudiziarie;
2. tutti i soggetti la cui attività principale consiste in trattamenti che, per la loro natura, il loro oggetto o le loro finalità, richiedono il monitoraggio regolare e sistematico degli interessati su larga scala;
3. tutti i soggetti la cui attività principale consiste nel trattamento, su larga scala, di dati sensibili, relativi alla salute o alla vita sessuale, genetici, giudiziari e biometrici.

Anche per i casi in cui il regolamento non impone in modo specifico la designazione di un RPD, è comunque possibile una nomina su base volontaria. Ma questa frase non farà effetto su quelle Società che pensano di nominare un DPO solo se strettamente obbligatorio per legge.

Si precisa che un gruppo di imprese o soggetti pubblici possono nominare un unico RPD.

Dunque un consulente esterno qualificato potrebbe assumere il ruolo di DPO, per così dire, in outsourcing, per diverse organizzazioni.

Gli esempi forniti nella Linea-guida del GdL Articolo 29 su chi effettivamente dovrà nominare un DPO in ambito privato forniscono qualche indicazione, ma non dirimono tutti i dubbi. Soprattutto il concetto di “larga scala” è molto dibattuto: preso atto che un medico di famiglia non tratta dati particolari (sanitari in questo caso) su larga scala, salendo sul gradino superiore di questa scala virtuale, quale soggetto, avente comunque un organico ridotto, tratta dati particolari su larga scala: un poliambulatorio privato, una clinica/ospedale privati, un Amministratore di Condominio, un fornitore di servizi di ristorazione collettiva?

Speriamo che non siano le sentenze a definire meglio la normativa che, qui come in altre parti, lascia ampio spazio all’interpretazione.

Da quanto esposto emerge una similitudine fra la figura del DPO – che deve proteggere i dati personali dell’individuo – e l’RSPP (Responsabile del Servizio Prevenzione e Protezione per la Sicurezza e Salute del Lavoro, secondo il D.Lgs 81/2009 e s.m.i.) – che deve garantire la sicurezza nei luoghi di lavoro -, con un distinguo, però: l’RSPP è responsabile anche legalmente in caso di incidente, mentre il DPO non è responsabile in caso di violazione dei dati personali.