Whistleblowing e NIS2: quando la segnalazione diventa governance

C’è un momento preciso in cui la complessità normativa smette di essere un problema teorico e diventa un problema operativo: quando un dipendente, un collaboratore o un fornitore si accorge che qualcosa non va (un accesso anomalo ai sistemi, una fuga di dati, una procedura di sicurezza aggirata) e non sa a chi riferirlo, né in quale ordine, né con quale forma. In quell’istante, la distanza tra compliance e realtà aziendale diventa misurabile, e spesso è abissale.

Dal 15 gennaio 2026 questo scenario non è più solo un rischio teorico. La Determinazione ACN n. 379907/2025 (adottata il 19 dicembre 2025, pubblicata il 24 dicembre 2025 e applicabile dal 15 gennaio 2026) e le Linee guida per la definizione del processo di gestione degli incidenti di sicurezza informatica, pubblicate il 31 dicembre 2025 con valore di indirizzo e non vincolanti sul piano regolatorio, hanno reso operativi gli obblighi di notifica al CSIRT Italia per i soggetti essenziali e importanti ai sensi del D.Lgs. 138/2024. Ma la vera sfida non è rispettare la scadenza delle 24 ore.

È capire che quella notifica esterna è l’atto finale di un processo che comincia molto prima e che può essere innescato da una segnalazione interna.

Il nodo irrisolto: la segnalazione che non trova casa

Nell’architettura di compliance di un’organizzazione soggetta alla NIS2 convivono oggi almeno quattro regimi normativi che si intersecano in modo non lineare: il D.Lgs. 138/2024 di recepimento della direttiva NIS2, il Regolamento GDPR con il D.Lgs. 196/2003, il D.Lgs. 231/2001 sulla responsabilità amministrativa degli enti e il D.Lgs. 24/2023 sul whistleblowing. A questi si aggiunge, dal 24 gennaio 2026, il D.Lgs. 211/2025, che ha introdotto nuovi reati presupposto legati alla violazione delle misure restrittive dell’Unione europea, estendendo contestualmente le tutele del D.Lgs. 24/2023 ai segnalanti di tali violazioni.

Il risultato pratico è che una singola segnalazione interna (per esempio: un dipendente del reparto IT che rileva un accesso sospetto alla rete aziendale) può contemporaneamente: configurare un incidente significativo ai sensi dell’art. 25 del D.Lgs. 138/2024, che impone la pre-notifica al CSIRT Italia entro 24 ore dall’evidenza; costituire potenzialmente un data breach ai sensi dell’art. 33 del GDPR, con il conseguente obbligo di notifica al Garante entro 72 ore; rientrare nella nozione di reato informatico ex art. 24-bis del D.Lgs. 231/2001, attivando i flussi informativi verso l’Organismo di vigilanza; essere infine veicolo di una segnalazione whistleblowing ai sensi del D.Lgs. 24/2023, se l’accesso anomalo è frutto di condotte interne dolose o di omissioni organizzative.

Nessuno di questi regimi è autosufficiente. Ognuno ha i suoi termini, le sue figure di riferimento, i suoi canali. E nessuno, preso singolarmente, garantisce che l’informazione rilevante arrivi nel posto giusto al momento giusto.

La NIS2 non si appalta: il punto fermo delle FAQ ACN

Uno degli aspetti che ha generato più equivoci nella fase di prima applicazione riguarda il rapporto tra soggetti NIS e fornitori ICT. Le FAQ pubblicate dall’ACN hanno chiarito con nettezza il principio fondamentale: l’obbligo di notifica degli incidenti significativi al CSIRT Italia non può essere delegato ai fornitori di servizi gestiti.

Spetta al soggetto NIS, attraverso il proprio Referente CSIRT (figura la cui designazione doveva avvenire entro il 31 dicembre 2025), gestire l’interlocuzione con l’autorità e trasmettere le notifiche. Il fornitore può supportare l’organizzazione, può contribuire alla raccolta delle evidenze tecniche, ma non può sostituirla nella responsabilità della notifica. Come ha osservato anche ICT Security Magazine negli adempimenti NIS2, la delega operativa è consentita, ma la responsabilità rimane in capo agli organi apicali e non è trasferibile.

Le FAQ introducono tuttavia una distinzione importante per i servizi cloud. Nella regola generale, se sia il cliente sia il fornitore cloud sono entrambi soggetti NIS, entrambi sono tenuti a notificare l’incidente significativo rispetto alla propria sfera di impatto. Fa eccezione il modello Infrastructure as a Service (IaaS): in quel caso, dove il cliente mantiene il controllo su sistemi operativi, applicazioni e configurazioni, l’obbligo di notifica grava esclusivamente sul cliente. La distinzione non è accademica: etichettare genericamente come «cloud» qualsiasi esternalizzazione, senza identificare il modello di servizio, significa esporsi a decisioni errate nel momento peggiore.

La supply chain al centro: le nuove determinazioni di aprile 2026

