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

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

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

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

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

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

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

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

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

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

 I punti dello schema sono illustrati nel seguito:

INTRODUZIONE

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

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

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

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

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

SCOPO E CAMPO DI APPLICAZIONE

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

RIFERIMENTI NORMATIVI

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

TERMINI E DEFINIZIONI

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

PRINCIPI E QUADRO DI RIFERIMENTO

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

CONSAPEVOLEZZA E RESPONSABILIZZAZIONE

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

OBIETTIVI E PIANIFICAZIONE DELLA GESTIONE DEL RISCHIO

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

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

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

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

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

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

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

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

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

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

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

SUPPORTO

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

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

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

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

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

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

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

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

ATTIVITÀ OPERATIVE

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

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

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

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

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

MONITORAGGIO

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

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

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

MIGLIORAMENTO

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

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

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

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

OBIETTIVI DI CONTROLLO

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

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

CONCLUSIONI

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

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

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

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

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

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

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

Qualora un trattamento debba essere effettuato per conto del titolare del trattamento, quest’ultimo ricorre unicamente a responsabili del trattamento che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del presente regolamento e garantisca la tutela dei diritti dell’interessato.

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

I trattamenti da parte di un responsabile del trattamento sono disciplinati da un contratto o da altro atto giuridico a norma del diritto dell’Unione o degli Stati membri, che vincoli il responsabile del trattamento al titolare del trattamento e che stipuli la materia disciplinata e la durata del trattamento, la natura e la finalità del trattamento, il tipo di dati personali e le categorie di interessati, gli obblighi e i diritti del titolare del trattamento

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

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

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

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

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

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

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

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

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

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

Veniamo a trattare alcuni elementi specifici.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conservazione ovvero cancellazione dei dati personali trattati al termine del contratto

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

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

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

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

Diritto di audit da parte del Titolare sul Responsabile

Il GDPR prevede che il Responsabile:

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

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

Impegno alla riservatezza del personale del Responsabile

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

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

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

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

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

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

Cos’è il rischio per la sicurezza delle informazioni?

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

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

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

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

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

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

La valutazione del rischio sulla sicurezza delle informazioni

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La valutazione del rischio privacy

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

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

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

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

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

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

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

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

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

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

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

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 assegnamo 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.

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.

Lo scorso dicembre – dopo lunghe discussioni – è stata pubblicata la norma UNI 11697:2017 “Attività professionali non regolamentate – Profili professionali relativi al trattamento e alla protezione dei dati personali – Requisiti di conoscenza, abilità e competenza”, inerente la definizione dei requisiti relativi all’attività professionale dei soggetti operanti nell’ambito del trattamento e della protezione dei dati personali (compreso il DPO), da questi esercitata a diversi livelli organizzativi (pubblico o privato).

L’UNI dichiara che “La norma definisce i profili professionali relativi al trattamento e alla protezione dei dati personali coerentemente con le definizioni fornite dall’EQF e utilizzando gli strumenti messi a disposizione dalla UNI 11621-1 Attività professionali non regolamentate – Profili professionali per l’ICT – Parte 1: Metodologia per la costruzione di profili professionali basati sul sistema e-CF“.

La norma, anche dopo la sua uscita, è stata fonte di animate discussioni fra gli esperti del settore e, soprattutto, è stata vivacemente contestata da chi ritiene che non esponga in modo chiaro e preciso i requisiti professionali delle figure in oggetto oppure definisca delle figure professionali favorevoli a certi profili piuttosto che altri.

Le figure professionali delineate dalla norma UNI sono le seguenti:

1. Data Protection Officer (DPO), figura di supporto al titolare o responsabile del trattamento nell’applicazione e per l’osservanza del Regolamento (UE) 2016/679, in conformità all’ art. 37 (Designazione del Responsabile della protezione dei dati), art. 38 (Posizione del Responsabile della protezione dei dati) e art. 39 (Compiti del Responsabile della protezione dei dati).
2. Manager Privacy, figura che assiste il titolare nelle attività di coordinamento di tutti i soggetti che – nell’organizzazione – sono coinvolti nel trattamento di dati personali (responsabili, incaricati, amministratori di sistema, ecc.), garantendo il rispetto delle norme in materia di privacy e il mantenimento di un adeguato livello di protezione dei dati personali.
3. Specialista Privacy, figura di supporto appositamente formato (è richiesta una formazione minima di 24 ore), che collabora con il Manager Privacy e cura la corretta attuazione del trattamento dei dati personali all’interno dell’organizzazione, svolgendo le attività operative che, di volta in volta, si rendono necessarie durante tutto il ciclo di vita di un trattamento di dati personali.
4. Valutatore Privacy, figura dotata di una apposita formazione (minima di 40 ore) che si caratterizza per la sua terzietà sia nei confronti del Manager che dello Specialista Privacy; egli esercita una attività di monitoraggio (audit) andando ad esaminare periodicamente il trattamento dei dati personali e valutando il rispetto delle normative di settore emanate.

Concentriamoci sulla figura del DPO o RPD. La norma definisce una descrizione sintetica del profilo, una missione, dei risultati attesi, dei compiti principali, delle competenze, delle abilità e delle conoscenze.

Per ognuna delle competenze assegnate seguenti è definito un livello di competenza:

• Pianificazione di Prodotto o di Servizio
• Sviluppo della Strategia per la Sicurezza Informatica
• Gestione del Contratto
• Sviluppo del Personale
• Gestione del Rischio
• Gestione delle Relazioni
• Gestione della Sicurezza dell’Informazione
• Governante dei sistemi informativi

Tra le Abilità (Skill) stabilite che deve possedere il DPO si segnalano:

• Contribuire alla strategia per il trattamento e per la protezione dei dati personali
• Capacità di analisi
• Capacità organizzative
• Pianificazione e programmazione
• Saper analizzare gli asset critici dell’azienda ed identificare debolezze e vulnerabilità riguardo ad intrusioni o attacchi
• Saper anticipare i cambiamenti richiesti alla strategia aziendale dell’information security e formulare nuovi piani
• Saper applicare gli standard, le best practice e i requisiti legali più rilevanti all’information security
• Garantire che la proprietà intellettuale (IPR) e le norme della privacy siano rispettate
• egoziare termini e condizioni del contratto
• Preparare i template per pubblicazioni condivise
• Progettare e documentare i processi dell’analisi e della gestione del rischio
• Essere in grado di seguire e controllare l’uso effettivo degli standard documentativi aziendali

Invece tra le Conoscenze (Knowledge) possedute dal DPO vi sono:

• I principi di privacy e protezione dei dati by design e by default I diritti degli interessati previsti da leggi e regolamenti vigenti Le responsabilità connesse al trattamento dei dati personali
• Norme di legge italiane ed europee in materia di trattamento e di protezione dei dati personali
• Norme di legge in materia di trasferimento di dati personali all’estero e circolazione dei dati personali extra UE
• Le metodologie di valutazione d’impatto sulla protezione dei dati e PIA
• Le norme tecniche ISO/IEC per la gestione dei dati personali
• Le tecniche crittografiche
• Le tecniche di anonimizzazione
• Le tecniche di pseudonimizzazione
• Sistemi e tecniche di monitoraggio e “reporting”
• Gli strumenti di controllo della versione per la produzione di documentazione
• I rischi critici per la gestione della sicurezza
• I tipici KPI (key performance indicators)
• Il ritorno dell’investimento comparato all’annullamento del rischio
• la computer forensics (analisi criminologica di sistemi informativi)
• La politica di gestione della sicurezza nelle aziende e delle sue implicazioni con gli impegni verso i clienti, i fornitori e i sub-contraenti
• Le best practice (metodologie) e gli standard nella analisi del rischio
• Le best practice e gli standard nella gestione della sicurezza delle informazioni
• Le norme legali applicabili ai contratti
• Le nuove tecnologie emergenti (per esempio sistemi distribuiti, modelli di virtualizzazione, sistemi di mobilità, data sets)
• Le possibili minacce alla sicurezza
• Le problematiche legate alla dimensione dei data sets (per esempio big data)
• Le problematiche relative ai dati non strutturati (per esempio data analytics)
• Le tecniche di attacco informatico e le contromisure per evitarli

