Incident Reporting sotto direttiva NIS2: come strutturare i processi di notifica in 24 ore

Gli incidenti significativi che colpiscono infrastrutture e servizi critici mettono le entità essenziali e importanti di fronte a una vera corsa contro il tempo per rispettare gli obblighi di notifica previsti dalla NIS2. In particolare, l’early warning deve essere trasmesso entro 24 ore dalla conoscenza/evidenza dell’incidente, richiedendo all’organizzazione una capacità di risposta tempestiva e strutturata.

Inoltre, per rispettare queste tempistiche, non è sufficiente reagire rapidamente all’evento: è necessario essere preparati in anticipo. L’organizzazione deve infatti essere in grado di classificare l’incidente e valutarne la significatività, attivare una chiara catena delle responsabilità, disporre di strumenti e procedure efficaci per la gestione e la notifica, valutare l’eventuale coinvolgimento di dati personali ai sensi del GDPR e comprendere il ruolo della supply chain e dei fornitori critici.

A questo si aggiunge la necessità di considerare le responsabilità degli organi direttivi, chiamati a garantire una governance adeguata del rischio cyber e la capacità dell’organizzazione di prevenire, gestire e comunicare tempestivamente gli incidenti.

Notifica degli incidenti NIS2: obblighi e vincolo delle 24 ore

Il D.Lgs 138/2024 recepisce in Italia la Direttiva NIS2 e stabilisce che i soggetti essenziali ed importanti devono notificare al CSIRT Italia gli incidenti significativi. Tale regime di notifica è pienamente operativo dal 15 gennaio 2026, come stabilito dalla determinazione ACN n. 379907/2025 determinazione ACN n. 379907/2025.

Inoltre, come indicato sul sito dell’ACN, sono state predisposte specifiche linee guida per supportare i soggetti NIS2 nel percorso di adeguamento agli obblighi previsti dal decreto. Tra queste risultano:

• Linee guida NIS – Specifiche di base – Guida alla lettura  con le quali sono fornite indicazioni per agevolare la comprensione e l’interpretazione delle specifiche di base degli allegati tecnici;
• Linee guida NIS – Specifiche di base – Per la definizione del processo di gestione degli incidenti di sicurezza informatica, con le quali viene suggerito un modello per il processo di gestione degli incidenti e descritta la relazione tra le fasi del processo e le misure di sicurezza di base”.

È importante evidenziare che la principale difficoltà nella gestione degli incidenti è la stretta tempistica di notifica, dato che, entro poche ore, bisogna comprendere se si tratti o meno di evento significativo, attivare la procedura di notifica e individuare quali informazioni sono già disponibili.

I criteri per riconoscere un incidente significativo

L’art. 25 del D.Lgs. 138/2025 definisce come “incidente significativo” un evento di sicurezza informatica che blocca o danneggia in modo pesante i servizi essenziali o importanti di un’azienda o di un ente, oppure che causa perdite economiche enormi o danni materiali e immateriali gravi a terzi.

In particolare, rientrano in questa categoria gli incidenti per i quali l’entità NIS dispone di evidenza de:

la perdita di riservatezza, con impatto verso l’esterno, di dati digitali che possiede o controlla, anche solo parzialmente;

la perdita di integrità, con impatto verso l’esterno, di dati digitali che possiede o controlla, anche solo parzialmente;

la violazione dei livelli di servizio attesi per i propri servizi e/o attività, sulla base dei livelli di servizio (SL) precedentemente stabiliti.

Inoltre, per le entità essenziali, sono considerati significativi anche gli incidenti per i quali vi sia evidenza di accessi non autorizzati ai dati digitali o accessi ottenuti mediante l’abuso di privilegi concessi, quando tali dati sono posseduti o controllati, anche solo parzialmente, dall’entità NIS2.

Ancora, ACN ha fornito la Tassonomia Cyber (TC-ACN) per: favorire lo scambio di informazioni attraverso un linguaggio comune e condiviso, anche ai fini della notifica degli incidenti al CSIRT Italia; fornire una classificazione nazionale univoca per identificare e caratterizzare gli eventi cyber; armonizzare il quadro nazionale con le principali tassonomie internazionali di cybersecurity, adattandole al contesto normativo italiano

Early warning, notifica completa e relazione finale

Il processo di notifica si articola in tre momenti:

Pre-notifica (early warning) – Entro 24 ore – La pre-notifica va inviata, senza ingiustificato ritardo e, comunque, entro le 24 ore dall’evidenza dell’incidente. Si tratta di fornire una segnalazione tempestiva con le informazioni disponibili (i.e. cosa sembra accaduto, quali servizi sono coinvolti; sospetto di azione illecita o un impatto transfrontaliero).

Notifica completa – Entro 72 ore – La notifica completa è inviata entro le 72 ore successive e fornisce un aggiornamento delle informazioni iniziali, una prima valutazione della gravità e dell’impatto e, se disponibili, degli indicatori di compromissione (IoC).

Relazione Finale – Entro 1 mese dalla notifica – La relazione finale, entro un mese, fornisce una descrizione dettagliata, causa probabile (.i. root cause), misure adottate e in corso, eventuale impatto transfrontaliero.

È importante evidenziare che i termini non decorrono dall’inizio dell’attacco, bensì dal momento di evidenza dell’incidente significativo, che può emergere anche molto dopo la compromissione iniziale.

Inoltre, se la gestione dell’incidente significativo è ancora aperta allo scadere del mese, si invieranno relazioni mensili di avanzamento e la relazione finale entro un mese dalla chiusura della gestione.

Preparare il processo di segnalazione al CSIRT Italia

È importante sottolineare che un processo di notifica deve essere strutturato secondo passaggi efficaci e in base a responsabilità nominali e decisioni già autorizzate. Pertanto, dovrebbe essere così articolato: rilevazione, triage tecnico, classificazione, decisione di notifica, invio segnalazione attraverso il canale ufficiale, aggiornamenti successivi.

Classificazione e decisioni: la catena delle responsabilità

La NIS2 attribuisce la responsabilità ultima agli organi di gestione che approvano e sovrintendono le misure di gestione del rischio. Nel momento critico, però, serve una catena decisionale snella, ad esempio:

• SOC o team di sicurezza – Esso ha la responsabilità di rilevare e di qualificare tecnicamente l’evento, raccogliendo le prime evidenze.
• Incident manager (spesso il CISO) – Applica la procedura di classificazione e decide se l’evento è significativo.
• Referente per il CSIRT Italia – È responsabile di trasmettere le notifiche. Il ruolo va formalizzato, con sostituti nominati e procedure chiare ed inserito nella piattaforma di ACN.
• Direzione e organo di gestione – È necessario che siano prontamente informati e devono ricevere un quadro aggiornato a ogni stadio.
• Legale e DPO – Essi valutano in parallelo i profili contrattuali e la possibile violazione di dati.

Le informazioni da predisporre per la segnalazione iniziale

L’early warning non deve essere perfetto, bensì tempestivo. Un modello di segnalazione iniziale dovrebbe già contenere:

• dati identificativi del soggetto e del referente;

• data e ora di evidenza e, se note, di inizio dell’incidente;

• tipologia presunta (ransomware, DDoS, compromissione di credenziali, esfiltrazione di dati);

• servizi, sistemi e asset coinvolti, con una stima dell’impatto;

• sospetto di attività illecita o dolosa;

• possibile impatto transfrontaliero;

• misure di contenimento già avviate.

È opportuno preparare il modello in anticipo, con i campi anagrafici precompilati e secondo la sopra menzionata Tassonomia Cyber di ACN. I dettagli tecnici più approfonditi, quali gli IoC completi, possono attendere la notifica a 72 ore.

Automatizzare la raccolta delle evidenze per la notifica

La raccolta di evidenze, la ricostruzione della timeline, la compilazione dei modelli può essere automatizzata e far risparmiar tempo prezioso, senza alcun togliere al giudizio umano in termini di significatività dell’incidente. Ma vediamo come.

SIEM e SOAR: dalla rilevazione alla precompilazione

Un sistema SIEM (Security Information and Event Management) raccoglie e correla i log di tutta la rete aziendale, mettendo in relazione i dati in tempo reale per trovare comportamenti strani o attacchi e generare alert.

Un SOAR (Security Orchestration, Automation and Response), invece, automatizza le risposte agli incidenti e collega tra loro diversi programmi di sicurezza ed usa i playbook (i.e. regole e istruzioni passo-passo per agire da solo), riducendo il lavoro manuale e accelerando i tempi di reazione.

È importante evidenziare che il dialogo tra questi due sistemi consente di ottenere un flusso continuo dalla rilevazione alla notifica, e, precisamente:

• apertura automatica del ticket di incidente, con le evidenze già allegate;
• registrazione dell’orario di evidenza, che avvia il conto alla rovescia delle 24 ore;
• arricchimento dell’evento con IoC, asset coinvolti e criticità dei servizi colpiti;
• precompilazione dei campi del modello di notifica;
• escalation automatica verso incident manager, se non c’è presa in carico entro tempi definiti.

Playbook ed esercitazioni contro i colli di bottiglia

I playbook trasformano una procedura in azioni ripetibili, pertanto devono coprire gli scenari più probabili – ad esempio, ransomware, esfiltrazione di dati, indisponibilità di un servizio critico, compromissione di un fornitore – e, per ciascuno di essi, è necessario prevedere:

• criteri di classificazione e soglia di significatività;
• albero decisionale per la notifica: chi decide, con quali informazioni, entro quando;
• checklist dei contenuti per early warning, notifica e relazione finale;
• contatti di emergenza, sostituti e canali alternativi se i sistemi ordinari sono fuori uso.

Inoltre, si consiglia di testare i playbook attraverso esercitazioni periodiche (i.e. tabletop e simulazioni) per eliminare eventuali ulteriori colli di bottiglia, prima che emergano durante l’incidente.

Notifiche NIS2 e GDPR: coordinare i due percorsi

È importante evidenziare che uno stesso incidente/evento può comportare obblighi di notifica verso autorità diverse.

Un ransomware che cifra i sistemi ed esfiltra dati, ad esempio, è sia un incidente NIS2 sia una violazione dei dati personali ai sensi del GDPR. Pertanto, per gestire efficacemente la sovrapposizione normativa è opportuno adottare un approccio coordinato, ovvero, un’unica ricostruzione tecnica dell’evento, sulla quale innestare le diverse valutazioni normative e i relativi processi di notifica.

Ne consegue che il SOC, il CSIRT interno, le funzioni legali e il DPO dovrebbero quindi lavorare sullo stesso nucleo informativo, condividendo e aggiornando almeno:

• l’ora della prima evidenza dell’incidente;
• le modalità di compromissione e di sfruttamento della vulnerabilità;
• i sistemi, le reti e i servizi coinvolti;
• gli effetti sulla disponibilità e sulla continuità dei servizi;
• la natura e l’eventuale quantità dei dati personali coinvolti;
• gli indicatori tecnici utili all’analisi e alla difesa della rete;
• le misure di contenimento e mitigazione già adottate;
• le informazioni disponibili sulle cause e sull’evoluzione dell’incidente;
• le notifiche e le comunicazioni già effettuate.

Ciò garantirebbe una gestione tecnica unitaria dell’incidente, mentre le valutazioni giuridiche e gli adempimenti di notifica vengono gestiti secondo i rispettivi requisiti NIS2 e GDPR.

Inoltre, ruoli, responsabilità, criteri decisionali e canali di escalation dovrebbero essere definiti prima dell’incidente e verificati attraverso esercitazioni periodiche.

La capacità di rispettare le diverse scadenze normative dipende, quindi, non dalla velocità con cui si redige una notifica dopo l’evento, ma dalla preparazione preventiva dell’organizzazione e dalla disponibilità di un processo integrato di incident response, valutazione normativa e comunicazione.

Continuità dei servizi e tutela dei dati: criteri distinti

È importante distinguere gli obiettivi e i criteri di attivazione previsti dalla NIS2 e dal GDPR, poiché, come già evidenziato, un medesimo incidente può avere conseguenze rilevanti sotto uno dei due profili, senza necessariamente configurare una violazione anche nell’altro.

Ai sensi della NIS2, l’attenzione è rivolta principalmente alla continuità e alla sicurezza dei servizi. Un incidente deve essere notificato quando raggiunge i criteri di significatività previsti dalla normativa e la gestione e la notifica degli incidenti coinvolgono il CSIRT Italia e l’ACN, secondo tempistiche già citate.

Il GDPR, invece, tutela i diritti e le libertà delle persone fisiche, i cui dati personali sono coinvolti. L’obbligo di notifica al Garante per la protezione dei dati personali scatta quando si verifica una violazione di dati personali che presenta un rischio per i diritti e le libertà degli interessati. La notifica deve essere effettuata, ove applicabile, entro 72 ore dal momento in cui il titolare viene a conoscenza della violazione; quando il rischio per gli interessati è elevato, può essere inoltre necessaria la comunicazione agli stessi.