Il 13 aprile 2026, a conferma che il quadro normativo è ancora in evoluzione, l’ACN ha pubblicato due nuove determinazioni che aggiornano significativamente il perimetro degli obblighi. La Determinazione n. 127437/2026 aggiorna e sostituisce integralmente la precedente n. 379887/2025 e introduce, all’art. 18, l’obbligo per i soggetti NIS di elencare i propri fornitori rilevanti nell’ambito dell’aggiornamento annuale delle informazioni sul Portale ACN, indicando denominazione, codice fiscale, sede legale, codici CPV delle forniture e il criterio di rilevanza applicato.

La Determinazione n. 127434/2026 fissa invece i termini per i soggetti inseriti per la prima volta nell’elenco NIS nel corso del 2026: obbligo di notifica degli incidenti significativi dal 1° gennaio 2027 e misure di sicurezza di base entro il 31 luglio 2027.

La nozione di «fornitore rilevante NIS» include non solo i classici operatori ICT (cloud provider, MSP, data center, DNS) ma anche forniture non strettamente tecnologiche che siano imprescindibili per la continuità del servizio NIS: connettività fissa e mobile non ridondata, alimentazione elettrica.

È un ampliamento che porta la supply chain ben oltre il perimetro IT e che rende ancora più urgente, per le organizzazioni, costruire una governance delle dipendenze esterne coerente con il sistema di incident response. I contratti con i fornitori rilevanti devono prevedere obblighi espliciti di notifica tempestiva degli eventi di sicurezza, cooperazione nelle attività di risposta e diritto di audit: senza queste clausole, il soggetto NIS rischia di non essere in grado di rispettare le scadenze di 24 e 72 ore, pur non essendo tecnicamente responsabile dell’evento.

Le Linee guida ANAC e la geometria dei canali

Il 26 novembre 2025, con la Delibera ANAC n. 478/2025 (pubblicata in G.U. n. 300 del 29 dicembre 2025), l’ANAC ha approvato le Linee guida n. 1/2025 sui canali interni di segnalazione, completando così il quadro avviato con la Delibera n. 311/2023. Il documento affronta in modo diretto il rapporto tra whistleblowing e Modello 231, chiarendo che l’istituzione del canale interno non è un adempimento autonomo: deve essere coerentemente integrato nella mappatura dei rischi del Modello organizzativo e nei flussi informativi verso l’Organismo di vigilanza.

Sul piano tecnico, le Linee guida sanciscono l’inadeguatezza della posta elettronica ordinaria come canale di segnalazione, salvo che sia accompagnata da misure di mitigazione adeguate (crittografia end-to-end, autenticazione a due fattori) giustificate da una specifica DPIA.

La riservatezza del segnalante deve essere garantita attraverso un sistema di key code che consenta l’interlocuzione senza rivelare l’identità. Gli enti sono inoltre obbligati a garantire che l’accesso al canale dalla rete aziendale non sia tracciabile dai sistemi IT interni o dai superiori gerarchici: un requisito che non è neutro rispetto alla NIS2. Un sistema di segnalazione whistleblowing che transitasse su infrastrutture aziendali compromesse o insufficientemente segregate potrebbe vanificare sia la riservatezza del segnalante sia la qualità delle evidenze raccolte. La sicurezza del canale di segnalazione è, in altri termini, anche una misura di sicurezza informatica.

L’OdV come crocevia: da archivio passivo a presidio attivo

Il vero collo di bottiglia del sistema integrato non è tecnologico. È organizzativo. In molte aziende italiane, l’Organismo di vigilanza riceve flussi informativi periodici da CISO e DPO, ma li gestisce in modo prevalentemente passivo: li archivia, li verbalizza, raramente li incrocia. Questo approccio è insufficiente in un contesto in cui un incidente informatico può attivare simultaneamente obblighi NIS2, GDPR, 231 e whistleblowing.

Un modello evoluto richiede che l’OdV diventi un vero crocevia informativo. Non significa che l’OdV debba gestire la risposta tecnica agli incidenti (non è la sua funzione), ma che debba ricevere informazioni tempestive sugli incidenti significativi, valutarne la rilevanza ai fini del Modello 231 (soprattutto con riferimento all’art. 24-bis, reati informatici e trattamento illecito di dati) e coordinarsi con il DPO per le implicazioni sul trattamento dei dati personali. Un registro unificato degli incidenti, che alimenti contemporaneamente il registro data breach GDPR, il report NIS2 verso il CSIRT Italia e il flusso informativo all’OdV, non è un lusso organizzativo ma una condizione di funzionamento del sistema.

Le valutazioni di impatto integrate (DPIA, analisi di rischio NIS2 e mappatura rischio reato ai fini 231) sono lo strumento attraverso cui questi tre regimi possono convergere in una visione unitaria. Svolte separatamente dai rispettivi presidi, rischiano di produrre risultati contraddittori o lacunosi. Svolte in modo coordinato, consentono all’organizzazione di avere una lettura coerente del proprio profilo di rischio.

Il Referente CSIRT e il gestore della segnalazione: un coordinamento necessario

