Decreto NIS2: guida agli obblighi per gli incidenti cyber

La Direttiva (UE) 2022/2555 (“Direttiva NIS2“) è il pilastro portante della nuova architettura europea in materia di cybersecurity e si pone in evoluzione rispetto alla precedente Direttiva (UE) 2016/1148 (“Direttiva NIS1”).

La Direttiva NIS2 estende infatti gli obblighi di protezione delle infrastrutture di rete e di comunicazione operanti nel mercato digitale europeo ad un più vasto insieme di settori commerciali, in cui le aziende che vi operano sono ora individuate come soggetti essenziali e importanti.

Gli obiettivi della direttiva NIS2

L’obiettivo primario perseguito prima dal legislatore europeo, e poi dal legislatore italiano attraverso il D. Lgs 138/2024 (“Decreto NIS2“) – che recepisce all’interno del nostro ordinamento giuridico la Direttiva NIS2 – non è solo la difesa delle infrastrutture digitali e l’innalzamento del loro livello di sicurezza, ma l’imposizione di un modello di gestione proattiva del rischio di cybersecurity. Strutture informatiche capaci di contrastare e mitigare rapidamente gli impatti generati da un attacco informatico, da una compromissione della continuità del sistema IT o da un’azione malevola condotta da una figura aziendale interna (c.d. insiders), non solo supportano la continuità dell’attività commerciale perseguita dall’azienda, ma sono altresì in grado di creare un vantaggio competitivo sul mercato di non poco conto.

Proviamo allora far luce sui complessi adempimenti previsti dal Decreto NIS2 in materia di gestione degli incidenti informatici cosiddetti significativi, specie considerando l’avvicinarsi della scadenza normativa prevista dall’Agenzia per la Cybersecurity Nazionale (“ACN“) con riferimento alla messa a terra dei necessari presidi, prendendo come spunto una fattispecie di incidente informatico significativo già oggi disciplinato nell’ordinamento giuridico nazionale: il reato di accesso abusivo a sistema informatico.

Verificando tutti gli aspetti di interesse, si forniranno alle aziende impattate dall’applicazione del Decreto NIS2 alcuni spunti operativi al fine di facilitare l’osservanza degli adempimenti normativi previsti e creare al contempo, sulla base di un efficiente sistema di governance interno, un vantaggio competitivo significativo dalla gestione degli incidenti di carattere informatico.

Il Decreto NIS2 ha introdotto nell’ordinamento italiano un nuovo paradigma di gestione degli incidenti informatici, imponendo alle aziende qualificate come soggetti essenziali e importanti l’adozione di presidi tecnico-organizzativi stringenti. Tra gli eventi che richiedono particolare attenzione figura l’accesso abusivo a sistema informatico, fattispecie già nota al diritto penale italiano ma ora rilevante anche sotto il profilo della compliance normativa in materia di cybersecurity.

Gli elementi costitutivi dell’accesso abusivo informatico

Prima di addentrarci nell’esame degli adempimenti imposti dal Decreto NIS2 per quel che concerne la gestione degli incidenti informatici di carattere significativo, occorre preliminarmente soffermarci sul reato di accesso abusivo a sistema informatico, se non altro perché tale fattispecie pare integrare in tutto e per tutto due tipici esempi di incidenti significativi soggetti ad obbligo di notifica alle autorità competenti, come previsto dall’art. 25 del Decreto NIS2 e dagli allegati 3 e 4 della Determinazione ACN n. 164179 del 14 aprile 2025 (“Determina“).

E, a ripercorrere brevemente la ratio e gli elementi dell’articolo 615-ter del Codice Penale, non si fatica a comprendere il perché. L’elemento fondamentale della fattispecie è infatti rappresentato dall’accesso illecito ad un sistema informatico, ovvero l’introduzione o la permanenza in un’infrastruttura digitale in assenza di un’autorizzazione espressa da parte del titolare della stessa. Secondo il costante orientamento della Corte di Cassazione in merito, tale condotta è sanzionabile penalmente anche qualora l’intrusione avvenga mediante l’impiego di credenziali valide, purché essa sia finalizzata a scopi diversi o eccedenti rispetto a quelli precedentemente accordati.

