NIS2, come costruire un processo di gestione incidenti conforme alle linee guida ACN

0

La NIS2 ha trasformato la gestione degli incidenti da “attività tecnica” a obbligo organizzativo misurabile, con tempi, ruoli e responsabilità che non si esauriscono nel SOC o nel team IT. Le Linee guida NIS pubblicate da Agenzia per la Cybersicurezza Nazionale a dicembre 2025, dedicate alla definizione del processo di gestione degli incidenti di sicurezza informatica, fissano un perimetro operativo chiaro: preparazione, rilevamento, risposta, ripristino e miglioramento diventano un ciclo continuo, documentato e verificabile, con un punto fermo su cui molte organizzazioni inciampano ancora oggi, cioè la differenza tra “stiamo gestendo un evento” e “abbiamo l’evidenza di un incidente significativo che attiva obblighi di notifica”. Il documento ACN rappresenta il riferimento tecnico per tradurre gli obblighi del decreto NIS in procedure interne, piani approvati dal vertice e flussi di comunicazione che reggono anche quando l’incidente evolve e le informazioni arrivano a ondate.

La prospettiva delle linee guida è concreta: descrive il processo e lo aggancia alle misure di sicurezza di base e alle tipologie di incidenti significativi di base definite nella determinazione sugli obblighi di base, collegando il tutto al Framework nazionale (versione 2025) e distinguendo tra soggetti importanti e soggetti essenziali non come etichette formali, ma come livelli diversi di requisiti e aspettative, anche sul piano della governance. In questa cornice, l’obiettivo non è “scrivere un manuale”, ma costruire un sistema che, davanti a un ransomware o a una compromissione della supply chain, sappia decidere in ore, non in giorni.

Specifiche di base e scadenze: perché il tempo è una componente della compliance

Le linee guida ACN richiamano il cuore degli adempimenti NIS: gli obblighi per gli organi di amministrazione e direttivi (articolo 23 del decreto), la gestione dei rischi per la sicurezza informatica (articolo 24) e le notifiche di incidente (articolo 25). Nella fase di prima applicazione, ACN può definire modalità e specifiche di base per assicurare la conformità, e lo fa tramite allegati tecnici che separano in modo netto ciò che riguarda la postura di sicurezza e ciò che riguarda l’obbligo di segnalazione.

Da un lato, le misure di sicurezza di base vengono sviluppate in accordo al Framework nazionale e organizzate in funzioni, categorie, sottocategorie e requisiti, con codici del tipo XX.YY-NN. Dall’altro, le tipologie di incidenti significativi di base definiscono quali fattispecie attivano l’obbligo di notifica, con un modello logico che lega condizione, compromissione e oggetto della compromissione. Nella pratica questo significa che l’azienda deve sapere, prima dell’incidente, quali “soglie” trasformano un evento in notifica obbligatoria e quali informazioni minime deve poter produrre quando ancora non conosce la root cause.

Le scadenze non sono un dettaglio burocratico: il documento ricorda che il termine per l’adozione delle misure di sicurezza di base è fissato in diciotto mesi dalla ricezione della comunicazione di inserimento nell’elenco dei soggetti NIS, e richiama il contesto di avvio delle comunicazioni da parte di ACN. Queste tempistiche hanno un effetto diretto sulla gestione incidenti, perché senza logging, backup, canali di comunicazione e ruoli definiti, le finestre di 24 e 72 ore diventano impraticabili, e la notifica finisce per essere un esercizio di approssimazione invece che una trasmissione affidabile di intelligence difensiva.

Il punto di partenza: i sistemi informativi e di rete e il concetto di “rilevanza”

Le misure e le notifiche si applicano ai sistemi informativi e di rete del soggetto. Qui si apre un punto spesso sottovalutato: il decreto e la determinazione sugli obblighi di base introducono anche la nozione di sistemi informativi e di rete rilevanti, cioè quei sistemi la cui compromissione comporterebbe un impatto significativo su riservatezza, integrità e disponibilità delle attività e dei servizi per cui l’organizzazione ricade nel perimetro NIS. Le linee guida ricordano che alcune disposizioni possono essere limitate “almeno” ai sistemi rilevanti, ma questa facoltà non alleggerisce la gestione incidenti: la rende più esigente, perché costringe l’organizzazione a sapere davvero dove risiede il valore operativo e quali dipendenze tecniche possono propagare un incidente oltre il perimetro atteso.

