NIS2: Cosa cambia davvero e perché molte organizzazioni non sono ancora pronte
Negli ultimi mesi la Direttiva (UE) 2022/2555 – NIS2 è entrata stabilmente nelle discussioni di Consigli di Amministrazione, Risk Committee e funzioni IT e Cybersecurity.
Non si tratta più di una normativa “tecnica” confinata agli addetti ai lavori, ma di un intervento regolatorio che incide direttamente sulla governance aziendale, sulle responsabilità degli organi apicali e sui meccanismi decisionali in caso di crisi cyber.
L’attenzione crescente non dipende solo dall’ampliamento del perimetro soggettivo – che coinvolge un numero significativamente maggiore di organizzazioni rispetto alla precedente NIS – ma soprattutto dal cambio di paradigma introdotto dalla Direttiva.
Sempre più spesso emerge una domanda chiave:
“Se domani si verificasse un incidente cyber rilevante, l’organizzazione sarebbe in grado di gestirlo in modo conforme alla NIS2?”
La risposta, nella maggior parte dei casi, non è tecnica.
È organizzativa, procedurale, culturale e decisionale.
Molte organizzazioni hanno investito negli anni in tecnologie di sicurezza, SOC, servizi di threat detection e risposta agli incidenti. Tuttavia, la NIS2 rende evidente un punto spesso trascurato: la sicurezza non è solo prevenzione, ma capacità di governo dell’incidente.
Dal “subire un attacco” al “governare un incidente”
I principali report europei e internazionali sulla cybersecurity mostrano un trend ormai consolidato:
gli incidenti cyber aumentano in frequenza, sofisticazione e impatto, coinvolgendo settori critici e non critici, grandi gruppi e organizzazioni di medie dimensioni.
Energia, trasporti, sanità, servizi digitali, manifattura e supply chain sono oggi esposti a rischi sistemici che possono avere effetti a cascata sull’economia e sulla sicurezza nazionale.
La NIS2 parte da un presupposto molto chiaro:
l’incidente cyber non è più un’eventualità remota, ma un evento atteso.
Per questo motivo la Direttiva sposta l’attenzione da una logica puramente difensiva a una logica di governance dell’incidente.
Non è più sufficiente dimostrare di avere:
- firewall,
- sistemi di detection,
- procedure tecniche di risposta.
Il regolatore valuta:
- come vengono prese le decisioni sotto pressione,
- chi ha l’autorità di dichiarare un incidente significativo,
- come vengono gestite le comunicazioni verso l’esterno,
- se il management è consapevole dei rischi e coinvolto nelle scelte.
In altri termini, la NIS2 introduce una lettura “manageriale” dell’incidente cyber:
non solo cosa è successo, ma come l’organizzazione ha reagito, deciso e comunicato.
NIS2 e responsabilità: un cambio di livello
Uno degli aspetti più dirompenti della NIS2 riguarda il tema delle responsabilità degli organi di gestione.
La Direttiva stabilisce che gli organi amministrativi:
- approvino le misure di gestione del rischio cyber,
- supervisionino la loro attuazione,
- possano essere chiamati a rispondere in caso di gravi inadempienze.
Questo implica un cambio culturale profondo.
La cybersecurity non può più essere considerata una materia “delegabile integralmente” alla funzione IT o al CISO.
Diventa una responsabilità di governance, al pari di altri rischi strategici.
In questo contesto, la gestione dell’incidente assume un valore centrale, perché è il momento in cui:
- le decisioni diventano visibili,
- le responsabilità emergono,
- la relazione con le autorità viene messa alla prova.
Obblighi NIS2: tempi, processi e accountability
La NIS2 introduce obblighi concreti e misurabili su più livelli.
1. Notifica degli incidenti significativi
La Direttiva prevede un processo strutturato di notifica:
- early warning entro tempistiche molto ristrette,
- notifica formale con informazioni iniziali validate,
- relazione finale con analisi dell’impatto e delle misure correttive.
Questo presuppone che l’organizzazione sappia:
- distinguere tra evento, incidente e incidente significativo,
- decidere rapidamente se scatta l’obbligo di notifica,
- validare le informazioni prima di trasmetterle.
Senza una governance chiara, il rischio è duplice:
- notificare troppo tardi,
- notificare in modo incompleto o incoerente.
Entrambi i casi espongono a rilievi e sanzioni.
2. Ruoli e responsabilità formalizzate
La NIS2 non ammette ambiguità organizzative.
Richiede ruoli chiari, responsabilità assegnate e processi documentati.
In particolare, presuppone l’esistenza di una funzione stabile in grado di:
- coordinare le diverse funzioni coinvolte,
- rappresentare l’organizzazione verso il CSIRT,
- garantire coerenza e tracciabilità delle decisioni.
Non si tratta di una figura “da nominare in emergenza”, ma di un ruolo definito ex ante.
Il nodo centrale: la relazione con il CSIRT
Durante un incidente significativo, la relazione con il CSIRT nazionale diventa un elemento cruciale.
La NIS2 richiede che:
- le comunicazioni siano tempestive ma affidabili,
- le informazioni siano contestualizzate,
- le decisioni siano documentate e difendibili.
Nella realtà operativa di molte organizzazioni, però, emergono criticità ricorrenti:
- il SOC parla un linguaggio tecnico,
- il Legal adotta un approccio prudenziale,
- il Management è sotto pressione reputazionale e operativa,
- le informazioni arrivano frammentate.
In assenza di una regia, il rischio è che:
- le comunicazioni siano incoerenti,
- le tempistiche non vengano rispettate,
- il CSIRT riceva informazioni parziali o contraddittorie.
Questo è uno dei principali fattori di non conformità NIS2.
Il Referente CSIRT: perché è una funzione di governance
La NIS2 non definisce il Referente CSIRT come una figura puramente tecnica.
Al contrario, ne delinea implicitamente il ruolo come funzione di coordinamento strategico.
Il Referente CSIRT si colloca:
- tra il livello operativo e quello decisionale,
- tra le funzioni tecniche e quelle di controllo,
- tra l’organizzazione e l’autorità esterna.
Per essere efficace deve:
- conoscere il quadro normativo,
- comprendere le implicazioni di business,
- avere accesso al management,
- disporre di un mandato chiaro.
È una funzione che non sostituisce il CISO, il SOC o il Legal, ma li coordina in una logica di governance dell’incidente.
Referente CSIRT as a Service – NIS2
Molte organizzazioni, soprattutto di medie dimensioni, non dispongono internamente di questa funzione strutturata.
Da qui nasce il servizio Referente CSIRT as a Service – NIS2.
Il servizio fornisce una funzione continuativa, indipendente e qualificata, focalizzata sugli obblighi NIS2 e sulla gestione dell’incidente come fatto di governance.
Ambiti di intervento
1. Inquadramento e governance NIS2
- definizione formale del ruolo,
- integrazione nei modelli di governance esistenti,
- allineamento tra IT, Risk, Legal e Management.
2. Preparazione all’incidente
- chiarimento delle soglie decisionali,
- definizione di playbook coerenti con la Direttiva,
- supporto a esercitazioni e simulazioni.
3. Gestione dell’incidente
- supporto decisionale nelle fasi critiche,
- coordinamento delle funzioni coinvolte,
- validazione delle comunicazioni.
4. Interfaccia con il CSIRT
- punto di contatto unico,
- rispetto delle tempistiche,
- tracciabilità delle decisioni e delle azioni.
5. Post-incident e miglioramento continuo
- analisi delle cause,
- revisione dei processi,
- supporto in caso di audit o ispezioni.
Perché la preparazione è il vero fattore critico
Le analisi post-incidente mostrano un dato costante:
i problemi più rilevanti non sono tecnologici, ma organizzativi.
Ruoli non chiari, decisioni tardive, documentazione insufficiente e comunicazioni incoerenti sono le principali cause di criticità regolatoria.
La NIS2 non chiede se un’organizzazione è stata colpita.
Chiede se era pronta.
Essere pronti significa:
- aver definito ruoli e responsabilità,
- aver testato i processi,
- aver preparato il management a decidere.
Un primo passo concreto: NIS2 Readiness Check – Referente CSIRT
Il NIS2 Readiness Check – Referente CSIRT (45 minuti) è pensato come primo passo pragmatico per:
- valutare il livello di maturità organizzativa,
- individuare gap decisionali e di governance,
- comprendere l’esposizione rispetto agli obblighi NIS2.
Non è un audit tecnico, ma una valutazione mirata della capacità dell’organizzazione di governare un incidente in modo conforme.
Conclusione
La NIS2 segna un passaggio chiave:
dalla cybersecurity come funzione tecnica alla cybersecurity come responsabilità di governance.
In questo contesto, il Referente CSIRT non è un dettaglio organizzativo, ma uno snodo strategico.
Le organizzazioni che lo comprendono per tempo trasformano un obbligo normativo in un vantaggio di controllo, credibilità e resilienza.
Le altre rischiano di scoprirlo nel momento peggiore: durante un incidente reale.
IT 
EN