NIS2 e CdA: la delibera diventa la prova della cybersicurezza

L’art. 23 del D.Lgs. 138/2024 non chiede al consiglio di amministrazione di capire di sicurezza informatica. Chiede di decidere e di poterlo dimostrare. Conclusa il 31 dicembre 2025 la fase di prima applicazione e fissato a ottobre 2026 il termine per le misure di sicurezza di base, la distanza tra ratificare e deliberare smette di essere una sfumatura organizzativa e diventa un fatto verificabile.

Nella maggior parte dei consigli di amministrazione italiani la cybersicurezza entra all’ordine del giorno una volta l’anno, sotto forma di presentazione. Il CISO — o il fornitore — espone lo stato dell’arte, elenca gli investimenti, mostra una matrice di rischio a colori. Il consiglio prende atto. Il verbale registra che l’argomento è stato trattato.

Quel verbale non prova quello che si crede provi. E il momento in cui qualcuno lo chiederà non è più un’ipotesi di scuola.

Il D.Lgs. 4 settembre 2024, n. 138, che recepisce la direttiva (UE) 2022/2555, è in vigore dal 16 ottobre 2024, ma i suoi obblighi sostanziali sono stati scaglionati. L’art. 42, comma 1, lettera c), ha previsto una fase di prima applicazione — conclusa il 31 dicembre 2025 — nel corso della quale l’Agenzia per la cybersicurezza nazionale ha definito modalità, specifiche e tempi graduali di implementazione: la determinazione n. 164179 del 14 aprile 2025 per le specifiche di base degli obblighi di cui agli artt. 23, 24, 25, 29 e 32; la determinazione n. 379907 del 19 dicembre 2025 per le misure di sicurezza e per la casistica degli incidenti significativi. Il regime di notifica è oggi operativo. Il termine per la piena implementazione delle misure di base è fissato a ottobre 2026. Dopo quella data, la fase di accompagnamento lascia il posto a quella di verifica.

Non c’è più, quindi, la distanza che nel 2024 permetteva di trattare la materia come un adempimento futuro.

Quattro doveri e un flusso informativo

L’art. 23 attribuisce agli organi di amministrazione e agli organi direttivi dei soggetti essenziali e importanti un nucleo di doveri che il decreto colloca direttamente in capo al vertice.

Il comma 1 ne indica tre: approvare le modalità di implementazione delle misure di gestione dei rischi per la sicurezza informatica adottate ai sensi dell’art. 24; sovrintendere all’implementazione degli obblighi del Capo IV e dell’art. 7; rispondere delle violazioni previste dal decreto.

Il comma 2 aggiunge la formazione: quella dei componenti degli organi e quella, coerente con la prima, da promuovere periodicamente verso i dipendenti.

Il comma 3 chiude il cerchio, ed è la disposizione che le letture divulgative citano meno: gli organi di amministrazione e direttivi sono informati su base periodica o, se opportuno, tempestivamente, degli incidenti e delle notifiche di cui agli articoli 25 e 26. Non è una previsione accessoria. È l’unica norma del decreto che descrive, sia pure in forma minima, il flusso informativo che deve alimentare la decisione del consiglio.

Sul piano della responsabilità personale, il decreto si limita a stabilire che gli organi «sono responsabili delle violazioni». È la direttiva recepita, all’art. 20, paragrafo 1, a esplicitarne la proiezione sulle persone fisiche: chi esercita funzioni dirigenziali di vertice può essere ritenuto responsabile dell’inadempimento del soggetto che rappresenta.

Letta come elenco di adempimenti, la norma sembra modesta: un’approvazione, una vigilanza, una formazione, un’informativa. Letta per quello che è — una norma sulla titolarità della decisione — cambia l’oggetto stesso della verifica.

Approvare non è prendere atto

La differenza tra prendere atto e approvare non è formale. Prendere atto significa registrare che qualcun altro ha deciso. Approvare significa assumere la decisione, e quindi assumerne i presupposti: l’informazione su cui si fonda, le alternative che sono state scartate, il rischio che resta dopo le misure adottate.