In altre parole, il processo di gestione incidenti non può vivere in astratto. Deve incastrarsi con inventario, classificazione dei servizi, dipendenze infrastrutturali e supply chain. Se l’azienda non sa quali sistemi sono “rilevanti”, non sa nemmeno quali log preservare con priorità, quali piani di ripristino testare più spesso, e quali soglie di degradazione del servizio misurare per capire se ricade nel perimetro di un incidente significativo.

Il processo ACN in cinque fasi: una sequenza che non è lineare

Le linee guida organizzano la gestione incidenti in cinque fasi: preparazione, rilevamento, risposta, ripristino e miglioramento. Il punto chiave è che, nella realtà, le sotto-fasi non seguono un ordine lineare. La risposta contiene segmenti che si intrecciano: si notifica, si investiga, si torna alla notifica con informazioni aggiornate, si contengono effetti, si scoprono nuovi artefatti, si riapre l’investigazione, si procede con eradicazione. Questo non è un problema di disordine, è il comportamento normale di un incidente moderno, e il processo deve reggerlo.

Preparazione

Governo

La preparazione non coincide con “avere un tool”. Coincide con la capacità dell’organizzazione di prendere decisioni durante una crisi. Il documento insiste su politiche e regole che rappresentano l’impegno formale dell’ente e guidano le decisioni. In questo quadro si colloca il piano per la gestione degli incidenti, che diventa la colonna portante perché descrive attività, strutture tecniche e organizzative coinvolte, strumenti utilizzati e reportistica prodotta.

La misura RS.MA-01 richiede di definire, attuare, aggiornare e documentare un piano per la gestione degli incidenti e la notifica al CSIRT Italia, in accordo a quanto previsto dall’articolo 25 del decreto. Il piano deve includere almeno le fasi e le procedure di gestione e notifica, con ruoli e responsabilità; le procedure per predisporre e trasmettere relazioni intermedie, mensili e finali; le informazioni di contatto per la segnalazione; le modalità di comunicazione interna ed esterna, includendo il coinvolgimento degli organi di amministrazione e direttivi; e la reportistica per documentare l’incidente. La stessa misura chiede che il piano venga approvato dagli organi di amministrazione e direttivi, riesaminato e aggiornato periodicamente almeno ogni due anni, e aggiornato anche dopo incidenti significativi integrando le lezioni apprese o mutamenti dell’esposizione alle minacce.

Qui emerge il primo passaggio “politico” della compliance NIS2: la gestione incidenti non è delegabile in modo totale al reparto tecnico. Il vertice approva, quindi deve comprendere almeno il modello di escalation, le soglie che attivano comunicazioni esterne e i vincoli di business che possono cambiare le scelte di contenimento. Se il piano esiste solo come documento tecnico, in crisi si trasforma in un elenco di buone intenzioni.

Ruoli e responsabilità e il nodo del Referente CSIRT

Le linee guida chiariscono che la figura deputata alle interlocuzioni con il CSIRT e alle notifiche obbligatorie e volontarie è il Referente CSIRT, designato dal Punto di contatto. Allo stesso tempo, ricordano che durante le interlocuzioni possono servire decisioni che escono dalle competenze del Referente CSIRT, e quindi l’organizzazione deve definire ruoli, responsabilità, fasi e procedure per assumere tali decisioni, che nei casi più rilevanti spettano agli organi di amministrazione e direttivi. Questo passaggio è il vero test di maturità: il team può raccogliere evidenze, ma solo un perimetro di deleghe chiaro evita ritardi che bruciano le finestre temporali della notifica.

Identificazione

Inventario e perimetro operativo

L’identificazione è la fase che impedisce al processo di diventare astratto. Si parte dall’inventario dei sistemi informativi e di rete, includendo l’elenco dei sistemi rilevanti, perché incident response senza mappa si riduce a un inseguimento. Un inventario utile all’IR non è un foglio Excel statico: è un set di informazioni aggiornate su asset, proprietari, dipendenze e criticità, che consente di decidere cosa isolare senza spegnere l’intera azienda e consente di capire cosa preservare a fini forensi.

Minacce e vulnerabilità come input continuo

