Il tema scelto per la rubrica “Dialoghi Penali” esplora l’impatto della direttiva sul MOG 231 della disciplina contenuta nella NIS2.
1. Due discipline con finalità diverse
Il rapporto tra modello di organizzazione, gestione e controllo previsto dal decreto legislativo 8 giugno 2001, n. 231 e disciplina NIS2 nasce dall’incontro di due sistemi normativi distinti, ma destinati a incidere sulla medesima realtà organizzativa. Il primo è costruito intorno alla responsabilità amministrativa dell’ente dipendente dalla commissione di determinati reati; il secondo mira a innalzare il livello di sicurezza dei sistemi informativi e di rete, imponendo misure di gestione del rischio, obblighi di segnalazione e presidi di vigilanza.
La direttiva (UE) 2022/2555 stabilisce, tra l’altro, misure di gestione dei rischi di cyber-sicurezza e obblighi di segnalazione per soggetti operanti nei settori individuati dalla disciplina europea, oltre a regole in materia di vigilanza ed esecuzione. Il MOG 231, invece, opera nel perimetro della responsabilità dell’ente per gli illeciti amministrativi dipendenti da reato, secondo quanto previsto dall’art. 1 del d.lgs. n. 231/2001.
La prima conseguenza metodologica è che la conformità alla NIS2 non equivale, da sola, all’adozione e all’efficace attuazione di un MOG 231. Allo stesso modo, l’esistenza di un MOG non dimostra automaticamente che l’organizzazione abbia adottato misure tecniche e procedurali adeguate ai rischi cyber. I due sistemi possono e, in molti casi, devono essere coordinati, ma non sono fungibili.
2. Il punto di contatto: il rischio informatico come rischio organizzativo
La direttiva NIS2 richiede che le misure di sicurezza siano adeguate ai rischi esistenti e siano costruite secondo un approccio multirischio. Tra gli elementi minimi indicati dall’art. 21 della direttiva (UE) 2022/2555 rientrano le politiche di analisi dei rischi e di sicurezza dei sistemi informativi, la gestione degli incidenti, la continuità operativa, la gestione dei backup e il ripristino in caso di disastro, la gestione delle crisi, la sicurezza della catena di approvvigionamento, la sicurezza nello sviluppo e nella manutenzione dei sistemi, la gestione delle vulnerabilità, la formazione, la sicurezza delle risorse umane e il controllo degli accessi.
Questi ambiti coincidono, almeno in parte, con le aree nelle quali un MOG 231 deve descrivere i processi sensibili, individuare i rischi di reato, stabilire protocolli decisionali, disciplinare i flussi informativi e prevedere controlli e sanzioni. L’intersezione non dipende soltanto dal contenuto tecnico delle misure, ma dalla loro traduzione in responsabilità, procedure verificabili, controlli periodici e documentazione idonea a dimostrare il funzionamento effettivo dell’organizzazione.
In questa prospettiva, la NIS2 può offrire al MOG 231 una griglia aggiornata per la mappatura dei rischi cyber. La valutazione non dovrebbe però limitarsi all’inventario degli asset informatici. Occorre collegare gli asset, i processi aziendali, le persone autorizzate, i fornitori, i livelli di accesso e le conseguenze di un incidente ai reati-presupposto concretamente rilevanti per l’ente.
3. I reati informatici e la colpa di organizzazione
Il raccordo con il MOG assume particolare rilievo per i delitti informatici e il trattamento illecito di dati. L’art. 24-bis del d.lgs. n. 231/2001 include nel catalogo dei reati-presupposto una serie di condotte, tra cui l’accesso abusivo a un sistema informatico o telematico, le interferenze illecite nelle comunicazioni, il danneggiamento di informazioni, dati e programmi informatici e alcune ipotesi di detenzione o diffusione abusiva di codici e programmi.
La presenza di un rischio cyber non comporta, di per sé, la responsabilità dell’ente. Devono essere verificati i presupposti propri del sistema 231: il reato deve essere commesso da un soggetto che abbia il rapporto qualificato previsto dalla legge e nell’interesse o a vantaggio dell’ente; inoltre, la responsabilità dell’organizzazione presuppone una carenza organizzativa rilevante rispetto al reato contestato.
La giurisprudenza di legittimità ha chiarito che la colpa di organizzazione è un elemento costitutivo dell’illecito dell’ente e non può essere confusa con la colpa della persona fisica autrice del reato. La Cassazione penale, Sez. IV, sentenza n. 18413 del 2022 ha sottolineato che la mera assenza o inadeguatezza del modello non è, da sola, sufficiente: occorre individuare specifici deficit dell’assetto organizzativo e il nesso causale tra tali carenze e il reato presupposto. La stessa impostazione è ribadita dalla Cassazione penale, Sez. IV, sentenza n. 570 del 2023, secondo cui non basta accertare l’interesse o il vantaggio dell’ente insieme alla genericità del modello, essendo necessaria la prova positiva della colpa di organizzazione e della sua incidenza causale.
Per il MOG, ciò significa che una clausola generica sull’uso corretto degli strumenti informatici non è normalmente sufficiente. Il modello dovrebbe misurarsi con i rischi effettivi: gestione delle identità digitali, privilegi amministrativi, separazione degli ambienti, autenticazione multifattore, aggiornamento e gestione delle vulnerabilità, registrazione degli eventi, risposta agli incidenti, sicurezza dei fornitori e modalità di conservazione delle evidenze.
4. Governance e responsabilità degli organi direttivi
La NIS2 attribuisce un ruolo centrale agli organi direttivi, chiamati a sovrintendere alle misure di gestione dei rischi e a promuovere la formazione. Questa dimensione di governance deve essere coordinata con l’architettura del MOG, senza sovrapporre automaticamente le funzioni del vertice aziendale, del responsabile della sicurezza informatica, del responsabile della protezione dei dati, dell’internal audit e dell’Organismo di vigilanza.
L’art. 6 del d.lgs. n. 231/2001 richiede, quando il reato è commesso da soggetti apicali, che l’ente dimostri di avere adottato ed efficacemente attuato un modello idoneo, di avere affidato a un organismo dotato di autonomi poteri di iniziativa e controllo il compito di vigilare sul funzionamento e sull’osservanza del modello e di curarne l’aggiornamento, nonché di non avere omesso o insufficientemente esercitato la vigilanza.
L’Organismo di vigilanza non diventa, per il solo fatto del coordinamento con la NIS2, l’organo responsabile della gestione tecnica della cyber-sicurezza. La sua funzione resta quella di vigilare sul modello 231 e sui relativi presidi, ricevere i flussi informativi, valutare le anomalie rilevanti e promuovere, nei limiti delle proprie attribuzioni, l’aggiornamento del sistema. La gestione operativa degli incidenti, la sicurezza delle infrastrutture e l’attuazione delle misure tecniche devono restare attribuite a soggetti competenti e formalmente individuati.
5. Incident reporting e flussi verso l’Organismo di vigilanza
Uno dei principali punti di integrazione riguarda la gestione degli incidenti. La NIS2 considera la gestione degli incidenti, la continuità operativa e il ripristino tra le misure essenziali di sicurezza; inoltre, la disciplina prevede obblighi di segnalazione e poteri di controllo e richiesta di informazioni da parte delle autorità competenti. Per i soggetti essenziali, l’art. 32 della direttiva (UE) 2022/2555 contempla ispezioni, audit, richieste di informazioni e misure di esecuzione, comprese istruzioni vincolanti e sanzioni amministrative.
Il MOG dovrebbe quindi individuare quali eventi cyber debbano essere comunicati all’Organismo di vigilanza, con quali tempi, da parte di chi e attraverso quali canali. Il flusso non dovrebbe riguardare soltanto gli incidenti già notificati all’autorità, perché l’interesse dell’Organismo di vigilanza può estendersi a vulnerabilità, violazioni delle procedure, mancati aggiornamenti, anomalie nei privilegi di accesso, esiti di test e audit, nonché ritardi nell’attuazione delle misure correttive.
La procedura deve tuttavia rispettare la distinzione tra il flusso di compliance tecnica e il flusso 231. Una segnalazione all’autorità competente non sostituisce la valutazione dell’Organismo di vigilanza; viceversa, una comunicazione interna all’Organismo non assolve automaticamente gli obblighi di notifica previsti dalla NIS2. È opportuno disciplinare il coordinamento tra i due percorsi, evitando duplicazioni, ritardi e conflitti nelle responsabilità.
6. Catena di fornitura e servizi esternalizzati
La sicurezza della catena di approvvigionamento è espressamente compresa tra le misure richieste dalla NIS2.
Il rischio può derivare dal fornitore di servizi gestiti, dal cloud provider, dal manutentore del software, dal gestore del data center o da altri soggetti che dispongono di accesso ai sistemi e ai dati dell’organizzazione.
Il MOG dovrebbe riflettere questa esposizione attraverso procedure di qualifica e due diligence, clausole contrattuali, attribuzione di responsabilità, diritto di audit, gestione degli accessi dei fornitori, obblighi di cooperazione in caso di incidente, conservazione dei log e piani di uscita o sostituzione. La relazione con il fornitore non può essere considerata una zona estranea al controllo dell’ente: la delega tecnica non elimina la necessità di governare il rischio organizzativo.
In termini di metodo, l’analisi dovrebbe distinguere i fornitori che svolgono attività meramente accessorie da quelli che supportano funzioni essenziali o processi sensibili per la continuità aziendale. La priorità dei controlli va definita in rapporto all’impatto potenziale dell’indisponibilità, della perdita di integrità o della divulgazione dei dati, non soltanto in base al valore economico del contratto.
7. Aggiornamento, formazione e sistema disciplinare
L’art. 7 del d.lgs. n. 231/2001 collega l’efficace attuazione del modello alla verifica periodica e alla sua eventuale modifica quando emergono violazioni significative o mutamenti nell’organizzazione e nell’attività. L’evoluzione delle minacce cyber, la sostituzione di un fornitore critico, l’introduzione di un nuovo servizio digitale o un incidente significativo possono quindi costituire occasioni per riesaminare il MOG e non soltanto il piano tecnico di sicurezza.
La formazione deve essere differenziata per ruolo. Agli organi direttivi occorre fornire una conoscenza sufficiente dei rischi e delle responsabilità di governance; alle funzioni tecniche servono competenze operative; agli utenti occorre trasmettere procedure concrete su autenticazione, gestione delle credenziali, phishing, segnalazione delle anomalie e uso dei dispositivi. La formazione dovrebbe essere tracciata e verificata, perché la semplice disponibilità di una policy non dimostra che essa sia stata compresa e applicata.
Il sistema disciplinare deve inoltre rendere effettive le regole cyber rilevanti per il MOG. Le violazioni devono essere individuate con sufficiente precisione e collegate a conseguenze proporzionate, nel rispetto della disciplina applicabile ai rapporti di lavoro e dei contratti. La sanzione non deve essere utilizzata per scoraggiare la segnalazione di incidenti: un sistema efficace deve distinguere l’errore tempestivamente comunicato, la negligenza, l’elusione consapevole e la condotta dolosa.
8. NIS2 e MOG 231: integrazione, non automatismo
Il coordinamento tra NIS2 e MOG 231 può produrre un sistema più coerente, soprattutto quando la mappatura dei rischi, i protocolli, gli audit, la formazione, la gestione degli incidenti e i flussi informativi vengono progettati con criteri comuni. Tuttavia, l’integrazione documentale non deve trasformarsi in un modello meramente compilativo.
La giurisprudenza ha più volte evidenziato che la responsabilità dell’ente richiede un accertamento concreto. La Cassazione penale, Sez. IV, sentenza n. 21704 del 2023 ha ricondotto la colpa di organizzazione all’inottemperanza dell’ente all’obbligo di adottare cautele organizzative e gestionali necessarie a prevenire i reati, mentre la Cassazione penale, Sez. V, sentenza n. 19096 del 2025 ha ribadito che la mancata adozione o l’inefficace attuazione del modello non costituiscono automaticamente l’intero contenuto della tipicità dell’illecito, ma devono essere valutate nel quadro della specifica colpa organizzativa contestata.
Ne deriva che l’adempimento agli obblighi NIS2 può rappresentare un elemento significativo nella valutazione dell’assetto organizzativo, ma non costituisce una certificazione preventiva di idoneità del MOG e non esclude automaticamente la responsabilità dell’ente. La valutazione resterà ancorata al reato concretamente contestato, al ruolo dell’autore, all’interesse o vantaggio dell’ente, alle procedure effettivamente vigenti e al loro funzionamento nel caso concreto.
9. Una possibile agenda operativa
Per un ente soggetto alla NIS2 e già dotato di MOG 231, il percorso di coordinamento può muovere da una verifica del perimetro applicabile e dei soggetti responsabili. È poi necessario confrontare la mappatura NIS2 dei sistemi, dei servizi, dei processi e dei fornitori con la mappatura 231 delle attività sensibili e dei reati-presupposto.
Il passaggio successivo consiste nell’individuare le sovrapposizioni e le lacune: gestione degli accessi, vulnerabilità, incident response, continuità operativa, sicurezza della supply chain, formazione, audit, conservazione delle evidenze e sistema disciplinare. Per ciascun presidio occorre definire un proprietario del processo, un controllo verificabile, la periodicità della verifica, il flusso verso l’Organismo di vigilanza e la procedura di remediation.
Infine, il sistema dovrebbe essere sottoposto a test e riesami periodici. Un incidente, un quasi incidente, un audit negativo o una modifica significativa dell’infrastruttura devono attivare una valutazione documentata sulla necessità di aggiornare procedure, deleghe, protocolli e parti speciali del MOG. L’obiettivo non è duplicare i documenti, ma rendere dimostrabile che la sicurezza informatica è stata incorporata nei processi decisionali e nei controlli dell’ente.
10 Conclusioni
NIS2 e MOG 231 appartengono a piani normativi diversi: la prima impone un sistema di gestione e controllo del rischio cyber rivolto alla resilienza dei soggetti interessati; il secondo opera come presidio di prevenzione della responsabilità dell’ente per reati-presupposto. La loro relazione più utile non è quella della sostituzione, ma quella dell’integrazione governata.
Un MOG aggiornato alla dimensione cyber deve rappresentare i rischi informatici in modo concreto, attribuire responsabilità effettive, ricevere informazioni tempestive, controllare la catena di fornitura e collegare le misure tecniche alle conseguenze organizzative e disciplinari. Un sistema NIS2 correttamente attuato, a sua volta, dovrebbe dialogare con il MOG senza assumere che la conformità tecnica risolva ogni questione 231.
La domanda centrale, perciò, non è se la NIS2 sostituisca il MOG 231, ma se l’ente sia in grado di dimostrare che il rischio informatico è stato conosciuto, governato, monitorato e riesaminato attraverso un assetto organizzativo effettivamente funzionante.