Fra le competenze richieste determinate dalla norma emergono profili afferenti a:

• Consulenti direzione
• Consulenti ed esperti di sistemi di gestione della sicurezza delle informazioni (famiglia delle norme ISO 27000)
• Auditor di sistemi di gestione
• Esperti di Risk Management
• Consulenti/esperti sulle normative attinenti alla privacy ed alla protezione dei dati personali (leggi, normative, disposizioni del Garante, ecc.)

Inoltre sono richieste conoscenze legali sulla contrattualistica, competenze sulla sicurezza informatica (tecniche di attacco, crittografia, ecc.) e sui sistemi informatici e relativi database.

Pur con le dovute precisazioni relative al fatto che il candidato DPO dovrà ricoprire un ruolo le cui caratteristiche dipendono fortemente dall’organizzazione in cui dovrà andare a operare, è evidente che prevalgono le competenze gestionali/manageriali e quelle relative alla sicurezza delle informazioni, piuttosto che quelle legali. Per quanto possa essere contestata, la norma chiaramente individua soggetti più vicini all’ingegnere dell’informazione che all’esperto legale come possibile DPO/RPD. Sicuramente le competenze legali eventualmente mancanti a un profilo molto vicino all’ingegnere dell’informazione sono più facilmente colmabili, anche attraverso consulenze specifiche, rispetto ad altre situazioni in cui il potenziale DPO si trova a dover colmare il gap di competenza relativo ai sistemi di gestione della sicurezza delle informazione, al risk management, alle basi di dati e magari anche alla cybersecurity.

Sicuramenteci sono in giro illustri avvocati esperti di info security e data protection, magari anche consulenti ed auditor ISO 27001, ma tutti coloro che si propongono per il ruolo di DPO con competenze essenzialmente giurisprudenziali saranno adatti a ricoprire il ruolo di DPO?

Naturalmente queste considerazioni valgono se si pensa di affidare il ruolo di DPO ad un’unica figura, con l’eventuale supporto di un team di esperti nelle varie discipline.

Chiaramente ogni organizzazione o ente pubblico che vorrà selezionare il proprio DPO potrà decidere come meglio crede in base ai compiti e le caratteristiche identificate per il DPO dal Regolamento UE 679/2016, ma la norma UNI 11697, volontaria, dice questo.

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.

Il Regolamento (Ue) 2016/679, noto anche come RGPD (Regolamento Generale sulla Protezione dei Dati) o GDPR (General Data Protection Regulation), troverà piena attuazione esattamente fra un anno da oggi, il 25 maggio 2018, ovvero al termine del periodo di transizione.

A seguito dell’interessante seminario svoltosi venerdì 19 maggio 2017 presso l’Ordine degli Ingegneri di Bologna sulle possibili forme di certificazione in ambito Privacy, è utile fare qualche riflessione sull’attuazione di questa nuova normativa nelle organizzazioni del nostro Paese.

Attualmente esistono alcuni documenti ufficiali che permettono di comprendere meglio come declinare i requisiti del GDPR nella propria organizzazione, tra i quali:

• Linee Guida all’applicazione del RGPD del Garante Privacy italiano
• Linee guida sui responsabili della protezione dei dati (RPD) WP-243 (compreso l’allegato con le FAQ)
• Linee guida per la valutazione di impatto -WP248 .

Al momento, però, le indicazioni fornite non sono in grado di fugare tutti i dubbi sull’applicazione del GDPR, anzi!

Il GDPR dà spazio a integrazioni dei requisiti in esso riportati per regolamentare situazioni specifiche per tipo di dati trattati e particolari legislazioni nazionali, sarà compito del Garante Italiano definire eventuali disposizioni integrative che avranno valore di Legge.

Esaminando i concetti principali del GDPR, quali responsabilizzazione (accountability) del titolare e del responsabile del trattamento, privacy by design, privacy by default, valutazione di impatto, valutazione dei rischi e “misure di sicurezza adeguate”, è facile individuare molti punti di debolezza di numerose organizzazioni italiane che, per mentalità, non sono abituate ad affrontare il problema della protezione dei dati personali con metodo e come una reale priorità. Per molti vertici aziendali la privacy è “solo una scocciatura” e il nuovo Regolamento un “ennesimo obbligo cui toccherà adeguarsi”, ma non tanto prima della scadenza. Come se bastasse fare quattro documenti per risolvere il problema per sempre (o per lo meno fino al prossimo cambiamento normativo)!.