Le linee guida inseriscono l’individuazione di minacce e vulnerabilità come parte della preparazione, non come attività separata. Questo punto è cruciale per l’operatività: se l’organizzazione non monitora vulnerabilità e segnali di minaccia, il “momento dell’evidenza” dell’incidente arriva più tardi, e più tardi partono i timer per 24 e 72 ore. In un contesto NIS2, il ritardo non è solo tecnico, diventa anche rischio di non conformità, perché l’evidenza dell’incidente spesso coincide con la prima correlazione utile tra log, alert e contesto.

Protezione

Misure tecnologiche e capacità di risposta

La protezione, nelle linee guida, non viene trattata come un capitolo di hardening generico, ma come l’insieme di presidi che rendono possibile la gestione incidenti. Logging adeguato, retention coerente, sincronizzazione temporale, controllo degli accessi e segregazione diventano prerequisiti dell’investigazione. Anche il backup smette di essere un adempimento di continuità operativa e diventa una leva di ripristino verificabile, soprattutto quando l’incidente coinvolge dati e servizi critici.

Misure organizzative e canali di comunicazione

La protezione include componenti organizzative che, nella pratica, determinano la resilienza: canali protetti per comunicare durante l’emergenza, procedure per attivare fornitori e partner quando la compromissione tocca la supply chain, e modelli di comunicazione interna che raggiungano rapidamente vertice, ufficio legale e funzioni impattate. Senza questi presidi, la “gestione” si riduce a interventi tecnici non coordinati, mentre NIS2 chiede un comportamento tracciabile, documentato e replicabile.

Rilevamento

Il rilevamento è la fase in cui l’organizzazione costruisce la propria capacità di arrivare presto all’evidenza dell’incidente. Le linee guida collegano questo punto anche alle politiche e alla definizione dei livelli attesi di servizio. In chiave NIS2, rilevare non significa solo “vedere un alert”, ma produrre un giudizio: capire se l’evento rientra in una tipologia di incidente significativo e se sta compromettendo riservatezza, integrità o livelli di servizio attesi.

Qui la misura di riferimento diventa anche culturale: l’organizzazione deve definire quali indicatori rendono “evidente” un incidente e come si passa dalla detection alla decisione. Se i livelli di servizio attesi non sono definiti, la tipologia di incidente basata sulla violazione degli SL perde sostanza e diventa impossibile stabilire quando un disservizio si trasforma in incidente significativo.

Risposta

Segnalazione

La risposta si apre con la segnalazione, e le linee guida entrano nel punto più sensibile: come notificare quando non si sa ancora tutto. La trasmissione delle notifiche al CSIRT Italia avviene tramite il portale https://segnalazioni.acn.gov.it/. Il documento sottolinea che, nelle fasi iniziali, potrebbero non essere disponibili tutte le informazioni richieste, come servizi e utenti impattati o vulnerabilità sfruttate, perché spesso emergono solo dopo un esame approfondito. Proprio per questo la logica operativa diventa sequenziale: prima la pre-notifica entro 24 ore dall’evidenza dell’incidente con ciò che si sa, poi le attività di investigazione, quindi il ritorno alla segnalazione per trasmettere la notifica entro 72 ore dall’evidenza dell’incidente con un quadro più robusto.

Le linee guida aggiungono un elemento che molte organizzazioni devono formalizzare: la segnalazione include anche la comunicazione alle parti interne ed esterne interessate, perché l’incidente non è un fatto “chiuso” in IT. Qui si innesta la misura RS.CO-02: quando ACN lo intima e quando opportuno e possibile, sentito il CSIRT Italia, l’organizzazione deve comunicare ai destinatari dei propri servizi gli incidenti significativi che possono ripercuotersi negativamente sulla fornitura e deve comunicare ai destinatari potenzialmente interessati da una minaccia informatica significativa le misure correttive o di mitigazione adottabili e la natura della minaccia. La stessa misura prevede la possibilità di informare il pubblico sugli incidenti occorsi quando ACN lo intima.

In parallelo, le linee guida ricordano che, se l’incidente comporta una violazione di dati personali, entra in gioco anche l’obbligo di notifica al Garante per la protezione dei dati personali ai sensi dell’articolo 33 del GDPR, salvo i casi in cui sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche. Questo passaggio impone una sincronizzazione tra incident response e privacy: la catena decisionale deve prevedere il coinvolgimento del DPO o di chi presidia la compliance privacy, senza bloccare la velocità della notifica NIS.