L’art. 23 usa il secondo verbo. E lo usa riferendolo non alle misure in sé, ma alle modalità di implementazione delle misure. È una precisazione che quasi tutte le letture divulgative saltano, e che invece pesa: al consiglio non è chiesto di scegliere un firewall, è chiesto di approvare il modo in cui l’organizzazione traduce il rischio in misure. Cioè un processo, non un acquisto.

Questo colloca la disposizione sullo stesso piano dell’art. 2086, secondo comma, del codice civile, che impone all’imprenditore operante in forma societaria o collettiva di istituire un assetto organizzativo, amministrativo e contabile adeguato alla natura e alle dimensioni dell’impresa, anche in funzione della rilevazione tempestiva della crisi e della perdita della continuità aziendale. Il rischio informatico vi rientra come qualsiasi altro rischio idoneo a compromettere quella continuità.

E la ripartizione interna è già scritta altrove: l’art. 2381 del codice civile affida agli organi delegati la cura dell’adeguatezza dell’assetto e al consiglio la valutazione, sulla base delle informazioni ricevute. È la stessa coppia — attuare e sovrintendere, riferire e valutare — che l’art. 23 riscrive in materia di sicurezza informatica, con l’aggiunta di un obbligo informativo tipizzato al comma 3.

L’art. 23 non crea, dunque, un dovere nuovo. Rende esplicito, e assistito da un apparato di vigilanza e di sanzione amministrativa (artt. 37 e 38 del decreto), un dovere che il diritto societario esprimeva già in forma generale.

Lo spostamento dell’oggetto della prova

Il punto che le organizzazioni tendono ancora a non mettere a fuoco è dove si sposta l’onere dimostrativo.

Nel modello precedente, la domanda dell’autorità era: quali misure avete adottato? La risposta era un inventario — tecnologie, contratti, certificazioni. Nel modello introdotto dalla NIS2, la domanda è doppia: la misura era operativa il giorno dell’incidente? e, subito dopo, chi ha deciso che quella misura era proporzionata al rischio, sulla base di quale informazione, e chi ha accettato ciò che restava scoperto?

La prima domanda si risponde con l’evidenza tecnica. La seconda si risponde solo con la delibera — o non si risponde.

Qui si produce l’asimmetria più costosa. Un’organizzazione può avere misure eccellenti e una governance indimostrabile: ha comprato bene, ma non sa ricostruire perché. Un’organizzazione può avere misure ordinarie e una governance solida: ha valutato, ha scelto, ha nominato il rischio residuo, lo ha assegnato a qualcuno, lo ha riesaminato. Davanti a una verifica, la seconda posizione è difendibile e la prima no — anche quando la prima ha speso di più.

Non è un paradosso. È la stessa logica che l’art. 5, paragrafo 2, del Regolamento (UE) 2016/679 aveva introdotto anni prima e che la maggior parte delle organizzazioni ha interpretato come obbligo di archiviazione. L’accountability non chiede la perfezione organizzativa: chiede la dimostrabilità delle scelte. La NIS2 estende quella logica al vertice, e le toglie l’ambiguità: non è il DPO a dover dimostrare, non è il CISO. È l’organo amministrativo.

Sicurezza informatica, Micozzi Francesco Paolo, Ed. CEDAM. Obblighi e responsabilità dopo il recepimento della NIS2 e la L. 90/2024. Scopri i dettagli dell’opera

Tre fronti, tre domande diverse, un solo evento

Un incidente rilevante attiva simultaneamente presidi che rispondono a domande differenti.

Verso il CSIRT Italia, l’art. 25 impone una sequenza a termini stretti: pre-notifica entro 24 ore da quando si è venuti a conoscenza dell’incidente significativo; notifica entro 72 ore dal medesimo momento, con la valutazione iniziale di gravità e impatto; relazione intermedia, se il CSIRT la richiede; relazione finale entro un mese dalla trasmissione della notifica; e, se l’incidente è ancora in corso, relazioni mensili fino alla conclusione della gestione. A ciò può aggiungersi, ai sensi del comma 9 dello stesso articolo, la comunicazione ai destinatari dei servizi.