NIS2 e GDPR non sono, di fatto, sovrapponibili. Ad esempio, un blocco della produzione causato da un malware può costituire un incidente significativo ai sensi della NIS2 senza comportare necessariamente una violazione di dati personali ai sensi del GDPR.

Al contrario, un’e-mail contenente dati personali ed inviata per errore al destinatario sbagliato può configurare un data breach ai sensi del GDPR, senza causare alcuna interruzione o compromissione della continuità operativa.

Pertanto, la corretta gestione di un incidente richiede di valutare sia l’impatto sulla continuità operativa e la sicurezza dei servizi sia l’eventuale coinvolgimento di dati personali, oltre a verificare gli obblighi di notifica previsti dai rispettivi quadri normativi.

Un registro condiviso per comunicazioni coerenti

A fronte di quanto appena evidenziato è importante essere in grado di gestire l’incidente secondo un approccio orchestrato di multi-compliance:

• un registro incidenti unico, con una timeline condivisa tra security, legale e DPO;
• una classificazione parallela, con criteri NIS2 e criteri GDPR nella stessa scheda di valutazione;
• il DPO coinvolto già nel triage, non a valle;
• modelli di comunicazione distinti, ma alimentati dagli stessi fatti verificati;
• messaggi coerenti: le due autorità devono ricevere descrizioni compatibili dell’evento, altrimenti le discrepanze diventano un problema a sé.

Incidenti nella supply chain: preparare lo scambio di informazioni

Gli eventi recenti hanno ulteriormente evidenziato il fatto che molti incidenti significativi nascono, o transitano, da un fornitore (i.e. un provider cloud, un managed service provider, un software gestionale). La NIS2 richiede la sicurezza della catena di approvvigionamento tra le misure di gestione del rischio, e chi dipende da servizi esterni non può limitarsi a delegare. Ma vediamo in dettaglio di che si tratta a seconda dei casi.

Fornitori cloud: tempi, contatti e obblighi contrattuali

Quando un incidente si verifica presso un fornitore cloud e può avere un impatto sui servizi dell’organizzazione soggetta alla NIS2, è fondamentale distinguere tra obblighi del fornitore e responsabilità dell’entità NIS2.

Di fatto, il fornitore cloud deve garantire una comunicazione tempestiva dell’incidente all’organizzazione cliente, secondo quanto previsto dagli accordi contrattuali e dai livelli di servizio definiti. L’entità NIS2, invece, deve disporre delle informazioni necessarie per valutare la significatività dell’incidente ed effettuare le notifiche previste dalla normativa NIS2 e dalle disposizioni ACN.

Ne consegue che i contratti con i fornitori cloud dovrebbero disciplinare, in modo chiaro, almeno i seguenti aspetti:

• SLA e requisiti di sicurezza, definendo livelli di servizio, disponibilità, resilienza e sicurezza attesi.
• Obblighi di notifica degli incidenti, specificando quali eventi devono essere comunicati e con quali modalità.
• Tempistiche di comunicazione, sufficientemente rapide da consentire all’organizzazione di rispettare le proprie scadenze normative, anche attraverso una comunicazione iniziale entro poche ore dalla rilevazione dell’incidente.
• Punti di contatto operativi 24/7 e procedure di escalation, preventivamente individuati e verificati.
• Contenuti minimi della comunicazione, comprendenti, ove disponibili: servizi interessati, natura e impatto dell’incidente, dati o sistemi potenzialmente coinvolti e misure di contenimento adottate.
• Accesso alle informazioni necessarie per gli adempimenti normativi, incluse quelle relative alla causa dell’incidente, agli impatti, alle misure correttive e all’evoluzione dell’evento.
• Obblighi di collaborazione, anche nell’ambito di attività di analisi, audit, test ed esercitazioni congiunte.
• Responsabilità, rimedi e meccanismi di escalation in caso di ritardi, mancata comunicazione o inadempimento degli obblighi concordati.

Inoltre, è importante mappare e classificare i fornitori critici, valutandone il livello di dipendenza, la rilevanza dei servizi forniti e il potenziale impatto sulla continuità operativa.

Ancora, la resilienza della supply chain dovrebbe essere verificata, non soltanto attraverso assessment documentali, ma anche mediante simulazioni ed esercitazioni congiunte, finalizzate a verificare che i processi di gestione degli incidenti, comunicazione, escalation e continuità del fornitore siano effettivamente coerenti e integrati con quelli dell’organizzazione.