Purtroppo questo “approccio” per essere conformi al GDPR deve cambiare, perché è una norma di stampo anglosassone (tipo “common law”, a dispetto della Brexit) che richiede una forte responsabilizzazione di coloro che ricopriranno il ruolo di titolari (rappresentanti legali per le società) e responsabili del trattamento.

L’affidamento all’esterno di dati personali, anche solo per adempimenti legislativi, come la preparazione delle buste paga demandate allo Studio di Consulenza del Lavoro, devono richiedere un’attenta analisi del contratto con il soggetto esterno e verifica che esso soddisfi tutti i requisiti in termini di misure di sicurezza per la protezione dei dati.

Certamente per le PMI che trattano solo dati personali di dipendenti e collaboratori, oltre a nominativi di referenti di clienti e fornitori, l’adeguamento al GDP non sarà di particolare impatto, ma basta demandare all’esterno ad un servizio via web come la gestione del personale oppure avere un sito internet di e-commerce che raccoglie dati di utenti per rendere la gestione un pochino più complessa.

Viceversa le organizzazioni che trattano dati particolari (i.e. sensibili), soprattutto se poco strutturate e se gestiscono tali dati insieme a fornitori di servizi mediante internet, dovranno cambiare il loro atteggiamento sulla privacy e valutare attentamente i rischi che corrono. Soprattutto non credano che basti far scrivere un DPS o “riesumare” quello precedentemente redatto prima che il Governo lo abolisse: la carta (o i documenti digitali) non bastano, occorre la consapevolezza e la sostanza di applicazione di regole comportamentali, misure di sicurezza fisica e logica (sistemi informatici) ritenute adeguate (da chi?) e instaurare con fornitori e partner rapporti contrattuali che prendano in considerazione anche il trattamento dei dati personali e la loro tutela.

Recenti eventi come i ransomware del tipo Wannacry potrebbero far piangere veramente i titolari di trattamenti di dati sanitari, il cui valore per gli hacker potrebbe essere ben superiore dei 300 dollari in Bitcoin. Il ricatto potrebbe essere non del tipo “se rivuoi i tuoi dati paga”, ma “se non vuoi che divulghi su internet i tuoi dati paga il riscatto”!. Ci sono stati già casi analoghi legati a ricatti a proprietari di diritti di serie TV americane molto più innocui.

Relativamente al ruolo del DPO, l’obbligo di nomina imposto dal Regolamento ricade in modo certo solo su Enti Pubblici, mentre le Organizzazioni che controllano in modo regolare e sistematico dati personali di interessati su larga scala e quelle che trattano dati particolari (traducibili con i dati sensibili del vecchio Codice Privacy, D.Lgs 196/2003) su larga scala o trattano dati relativi a condanne penali e reati non sono facilmente determinabili. Cosa significa “su larga scala”? Le indicazioni fornite hanno permesso di stabilire che un medico di base della Sanità Italiana non tratta dati sanitari su larga scala, ma come considerare strutture superiori come Farmacie, Ambulatori medici Privati, Cliniche Private? Gli Studi Legali devono nominare un DPO?

Sicuramente le competenze del DPO dovrebbero comprendere competenze legali (conoscenza di normative e leggi applicabili alla materia ed ai dati trattati dall’organizzazione titolare del trattamento), competenze informatiche (non necessariamente particolarmente approfondite, per esse può rivolgersi a tecnici specializzati come sistemisti ed esperti di sicurezza informatica) e gestionali-organizzative.

Relativamente alle forme di certificazione sulla privacy che, beninteso, non esimono i titolari ed i responsabili del trattamento da essere passibili delle sanzioni previste dal Regolamento e dal Garante Privacy Italiano in caso di infrazioni, occorre distinguere fra diversi tipi di certificazione:

