nis2 articolo

Quanti documenti di sicurezza informatica passano davvero sul tavolo del vostro vertice aziendale?

Se la risposta è "nessuno" o "non saprei", non siete i soli. È probabilmente lo scenario più comune quando si parla di responsabilità NIS2 e CdA nelle aziende italiane. Ed è anche, purtroppo, un errore che la normativa non perdona — chiunque sieda al vertice, che si tratti di un Consiglio di Amministrazione, di un Amministratore Delegato o di un Amministratore Unico.

Responsabilità NIS2 CdA: non solo il Consiglio di Amministrazione

C'è un equivoco molto diffuso: pensare che la responsabilità NIS2 riguardi solo i membri di un Consiglio di Amministrazione, e che nelle strutture più snelle il tema si allenti. Non è così.

Cosa dice l'articolo 23 del D.Lgs. 138/2024

Il decreto italiano che recepisce la direttiva europea è esplicito su chi risponde in caso di violazione. La norma coinvolge non un singolo ruolo, ma un insieme di figure apicali: chi ha funzioni di amministratore delegato, chi ha la rappresentanza legale, e chi fa parte degli organi di amministrazione o direttivi dell'azienda. Tutte queste figure possono essere ritenute responsabili dell'inadempimento in caso di violazione degli obblighi NIS2 da parte dell'organizzazione.

In pratica: la responsabilità non è "del CdA" in senso generico. È personale, e riguarda ciascuno di questi ruoli individualmente.

Il caso dell'Amministratore Delegato

Se in azienda c'è un Amministratore Delegato, la sua posizione non è diversa da quella di un consigliere di CdA agli occhi della norma: la legge lo nomina esplicitamente insieme al rappresentante legale, come soggetto che può rispondere in prima persona delle violazioni.

E se l'azienda ha un Amministratore Unico invece del CdA?

Qui arriva il chiarimento più utile per chi guida realtà meno strutturate. L'Agenzia per la Cybersicurezza Nazionale ha chiarito che l'approvazione delle misure di sicurezza previste dalla norma è una competenza esclusiva dell'organo di amministrazione — collegiale o monocratico — e non può essere delegata. In altre parole, un Amministratore Unico ha esattamente lo stesso livello di responsabilità e gli stessi obblighi di approvazione di un intero Consiglio di Amministrazione. Non esiste una "soglia di semplicità" che esclude le PMI da questo obbligo.

Differenza tra CISO e Referente CSIRT nella NIS2

Nominare un CISO basta per essere in regola?

Qui si annida il secondo equivoco, forse ancora più diffuso del primo.

CISO o Referente CSIRT: la differenza che (quasi) nessuno spiega

"CISO" è un termine di uso comune nel mondo della sicurezza informatica, ma non è la figura che la normativa italiana obbliga a nominare con questo nome. La figura effettivamente richiesta dal quadro NIS2 è il Referente CSIRT (a volte chiamato, in modo meno preciso, Referente NIS2): una persona fisica designata per interfacciarsi operativamente con lo CSIRT Italia e gestire le notifiche di incidente, la cui nomina va formalizzata attraverso il Portale ACN.

Il Referente CSIRT e il CISO possono coincidere nella stessa persona, ma non è detto che sia così, e ad oggi non ci sono ancora chiarimenti ufficiali che impongano o escludano questa sovrapposizione. Quello che è certo è che si tratta di due ruoli con una natura diversa: il CISO è tipicamente una figura di governance della sicurezza a tutto tondo, mentre il Referente CSIRT ha un compito operativo specifico e circoscritto, definito dalla determinazione ACN.

Perché la responsabilità del vertice resta comunque

Che abbiate un CISO, un Referente CSIRT, entrambi, o una struttura interna che li unisce in un'unica persona, un punto non cambia: l'esecuzione tecnica può essere affidata a queste figure, ma l'approvazione delle misure di sicurezza e la vigilanza sulla loro attuazione restano — per legge — in capo al vertice aziendale, e non possono essere trasferite a chi le esegue materialmente.

Questo significa che potete avere il miglior Referente CSIRT o CISO del mercato, ma se il vertice non vede mai un report, non discute mai un rischio, non approva mai un piano di gestione degli incidenti, la responsabilità in capo agli amministratori resta comunque scoperta.

Cosa deve arrivare davvero sul tavolo del vertice

Non è "abbiamo nominato un Referente CSIRT?" La domanda giusta è: quanti documenti di sicurezza informatica sono arrivati davvero sul tavolo del vertice negli ultimi 12 mesi?

Un'organizzazione in linea con lo spirito della norma dovrebbe vedere, con una cadenza regolare, alcuni documenti chiave:

  • Una sintesi dello stato di rischio informatico dell'organizzazione, aggiornata periodicamente
  • Il piano di gestione del rischio e il piano di trattamento del rischio
  • Gli esiti di eventuali test, audit o valutazioni di vulnerabilità
  • Il piano di risposta agli incidenti, e una relazione su eventuali incidenti già occorsi
  • Lo stato di avanzamento delle misure di sicurezza già approvate

Un indicatore semplice per capire se siete in regola

Se la risposta a "quanti di questi documenti ha visto il vertice nell'ultimo anno" è zero, o "solo quando c'è stato un problema", è un segnale chiaro che la governance della cybersicurezza non sta funzionando come richiesto — indipendentemente da quanto sia competente il team tecnico sottostante.

Da dove iniziare

Colmare questo vuoto non richiede necessariamente una rivoluzione interna: spesso basta strutturare un flusso informativo regolare tra chi gestisce la sicurezza operativa (CISO, Referente CSIRT, team IT) e chi siede al vertice, con un linguaggio e una cadenza pensati per chi deve decidere, non per chi deve implementare.

Se volete capire concretamente da dove partire — con la vostra situazione specifica, i vostri obblighi e i vostri tempi — potete trovare una panoramica dei nostri servizi di consulenza e supporto NIS2.