E già qui iniziamo a intravedere i connotati tipici di quell’incidente informatico in grado di violare la riservatezza delle informazioni contenute in un’infrastruttura di rete, qualificato dal Decreto NIS2 e dalla Determina quale evento potenzialmente idoneo a mettere a repentaglio la continuità dell’attività commerciale svolta e/o servizi forniti dall’azienda.

Il reato si qualifica anche nel caso in cui l’agente si mantenga nel sistema informatico contro la volontà del titolare dello stesso, protraendo così la sua consumazione fino alla cessazione della permanenza non autorizzata. A tal proposito, il costante orientamento della Corte di Cassazione è chiaro sul concetto di “volontà del titolare“: deve corrispondere al suo consenso. E come sappiamo, gli elementi del consenso non possono prescindere da una scelta libera, chiara, espressa ed inequivocabile, che pertanto esclude sin d’ora la possibilità che la medesima sia rappresentata o desunta in maniera implicita. E corollario di un simile principio è altresì un aspetto, non per importanza, secondario: che il titolare del sistema deve specificare con precisione non solo l’autorizzazione a entrare nello stesso, ma anche le finalità d’uso consentite. Sicché, qualsiasi comportamento tenuto in violazione di tali regole, ben può configurare il realizzarsi del reato di accesso abusivo a sistema informatico.

A questo riguardo, vale specificare altresì che la negligenza del titolare del sistema informatico nell’utilizzare sistemi o dispositivi informatici privi di adeguata protezione non giustifica in alcun modo l’intrusione di terzi. Il semplice ritrovarsi, ad esempio, di fronte a un computer non protetto da idonei strumenti di autenticazione, non autorizza di per sé la persona ad accedervi, e pertanto anche un simile scenario è da qualificarsi, in potenza, come incidente informatico di carattere significativo, in particolare laddove le conseguenze di tale accesso non consentito si concretizzino all’esterno dell’organizzazione (quando, ad esempio, a seguito dell’accesso non autorizzato vengano sottratte informazioni aziendali).

Obblighi di notifica e categorie di incidenti significativi

Spostandoci sul piano della compliance al Decreto NIS2, e più in generale su cosa si intenda per incidente informatico significativo, è utile partire da quanto previsto in merito dalla Determina e, in particolare, dai suoi allegati 3 e 4.

Partendo dal principio, il tema della gestione degli incidenti informatici e dei relativi obblighi di notifica in capo alle aziende interessate dall’applicazione del Decreto NIS2 rappresenta uno dei pilastri della compliance normativa in ambito di cybersecurity. A seconda che l’azienda sia stata qualificata da ACN come soggetto importante o soggetto essenziale, in linea con la categorizzazione introdotta dalla Direttiva NIS2 accennata in introduzione, possiamo osservare una disciplina differente da parte del legislatore interno per quel che concerne gli eventi soggetti ad obbligo di notifica nei confronti del Computer Incident Response Team (“CSIRT Italia“) costituito presso ACN.

I soggetti importanti, ai sensi dell’allegato 3 della Determina, sono infatti tenuti a notificare gli incidenti che ricadono in tre categorie principali:

1. La prima categoria riguarda l’evidenza della perdita di riservatezza di dati e informazioni (propri o sui quali l’azienda esercita controllo) con un impatto che si manifesta all’esterno dell’organizzazione aziendale.
2. La seconda categoria concerne l’avvenuta perdita di integrità dei dati, anche in questo caso con impatto verso l’esterno.
3. La terza categoria, infine, entra in gioco quando l’azienda rileva la violazione dei livelli di servizio attesi (c.d. SLA) per i suoi servizi o attività, come definiti internamente e nei rapporti con le terze parti esterne (tipicamente, i fornitori di servizi o prodotti ICT).

Mentre i soggetti essenziali, secondo quanto previsto dall’allegato 4 della Determina, sono chiamati a considerare le prime tre categorie di incidenti sopra descritte per i soggetti Importanti, con l’aggiunta di un quarto criterio specifico. L’elemento distintivo per i soggetti essenziali è rappresentato da un’ulteriore casistica di incidente – anch’essa idonea ad imporre l’obbligo di notifica allo CSIRT Italia – che ricorre qualora si abbia evidenza di un accesso non autorizzato o con abuso dei privilegi concessi a dati e informazioni, anche di carattere parziale, in violazione con i parametri qualitativi e quantitativi definiti internamente dall’azienda.

