Se il 2025 è stato l’anno delle registrazioni in piattaforma NIS2, il 2026 sarà l’anno della implementazione completa – e concreta – di tutto l’assetto normativo del D.Lgs. 138/2024.
Tale assunto pare provato dalla approvazione a fine dicembre della Determinazione ACN 379907/2024 e relativi allegati e dalla pubblicazione sul sito di due Linee Guida: quella sulla gestione degli Incidenti Nis2 (di assoluta rilevanza perché spiega come organizzare e gestire tale adempimento) e quella sulle Specifiche di base (che in realtà aggiorna la prima stesura del settembre 2025).
Cogliamo allora l’occasione per fare un breve riepilogo della materia in generale, per poi analizzare in maniera più approfondita quali incidenti sono considerati rilevanti e come vanno gestiti.
Indice degli argomenti
Adottare la NIS2: quadro normativo e soggetti coinvolti
La Direttiva (UE) 2022/2555, comunemente nota come NIS 2, è stata recepita in Italia con il Decreto Legislativo 4 settembre 2024, n. 138.
Il nuovo quadro legislativo rappresenta un’evoluzione significativa rispetto alla precedente direttiva NIS, ampliando notevolmente il perimetro dei soggetti obbligati e introducendo un sistema di governance della sicurezza informatica più stringente e strutturato.
In primo luogo si introduce una distinzione fondamentale tra due categorie di soggetti (c.d. Soggetti NIS – art. 6 D.Lgs. 138/2024):
I soggetti essenziali comprendono gli operatori di grandi dimensioni che superano i massimali per le medie imprese ai sensi della Raccomandazione 2003/361/CE e operano nei settori di cui all’Allegato I del decreto (energia, trasporti, settore bancario, infrastrutture dei mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione dei servizi TIC, pubblica amministrazione, spazio). Rientrano altresì in questa categoria, indipendentemente dalle dimensioni, i soggetti identificati come critici ai sensi della direttiva CER, i prestatori di servizi fiduciari qualificati, i gestori di registri dei nomi di dominio di primo livello e le pubbliche amministrazioni centrali.
I soggetti importanti sono tutti i soggetti rientranti nell’ambito di applicazione del decreto che non sono considerati essenziali. Questa categoria include tipicamente le medie imprese operanti nei settori dell’Allegato I e le imprese operanti nei settori dell’Allegato II (servizi postali, gestione dei rifiuti, fabbricazione, produzione e distribuzione di sostanze chimiche, produzione e distribuzione di alimenti, fabbricazione, fornitori di servizi digitali, ricerca).
NIS2: governance e gestione incidenti tra ACN, CSIRT e autorità di settore
Per quanto attiene poi al sistema di governance, la stessa si articola intorno a diversi attori istituzionali: l’Agenzia per la Cybersicurezza Nazionale (ACN), designata quale Autorità nazionale competente NIS, con funzioni di regolazione, vigilanza e sanzionatorie (art. 10 D.Lgs. 138/2024); il CSIRT Italia, quale l’organo preposto alle funzioni di gestione degli incidenti di sicurezza informatica (art. 15 D.Lgs. 138/2024); e le Autorità di settore NIS, individuate dall’articolo 11, che supportano l’ACN nella verifica e implementazione settoriale degli obblighi.
Gestione incidenti NIS2 e articolo 24: l’approccio multirischio
L’articolo 24 del D.Lgs. 138/2024 costituisce il cuore degli obblighi in materia di gestione del rischio per la sicurezza informatica dei soggetti NIS.
I soggetti essenziali e importanti sono infatti chiamati ad adottare misure tecniche, operative e organizzative adeguate e proporzionate alla gestione dei rischi posti alla sicurezza dei sistemi informativi e di rete che utilizzano nelle loro attività o nella fornitura dei loro servizi.
Le misure da adottare devono poi essere basate su un approccio multirischio, definito dall’articolo 2, comma 2, lettera dd), come “cosiddetto approccio all-hazards, l’approccio alla gestione dei rischi che considera quelli derivanti da tutte le tipologie di minaccia ai sistemi informativi e di rete nonché al loro contesto fisico, quali furti, incendi, inondazioni, interruzioni delle telecomunicazioni e della corrente elettrica, e in generale accessi fisici non autorizzati”.
In sostanza devono essere valutati non solo i rischi informatici, ma tutte le tipologie di rischio, informatici e fisici, legati al contesto ed altresì agli atti umani interni ed esterni.
L’art. 24, comma 2, elenca poi gli elementi minimi che le misure devono comprendere: a) politiche di analisi dei rischi e di sicurezza dei sistemi informativi e di rete; b) gestione degli incidenti; c) continuità operativa, gestione di backup e ripristino in caso di disastro; d) sicurezza della catena di approvvigionamento; e) sicurezza dell’acquisizione, sviluppo e manutenzione dei sistemi; f) politiche per valutare l’efficacia delle misure di gestione dei rischi; g) pratiche di igiene e formazione in materia di sicurezza informatica; h) politiche sull’uso della crittografia; i) sicurezza e affidabilità del personale, controllo dell’accesso e gestione dei beni; l) uso di soluzioni di autenticazione a più fattori e sistemi di comunicazione protetti.
Tempistiche e scadenze NIS2: 9 mesi per le notifiche, 18 per le misure
Per quanto riguarda poi i tempi di attuazione, l’articolo 42 del D.Lgs. 138/2024, disciplinando la fase di prima applicazione del decreto, prevede una tempistica graduale.
Il termine per l’adempimento degli obblighi di notifica degli incidenti è fissato in 9 mesi dalla ricezione della comunicazione di inserimento nell’elenco dei soggetti NIS.
Il termine per l’adempimento degli obblighi relativi alle misure di sicurezza di base è fissato in 18 mesi dalla medesima comunicazione.
Considerando che le prime comunicazioni di inserimento sono state inviate dall’ACN a partire dal 12 aprile 2025, i termini operativi per la maggior parte dei soggetti scadranno rispettivamente nel gennaio 2026 (notifiche degli incidenti) e nell’ottobre 2026 (misure di sicurezza per la gestione dei rischi).
Determinazione ACN 379907/2025: allegati e sostituzione della 164179
Veniamo ora alle novità di dicembre 2025.
Con la Determinazione del Direttore Generale n. 379907 del 18 dicembre 2025, adottata in ragione del principio di proporzionalità e gradualità di cui all’articolo 31 D.Lgs. 138/2024, l’ACN ha stabilito le modalità e le specifiche di base per l’adempimento degli obblighi previsti dagli articoli 23, 24, 25, 29 e 32 del decreto NIS.
Questa determinazione, che ha sostituito la precedente Determinazione ACN n. 164179 del 14 aprile 2025, è corredata da quattro allegati tecnici: l’Allegato 1 contiene le misure di sicurezza di base per i soggetti importanti; l’Allegato 2 le misure di sicurezza di base per i soggetti essenziali; l’Allegato 3 gli incidenti significativi di base per i soggetti importanti; l’Allegato 4 gli incidenti significativi di base per i soggetti essenziali.
A valle di tale Determinazione, l’ACN ha ritenuto di pubblicare sul proprio sito istituzionale due documenti di soft law che, partendo dal quadro normativo generale e dalle diverse Determinazioni approvate nel corso dell’anno, spiegano in quale modo essere, operativamente, compliant alla disciplina.
Palese dunque che, seppur non obbligatorie, sono comunque da leggere (entrambe) con grande attenzione.
Più esattamente si tratta di: Linee Guida per la definizione del processo di gestione degli incidenti di sicurezza informatica (31 dicembre 2025) e Linea Guida alla lettura delle specifiche di base (versione 2.0, dicembre 2025, che aggiorna quella precedente di settembre 2025).
Tenuto conto che la Linee Guida sulle specifiche di base è già stata analizzata in altri articoli e che quella di dicembre è solo una versione con alcuni aggiornamenti, in questa sede si analizzerà solo la “nuova” Linee Guida sugli incidenti.
Gestione incidenti NIS2: le linee guida ACN e le cinque fasi
Le Linee Guida per la definizione del processo di gestione degli incidenti di sicurezza informatica costituiscono la vera novità del panorama regolatorio NIS.
Questo documento fornisce indicazioni operative dettagliate per strutturare un processo efficace di incident management, in conformità a quanto previsto dal decreto NIS e dalla Determinazione n. 379907/2025 sugli obblighi di base.
Vediamo i punti principali.
Il modello di processo presentato nelle Linee Guida, elaborato sulla base del documento NIST SP 800-61r3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management», si articola in cinque macro-fasi interconnesse.
Preparazione
La fase di Preparazione precede il verificarsi dell’incidente e costituisce la base per una risposta efficace. Include tre sotto-fasi: il governo, che comprende la definizione delle politiche di sicurezza e l’assegnazione dei ruoli e responsabilità; l’identificazione, che riguarda l’inventario dei sistemi informativi e di rete e l’individuazione di minacce e vulnerabilità; la protezione, che include le misure tecniche (backup, log, controllo accessi) e organizzative (procedure, formazione).
Rilevamento
La fase di Rilevamento è finalizzata a individuare e analizzare gli eventi rilevanti per la sicurezza informatica, con l’obiettivo di individuare tempestivamente il verificarsi di un incidente e limitarne l’impatto e l’estensione.
Le attività di monitoraggio possono essere realizzate secondo approcci reattivi (alert-driven), proattivi (Threat Hunting) o combinati. Gli strumenti tipicamente impiegati includono SIEM, SOAR ed EDR.
Risposta
La fase di Risposta rappresenta il cuore del processo e si articola in quattro sotto-fasi. La segnalazione riguarda la notifica dell’incidente alle autorità competenti e la comunicazione alle parti interessate.
L’investigazione mira a comprendere l’origine, la portata e l’impatto dell’incidente. Il contenimento ha l’obiettivo di limitare la diffusione dell’incidente e prevenire ulteriori danni. L’eradicazione consiste nella rimozione della minaccia dai sistemi compromessi.
Queste sotto-fasi non seguono necessariamente un ordine lineare, ma possono essere realizzate in parallelo e in modo interlacciato.
Ripristino
La fase di Ripristino è finalizzata a riportare i sistemi informativi allo stato antecedente all’incidente, assicurandosi che tutto funzioni regolarmente.
Le attività tipiche includono la creazione di golden/clean image, la reinstallazione dei sistemi, il ricollegamento in rete dei sistemi bonificati e il monitoraggio per verificare l’efficacia delle attività.
Miglioramento
La fase di Miglioramento si estende per l’intero ciclo di vita del processo ed è finalizzata a potenziare la capacità di gestione degli incidenti.
Riguarda principalmente l’analisi post-incidente (lesson learned) per individuare eventuali carenze e valutare l’efficacia della risposta. Gli esiti delle riunioni di lesson learned costituiscono la base per definire interventi di miglioramento quali l’aggiornamento delle politiche e delle procedure, l’implementazione di nuove logiche di rilevamento e la previsione di specifiche attività di formazione.
Ruoli e responsabilità: punto di contatto, referente CSIRT, terze parti
Le Linee Guida definiscono con precisione i ruoli e le responsabilità necessari per una gestione efficace degli incidenti.
La misura GV.RR-02 richiede di definire un’organizzazione per la sicurezza informatica approvata dagli organi di amministrazione e direttivi, stabilendo ruoli e responsabilità. Tale organizzazione deve includere il Punto di contatto, i relativi sostituti, il Referente CSIRT e gli eventuali suoi sostituti.
Il Referente CSIRT ha il compito di interloquire con lo CSIRT Italia ed effettuare le notifiche obbligatorie degli incidenti significativi.
Le Linee Guida precisano che deve possedere almeno competenze di base in materia di sicurezza informatica e di gestione degli incidenti, nonché una conoscenza approfondita dei sistemi informativi e di rete del soggetto.
La misura GV.SC-02 estende l’organizzazione per la sicurezza informatica alle terze parti, richiedendo di definire gli eventuali ruoli e responsabilità in materia di sicurezza informatica assegnati al personale esterno.
Questo aspetto è particolarmente rilevante nei casi di esternalizzazione di servizi di sicurezza (SOC/CERT) o della gestione dell’infrastruttura IT.
Gestione incidenti NIS2: documentazione, piani, SOP e reportistica
Le Linee Guida enfatizzano l’importanza di una documentazione strutturata e approvata.
La misura RS.MA-01 richiede la definizione di un piano per la gestione degli incidenti che comprenda almeno: le fasi e procedure di gestione e notifica con indicazione dei ruoli e responsabilità; le procedure per la predisposizione delle relazioni intermedie, mensili e finali; le informazioni di contatto per la segnalazione; le modalità di comunicazione interna ed esterna; la reportistica per la documentazione dell’incidente.
Il piano deve essere approvato dagli organi di amministrazione e direttivi e riesaminato periodicamente, almeno ogni due anni.
La misura ID.IM-04 richiede inoltre la definizione di tre piani fondamentali per la resilienza operativa: il piano di continuità operativa, il piano di ripristino in caso di disastro e il piano per la gestione delle crisi informatiche.
Tutti questi piani devono essere approvati dagli organi di amministrazione e direttivi.
Le Linee Guida sottolineano che l’uso di procedure formalizzate (anche denominate SOP – Standard Operating Procedure) consente di guidare le attività del processo in modo strutturato, migliorando l’efficienza operativa, riducendo il rischio di errori e garantendo risposte coerenti e ripetibili.
Ogni procedura dovrebbe includere: titolo e versione; ambito di applicazione; attività operative in ordine sequenziale; strumenti utilizzati; ruoli e responsabilità.
Notifica e tracciabilità nella gestione incidenti NIS2: incidenti IS-1/2/3/4 e log
La Linee Guida (ed altresì la Determinazione ACN 379907) definisce le tipologie di incidenti significativi di base che i Soggetti NIS sono tenuti a notificare.
Per i soggetti importanti sono previste tre tipologie: IS-1 (perdita di riservatezza verso l’esterno di dati digitali); IS-2 (perdita di integrità con impatto verso l’esterno di dati digitali); IS-3 (violazione dei livelli di servizio attesi).
I soggetti essenziali devono notificare anche l’incidente IS-4 (accesso non autorizzato o con abuso dei privilegi concessi a dati digitali).
La procedura di notifica prevede tempistiche stringenti (art. 25 D.Lgs. 138/2024).
Entro 24 ore dall’acquisizione dell’evidenza dell’incidente deve essere trasmessa una pre-notifica.
Entro 72 ore una notifica completa con valutazione iniziale della gravità e dell’impatto.
Entro un mese dalla notifica una relazione finale che comprenda descrizione dettagliata dell’incidente, root cause, misure di attenuazione adottate e impatto transfrontaliero.
Infine, le Linee Guida ribadiscono l’importanza della tracciabilità di tutte le attività svolte durante le fasi dell’incidente.
La misura PR.PS-04 richiede di acquisire e conservare in modo sicuro e possibilmente centralizzato almeno i log necessari ai fini del monitoraggio degli eventi di sicurezza, compresi i log relativi agli accessi da remoto e quelli effettuati con utenze con privilegi amministrativi.
Per i soggetti essenziali, la misura DE.CM-01 richiede inoltre di definire, monitorare e documentare parametri quali-quantitativi per rilevare gli accessi non autorizzati o con abuso dei privilegi concessi.
Al fine di garantire tracciabilità e coerenza delle azioni intraprese, le Linee Guida raccomandano di documentare per ogni fase del processo almeno le seguenti informazioni: sistemi informativi e di rete impattati; obiettivi delle attività; attività individuate e loro motivazioni; strutture coinvolte; modalità di verifica dell’efficacia; esiti attesi.
Conclusioni: gestione incidenti NIS2 e responsabilità del vertice
Senza dubbio il tema gestione incidenti, essendo il primo a diventare efficace, è già all’attenzione delle aziende che sono soggetti NIS 2.
Quello che invece – onestamente – non pare essere stato colto in pieno è che non si tratta di un “problema del dipartimento IT”.
Ovviamente è necessario coinvolgere il dipartimento IT, ma la consapevolezza, le decisioni, la gestione è in capo agli organi direttivi, non all’IT.
La NIS 2 ha infatti completamente capovolto il paradigma storico: la cybersecurity è una responsabilità diretta degli organi di amministrazione e direttivi.
Basta leggere l’art. 23 del D.Lgs. 138/2024: gli organi di amministrazione e direttivi dei soggetti essenziali e importanti sono chiamati non solo approvare le modalità di implementazione delle misure di gestione dei rischi, ma a sovrintendere all’implementazione degli obblighi; sono tenuti ad una formazione specifica e sono comunque responsabili delle violazioni del decreto.
Tali obblighi appaiono poi nella loro incisività quando si leggono le sanzioni.
L’art. 38 del D.Lgs. 138/2024, infatti, oltre alle “tradizionali” sanzioni pecuniarie (peraltro piuttosto alte) prevede espressamente “sanzioni personali” in capo agli organi di amministrazione e direttivi.
Il comma 5 stabilisce infatti che «qualsiasi persona fisica responsabile di un soggetto essenziale o che agisca in qualità di suo rappresentante legale con l’autorità di rappresentarlo, di prendere decisioni per suo conto o di esercitare un controllo sul soggetto stesso, assicura il rispetto delle disposizioni di cui al presente decreto. Tali persone fisiche possono essere ritenute responsabili dell’inadempimento in caso di violazione del presente decreto da parte del soggetto di cui hanno rappresentanza».
Il comma 6 prevede che, qualora il soggetto non adempia nei termini stabiliti dalle diffide dell’Autorità competente, questa può disporre nei confronti delle persone fisiche, inclusi gli organi di amministrazione e direttivi, l’applicazione della sanzione amministrativa accessoria della incapacità a svolgere funzioni dirigenziali all’interno del medesimo soggetto.
Tale sospensione temporanea è applicata finché il soggetto non adotta le misure necessarie a porre rimedio alle carenze.
Non vi è dubbio quindi che l’implementazione delle misure per la gestione degli incidenti, ed altresì delle misure per sicurezza di base, sono temi che comportano una responsabilità diretta della direzione aziendale, delegabili al Dipartimento IT ma solo dal punto di vista operativo.
L’intero impianto normativo indica che la sicurezza informatica è uscita definitivamente dal perimetro dei reparti tecnici per entrare nelle sale dei consigli di amministrazione: la responsabilità degli organi apicali non è più solo formale, ma sostanziale, e può tradursi in conseguenze personali significative.
In questo contesto, l’investimento in formazione, consulenza specializzata e strumenti di governance della cybersecurity non rappresenta più un optional, ma una necessità imprescindibile per qualsiasi organizzazione che intenda operare in conformità al nuovo quadro normativo.
