La Direttiva NIS 2 e il D.lgs. 138/2024 hanno introdotto un cambiamento profondo per i soggetti rientranti nel perimetro e in termini di obblighi di gestione e notifica degli incidenti informatici.
Non tutti gli incidenti restano confinati nella sfera tecnica o aziendale: alcuni di questi possono assumere una dimensione di interesse pubblico e, in determinate circostanze, un carattere potenzialmente criminale.
Questo capitolo della nuova esalogia ricostruisce il nuovo paradigma introdotto dalla NIS 2, spiegando perché l’incidente significativo non è più un fatto “interno” e descrivendo quale ruolo assume il CSIRT Italia e perché la sicurezza informatica diventa oggi una responsabilità che travalica l’organizzazione colpita.
Indice degli argomenti
Un nuovo modo di leggere gli incidenti informatici
Per molto tempo l’incidente informatico è stato vissuto come un problema da risolvere rapidamente e, possibilmente, in silenzio.
Un guasto, un malfunzionamento, un attacco era qualcosa che riguardava l’IT, da confinare nel perimetro tecnico e da chiudere il prima possibile per ridurre l’impatto operativo e reputazionale.
Questa impostazione, che in passato poteva apparire ragionevole, oggi non è più sostenibile. Già con l’introduzione del GDPR le organizzazioni sono state chiamate a un cambio di passo sostanziale: non più la gestione informale degli incidenti, ma l’obbligo di notificare quelli in grado di compromettere in modo significativo la disponibilità, la riservatezza o l’integrità dei dati personali degli interessati.
Questo ha imposto, per la prima volta in modo strutturato, la necessità di classificare gli incidenti, definendone il livello di gravità e individuando con chiarezza le soglie di criticità rilevanti ai fini della notifica e della responsabilità organizzativa.
La NIS 2 nasce da una presa d’atto: i sistemi informativi e di rete non sono più strumenti isolati ma infrastrutture che sostengono funzioni essenziali della società.
Quindi, quando un soggetto che rientra nel perimetro NIS 2 subisce un incidente significativo, l’effetto non si ferma ai confini dell’organizzazione, ma può propagarsi lungo filiere, servizi e territori.
Da qui prende forma un nuovo modo di leggere l’incidente che non è più solo evento tecnico, ma anche un fatto che può assumere una dimensione pubblica.
Dalla normalità operativa alla rilevanza sistemica
Per governare operativamente la materia, è utile distinguere tra eventi, incidenti e incidenti significativi. La NIS 2 definisce l’incidente e impone criteri di valutazione per identificare quelli significativi.
Si tratta di una scala che misura l’impatto dell’accaduto sul sistema nel suo complesso.
Quindi distinguiamo:
- un evento che può essere fisiologico e gestibile in autonomia;
- un incidente che rompe l’equilibrio operativo;
- incidente significativo che supera una soglia: per durata, per diffusione, per numero di utenti coinvolti e per impatto sui servizi essenziali.
Quando si entra in questa terza categoria, l’incidente cambia natura e diventa un fatto da governare.
La soglia della significatività segna il passaggio da una logica interna a una logica sistemica, in cui entrano in gioco obblighi di notifica, coordinamento e responsabilità estesa.
L’incidente informatico come fatto di interesse pubblico
Il cuore del cambiamento introdotto dalla NIS 2 è concettuale prima ancora che normativo: la sicurezza delle reti e dei sistemi informativi viene trattata come interesse collettivo e sistemico.
Questo significa che l’incidente significativo non riguarda più solo chi lo subisce, ma anche l’ecosistema in cui quell’organizzazione opera.
In questo quadro di situazione, la notifica non è una sanzione preventiva ma uno strumento di governo del rischio collettivo perché serve a:
- consentire una visione d’insieme;
- intercettare pattern ricorrenti;
- prevenire effetti domino.
Per questo motivo, la NIS 2 rompe definitivamente l’illusione dell’incidente “privato”: quando l’impatto supera una certa soglia l’interesse pubblico (e quindi diventa “significativo” per usare la terminologia NIS 2) prevale sulla gestione riservata.
Il comma 8 dell’articolo 25: una norma breve con un impatto enorme
Il comma 8 dell’articolo 25 stabilisce che, qualora si sospetti che l’incidente significativo abbia carattere criminale, il CSIRT Italia debba fornire al soggetto notificante orientamenti sulla segnalazione dell’incidente all’organo centrale del Ministero dell’Interno per la sicurezza e per la regolarità dei servizi di telecomunicazione, ossia alla Polizia Postale quale Autorità di contrasto.
Questa disposizione è spesso letta in modo superficiale, come un dettaglio procedurale mentre, in realtà, è una delle norme più dense dell’intero impianto NIS 2.
Essa sancisce, in modo inequivocabile, che:
- esistono incidenti di sicurezza con possibile rilevanza penale;
- la loro gestione non può restare confinata nell’organizzazione;
- il CSIRT svolge un ruolo di punto di raccordo informativo e tecnico-istituzionale tra il soggetto colpito e le Autorità di contrasto.
È un meccanismo di responsabilità condivisa, coerente con la natura sistemica della sicurezza digitale.
Quando un incidente assume rilevanza penalistica
Una delle domande più frequenti e spesso formulate in modo improprio, è: “Quando un incidente può costituire un reato?”. La risposta non è mai puramente tecnica.
Un incidente assume carattere criminale quando emergono elementi che fanno ragionevolmente sospettare:
- l’intenzionalità dell’azione;
- la violazione consapevole di sistemi o dati;
- l’esistenza di una condotta tipica prevista dal codice penale o dalla normativa speciale.
L’agente malevolo può essere un soggetto sia esterno che interno all’organizzazione.
Ransomware, accessi abusivi, sabotaggi, manipolazioni di dati, estorsioni digitali, interferenze nelle comunicazioni, compromissioni finalizzate allo spionaggio industriale sono esempi evidenti.
Esistono, però, anche situazioni più ambigue, in cui il carattere criminale emerge progressivamente, man mano che l’incidente viene analizzato.
Per questo motivo, la NIS 2 fa esplicito riferimento ai sospetti che l’incidente significativo abbia carattere criminale.
Il ruolo del CSIRT: supporto, orientamento, responsabilità istituzionale
Il CSIRT Italia non è un organo investigativo e non svolge funzioni di polizia giudiziaria. Il suo ruolo è diverso, ma non per questo marginale.
Infatti è un attore istituzionale che opera a tutela della sicurezza nazionale delle reti e dei sistemi informativi.
Quando riceve una notifica di incidente significativo, il CSIRT:
- analizza l’evento;
- supporta il soggetto colpito;
- valuta l’impatto sistemico;
- coordina la risposta a livello nazionale.
Inoltre, quando emerge un sospetto di carattere criminale, il CSIRT orienta il soggetto notificante verso la segnalazione all’Autorità di contrasto (la Polizia Postale).
Questo orientamento non è una semplice raccomandazione informale, ma l’espressione di una responsabilità pubblica.
Quindi, ridurre il CSIRT a un interlocutore puramente tecnico significa perdere il senso istituzionale attribuito dalla NIS 2 e dalla disciplina nazionale di recepimento.
Dal CSIRT alla Polizia di Stato, fino alla Procura della Repubblica
Quando il CSIRT orienta verso la segnalazione all’Autorità di contrasto, si apre un percorso che coinvolge la Polizia di Stato e, successivamente, la Procura della Repubblica.
Questo passaggio non è automatico né meccanico, ma dipende dalla valutazione degli elementi raccolti.
È importante comprendere che, una volta entrati in questo circuito, la gestione dell’evento cambia natura.
Le esigenze investigative, la conservazione delle prove (o meglio, delle fonti di prova), la documentazione delle attività diventano centrali ed è qui che emergono le prime vere criticità organizzative.
Molte aziende scoprono, troppo tardi, di non essere preparate a questo scenario.
La procedura per la gestione degli incidenti
Tra le misure organizzative più rilevanti per governare lo scenario descritto vi è la predisposizione di una procedura strutturata per la gestione degli incidenti.
Non si tratta di un documento meramente tecnico ma di uno strumento di direzione e coordinamento, pensato per guidare l’organizzazione nei momenti di maggiore pressione decisionale.
La procedura deve disciplinare in modo esplicito anche la gestione degli incidenti che presentano o possono presentare un profilo di rilevanza penale, fornendo indicazioni chiare e non equivocabili su tre profili essenziali.
Tra le misure organizzative più rilevanti per governare lo scenario descritto vi è la predisposizione di una procedura strutturata per la gestione degli incidenti.
Non si tratta di un documento meramente tecnico, ma di uno strumento di direzione e coordinamento, pensato per guidare l’organizzazione nei momenti di maggiore pressione decisionale.
La procedura deve disciplinare in modo esplicito anche la gestione degli incidenti che presentano o possono presentare un profilo di rilevanza penale, fornendo indicazioni chiare e non equivocabili su tre profili essenziali.
La sicurezza come prova di maturità organizzativa
La NIS 2 ha reso esplicito ciò che per anni è rimasto implicito cioè che alcuni incidenti informatici non sono semplici problemi tecnici, ma eventi che coinvolgono l’interesse pubblico e l’ordinamento giuridico nel suo insieme.
In questi casi, la trasparenza, la collaborazione e la correttezza delle azioni intraprese diventano elementi determinanti.
Comunque, la segnalazione e il coinvolgimento delle Autorità non esauriscono il problema.
Al contrario, ne aprono uno ancora più delicato che richiede di dimostrare:
- cosa è accaduto;
- come è stato gestito l’incidente;
- quale è stato il comportamento dell’organizzazione.
È su questo terreno che entra in gioco il tema delle prove forensi, della loro raccolta, della loro integrità e del loro valore giuridico.
Ed è proprio a questo tema che sarà dedicato il prossimo capitolo dell’esalogia, in cui analizzeremo perché la prova forense è uno strumento essenziale di tutela, verità e responsabilità.