La Determinazione ACN n. 379907/2025 e le Linee guida del 31 dicembre 2025 descrivono il Referente CSIRT come la figura deputata all’interlocuzione ufficiale con il CSIRT Italia, responsabile della trasmissione delle notifiche per conto dell’organizzazione. Le Linee guida ANAC del novembre 2025 descrivono il gestore della segnalazione come il soggetto destinatario delle segnalazioni whistleblowing, responsabile dell’istruttoria e dei flussi verso l’OdV. Sono due figure distinte, con ruoli distinti. Ma possono operare sugli stessi eventi.

Quando un dipendente segnala tramite il canale whistleblowing un comportamento anomalo che si rivela essere un incidente informatico significativo, il gestore della segnalazione e il Referente CSIRT devono coordinarsi immediatamente. Il rischio opposto è tutt’altro che teorico: i due processi procedono in parallelo, ignari l’uno dell’altro. Il gestore potrebbe avviare un’istruttoria interna destinata a durare settimane, mentre i termini NIS2 per la pre-notifica scadono nelle 24 ore successive all’evidenza dell’incidente. La mancata sincronizzazione non è solo un’inefficienza operativa: è una violazione.

Le procedure interne devono quindi prevedere espressamente un meccanismo di escalation che, nel momento in cui una segnalazione whistleblowing presenta profili di incidente informatico, attivi immediatamente il coinvolgimento del Referente CSIRT e avvii in parallelo il processo di notifica NIS2. La riservatezza del segnalante non è incompatibile con questo meccanismo, a patto che la procedura sia progettata in modo da separare l’identità del segnalante dalla sostanza dell’incidente nelle comunicazioni verso il CSIRT Italia. Su questo punto, la lettura degli adempimenti NIS2 per la governance aziendale è un riferimento operativo utile per costruire la catena di responsabilità interna.

Verso un sistema di compliance integrato: architettura minima

Costruire un sistema di compliance integrato non significa unificare tutto sotto un unico ufficio o strumento. Significa progettare le interfacce tra presidi che mantengono le loro specificità senza operare in silos. Sulla base del quadro normativo vigente, si possono identificare alcuni elementi essenziali.

Il primo è un registro unificato degli incidenti e delle segnalazioni, progettato per tracciare in modo coerente le informazioni rilevanti ai fini NIS2, GDPR e 231, senza duplicare i dati e rispettando i requisiti di riservatezza del whistleblowing. Il secondo è una matrice di escalation, che definisca per ciascuna tipologia di segnalazione o incidente i soggetti da coinvolgere (Referente CSIRT, DPO, OdV, management, legal) e i tempi di attivazione, in modo che la scadenza delle 24 ore NIS2 non sia mai compromessa da un’istruttoria whistleblowing in corso. Il terzo è un protocollo di coordinamento tra Referente CSIRT, DPO e OdV, con incontri periodici e, in caso di incidente, un flusso informativo immediato con ruoli e contenuti predefiniti.

Il quarto è una formazione integrata: non sessioni compartimentate su GDPR, NIS2 e 231, ma percorsi che aiutino il personale a riconoscere le intersezioni e a sapere a chi rivolgersi in ciascun scenario. Il quinto, rafforzato dalla Determinazione ACN n. 127437/2026 del 13 aprile 2026, è la revisione e classificazione dei contratti con i fornitori rilevanti, per inserire obblighi espliciti di notifica interna degli incidenti, di cooperazione nelle attività di risposta e di condivisione delle evidenze forensi, in modo che la supply chain non diventi un punto cieco del sistema nel momento in cui i termini scorrono.

Una questione di cultura, prima che di procedure

C’è una tentazione che attraversa ogni discussione sulla compliance integrata: ridurla a un problema di processi e strumenti. I processi contano, gli strumenti contano. Ma il punto di partenza è culturale.

Un dipendente che teme ritorsioni non usa il canale whistleblowing, anche se tecnicamente impeccabile. Un CISO che percepisce l’OdV come un organo formale di controllo non lo coinvolge nei momenti critici. Un fornitore che non ha interiorizzato gli obblighi contrattuali aspetta a segnalare un incidente nel timore di perdere il cliente. In tutti questi casi, la procedura esiste ma non funziona.

Le Linee guida ANAC insistono sulla formazione del personale e sul ruolo degli enti del Terzo settore nel promuovere la cultura della segnalazione. Le Linee guida ACN insistono sulle lesson learned dopo ogni incidente come processo istituzionalizzato, non come riflessione informale. Entrambi i documenti riconoscono che il rispetto formale degli obblighi non è sufficiente: ciò che conta è la capacità dell’organizzazione di rilevare tempestivamente i problemi, di comunicarli senza reticenze interne, di imparare dagli errori.

Il 2026 è l’anno in cui questa capacità viene messa alla prova, non più in teoria ma nella pratica quotidiana, con oltre 21.000 soggetti NIS censiti dall’ACN. Le organizzazioni che hanno costruito un sistema di compliance integrato (dove il canale di segnalazione whistleblowing, il processo di incident response NIS2 e i flussi informativi verso OdV e DPO sono progettati per lavorare insieme) sono quelle che riusciranno a rispettare le scadenze di 24 e 72 ore non perché hanno una buona procedura scritta, ma perché hanno un’organizzazione che sa cosa fare quando l’incidente accade davvero.