Diciamolo subito, senza girarci attorno: la NIS 2 non è l'ennesima normativa che vi chiede di produrre carta per riempire faldoni. È qualcosa di molto più profondo, e se ancora non l'avete capito, è il momento di farlo. La Direttiva NIS 2, recepita in Italia con il D.Lgs. 138/2024, ha introdotto un concetto che rompe col passato in modo netto: la sicurezza informatica è materia di governo societario. Punto. Non è più roba da IT, non è più "il problema del tecnico". È roba da Consiglio di Amministrazione.
L'Appendice C delle Linee Guida dell'ACN — le famose "NIS – Specifiche di base – Guida alla lettura" di settembre 2025 — individua un insieme di documenti che devono essere approvati dagli organi di amministrazione e direttivi. Non suggeriti: approvati. La differenza non è sottile.
Quando nessuno decide, tutti decidono (male)
Ogni organizzazione governa il rischio, anche quando non se ne rende conto. Governa quando sceglie un cloud piuttosto che un altro, quando si affida a un fornitore senza controllare quanto sia solido dal punto di vista della sicurezza, quando stabilisce che un certo investimento in protezione "può aspettare".
Il guaio è che queste scelte, nella maggior parte dei casi, vengono prese senza una strategia chiara. Nessuno al vertice ha stabilito esplicitamente quale sia il livello di rischio accettabile, quali siano le priorità, quali asset siano davvero critici, quali scenari non siano tollerabili.
E allora cosa succede? Succede che le decisioni vengono prese dal basso. Caso per caso. Sulla base dell'urgenza del momento, del budget disponibile o, e questa è la cosa peggiore, della sensibilità del singolo. Sembrano scelte tecniche o organizzative, ma in realtà stanno definendo la politica del rischio dell'intera organizzazione. Senza che nessuno se ne assuma la responsabilità.
Finché tutto resta implicito, non esiste un atto deliberativo che dica: "questo livello di esposizione è stato valutato, compreso e scelto consapevolmente."
La NIS 2 interviene proprio qui, imponendo che il rischio digitale non venga più gestito per inerzia, ma sia oggetto di indirizzo strategico. Questo è il vero salto culturale.
Basta con l'illusione che sia "roba da tecnici"
Per anni la sicurezza informatica è stata confinata nel reparto IT. Il vertice aziendale, nel migliore dei casi, riceveva relazioni sintetiche, spesso incomprensibili, e si limitava a prenderne atto. Un cenno del capo e via, avanti il prossimo punto all'ordine del giorno.
La NIS 2 e il D.Lgs. 138/2024 superano questo schema in modo drastico. La norma attribuisce agli organi di amministrazione e direttivi obblighi di supervisione e responsabilità diretta. Non è un suggerimento: è un obbligo giuridico vero e proprio che incide sul modo in cui il vertice governa l'organizzazione.
E attenzione: questa responsabilità non si esaurisce in un atto iniziale di approvazione. È continua nel tempo. Gli organi apicali sono chiamati a riesaminare periodicamente le misure adottate, verificarne l'adeguatezza, confermarle o aggiornarle. La governance, per essere tale, deve essere continua, consapevole e documentabile.
Le Linee Guida dell'ACN, nell'Appendice C, rendono esplicito questo obbligo individuando i documenti che il vertice deve approvare. E riguardano tutto l'arco della sicurezza: dall'organizzazione interna alle politiche, dalla valutazione del rischio ai piani di trattamento e gestione delle vulnerabilità, dal piano di adeguamento alla continuità operativa, dal disaster recovery alla gestione delle crisi, dalla formazione fino alla gestione degli incidenti.
I documenti non sono formalità: sono la mappa del rischio
Non stiamo parlando di documenti messi lì a caso. Ognuno di essi discende da requisiti normativi precisi, strutturati nei domini di governance, identificazione, protezione, risposta e ripristino. Per capirci: l'organizzazione per la sicurezza informatica si aggancia al controllo GV.RR-02, le politiche al GV.PO-01, la valutazione del rischio all'ID.RA-05, e così via per ciascun elemento.
Questo intreccio tra controlli e documenti dimostra un fatto concreto: l'Appendice C è la traduzione documentale di requisiti normativi puntuali. Il vertice è chiamato ad assumersi formalmente la responsabilità su ciascuna di queste aree. Non c'è scampo.
Se guardiamo l'insieme di questi documenti, ciò che emerge non è una struttura coerente che descrive l'intero percorso del rischio all'interno dell'organizzazione.
Tutto parte dall'organizzazione della sicurezza: chi decide, chi attua, come le informazioni risalgono fino al vertice. Su questa base si innestano le politiche, che traducono la strategia in indirizzi chiari. Poi la valutazione del rischio, il momento in cui si prende consapevolezza delle proprie esposizioni. Da lì scaturisce poi il piano di trattamento, che trasforma la consapevolezza in azione concreta.
Quando emergono scostamenti, interviene il piano di adeguamento. La gestione delle vulnerabilità tiene d'occhio le debolezze tecniche prima che diventino incidenti. Se l'incidente si verifica, la gestione operativa disciplina la risposta, mentre continuità operativa e disaster recovery garantiscono la sopravvivenza delle funzioni essenziali. Nei momenti critici, la gestione delle crisi coordina decisioni e comunicazioni. E lungo tutto il percorso, la formazione consolida la consapevolezza: senza cultura organizzativa nessun sistema regge nel tempo.
È un ciclo completo, una logica PDCA (Plan, Do, Check, Act) che accompagna il rischio dalla prevenzione alla resilienza. E su questo ciclo, nella sua interezza, il vertice di una azienda o di un ente statale o una pubblica amministrazione deve deliberare e assumersi la responsabilità.
Approvare non è firmare: è scegliere
Quando un Consiglio di Amministrazione o un Consiglio di una PA approva una valutazione del rischio quindi, non sta semplicemente mettendo una firma sull'ennesimo documento inteso come "carta da riempire". Sta attestando di aver preso atto delle minacce individuate e di ritenere adeguate le misure proposte. Anche senza competenze tecniche di dettaglio, compie una scelta consapevole: quella di fare affidamento sui propri esperti e far propria la sintesi tecnica ricevuta.
Quando approva un piano di continuità operativa, fa una dichiarazione ancora più netta: individua quali funzioni considera vitali per la tenuta dell'organizzazione e definisce il livello di investimento che intende sostenere per proteggerle. In quel momento stabilisce cosa va preservato a ogni costo.
E quando arriva un'ispezione dell'ACN? Beh, è verosimile che non verrà valutata solo l'esistenza del documento, ma la coerenza tra valutazione del rischio, piano di trattamento, piano di adeguamento e misure effettivamente implementate. Si verificherà la periodicità degli aggiornamenti e la tracciabilità delle approvazioni. La documentazione diventa, in pratica, la prova della diligenza organizzativa.
Governare significa rendere dimostrabile
La NIS 2 si colloca nella stessa traiettoria del GDPR: la responsabilità va dimostrata, non basta affermarla. La solidità dell'architettura documentale non dipende solo dalla qualità tecnica dei contenuti, ma dalla capacità di renderli tracciabili, aggiornati e coerenti nel tempo. Senza un sistema di gestione documentale che garantisca versioning, controllo delle modifiche e formalizzazione delle approvazioni, anche il miglior impianto rischia di cadere come un castello di carte davanti a un'ispezione.
Il legislatore europeo ha capito una cosa fondamentale: la sicurezza non può essere lasciata alla buona volontà tecnica. Deve entrare nella grammatica della governance.
Su cosa focalizzarsi
La NIS 2 non vi chiede di produrre documenti per riempire archivi. Vi chiede - anzi, vi impone - di assumere il rischio digitale come materia propria del vertice organizzativo. Comprenderlo, deliberarlo, lasciarne traccia formale.
L'Appendice C delle Linee Guida ACN di settembre 2025 individua la struttura minima attraverso cui questo governo diventa visibile. Ogni documento è un presidio di responsabilità, un segmento del ciclo del rischio, che può essere sintetizzato in tre passi.
Capire questa architettura è il primo passo. Costruirla in modo coerente è il secondo. Tenerla aggiornata e valida nel tempo è il terzo.
Non è una questione di "carta prodotta" o carta tinta, come si dice dalle mie parti. È una questione di architettura organizzativa: una struttura capace di rendere visibile e dimostrabile la responsabilità di chi sta al vertice. E se ancora pensate che la sicurezza informatica sia "roba da IT", beh, è il momento di ricredervi.