• Certificazione di prodotto o servizio, accreditata secondo ISO 17065, come ad es. lo schema ISDP 10003:2015 – Criteri e regole di controllo per la Certificazione dei processi per la tutela delle persone fisiche con riguardo al trattamento dei dati personali – Reg. EU 679/2016.
• Certificazione delle figure Professionali della Data Protection (DPO, “Auditor Privacy”, “Privacy Officer” e “Consulente Privacy”).
• Certificazione delle Aziende del Data Protection Management System in conformità al Codice di Condotta DPMS 44001:2016^© ed al Reg. (UE) 679/2016.
• Certificazione del sistema di gestione della sicurezza delle informazioni secondo la ISO 27001:2013.

Premesso che la certificazione accreditata secondo il Regolamento UE 679/2016, così come esposta dall’articolo 43 dello stesso RGPD, trova attualmente riscontri solo in standard e certificazioni afferenti allo schema di accreditamento ISO 17065 (certificazioni di prodotto o servizio), emergono le seguenti considerazioni:

• Non si è ancora affermato un sistema di gestione della privacy riconosciuto che, sulla base della struttura HLS delle norme sui sistemi di gestione (ISO 9001, ISO 27001, ecc.), consenta di gestire la protezione dei dati con un approccio sistemico, basato sui processi e concetti come il risk based thinking e l’attuazione di azioni finalizzate ad affrontare i potenziali rischi sul trattamento di dati personali.
• Il ruolo del Data Processor Officer (DPO o RPD), come è definito dal Regolamento, non corrisponde ad una figura professionale specifica avente determinati requisiti di competenza (istruzione scolastica e post scolastica, conoscenze normative e tecniche, esperienza nell’ambito privacy, partecipazione a corsi di formazione, superamento di esami o abilitazioni). Il DPO è piuttosto “un ruolo” che potrebbe richiedere competenze differenti a seconda della realtà in cui opera e della criticità della protezione dei dati personali nell’organizzazione stessa.
• Tutti gli schemi e gli standard sopra indicati permettono di ridurre il rischio che il titolare del trattamento e gli eventuali responsabili incorrano in infrazioni nel trattamento di dati personali e, quindi, rischino infrazioni anche pesanti e/o gravi danni di immagine.

Per concludere, secondo il risk based thinking, quali rischi corrono le aziende che non sono adeguate al GDPR?

La probabilità di essere sanzionati a seguito di ispezioni del Nucleo Privacy della GdF è estremamente bassa, un po’ più alta per organizzazioni che trattano dati particolarmente critici (la valutazione è fatta in base al numero delle ispezioni avvenute negli ultimi anni).

La probabilità di incorrere in sanzioni o in risarcimento danni a causa di istanze di interessati che si sentono danneggiati nella loro privacy oppure in caso di incidenti di dominio pubblico è un po’ più alta.

L’impatto delle conseguenze nel caso si verifichino suddetti eventi negativi dipende dal tipo di organizzazione e dai dati trattati, può essere significativo o devastante a seconda dei casi.

Leggi anche l’articolo Impatti del Regolamento Privacy sullo sviluppo software.

Il Nuovo Regolamento Europeo sulla Privacy, emanato lo scorso maggio ed in vigore entro fine maggio 2018, pone nuove questioni relativamente all’impiego di programmi software per l’elaborazione di dati personali, in particolare se si tratta anche di dati c.d. “sensibili” secondo la vecchia definizione del D. Lgs 196/2003.

Infatti il nuovo Regolamento Europeo sulla privacy (“Regolamento UE 2016/679 del Parlamento europeo”) impone alle organizzazioni che intendono effettuare trattamenti di dati personali di “progettare” il sistema in modo tale che sia conforme fin da subito (Privacy by design ) alle regole della privacy, spostando la responsabilità del corretto trattamento tramite strumenti informatici idonei sul titolare e sul responsabile del trattamento, quando identificato.

Nella pratica una organizzazione, prima di impiegare un applicativo software per trattare dati personali dovrà verificare che esso sia conforme ai requisiti stabiliti dal regolamento UE 679/2016, ovvero che presenti caratteristiche di sicurezza adeguate per mantenere protetti i dati personali, compresa l’eventuale pseudonomizzazione dei dati personali, quando necessaria, e la cifratura dei dati stessi.