Se l’incidente comporta anche una violazione di dati personali, resta autonomo l’obbligo di notifica al Garante per la protezione dei dati personali nei termini del GDPR, con un perimetro valutativo diverso — il rischio per i diritti e le libertà degli interessati, non l’impatto sul servizio.

Sul piano societario, infine, si apre la questione dell’adeguatezza dell’assetto, che non ha un termine perché non ha una notifica: emerge dopo, quando qualcuno ricostruisce a ritroso.

Ventiquattro ore è un termine che si rispetta soltanto se il processo esiste prima: chi rileva, chi qualifica l’evento come significativo, chi ha il potere di far partire la pre-notifica senza attendere una riunione. Nessuno di questi tre ruoli può essere improvvisato il giorno dell’attacco, e nessuno dei tre si costituisce con una policy. Si costituiscono con una delibera che li nomina.

Le organizzazioni che gestiscono questi fronti come pratiche separate — sicurezza al CISO, dati personali al DPO, governance al segretario del consiglio — non hanno tre presidi. Hanno tre versioni potenzialmente incoerenti dello stesso evento, prodotte sotto pressione, in giorni diversi, per destinatari che si parlano.

Cosa deve contenere una delibera perché regga

Il passaggio operativo è meno complicato di quanto la materia suggerisca. Una delibera sulle misure di gestione del rischio informatico è dimostrabile se contiene cinque elementi, e non lo è se ne manca uno.

L’informazione su cui la decisione si fonda, con la sua fonte e la sua data. Un consiglio che approva sulla base di una presentazione non datata e non firmata ha approvato nel vuoto.

Le alternative considerate e la ragione dello scarto. È l’elemento che quasi sempre manca, ed è quello che distingue una scelta da una ratifica. Se agli atti risulta una sola opzione, non è stata presa una decisione: è stata confermata quella di qualcun altro.

Il rischio residuo, nominato. Non «residuano rischi fisiologici», ma quale rischio, su quale servizio, con quale impatto atteso. Un rischio residuo che non si può leggere non è stato accettato: è stato ignorato in forma elegante.

Il presidio di monitoraggio e la data del riesame. L’obbligo di sovrintendere non si esaurisce nell’approvazione. Senza una data di ritorno, la sovrintendenza è un’affermazione di principio.

Il presidio di continuità tra un riesame e l’altro: chi risponde, con nome e funzione, e che cosa deve arrivare al consiglio senza attendere il riesame. Che è poi, in forma minima, ciò che il comma 3 dell’art. 23 pretende in via ordinaria.

Cinque elementi. Nessuno richiede competenza tecnica al consigliere. Tutti richiedono che l’organizzazione abbia un processo che li produce — e questo è esattamente ciò che l’art. 23 chiama modalità di implementazione.

La conseguenza

Il dibattito seguito al recepimento si è concentrato sui profili di responsabilità individuale, penale e amministrativa. È una lettura legittima, e presidiata. Ma arriva a valle di una questione che resta aperta a monte: molte organizzazioni non hanno ancora un processo che produca, in via ordinaria, delibere con quei cinque elementi. Non perché manchi la volontà. Perché il consiglio non è mai stato attrezzato per decidere su questa materia, e la materia gli è arrivata addosso già matura.

Il tempo utile per costruire quel processo è quello che separa oggi dalla prima verifica, e oggi ha una scadenza scritta. Non coincide, peraltro, con il tempo utile per acquistare tecnologia: si compra in settimane, si delibera bene solo se qualcuno ha già disegnato il flusso informativo che precede la delibera.

La domanda da porre in consiglio non è se l’azienda sia conforme alla NIS2. È più semplice e più scomoda: se un’autorità chiedesse domani di vedere l’ultima decisione presa su questa materia, cosa troverebbe agli atti — un’approvazione o un verbale di presa d’atto?