Per approfondire la procedura di notifica, le linee guida rimandano alla guida ACN “Guida alla notifica degli incidenti informatici” disponibile qui: https://www.acn.gov.it/portale/w/guida-alla-notifica-degli-incidenti-informatici e alle FAQ NIS su misure e notifiche di base: https://www.acn.gov.it/portale/faq/nis/misure-notifiche-base.

Le relazioni: dalla notifica alla chiusura formale dell’incidente

Il documento ricostruisce anche il flusso successivo alla notifica, cioè la parte che trasforma la gestione in un ciclo tracciabile. Dopo la pre-notifica e la notifica, il processo prevede aggiornamenti e relazioni: su richiesta del CSIRT Italia può essere necessaria una relazione intermedia sui pertinenti aggiornamenti della situazione; la relazione finale deve arrivare entro un mese dalla trasmissione della notifica e deve includere una descrizione dettagliata dell’incidente con gravità e impatto, il tipo di minaccia o la probabile causa originale, le misure di attenuazione adottate e in corso, e, se noto, l’impatto transfrontaliero. Se l’incidente è ancora in corso al momento della relazione finale, il processo prevede una relazione mensile sui progressi e una relazione finale entro un mese dalla conclusione della gestione.

Questo blocco cambia la gestione incidenti in modo netto: non basta “ripristinare il servizio”. Serve una capacità di ricostruzione, attribuzione tecnica della causa probabile e documentazione delle contromisure, perché la compliance NIS2 vive anche nella qualità della reportistica.

Investigazione

L’investigazione è la fase in cui l’organizzazione prova a ricostruire l’intera sequenza degli eventi, la cosiddetta cyber kill chain, per individuare la causa e valutare l’estensione della compromissione. Le linee guida avvertono che potrebbe essere necessario tornare più volte all’investigazione, perché la notifica al CSIRT può far emergere nuovi indicatori di compromissione e perché durante l’eradicazione possono emergere nuovi artefatti malevoli. Questo approccio “a ricorsione” impone un’organizzazione dei dati e delle evidenze rigorosa: ogni nuova informazione deve entrare in una timeline coerente.

Nel concreto, l’investigazione include l’acquisizione di evidenze forensi, la valutazione del perimetro compromesso, la caratterizzazione dell’incidente almeno per categoria, gravità e impatto, e l’esame basato su log, artefatti ed evidenze rilevate, correlazione degli eventi e attività dell’attaccante, predisposizione della timeline, identificazione del vettore di attacco e della possibile causa, e individuazione e documentazione degli indicatori di compromissione.

Questa descrizione ha un effetto operativo: l’organizzazione deve predisporre, prima dell’incidente, strumenti e procedure che rendano acquisibili e preservabili log ed evidenze senza distruggerle. Se durante la risposta si “ripulisce” senza preservare, la relazione finale diventa fragile e la capacità di apprendere dall’incidente crolla.

Contenimento

Il contenimento, nella logica delle linee guida, è la fase che riduce l’impatto mentre l’investigazione procede. In contesti reali, contenere significa isolare segmenti di rete, limitare accessi, mettere in sicurezza endpoint e server, e interrompere la propagazione, con una tensione costante tra continuità operativa e sicurezza. Proprio per questo il processo deve prevedere chi decide cosa spegnere e con quali criteri, perché un contenimento tardivo rende inutile la migliore investigazione.

NIS2 spinge a formalizzare questi criteri perché, se l’incidente compromette livelli di servizio attesi, la decisione di contenimento incide direttamente sulla valutazione di impatto e quindi sul contenuto delle relazioni. Un contenimento ben disegnato, inoltre, può produrre indicatori utili da condividere con il CSIRT, riducendo la finestra di esposizione anche per altri soggetti.

Eradicazione

L’eradicazione mira a rimuovere la causa tecnica dell’incidente e impedire la re-infezione o la ri-entrata dell’attaccante. In un ransomware può significare rimozione di persistenza e ripulitura di strumenti laterali; in una compromissione di credenziali può significare reset di password e rotazione di chiavi e certificati; in un attacco basato su vulnerabilità può significare patching e mitigazioni temporanee, con verifiche sul fatto che la vulnerabilità non sia sfruttabile altrove nel perimetro.

