In vari articoli precedenti si è cercato di dimostrare che la realizzazione di una effettiva compliance integrata in azienda, risultante dalla cooperazione di DPO e OdV richiede un approccio pragmatico e mirato, fondato sull’analisi dettagliata della realtà organizzativa.
Solo immergendosi nella concreta comprensione delle dinamiche dei rapporti tra i due organi di controllo è possibile identificare le radici dei problemi e delineare soluzioni effettive.
Tale modello, attraverso esempi concreti, si distingue da tutti gli altri approcci per la sua capacità di fornire risposte dirette, evitando soluzioni generiche e superficiali.
Solo l’analisi concreta della realtà aziendale, eseguita da chi questa realtà la conosce bene, permette di contestualizzare le sfide, garantendo una visione completa e consentendo di adottare strategie mirate che rispondano alle specifiche esigenze.
Continuando ad applicare questo metodo si vuole ora proporre l’analisi di un caso di studio, concreto e verosimile, che possa offrire delle “lezioni apprese”, fornendo insight preziosi per tutte le organizzazioni che intendano migliorare la propria conformità attraverso una collaborazione più profonda tra DPO e OdV.
Indice degli argomenti
Compliance integrata: il caso concreto e verosimile
Alfredo è stato da poco assunto come Responsabile commerciale di Alfa (broker assicurativo forma giuridica Società per azione). Egli, prima, era dipendente di Beta (broker assicurativo forma giuridica Società a Responsabilità Limitata specializzato nell’offrire servizi mirati al segmento di mercato high spender). Al momento dell’interruzione del suo precedente rapporto di lavoro non gli sono stati revocati i privilegi di accesso ai sistemi di Beta. Pertanto, egli può ancora accedere in modo abusivo.
Quindi, lo stesso Alfredo sfrutta tale lacuna e utilizzando device aziendali, dal suo nuovo ufficio presso la sede di Alfa, si collega e accede ripetutamente, ai sistemi di Beta (suo ex datore di lavoro) per carpire informazioni riservate. Successivamente, utilizza tali informazioni per proporre ai clienti (persone fisiche ed aziende) di Alfa offerte più vantaggiose da parte del suo nuovo datore di lavoro (la stessa Alfa).
Così, Alfredo, con tali informazioni, acquisisce una serie di nuovi clienti, sottraendoli a Beta.
In Alfa sono tutti felicemente sopresi delle ottime performance di Alfredo, nell’acquisire nuovi clienti, ampiamente sopra la media dei suoi nuovi colleghi, tanto che gli riconoscono un rilevante premio di produzione.
Da parte sua, la Direzione di Beta, avendo constatato l’inaspettata, repentina e significativa riduzione del pacchetto clienti, per comprenderne le cause, su suggerimento del Responsabile del sistema di gestione, esegue un controllo degli accessi ai sistemi informatici e constata che le credenziali di accesso di Alfredo non erano mai state revocate. Quindi, la Direzione di Beta, dopo aver raccolto sufficienti prove, presenta denuncia presso la locale Stazione Carabinieri per i reati ravvisabili nei fatti accertati.
Gli effetti nella prospettiva di Alfredo
Ora, partendo da questo ipotetico caso analizziamo gli effetti nella prospettiva di Alfredo, di Beta e di Alfa.
Quale reato viene compiuto da Alfredo?
A carico di Alfredo risulta ravvisabile il reato di “Accesso abusivo ad un sistema informatico o telematico” previsto e punito dall’art. 615 ter c.p. che rientra nel perimetro dei reati presupposto ex D.lgs. 231/2001, specificamente dall’art. 24 bis.
È altresì ipotizzabile a carico di Alfredo, ove ne sussistano tutti gli specifici elementi della condotta, il reato di “Frode informatica” ex art. 640 ter c.p..
Si veda sul punto la pronuncia della Suprema Corte (Cassazione Sez. II Penale, 29 maggio 2019, n. 26604) per la quale “il delitto di accesso abusivo ad un sistema informatico può concorrere con quello di frode informatica” essendo diversi i beni giuridici tutelati e le condotte sanzionate.
Sempre la Cassazione ha precisato, a proposito della condotta di cui all’art. 640 ter, che: “È questo un reato a forma libera che, finalizzato pur sempre all’ottenimento di un ingiusto profitto con altrui danno, si concretizza in un’illecita condotta intensiva, ma non alterativa del sistema informatico o telematico”.
Il reato di frode informatica, ex art. 640 ter c.p. è stato aggiunto, a seguito delle modifiche intervenute con D.lgs. 184/2021 e D.lgs. 150/2022, ai “Delitti informatici e trattamento illecito dei dati” previsti dall’art. 24-bis del Dlgs. 231/2001.
Perché il caso rientra nel D.lgs. 231/2001?
Il caso rientra nel perimetro del D.lgs. 231/2001 in quanto vi è un evidente vantaggio per Alfa derivante dallo sfruttamento di una lacuna nei sistemi di Beta.
Questo esempio sottolinea come le misure di protezione devono essere poste in atto anche per mitigare la conseguenza di atti effettuati da terzi in danno della società, che nel caso in esame è vittima dell’evento.
Gli effetti nella prospettiva di Alfa
Ovviamente, ai fini della prevenzione del reato occorre definire le misure per Alfa e non per Beta, poiché il reato:
- è stato compiuto all’interno del perimetro di Alfa, utilizzando asset interni all’azienda;
- è la stessa Alfa ad avvantaggiarsene.
Ciò, sebbene Beta sia stata inadempiente sotto il profilo organizzativo e in particolare della protezione dei dati personali, considerando che per le organizzazioni che operano nel mercato assicurativo il rapporto con la clientela si basa sui valori della lealtà e del rispetto e la componente della reputazione è molto importante.
Vediamo, ora, di comprendere quali misure avrebbero dovuto adottare le due organizzazioni e, nello specifico quali controlli avrebbero dovuto mettere in atto i rispettivi DPO e OdV.
Riesame del MOGC e dei sistemi Whistleblowing e disciplinare
A seguito del compimento di un reato nel perimetro del D.lgs. 231/2001, riconducibile ad una mancata consapevolezza da parte di un collaboratore in merito ai comportamenti etici che l’azienda pretende vengano assunti dagli stessi, l’OdV di Alfa deve riconsiderare in termini generali l’efficacia del modello e deve quindi avviare delle azioni correttive.
Specificamente deve:
- riconsiderare i riferimenti presenti nel Codice Etico e nel Modello Organizzativo in relazione ai reati informatici;
- rivedere i “Criteri di condotta” del Codice Etico sotto il profilo dei doveri del personale (tutela patrimonio aziendale, trattamento dati) e delle relazioni con i clienti (contratti e comunicazioni con nuovi e storici);
- rivalutare l’efficacia della formazione, sia iniziale che ad intervalli, somministrata ai collaboratori sui principi riportati nel Codice Etico e l’utilizzo dei device aziendali;
- comprendere se e come gli uffici amministrativi/controllo di gestione tengono sotto controllo le performance aziendali e quali segnali di allarme sono posti in atto in caso di deviazioni significative dagli standard aziendali;
- valutare l’efficacia dei controlli e delle verifiche aziendali (ivi compresi i flussi di informazioni che favoriscono l’esercizio delle funzioni di vigilanza).
Inoltre, laddove emergessero delle falle nelle procedure le stesse devono essere modificate e oggetto di formazione al personale e successivamente di audit.
È altresì opportuno riconsiderare il sistema whistleblowing e quello disciplinare, sempre nel rispetto della materia giuslavoristica; oltre ad indagare eventualmente il ruolo di collegio sindacale e della società di revisione.
Responsabilità dei membri dell’OdV
È importante chiarire la responsabilità dei membri dell’OdV, un argomento complesso a causa della mancanza di disposizioni legislative esaustive e delle diverse interpretazioni della dottrina e della giurisprudenza.
Dal punto di vista civile, se i membri dell’OdV violano i loro doveri causando un danno all’ente, si applicano i principi generali di responsabilità contrattuale ed extracontrattuale. Pertanto, sarà necessario dimostrare:
- la violazione degli obblighi di vigilanza (obbligazione di mezzi);
- l’assenza dei requisiti di professionalità, diligenza professionale (ex art. 1176 c.c.);
- la legittimazione attiva dell’Ente:
- l’onere della prova che grava sull’Ente.
Dal punto di vista penale, la situazione è meno chiara. La responsabilità dei membri deve tenere conto dello status dell’OdV come controllore autonomo e indipendente e delle sue funzioni, nonché dei principi fondamentali di legalità, colpevolezza e personalità.
La maggior parte della dottrina ha escluso la possibilità di una responsabilità penalmente rilevante, sostenendo che l’OdV non ha una posizione di garanzia (ex art. 40 c.p.) e quindi non è obbligato a prevenire i reati (ex. D.lgs. 231), a differenza di amministratori e sindaci.
Tuttavia, recenti sentenze del Tribunale di Milano (n. 13490/2019 e n. 1074/2021) hanno parzialmente messo in discussione questa posizione, attribuendo all’OdV un controllo diretto sugli atti di gestione della società e un ruolo nella prevenzione dei reati. Questa interpretazione è stata criticata dalla dottrina prevalente, che teme una possibile confusione dei ruoli dei vari organi di controllo, dato lo status dell’OdV come controllore di secondo livello.
In attesa di future decisioni che possano stabilire principi più chiari, sarebbe auspicabile un intervento legislativo specifico in linea con lo spirito del D.lgs. 231 e con l’obiettivo di un sistema di compliance integrato capace di implementare misure correttive efficaci.”
Conseguenti adempimenti privacy nel contesto organizzativo di Alfa
Alfa è responsabile di aver causato un data breach a un’altra azienda con la quale non ha peraltro in essere alcun rapporto. Il DPO di Alfa, venuto a conoscenza dei fatti grazie ai flussi, in modo analogo a quanto effettuato dall’OdV, in base alle sovrapposizioni che in parte si possono riscontrare tra queste due funzioni dovrebbe comprendere:
- la sanzione comminata ad Alfredo;
- la pianificazione, implementazione e sorveglianza dell’efficacia delle misure che devono essere adottate per evitare il ripetersi di un evento come quello occorso.
Gli effetti nella prospettiva di Beta
Analizziamo, ora, quelli che possono essere gli effetti nella prospettiva di Beta.
Quali conseguenze per Beta
Beta ha subito un data breach e, per quanto ci è noto, non ha applicato – o ha applicato in modo inefficace – la procedura prevista nel caso di cessazione del rapporto di lavoro con un collaboratore.
Conseguentemente è esposta:
- a un’sanzione pecuniaria da parte del Garante privacy;
- al risarcimento del danno da parte degli interessati;
- al danno reputazionale considerando che in modo particolare nel settore in cui opera (assicurativo) la scelta della clientela si basa su un rapporto di lealtà e stima.
Potrà trovare un limitato strumento di compensazione, costituendosi parte civile nel processo penale a carico di Alfredo che potrebbe in parte lenire tali danni.
L’evento dalla prospettiva del DPO di Beta
Una volta noto l’evento il DPO di Beta dovrebbe verificare:
- la presenza, l’efficacia e l’applicazione delle procedure per la dimissione di un collaboratore[1];
- che a tutti i collaboratori non più in organico siano state dismesse le credenziali.
L’evento dalla prospettiva dell’ODV di Beta
Dalla prospettiva dell’OdV di Beta non sono da rilevare controlli specifici.
La stessa Beta è rimasta vittima di un reato e non si profila a suo carico alcuna responsabilità amministrativa per reato presupposto, anche se, nell’ambito dei flussi verso l’OdV, l’organo dovrà essere informato dell’evento.
Conclusioni
In conclusione, questo articolo si è proposto di ispirare e guidare, attraverso un approccio pragmatico, coloro che cercano di spingersi oltre la superficie della conformità normativa per raggiungere un livello di efficienza più profondo e duraturo.
Si è cercato di dimostrare come l’analisi di un caso concreto e verosimile possa essere un catalizzatore potente per guidare il cambiamento e migliorare la resilienza aziendale di fronte a sfide complesse.
Restiamo convinti che solo l’analisi e la discussione dei casi possa davvero aiutare nella risoluzione dei problemi aziendali complessi, fornendo linee guida pratiche ed essere anche un utile veicolo per la formazione del personale.
Tale approccio consente, infine, di introdurre un ulteriore spunto di riflessione, meritevole di approfondimento, circa la “la qualità dei dati”, ovvero l’importanza della creazione di un sistema di gestione della qualità dei dati (DQM), quale ad esempio quello strutturato secondo la normativa ISO 8000-61 in combinazione con la normativa ISO 9001, secondo un approccio per processi, per procedimenti ripetibili ed affidabili, di miglioramento continuo, di eliminazione dei fattori di scarsa qualità, di misurazione della maturità organizzativa, di coinvolgimento del personale.
La prospettiva di un sistema di DQM efficace, nel quale i dati a disposizione sono attendibili ed affidabili, si traduce per il business aziendale in competitività sul mercato e fiducia nelle relazioni commerciali.
[1] Vedi art 32 GDPR.