Alla luce di quanto sopra brevemente rappresentato, appare quasi immediato notare come il reato di accesso abusivo a sistema informatico possa tradursi, utilizzando altri termini e nel contesto di situazioni giuridiche molto differenti, in un episodio idoneo a determinare, da una parte, una perdita di riservatezza dell’informazione (e, potenzialmente, anche della sua integrità, qualora a seguito dell’accesso abusivo si realizzi anche una modifica dell’informazione stessa a titolo malevolo) e, dall’altra, un vero e proprio accesso ad un sistema informatico sprovvisto dei necessari privilegi autorizzativi o, peggio, in abuso di tali privilegi.

E ciò non è di poco conto. È verosimile poter affermare che una perdita di riservatezza di dati e informazioni conservate in un sistema informatico possa essere generata da una condotta che integra la fattispecie di accesso abusivo. Ma attenzione: per poter individuare un tratto comune, è necessario che la perdita di riservatezza – originata dall’accesso abusivo – si rifletta in conseguenze pregiudizievoli sui servizi aziendali o perdite materiali o immateriali per l’azienda o terzi, quantomeno per far scattare l’obbligo di notifica dell’evento nei confronti dello CSIRT Italia ai sensi di quanto previsto dal Decreto NIS2. È ciò che accade, ad esempio, nel più classico degli attacchi informatici dove l’attaccante è in grado di introdursi nel sistema informatico per esfiltrare quante più informazioni e dati possibili.

Il nesso tra accesso abusivo e perdita di riservatezza dei dati

Peraltro, quanto appena affermato vale ancora di più con riferimento alla quarta aggiuntiva illustrata, dove un parallelismo diretto tra i due mondi normativi si rinviene addirittura nella scelta terminologica di descrizione dell’incidente significativo. Qui è proprio l’accesso abusivo a dati di carattere digitale di proprietà aziendale o comunque rientranti nel suo controllo, accompagnato eventualmente da una condotta di abuso dei privilegi concessi, che è formalmente riconosciuto dalla Determina come episodio meritevole di notifica allo CSIRT Italia. E dunque il gancio diretto con la fattispecie penale del reato di accesso abusivo a sistema informatico appare decisamente più immediato.

3. Qualche indicazione operativa

Modello organizzativo e governance del rischio informatico

Dunque, quali strumenti e misure possono – anzi, devono – adottare tutte quelle organizzazioni soggette all’applicazione del Decreto NIS2, con particolare riferimento alla gestione degli incidenti informatici significativi? Quale è il punto di partenza e quali sono i presidi fondamentali da considerare?

Proviamo a fornire una risposta quanto più esaustiva in merito, visto in particolare l’attualità e urgenza della tematica per tutte quelle società sottostanti all’ambito di applicabilità del Decreto NIS2; queste ultime, difatti, tenuto conto delle indicazioni fornite da ACN, hanno 9 mesi di tempo – decorrenti dalla ricezione della comunicazione formale con ACN ha confermato loro l’applicabilità del Decreto NIS2 – per mettere a terra tutti i presidi tecnico-organizzativi necessari.

Da cosa partire? Sicuramente, l’azienda non può prescindere dall’adozione di un documento che disciplini le attività da svolgere, le risorse assegnate e le responsabilità allocate. In altre parole? Un buon modello organizzativo per la gestione del rischio informatico (“Modello“). Difatti, un efficiente framework di governance stabilisce chi decide, chi esegue, chi coordina e chi risponde delle attività e di come vengono prese le decisioni nei momenti critici.

Se approntato in maniera efficiente, il Modello fornisce un’ottima base di partenza nell’individuazione:

• dei ruoli e delle responsabilità: in fase di gestione di un incidente informatico, a maggior ragione se significativo, non si può prescindere, ad esempio, dalla presenza di risorse aventi un background informatico. Alcuni esempi? Sicuramente il Chief Information Security Officer (meglio conosciuto come CISO) ove nominato, quale responsabile della sicurezza aziendale, ma anche un c.d. Incident Manager, un IT Manager o anche, banalmente, una risorsa specializzata nell’ambito informatico (casistica assai comune nelle realtà aziendali di dimensioni più contenute). Tali figure tecniche devono poi essere coordinate e accompagnate da rappresentanti delle aree aziendali potenzialmente impattate da un incidente informatico, in primis le linee di business. È infatti il servizio erogato dalla società il “bene” da proteggere in questa circostanza, specie se la sua operatività e continuità può essere compromessa dall’incidente;
• delle linee di escalation e dei livelli decisionali: sapere chi coinvolgere e quando è di fondamentale importanza quando occorre gestire un incidente informatico, tenuto conto, a maggior ragione, di quanto previsto dal Decreto NIS2 in materia di responsabilità ultima degli organi direttivi e societari dell’azienda. Essi, infatti, devono essere tempestivamente, e quantomeno periodicamente, informati sul verificarsi di un incidente informatico e della sua qualificazione quale incidente significativo, con annesso obbligo di notifica allo CSIRT Italia;

Criteri di criticità e tempistiche di notifica agli organi competenti

• delle soglie di criticità e dei criteri di notifica, tenuto conto (i) dei servizi aziendali ritenuti di natura critica (ossia, questi servizi la cui compromissione, anche se breve, può generare un impatto negativo di grande intensità per l’azienda, in particolare sotto l’aspetto economico e reputazionale) e (ii) delle tempistiche di notifica previste dall’art. 25 del Decreto NIS2, le quali sono assai rigide e che richiedono – con particolare riferimento al c.d. “pre-allarme” – un’attivazione quanto più proattiva da parte dell’azienda entro il termine massimo di 24 ore dalla scoperta dell’evento.

Incident response plan: contenuti e requisiti minimi essenziali

Scendendo più nel concreto, la gestione di un incidente informatico significativo non può certamente prescindere, in ottica di accountability, dalla sussistenza di una procedura adeguata. In questo caso il riferimento principe è senza dubbio un documento in grado di garantire una corretta individuazione, gestione e contenimento dell’incidente, con conseguente ripristino del servizio completo, fino alla regolamentazione delle casistiche e contenuto della notifica. Parliamo in tal senso del piano di risposta agli incidenti, noto anche con il termine di Incident Response Plan.

Tale piano di risposta, un po’ come il Modello sopra descritto, consente di disciplinare le risorse, i ruoli e le responsabilità assegnate alla fase di gestione dell’incidente.

Deve senz’altro essere approvato dal vertice societario (ad esempio, dal Consiglio di Amministrazione ove presente) e quantomeno contemplare alcuni requisiti minimi a livello di contenuto. In particolare, dovrebbe prevedere:

Elementi operativi del piano di risposta agli incidenti