Il valore del documento ACN qui sta nel collegamento implicito con la reportistica: l’organizzazione deve saper descrivere le misure di attenuazione adottate e in corso e deve saper sostenere, nella relazione finale, una root cause probabile. Questo spinge verso pratiche di hardening documentato e verso un change management che conservi traccia delle azioni eseguite durante la crisi.

Ripristino

Il ripristino chiude la sequenza tecnica ma non chiude l’incidente sul piano NIS2. Ripristinare significa riportare servizi e attività entro livelli di funzionamento accettabili, verificare che i sistemi ripristinati non contengano residui di compromissione e confermare che il servizio torni entro i livelli attesi definiti in precedenza. In un contesto dove la violazione degli SL può costituire incidente significativo, il ripristino richiede misure: senza baseline e metriche non si dimostra il ritorno alla normalità.

In questa fase, backup e piani di continuità diventano evidenze operative. Se un’organizzazione non ha backup verificati e offline o non ha testato la restaurabilità, il ripristino si trasforma in improvvisazione, e la gestione incidenti finisce per durare settimane, obbligando a relazioni mensili e a un dialogo prolungato con CSIRT e autorità.

Miglioramento

Il miglioramento è la fase che trasforma l’incidente in un investimento, non in una perdita. Le linee guida lo legano esplicitamente al riesame del piano e all’integrazione delle lezioni apprese, prevedendo aggiornamenti almeno biennali e aggiornamenti anche a seguito di incidenti significativi. Questo passaggio impone un metodo: post-incident review strutturata, aggiornamento di procedure e controlli, revisione delle metriche di rilevamento e delle soglie di escalation, e riallineamento tra risk assessment e realtà dell’attacco subito.

In termini NIS2, il miglioramento è anche un argomento di governance: gli organi di amministrazione e direttivi approvano il piano e quindi devono ricevere evidenze di come l’organizzazione ha imparato dall’incidente. È qui che la gestione incidenti diventa cultura organizzativa e non semplice operazione di emergenza.

Incidenti significativi di base: il modello IS e la differenza tra soggetti importanti e soggetti essenziali

La parte “normativa-operativa” più interessante delle specifiche di base riguarda le tipologie di incidenti significativi. Le linee guida ricordano che sono state definite 3 tipologie per i soggetti importanti e 4 tipologie per i soggetti essenziali, e che ogni tipologia può essere descritta da un modello composto da condizione, compromissione e oggetto della compromissione. Questo modello serve a rendere verificabile l’obbligo: l’organizzazione non discute più in modo generico se “è grave”, ma valuta se si è verificata una specifica condizione e se la compromissione riguarda un oggetto definito.

Il documento esemplifica la rappresentazione in tabella e introduce codici come IS-1, IS-2 e IS-3, legati rispettivamente a perdita di riservatezza verso l’esterno, perdita di integrità con impatto verso l’esterno e violazione dei livelli di servizio attesi, con l’oggetto della compromissione indicato nei dati digitali o nei servizi.

Operativamente, questo significa che il processo deve includere una capacità di classificazione rapida: quando l’organizzazione ha evidenza di perdita di riservatezza verso l’esterno su dati digitali, deve capire se rientra nella tipologia IS-1 e quindi se scatta l’obbligo. Quando rileva una manipolazione che impatta verso l’esterno, deve valutare la logica IS-2. Quando i livelli di servizio scendono sotto la soglia attesa, deve poter misurare e dimostrare la violazione per capire se si attiva IS-3. Senza definizione dei livelli di servizio, questa valutazione è impossibile e la compliance diventa aleatoria.

Misure di sicurezza di base e Framework nazionale: perché incident response è un sistema, non una singola misura

Le linee guida ricordano che le misure di sicurezza di base sono sviluppate in accordo al Framework nazionale e fanno uso della versione 2025 disponibile su https://www.cybersecurityframework.it/. Nel complesso, sono state definite 37 misure con 87 requisiti per i soggetti importanti e 43 misure con 116 requisiti per i soggetti essenziali, in applicazione del principio per cui gli obblighi tengono conto di esposizione al rischio, dimensioni e probabilità e gravità degli incidenti, incluso impatto sociale ed economico.