L’obiettivo non è semplicemente stabilire chi deve comunicare l’incidente, ma assicurare che l’intera catena di gestione sia in grado di garantire: rilevazione tempestiva, condivisione delle informazioni, escalation e adempimento degli obblighi di notifica, anche quando l’evento ha origine al di fuori del perimetro diretto dell’organizzazione.

Omessa notifica e responsabilità degli organi direttivi

È importante evidenziare che l’omessa o tardiva notifica espone a sanzioni amministrative pecuniarie, disciplinate dall’art. 38 del D.Lgs. 138/2024. E precisamente:

• Soggetti essenziali – Fino a 10 milioni di euro o al 2% del fatturato mondiale annuo
• Soggetti importanti – Fino a 7 milioni di euro o all’1,4% del fatturato mondiale annuo

L’importo concreto dipende dalla violazione contestata e dalle circostanze del caso, quindi, va sempre verificato sul testo vigente e sulle indicazioni dell’ACN.

Inoltre, in termini di accountability degli organi direttivi, sono previste sanzioni accessorie, considerando che, ai sensi dell’art. 23 del D.Lgs. 138/2024, gli organi direttivi devono:

• Approvare e vigilare – Adottare formalmente le misure di gestione dei rischi informatici e supervisionarne l’attuazione pratica.
• Formazione obbligatoria – Seguire corsi specifici in materia di cybersecurity per comprendere le minacce e i rischi di gestione.
• Formazione aziendale – Promuovere e garantire un’offerta periodica di formazione sulla sicurezza informatica anche per tutti i dipendenti.
• Dimostrare la compliance – Conservare le prove documentali delle decisioni e delle attività di supervisione svolte (principio di accountability).

La mancata osservanza di questi doveri sposta la responsabilità sul piano personale e sono previste sanzioni amministrative pecuniarie e personali, oltre a misure interdittive (i.e. la sospensione temporanea dalle funzioni direttive) in caso di gravi inadempienze, fino all’adozione di piani correttivi.

La notifica sul campo: l’esperienza di Start 4.0

Paola Girdinio, Presidente di Start 4.0, rivela: “ Dal nostro osservatorio di Centro di Competenza vediamo che la maggior parte delle aziende che accompagniamo ha ormai compreso l’obbligo di notifica, ma molto meno la preparazione organizzativa che serve per rispettarlo: le procedure esistono sulla carta, mentre ruoli, deleghe decisionali e criteri di significatività raramente sono stati messi alla prova.

Il divario più evidente riguarda la catena decisionale e la supply chain: in poche ore bisogna capire se un evento è significativo, chi firma la decisione e quali informazioni arrivano dai fornitori critici, e quasi sempre è proprio lì che si perde tempo. Per questo formazione ed esercitazioni sono decisive: solo simulando periodicamente un incidente – con tabletop che coinvolgano insieme SOC, legale, DPO, fornitori e vertice aziendale – un’organizzazione scopre i propri colli di bottiglia prima che lo faccia un attaccante”

Inoltre, Girdinio aggiunge: “La finestra delle 24 ore non si gioca durante l’incidente ma nei mesi precedenti, e gli organi di gestione, che la NIS2 obbliga anche a formarsi, devono considerare la gestione delle crisi una responsabilità di governance, non un tema che riguarda solo i tecnici”.

Rispettare le scadenze NIS2 con una capacità organizzativa stabile

Le strette tempistiche previste per la notifica degli incidenti non devono essere interpretate come un semplice adempimento formale, ma come la necessità di disporre di una reale capacità organizzativa di rilevare, valutare, gestire e comunicare un evento cyber.

Inoltre, per rispettare le scadenze, non basta sapere quando notificare un incidente: è necessario essere già preparati a farlo. In altre parole, ci si deve “preparare in tempo di pace” per poter “agire in tempo di crisi”. Ciò comporta conoscere il proprio contesto operativo, identificare e valutare i rischi, definire responsabilità e ruoli, stabilire procedure di escalation e comunicazione e integrare i processi di cyber risk management, gestione degli incidenti, business continuity e protezione dei dati personali.

Concludendo, essere compliant non significa semplicemente rispettare una scadenza, ma dimostrare di possedere una capacità strutturata, continuativa e verificabile di gestione del rischio e degli incidenti cyber.