• una descrizione sommaria del proprio scopo e dei relativi obiettivi;
• una descrizione normativa degli scenari di incidente significativo, riprendendo in merito quanto previsto dagli allegati 3-4 della Determina (tenuto conto della qualificazione dell’azienda come soggetto importante o essenziale);
• l’indicazione delle unità organizzative coinvolte nelle diverse fasi di gestione dell’incidente, contemplando senz’altro la funzione IT e quella legale;
• l’individuazione dei ruoli coinvolti con indicazione delle attività assegnate per ciascuna fase di gestione dell’incidente, comprensiva altresì dei flussi comunicativi intercorrenti tra le varie risorse assegnate. Tale passaggio è di fondamentale importanza per consentire di avere ben chiaro il metodo di c.d. reporting e il regime di responsabilità connesso;
• una matrice c.d. RACI dedicata, che fornisca indicazioni precise e univoche sui ruoli assunti dagli stakeholders coinvolti, accompagnata dalle le linee di escalation interne (criteri, soglie e destinatari);
• i criteri di classificazione dell’incidente (ad esempio, basso, medio, alto, critico) basati su impatto e criticità del singolo servizio colpito, i quali dovrebbero essere calcolati sulla base di una metodologia del rischio dedicata;
• gli strumenti tecnici e organizzativi di rilevazioni degli incidenti, con particolare riferimento – ad esempio – ad un SIEM aziendale (ove presente), ad una soluzione di intrusion detection o a un sistema di ticketing e di segnalazione, che consenta a chiunque di poter comunicare il verificarsi di un incidente significativo, nonché gli strumenti di raccolta delle informazioni necessarie all’esame dell’incidente (quali log e indicatori di compromissione);
• un processo di contenimento delle conseguenze negative prodotte dall’evento, che in potenza possono generare una compromissione del servizio erogato e generare pertanto danni economici e di immagine all’azienda;
• regole e misure idonee a preservare le evidenze di carattere forense durante la messa a terra delle misure di remediation necessarie;
• la descrizione di attività e operazioni tecniche idonee a rimuovere, ove possibile, la causa dell’incidente e attività di monitoraggio per verificare che la minaccia sia effettivamente rimossa;
• qualora interrotti, procedure e flussi di processo per il ripristino dei sistemi interessati (i.e. restore da backup) e dei dati coinvolti;
• processi di verifica dell’integrità e della sicurezza dell’ambiente informatico prima del ritorno in fase di produzione, accompagnati da test operativi per assicurare che il servizio funzioni correttamente dopo il ripristino;
• processi di monitoraggio delle tempistiche ai fini dell’invio delle notifiche nelle diverse fasi e termini previsti dal Decreto NIS2, con altresì l’indicazione precisa dei soggetti deputati alla gestione delle stesse e/o che devono essere necessariamente coinvolti;
• flussi comunicativi interni ed esterni all’azienda per rendere informati tutti i soggetti interessati degli esiti dell’attività di gestione e notifica dell’incidente informatico di carattere significativo;
• un processo che declini nella pratica le regole e le best practices da osservare per condurre una corretta attività di reporting a titolo di relazione finale sulle modalità adottate dall’azienda per individuare, contenere e gestire l’incidente informatico occorso. Tale documento, peraltro, potrebbe altresì fungere da evidenza documentale qualora necessario per dimostrare l’accountability societaria;
• un processo di monitoraggio successivo alla chiusura dell’attività di gestione dell’incidente per eventuale raccolta di eventi e alert a titolo di lessons learnt.

Sanzioni e conseguenze della mancata compliance normativa

Alla luce di tutto quanto sopra rappresentato e, seppur brevemente, descritto, il messaggio finale è il seguente: che generi impatti a livello di responsabilità penale o rischi di sicurezza, l’osservanza dei precetti previsti dal Decreto NIS2 è un aspetto di fondamentale importanza per le aziende interessate. Specie con riferimento alla gestione degli incidenti di sicurezza che, è bene ricordare, sono episodi in grado anche di interrompere l’attività commerciale svolta dalla singola azienda, con tutte le ripercussioni del caso.

E se ciò non bastasse, non dimentichiamo l’impatto generato dalla disciplina sanzionatoria prevista dal Decreto NIS2: infatti, qualora siano accertati, da parte di ACN, eventuali profili di non conformità al Decreto NIS2, i minimi e massimi edittali della sanzione amministrativa possono arrivare sino a 10 milioni di Euro o il 2% del fatturato aziendale, nel caso in cui si parli di aziende qualificate come soggetti essenziali, e sino a 7 milioni di euro o l’1,4% del fatturato aziendale, qualora si considerino aziende individuate come soggetti importanti.

La preparazione dell’azienda di fronte ai controlli ACN

Per tali motivi, è quantomeno cruciale che le aziende target di questa normativa si siano già adoperate, ad oggi, per imbastire un’efficiente struttura di governance interna idonea a disciplinare, nel concreto, le misure tecnico-organizzative necessarie. Per coloro che non si siano ancora mossi, il tempo è ormai agli sgoccioli e, una volta scaduto il termine riconosciuto da ACN alle aziende per implementare le misure di gestione degli incidenti informatici significativi, quest’ultima sarà legittimata a mettere in pratica tutte le misure di esecuzione, monitoraggio e verifica a lei riconosciute dal Capo V del Decreto NIS2, con particolare riferimento alle attività ispettive, ai possibili audit sulla sicurezza e alle richieste documentali e/o di informazioni ulteriori, solo per citarne alcune.

Al netto dell’attività di gestione del rischio informatico, che è l’attività principe da condurre per una corretta osservanza dei requisiti normativi previsti dal Decreto NIS2, sarà bene farsi trovare preparati anche nella malaugurata ipotesi in cui scenari di questo tipo diventino reali.