Questo contesto spiega una scelta di design: ACN non tratta la gestione incidenti come un capitolo isolato. La lega a inventario, valutazione del rischio, protezione, rilevamento e comunicazione, e introduce anche clausole operative che, se usate male, diventano un boomerang. La possibilità di limitare l’ambito ai sistemi rilevanti può funzionare solo se l’inventario dei sistemi rilevanti è accurato. La possibilità di definire modalità e ambito di attuazione in funzione della valutazione del rischio funziona solo se la valutazione del rischio è seria e documentata. La possibilità di derogare per ragioni normative o tecniche richiede motivazioni documentate, e quindi governance e tracciabilità.

Da qui nasce un principio pratico: un processo di gestione incidenti conforme alle linee guida non si costruisce “a valle”, quando l’azienda ha già subito l’incidente. Si costruisce a monte, integrando i requisiti in procedure e strumenti che producano evidenze, cioè log, report, timeline, decisioni e comunicazioni tracciate.

Tradurre le linee guida in operatività: piano, runbook e disciplina delle informazioni

Cosa cambia in azienda perché quelle fasi funzionino?

Il primo elemento è il piano RS.MA-01: deve essere scritto in modo che, durante la crisi, chiunque sappia dove guardare. Non basta “avere un piano”. Serve un piano che includa contatti, escalation, deleghe decisionali, modelli di reportistica e procedure per relazioni intermedie, mensili e finali.

Il secondo elemento è la disciplina delle informazioni: la finestra di 24 ore dalla evidenza dell’incidente impone che l’organizzazione definisca prima che cosa è “evidenza” e come viene registrata, perché quel timestamp può diventare il riferimento temporale per la pre-notifica e la notifica. Un’organizzazione matura registra l’evidenza come evento formalizzato, non come commento in chat. Questo non burocratizza l’IR: lo rende ripetibile.

Il terzo elemento è l’integrazione tra detection e reportistica. Le linee guida sono esplicite: nella prima fase potrebbero mancare informazioni, ma la pre-notifica deve partire con ciò che è disponibile, e l’organizzazione deve poi aggiornare dopo investigazione. Questo richiede che investigazione e segnalazione non siano silos: chi investiga deve sapere cosa serve per aggiornare la notifica e deve alimentare una narrativa tecnica coerente che confluirà nella relazione finale.

Il quarto elemento è la comunicazione esterna. La misura RS.CO-02 e il richiamo alle comunicazioni a utenti e destinatari, oltre alla possibilità di informare il pubblico se ACN lo intima, impongono una collaborazione stretta tra sicurezza, legale e comunicazione. NIS2, in questo senso, non “aggiunge un obbligo”: costringe l’azienda a progettare una comunicazione che non peggiori l’incidente e non esponga ulteriormente la superficie di attacco. Anche per questo la guida alla notifica e il portale diventano strumenti operativi, non solo canali amministrativi: https://segnalazioni.acn.gov.it/ e https://www.acn.gov.it/portale/w/guida-alla-notifica-degli-incidenti-informatici.

Il quinto elemento è la chiusura formale tramite relazioni. La relazione finale richiede dettagli tecnici, root cause probabile, misure adottate, impatto transfrontaliero se noto. Questo obbliga l’organizzazione a investire in capacità di analisi e forensics e in una gestione documentale della crisi. Anche la previsione di relazioni mensili in caso di incidente in corso impone un sistema di tracciamento e aggiornamento: se l’azienda non mantiene una timeline viva, finisce per ricostruire tutto a posteriori, con rischi di incoerenza.

Il sesto elemento è il miglioramento. Se il piano deve essere aggiornato dopo un incidente significativo integrando lezioni apprese, l’organizzazione deve prevedere una fase di debrief obbligatoria, con output concreti: quali controlli mancavano, quali alert non hanno funzionato, quali dipendenze non erano note, quali decisioni hanno richiesto troppo tempo. Questo output deve rientrare nel ciclo di governance, perché il piano viene approvato dagli organi direttivi e quindi deve tornare al vertice con evidenze e proposte di correzione.

Guida Matrice Digitale su NIS2 e obblighi ACN

FAQ sulla gestione incidenti NIS2 secondo le linee guida ACN