Un incidente va notificato quando è «significativo» secondo le fattispecie definite dall'Agenzia per la Cybersicurezza Nazionale (ACN) per i soggetti della normativa Network and Information Security (NIS). La segnalazione va al CSIRT Italia (Computer Security Incident Response Team) in due passaggi: una pre-notifica senza ingiustificato ritardo e comunque entro 24 ore da quando si dispone degli elementi oggettivi che fanno ritenere ricorsa una fattispecie, e una notifica completa entro 72 ore. A premere invio è sempre il soggetto NIS, non il fornitore di servizi di sicurezza: questo articolo ricostruisce un caso pratico e il flusso decisionale interno per arrivare preparati.
Esempio illustrativo: un venerdì senza biglietti
Esempio illustrativo. Il caso seguente è inventato: non descrive un incidente avvenuto presso un cliente.
Venerdì, ore 6:40. In una società che gestisce la bigliettazione online di una rete di trasporto regionale, inserita nell'elenco nazionale dei soggetti NIS, la piattaforma di vendita non risponde. I tecnici verificano: non è un problema di rete, il servizio è fermo e il ripristino richiede ore. I pendolari del lunedì comprano gran parte dei titoli di viaggio nel fine settimana. Il responsabile IT si chiede tre cose: questo incidente è notificabile? Chi lo valuta? Entro quando va comunicato, e con quali informazioni? Le risposte non si improvvisano durante l'emergenza: si preparano prima.
Quando un incidente va notificato
L'articolo 25 del decreto legislativo 138/2024, che recepisce la direttiva NIS2, obbliga i soggetti NIS a notificare gli incidenti significativi. Per rendere la valutazione oggettiva, ACN ha definito apposite fattispecie: tre per tutti i soggetti e una ulteriore per i soli essenziali, descritte negli allegati 3 e 4 della Determinazione ACN 379907 del 19 dicembre 2025. Come spiegano le FAQ ufficiali ACN, riguardano:
- violazioni della riservatezza di servizi e attività (per esempio dati sottratti);
- violazioni dell'integrità (dati o sistemi alterati);
- violazioni della disponibilità (un servizio che smette di funzionare, come nel nostro esempio);
- per i soli soggetti essenziali, l'accesso non autorizzato o l'abuso dei privilegi concessi.
Tre precisazioni utili, sempre dalla stessa fonte. Primo: la causa non conta ai fini della significatività — rientrano nell'obbligo anche incidenti dovuti a eventi naturali, guasti o errori umani, perché la NIS2 adotta un approccio multi-rischio. Secondo: l'obbligo è in capo al soggetto NIS cliente, anche quando l'incidente avviene su sistemi gestiti da un fornitore; il fornitore va coinvolto nella gestione, ma la notifica non si delega. Terzo: resta possibile segnalare volontariamente incidenti non significativi, quasi-incidenti e minacce. Nel nostro esempio, un fermo prolungato della bigliettazione che impedisce l'acquisto dei titoli di viaggio è esattamente il tipo di situazione da valutare rispetto alla fattispecie sulla disponibilità: la valutazione spetta al referente dell'azienda, non al software.
Le fasi della segnalazione: pre-notifica e notifica
La procedura descritta da ACN prevede due invii, con contenuti diversi:
- Pre-notifica, entro 24 ore. Va trasmessa senza ingiustificato ritardo e comunque non oltre 24 ore da quando il soggetto dispone — anche dopo un'analisi sommaria — degli elementi oggettivi da cui risulta una fattispecie. Contiene le informazioni di base necessarie al CSIRT Italia per contestualizzare l'incidente: chi è il soggetto, cosa è successo, quali servizi sono coinvolti, cosa si sa finora.
- Notifica completa, entro 72 ore. A seguito della pre-notifica, senza ingiustificato ritardo e comunque non oltre 72 ore, si trasmette la notifica con gli ulteriori elementi raccolti nel frattempo: impatti osservati, sistemi interessati, azioni intraprese, stato del ripristino.
I canali, i modelli e le eventuali comunicazioni successive vanno verificati sul portale NIS di ACN alla luce della propria posizione: l'obbligo di notifica decorre in momenti diversi a seconda di quando il soggetto è entrato nell'elenco (nove mesi dalla comunicazione di inserimento per chi è entrato nel 2025; dal 1° gennaio 2027 per chi entra nel 2026). Nel nostro scenario, l'azienda rileva il fermo alle 6:40 di venerdì: se l'analisi conferma la fattispecie, la pre-notifica deve partire entro sabato mattina. Chi ha già pronti contatti, modelli e dati arriva puntuale; chi improvvisa perde ore proprio mentre gestisce l'emergenza.
Il flusso interno: ruoli, approvazioni, evidenze
Rispettare i tempi dipende meno dalla velocità tecnica che dalla chiarezza del flusso decisionale. Un percorso ordinato prevede quattro passaggi, ciascuno con un responsabile:
- Rilevamento. Il segnale arriva dal monitoraggio, da un utente o da una segnalazione esterna: va registrato con orario e fonte. Nel nostro esempio, il fermo della piattaforma di vendita è osservato dai sistemi di controllo e confermato dai tecnici.
- Classificazione. Il referente confronta gli elementi oggettivi con le fattispecie ACN e decide se l'incidente è notificabile. È una valutazione umana, che va motivata e conservata anche quando l'esito è «non notificabile».
- Approvazione e invio. La pre-notifica e poi la notifica vengono compilate e trasmesse dal soggetto NIS attraverso i canali ufficiali, con l'autorizzazione del responsabile designato. Nessun fornitore esterno e nessun software può sostituirsi a questo atto.
- Conservazione delle evidenze. Orari, sistemi coinvolti, impatti osservati, decisioni e azioni restano in una cronologia ricostruibile: serviranno per la notifica delle 72 ore, per eventuali richieste successive e per il riesame a emergenza conclusa.
In un'azienda che usa OverZeus, tre agenti supportano questo percorso senza togliere decisioni alle persone. Ares organizza la gestione dell'incidente: priorità, indagine e un piano di contenimento che viene eseguito solo dopo l'approvazione del responsabile. Hermes porta la proposta nell'app dei responsabili, spiega le opzioni e raccoglie la decisione — il silenzio non autorizza alcun intervento. Mnemosyne conserva fonti, timeline, autorizzazioni ed esiti, così la ricostruzione per il CSIRT Italia non dipende dalla memoria di chi era di turno. OverZeus raccoglie e organizza le informazioni; non invia nulla ad ACN in autonomia: valutazione, compilazione e trasmissione restano del referente.
Prepararsi prima dell'incidente
Le linee guida internazionali sulla risposta agli incidenti, come il NIST SP 800-61 revisione 3 — un profilo applicativo del Cybersecurity Framework 2.0 — collocano la risposta agli incidenti dentro la gestione complessiva del rischio cyber: prepararsi è parte di quel percorso, non un dettaglio tecnico. In termini pratici, prima che serva, conviene:
- nominare per iscritto il referente per le comunicazioni con il CSIRT Italia e gli eventuali sostituti, come previsto dall'organizzazione di sicurezza informatica delle misure di base ACN (misura GV.RR-02);
- preparare i dati già noti della pre-notifica (identità del soggetto, servizi, contatti) in un modello pronto all'uso;
- collegare il flusso di notifica al piano di gestione degli incidenti richiesto dalle misure di sicurezza;
- verificare che la conservazione delle evidenze copra orari, sistemi, impatti e decisioni;
- simulare il percorso completo — rilevamento, classificazione, approvazione, invio fittizio — in un ambiente o canale di prova che non tocchi la produzione né i canali ufficiali.
Se la vostra posizione NIS è recente, controllate anche dove siete nel percorso amministrativo: la registrazione sul portale ACN e la designazione del punto di contatto sono il presupposto per operare senza intoppi, e sapere come prepararsi a un controllo ACN aiuta a tenere in ordine evidenze e responsabilità.
Esamina con noi le fonti e i controlli da collegare al tuo percorso NIS2.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.