Il Regolamento parla anche di “certificazione” della privacy, che può riferirsi ad un singolo o ad un insieme di trattamenti effettuati da un programma software, oppure da tutti i trattamenti effettuati da una organizzazione. In quest’ultimo caso siamo molto vicini alla certificazione del sistema di gestione ISO 27001. Al proposito è stato approvato da ACCREDIA lo schema proprietario ISDP©10003:2015 (conformità alle norme vigenti EU in tema di trattamenti dei dati personali).

Lo schema di certificazione ISDP 10003:2015 risponde ai requisiti di cui agli art. 42 e 43 del Regolamento 679/2016 ed è applicabile a tutte le tipologie di organizzazioni soggette alle norme vigenti in tema di tutela delle persone fisiche con riguardo al trattamento dei dati personali e la libera circolazione di tali dati. Lo schema di certificazione specifica ai “Titolari” e “Responsabili” del

trattamento, soggetti ai vincoli normativi vigenti nel territorio dell’EU, i requisiti necessari per la corretta valutazione della conformità alle norme stesse.

Ricordiamo anche che all’art 25, coma 2 il Regolamento sancisce che:

Il titolare del trattamento mette in atto misure tecniche e organizzative adeguate per garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento. Tale obbligo vale per la quantità dei dati personali raccolti, la portata del trattamento, il periodo di conservazione e l’accessibilità. In particolare, dette misure garantiscono che, per impostazione predefinita, non siano resi accessibili dati personali a un numero indefinito di persone fisiche senza l’intervento della persona fisica.

Rappresenta la c.d. Privacy by default: devono essere trattati “per default” solo i dati necessari a perseguire le finalità del trattamento posto in essere dal responsabile dello stesso, ovvero non devono essere trattati dati in eccesso senza che una persona fisica autorizzata lo consenta.

La certificazione introdotta all’Art. 42 può servire a dimostrare l’adozione di misure tecniche ed organizzative adeguate.

L’impatto di queste regole sugli applicativi software utilizzati per trattare anche dati personali è notevole: una organizzazione di qualsiasi dimensione che adotta un sistema informatico gestionale che tratta dati personali non in modo conforme al Regolamento UE 679/2016 di fatto rischia di essere sanzionata perché non ha adottato misure di sicurezza adeguate. Le responsabilità ricadono, in questo caso, sul titolare del trattamento e sul responsabile del trattamento, ove presente.

Dunque prima di adottare un nuovo software che gestisce archivi contenenti dati personali (a maggior ragione se vengono gestiti dati sanitari o altri dati c.d. “sensibili”) titolari e responsabili del trattamento devono valutarne la conformità alla normativa sulla privacy e questo può essere al di fuori delle competenze di chi decide l’acquisto di un applicativo software (responsabili EDP, Direttori Generali, ecc.), soprattutto nelle piccole e medie imprese o nelle strutture sanitarie di modeste dimensioni (es. Cliniche ed ambulatori privati).

La casistica di software che ricadono in questa sfera è vastissima, si va dai comuni ERP che trattano anche dati del personale, ai software per la gestione delle paghe, ai programmi per la gestione delle fidelity card, ai software impiegati in strutture sanitarie o quelli utilizzati dagli studi legali.

Oggi molti applicativi, magari obsoleti, non permettono di implementare misure di sicurezza adeguate (password di lunghezza adeguata, password di complessità minima variate periodicamente, password trasmesse via internet con connessioni crittografate, gestione utenti, raccolta di dati minimi indispensabili, gestione dei consensi, procedure di backup, ecc.) e in futuro il loro impiego diverrà non conforme alla normativa sulla privacy, ovvero non saranno più commercializzabili.

Da un lato i progettisti e gli sviluppatori di applicativi software dovranno considerare fra i requisiti di progetto anche quelli relativi alla normativa privacy, dall’altro le organizzazioni che adotteranno applicativi software (o che già li stanno utilizzando) saranno responsabili della loro eventuale non conformità al Regolamento Privacy.