Sia gli esperti di modelli 231 (i cosiddetti MOG 231, cioè i Modelli di Organizzazione e Gestione) sia gli operatori in ambito privacy e GDPR sanno che, prima di impostare una compliance, è necessario effettuare un’analisi dei rischi a partire dal processo aziendale.
Detto altrimenti, si devono verificare i processi input-output di riferimento e comprendere quali siano i rischi e le opportunità presentati dall’applicazione della normativa in quel determinato contesto.
Nel caso del GDPR, i processi di riferimento sono unicamente quelli relativi al trattamento dei dati personali trattati dall’azienda; nel caso del MOG 231, invece, oggetto di vaglio sono tutti i processi aziendali, a partire dalle fattispecie di reato previste dal D.lgs. 231/2001.
Questa analisi può essere effettuata applicando lo schema SWOT (Strengths, Weaknesses, Opportunities, Threats, e cioè: punti di forza, debolezze, opportunità e minacce) o altri più semplici, ma è indubbio che si debba partire dall’individuazione dei rischi di riferimento, dalle procedure atte ad escluderne la verificazione ed alla previsione – comunque – di misure idonee alla mitigazione delle conseguenze in caso di verificazione dell’evento che si intende evitare.
Questo approccio, di derivazione anglosassone ma ormai molto noto anche in Italia, è assimilabile a quello adottato dagli standard UNI ISO, in materia, ad esempio, di qualità, ambiente, sicurezza sul lavoro e, per quanto attiene alla privacy, alla norma ISO/IEC 27001 in materia di cyber security.
Quest’ultima, anche se non perfettamente sovrapponibile alla compliance prevista dal Reg. UE 2016/679, è stata ritenuta, dagli operatori del settore, uno standard di qualità rilevante in materia di GDPR.
Indice degli argomenti
GDPR e MOG, tra sanzioni, regolamentazioni e mercato
Se è vero che la valutazione dei rischi è un elemento comune ad entrambe le compliance, va detto che le finalità sono molto diverse.
La normativa in materia di responsabilità amministrativa da reato degli enti ha finalità preventiva solo nella misura in cui sanziona l’impresa per la commissione di fatti di reato commessi da propri soggetti apicali o dipendenti per interesse o vantaggio dell’impresa stessa.
È, quindi, una normativa sostanzialmente sanzionatoria, poiché le regolamentazioni specifiche sono previste in altre normative di riferimento.
Il GDPR, al contrario, imposta un sistema autosufficiente finalizzato alla creazione di un ecosistema equilibrato di trattamento dei dati in ambito UE, dove il focus non è sulla sanzione ma sulla consapevolezza dell’attività aziendale in materia di dati personali.
In quest’ottica, il Reg. UE 2016/679 appare portatore di un approccio effettivamente innovativo, quantomeno nell’ordinamento italiano.
L’accountability tra GDPR e MOG
Il Reg. UE 2016/679 ha, di fatto, eliminato la compliance standard minima prevista, in Italia, dal D.lgs. 196/2003, lasciando in capo ad ogni titolare del trattamento l’onere di impostare una compliance efficace e taylor made per la propria realtà aziendale.
Il MOG previsto dal D.lgs. 231/2001, di fatto, ha sempre risposto a questa logica, imponendo alle aziende l’applicazione di protocolli per il pieno rispetto delle normative cogenti e per l’implementazione di standard sempre più elevati, in particolare nel delicato ambito della sicurezza sul lavoro.
Sotto questo profilo, quindi, si può dire che i due sistemi di riferimento rispondano a logiche tra loro armoniche.
Non stupisce, quindi, che le realtà in cui il MOG era già stato implementato abbiano risposto in maniera più efficiente e tempestiva all’entrata in vigore del GDPR rispetto alle aziende in cui l’analisi dei processi e l’elaborazione di protocolli non era all’ordine del giorno.
I punti di tangenza tra GDPR e MOG
L’art. 24 bis del D.lgs. 231/2001, rubricato “Delitti informatici e trattamento illecito di dati” stabilisce che:
“1. In relazione alla commissione dei delitti di cui agli articoli 615-ter, 617-quater, 617-quinquies, 635-bis, 635-ter, 635-quater e 635-quinquies del Codice penale, si applica all’ente la sanzione pecuniaria da cento a cinquecento quote. 2. In relazione alla commissione dei delitti di cui agli articoli 615-quater e 615-quinquies del Codice penale, si applica all’ente la sanzione pecuniaria sino a trecento quote. 3. In relazione alla commissione dei delitti di cui agli articoli 491-bis e 640-quinquies del Codice penale, salvo quanto previsto dall’articolo 24 del presente decreto per i casi di frode informatica in danno dello Stato o di altro ente pubblico, e dei delitti di cui all’articolo 1, comma 11, del decreto-legge 21 settembre 2019, n. 105, si applica all’ente la sanzione pecuniaria sino a quattrocento quote. 4. Nei casi di condanna per uno dei delitti indicati nel comma 1 si applicano le sanzioni interdittive previste dall’articolo 9, comma 2, lettere a), b) ed e). Nei casi di condanna per uno dei delitti indicati nel comma 2 si applicano le sanzioni interdittive previste dall’articolo 9, comma 2, lettere b) ed e). Nei casi di condanna per uno dei delitti indicati nel comma 3 si applicano le sanzioni interdittive previste dall’articolo 9, comma 2, lettere c), d) ed e)”.
Detto altrimenti, i reati informatici commessi nell’interesse o vantaggio dell’ente da parte di soggetti apicali o preposti determinano la responsabilità amministrativa dell’ente stesso.
Ciò che colpisce è che il legislatore nazionale non ha inteso inserire nell’elenco dei c.d. reati-presupposto i delitti previsti dal “Codice della privacy”, ossia dal D.lgs. 196/2003, anche inseguito alla rivisitazione delle fattispecie effettuata nel 2018, con l’adozione del D.lgs. 101/2018.
Quello che va rilevato, peraltro, è che i reati previsti dall’art. 24 bis D.lgs. 231/2001 sono, sostanzialmente, tutte ipotesi di data breach dolosi o di violazioni informatiche con implicazioni anche in tema di trattamento dei dati.
Chi imposta una privacy compliance deve certamente valutare i rischi di violazioni dolose rientranti nelle fattispecie di cui all’art. 24 bis D.lgs. 231/2001, ma anche di quelle previste dal D.lgs. 196/2003, come modificato dal D.lgs. 101/2018.
Nelle realtà in cui il MOG sia presente, quindi, la sovrapponibilità delle procedure potrà avvenire solo in parte qua.
Altro elemento di tangenza rilevante è la previsione della procedura di whistelblowing, prevista dalla L. 179/2017: è un elemento del MOG ed è un ambito di intervento in tema di trattamento dei dati, in relazione a minimizzazione e bilanciamento tra diritto del whistelblower a non subire ritorsioni e del soggetto chiamato in causa a conoscere anche la fonte degli addebiti mossigli.
OdV e DPO: i controllori si controllano a vicenda?
Sia l’organismo di vigilanza che il data protection officer hanno compiti di vigilanza e possono indicare eventuali azioni correttive su procedure o protocolli che necessitano di aggiornamento.
Se, da un lato, è pacifico che l’organismo di vigilanza può – ma non deve – essere esterno all’azienda, tale caratteristica si estende anche al DPO, la cui caratteristica essenziale è l’indipendenza.
Ci si è chiesti che tipo di inquadramento abbia l’organismo di vigilanza in ambito privacy.
Posto che la valutazione va fatta in concreto (un OdV monocratico interno è diverso da uno collegiale esterno), ci si è chiesti se la qualifica come responsabile esterno ex art. 29 GDPR fosse corretta.
L’Autorità Garante per il trattamento dei dati personali è intervenuta il 12 maggio, con un parere in materia, richiesto dall’Associazione dei Componenti degli Organismi di Vigilanza ex d.lgs. 231/2001 AODV 231.
Fondamentalmente, il Garante ha ritenuto che la qualifica più corretta sia quella di incaricato del trattamento laddove operi ai sensi dell’art. 6, commi 1 e 2 del D.lgs. n. 231/2001, rimanendo quindi esclusa dalla qualificazione soggettiva delineata in ambito privacy.
Tale presa di posizione del Garante è motivata dall’aver ritenuto l’organismo di vigilanza vera e propria parte dell’impresa, con tutte le conseguenze del caso.
