Nei piani di incident response che ci capita di leggere c’è quasi sempre una tabella con una soglia interna: sopra tot ore di fermo si notifica, sotto no. È un esercizio ragionevole e, per la NIS2, superfluo. La soglia esiste già, è scritta, ed è stata definita proprio per togliere quella decisione all’azienda.
Questo articolo risponde alla domanda quando scatta l’obbligo. Il come — portale, campi, chi accede, cosa preparare prima — resta nel nostro runbook della notifica in 24 e 72 ore, che va letto insieme a questo.
La soglia non la fissate voi
Il decreto NIS obbliga i soggetti NIS a notificare allo CSIRT Italia gli incidenti considerati significativi. Detta così, la formula sembrerebbe rimandare a una valutazione discrezionale. Non è così: ACN scrive che, «al fine di semplificare tale valutazione e fornire dei parametri oggettivi», l’Autorità nazionale competente NIS ha definito quattro fattispecie — tre per tutti i soggetti e una ulteriore per i soli soggetti essenziali — che, ove si verifichino, sono considerate incidenti significativi.
La conseguenza pratica è netta. Il lavoro di preparazione non consiste nello scrivere una soglia propria, ma nel mappare i propri servizi e le proprie attività contro fattispecie già scritte da altri. Chi si è dato una soglia interna più permissiva di quelle fattispecie non ha semplificato: ha costruito un criterio che non ha valore verso l’Autorità.
Le fattispecie non sono le stesse per tutti. Sono definite nell’allegato 3 per i soggetti importanti e nell’allegato 4 per i soggetti essenziali. È lo stesso schema già usato per le misure di sicurezza di base, dove l’allegato 1 vale per gli importanti e l’allegato 2 per gli essenziali. Tutti e quattro gli allegati appartengono alla Determinazione ACN 379907 del 19 dicembre 2025.
| Soggetti importanti | Soggetti essenziali | |
|---|---|---|
| Misure di sicurezza di base | Allegato 1 | Allegato 2 |
| Fattispecie di incidente significativo | Allegato 3 | Allegato 4 |
Prima di tutto il resto, quindi, serve sapere come siete classificati. Un soggetto importante che studia l’allegato 4 sta leggendo un documento che non lo riguarda. Se non avete ancora chiarezza sulla vostra posizione nel perimetro, il punto di partenza è il nostro self-assessment NIS2, e per il quadro d’insieme la guida operativa su cosa fare nel 2026.
IS-1, IS-2, IS-3, IS-4: cosa coprono
Ogni incidente significativo è identificato da un codice e da una descrizione della tipologia. ACN riassume così i quattro codici:
| Codice | Che cosa copre, secondo ACN |
|---|---|
| IS-1 | Violazioni in termini di riservatezza dei servizi e delle attività del soggetto NIS |
| IS-2 | Violazioni in termini di integrità dei servizi e delle attività del soggetto NIS |
| IS-3 | Prevalentemente, violazioni in termini di disponibilità dei servizi e delle attività |
| IS-4 | Accesso non autorizzato o con abuso dei privilegi concessi |
Due avvertenze, perché è qui che si sbaglia leggendo di fretta.
La prima: quelle righe sono la descrizione sintetica delle categorie, non il testo delle fattispecie. Il testo puntuale — cioè quello che permette davvero di dire «questo caso rientra, quest’altro no» — sta negli allegati 3 e 4, non nelle FAQ. Una PMI che voglia scrivere la propria matrice di classificazione deve aprire l’allegato che la riguarda: riassunti di terze parti, questo incluso, non bastano.
La seconda: ACN dice che le fattispecie sono quattro, di cui tre valide per tutti e una ulteriore per i soli soggetti essenziali, ma nella descrizione dei quattro codici non specifica quale sia quella riservata agli essenziali. Non deducetelo dall’ordine dei codici, e soprattutto non costruiteci sopra una procedura: la risposta si legge confrontando l’allegato 3 con l’allegato 4.
Un’ultima nota che spesso sfugge: accanto all’obbligo resta sempre la possibilità di notificare su base volontaria incidenti non significativi, quasi-incidenti e minacce informatiche. È una facoltà, e come tale non va inserita in procedura al posto della notifica dovuta.
La causa dell’incidente è irrilevante
Questo è il punto su cui la divulgazione corrente è più fuorviante. Quasi tutti gli esempi che circolano sono dolosi: ransomware, esfiltrazione, attacco mirato. Sono esempi corretti ma parziali, e la parzialità produce un errore di procedura preciso — il piano di incident response che fa partire la valutazione di notifica solo quando qualcuno pronuncia la parola «attacco».
ACN è esplicita: «La causa dell’incidente non è rilevante per determinare se si tratta di un incidente significativo o meno». Rientrano quindi nell’obbligo di notifica anche gli incidenti significativi dovuti a eventi naturali (l’esempio della fonte è l’alluvione), ad eventi accidentali (i malfunzionamenti) e a cause di natura antropica (l’errore umano).
La ragione è strutturale, non un’aggiunta italiana: è il cosiddetto approccio multi-rischio della direttiva NIS, che — superando e ampliando l’ambito della direttiva precedente — prende in esame per la gestione dei rischi quelli «derivanti da tutte le tipologie di minaccia ai sistemi informativi e di rete nonché al loro contesto fisico, quali furti, incendi, inondazioni, interruzioni, anche parziali, delle telecomunicazioni e della corrente elettrica, e in generale accessi fisici non autorizzati».
Tradotto in esempi — ipotizziamo una PMI manifatturiera: l’allagamento del locale tecnico che ferma il gestionale di produzione, l’aggiornamento firmware che manda offline lo storage e la cancellazione di una share da parte di un operatore vanno valutati con lo stesso criterio del ransomware. Se ricadono in una delle fattispecie, si notificano. Un runbook che li instrada su un percorso «guasto» separato dal percorso «security» perde il termine delle 24 ore senza che nessuno se ne accorga.
I due orologi, e perché non partono insieme
Il modello dei termini è a due tempi e i due tempi non decorrono dallo stesso istante.
La pre-notifica va trasmessa senza ingiustificato ritardo e comunque non oltre 24 ore da quando si è venuti a conoscenza dell’incidente significativo. ACN precisa da quando si misura quella conoscenza: il termine decorre dal momento in cui il soggetto dispone, a valle di un’analisi anche sommaria, degli elementi oggettivi dai quali si evince che si è verificata una delle fattispecie degli allegati 3 o 4. Non serve la certezza forense, serve l’evidenza sommaria.
L’evidenza, sempre secondo ACN, si acquisisce generalmente dall’analisi di tre categorie di input, che la fonte elenca così: segnalazioni esterne (per esempio dallo stesso CSIRT Italia), segnalazioni interne (l’utente che riporta un malfunzionamento all’help desk) ed eventi di sicurezza o malfunzionamenti rilevati dai sistemi di monitoraggio. Vale la pena rileggere l’elenco: due voci su tre non passano dal SOC. La chiamata all’help desk è uno degli input la cui analisi può far emergere gli elementi oggettivi da cui decorrono le 24 ore. Il termine non parte dal ticket, ma dal momento in cui, anche a valle di un’analisi sommaria, quegli elementi ci sono — ed è proprio questo che rende il triage dell’help desk il punto in cui il rischio di perdere il termine è più alto.
La notifica completa va poi trasmessa senza ingiustificato ritardo e comunque non oltre 72 ore «a seguito della pre-notifica». È scritto così, e cambia tutto: le 72 ore non decorrono dalla conoscenza dell’incidente, ma dalla pre-notifica. Chi le calcola dal momento della scoperta si dà un margine più stretto di quello reale; chi assume sempre 96 ore dalla conoscenza si sbaglia ogni volta che ha pre-notificato in anticipo. La fonte, va detto, non precisa se il conteggio parta dall’invio o dalla ricezione della pre-notifica: in assenza di indicazione, la scelta prudente è misurare dall’invio.
La pre-notifica contiene gli elementi informativi di base necessari allo CSIRT Italia per contestualizzare l’incidente segnalato; la notifica completa reca gli ulteriori elementi che il soggetto avrà potuto raccogliere nel frattempo. Qui ci occupiamo di questi due soli termini: quello che viene dopo la notifica completa sta nel runbook.
Da quando siete tenuti a notificare
L’obbligo di notifica degli incidenti significativi di base non decorre per tutti nello stesso momento. ACN distingue due platee:
- per i soggetti inseriti nell’elenco dei soggetti NIS nel corso dell’anno solare 2025, il termine è fissato in nove mesi dalla ricezione, da parte del soggetto, della comunicazione di inserimento nell’elenco;
- per i soggetti inseriti nell’elenco per la prima volta nel corso dell’anno solare 2026, il termine decorre dal 1° gennaio 2027.
Attenzione alla differenza fra le due formulazioni, che non è stilistica. Per la seconda platea la fonte indica una decorrenza, non una scadenza: dice da quando l’obbligo comincia a valere, non entro quando fare qualcosa. È un caso diverso da quello delle misure di sicurezza di base, dove per i soggetti 2026 il termine è invece una scadenza vera (il 31 luglio 2027). Non trattate le due date allo stesso modo nella vostra pianificazione.
Una nota per chi arriva dal regime precedente: le previsioni transitorie sull’obbligo di notifica per gli operatori di servizi essenziali e per gli operatori telco sono rimaste in vigore fino al 14 gennaio 2026; dal 15 gennaio 2026 si applica la disciplina generale dell’obbligo di notifica.
Quando in mezzo c’è un fornitore
È la parte che genera più confusione, perché la risposta cambia a seconda di dove accade l’incidente, non di chi gestisce il sistema. L’obbligo è quello dell’articolo 25 del decreto NIS.
| Dove accade l’incidente significativo | Chi notifica allo CSIRT Italia |
|---|---|
| Sui sistemi del cliente soggetto NIS, con un fornitore che eroga servizi gestiti (per esempio un SOC, o la manutenzione di un impianto di riscaldamento, ventilazione e condizionamento dell’aria — HVAC) | Il cliente, che potrà poi coinvolgere il fornitore nella gestione dell’incidente |
| Sui sistemi del fornitore soggetto NIS, che eroga servizi al cliente (per esempio l’amministrazione di un sistema di gestione degli impianti — BMS) | Il fornitore; e anche il cliente, se l’incidente si configura come significativo pure in relazione ai suoi servizi e alle sue attività |
| Sui sistemi del cliente soggetto NIS, con un fornitore che eroga servizi cloud | Entrambi, cliente e fornitore |
| Sui sistemi del cliente soggetto NIS, con servizi cloud di tipo IaaS o di hosting dell’infrastruttura del cliente | Il solo cliente |
Le due righe sul cloud vanno lette per intero, condizione compresa: valgono per un incidente che occorre sui sistemi informativi e di rete del cliente. Se invece l’incidente occorre sui sistemi del fornitore, non si applica questa regola ma il caso dell’incidente sui sistemi del fornitore, descritto sopra — notifica il fornitore, e il cliente solo se l’incidente è significativo anche in relazione ai propri servizi e alle proprie attività.
Il primo caso è quello che sorprende di più: affidare il monitoraggio a un SOC esterno non sposta l’obbligo di notifica sul SOC. Se l’incidente è sui vostri sistemi, notificate voi.
C’è poi un vincolo contrattuale che discende direttamente da qui. Nell’ambito della definizione dei requisiti di sicurezza sulla fornitura previsti dalla misura GV.SC-01 — una delle misure di sicurezza di base, che stanno nell’allegato 1 per i soggetti importanti e nell’allegato 2 per gli essenziali della stessa Determinazione — il cliente soggetto NIS è tenuto ad assicurarsi che il fornitore segnali tempestivamente il rilevamento di eventi di sicurezza che hanno impatto sui servizi del cliente. Senza quella clausola, il cliente resta titolare di un obbligo il cui presupposto — sapere che è successo qualcosa — dipende dalla buona volontà di un terzo. Il tema si incrocia con quanto abbiamo scritto sugli obblighi che ricadono sui fornitori di aziende soggette.
Sui tempi, però, ACN è meno drastica di quanto la lettura frettolosa suggerisca: non è obbligatorio adeguare i contratti di fornitura già in essere. L’inserimento dei requisiti di sicurezza è obbligatorio — fatte salve motivate e documentate ragioni normative o tecniche — per i contratti stipulati, rinnovati o prorogati a partire dal termine per l’adozione delle misure di sicurezza, che per i soggetti iscritti nell’elenco entro il 31 dicembre 2025 è fissato in diciotto mesi dalla ricezione della comunicazione di inserimento. Il che significa: nessuna rinegoziazione d’urgenza del parco contratti, ma un modello di clausola pronto per il primo rinnovo utile a valle di quel termine.
Cosa cambiare, concretamente
Tre azioni, nell’ordine.
Aprite l’allegato giusto e costruite la matrice. Per ciascun servizio o attività rilevante, indicate quale fattispecie fra quelle dell’allegato che vi riguarda sarebbe integrata e con quale evidenza la si riconosce. È il documento che sostituisce la vostra soglia interna, e va scritto adesso perché a incidente in corso non lo si redige.
Togliete dal runbook ogni filtro sulla causa. Guasti, disastri ed errori umani devono entrare nello stesso imbuto di valutazione degli eventi malevoli. In pratica significa che anche il ticket di help desk «non si apre più il gestionale» deve avere un passaggio di triage che si chiede se sia integrata una fattispecie.
Scrivete i due termini separatamente. 24 ore dalla conoscenza per la pre-notifica; 72 ore dalla pre-notifica per la notifica completa. Due campi distinti nel registro incidenti, con due timestamp distinti, e non un unico contatore.
Nessuna di queste tre cose richiede tecnologia: tutte e tre richiedono di aver letto il documento giusto prima che serva — che è, quasi sempre, la differenza fra una notifica nei termini e una tardiva.
Domande frequenti
Chi decide se un incidente è significativo ai fini della notifica NIS2?
Non l’azienda. ACN scrive che, «al fine di semplificare tale valutazione e fornire dei parametri oggettivi», l’Autorità nazionale competente NIS ha definito quattro fattispecie — tre per tutti i soggetti e una ulteriore per i soli soggetti essenziali — che, ove si verifichino, sono considerate incidenti significativi. Sono definite nell’allegato 3 per i soggetti importanti e nell’allegato 4 per i soggetti essenziali.
Che cosa sono IS-1, IS-2, IS-3 e IS-4?
Sono i codici identificativi delle quattro fattispecie. Secondo ACN, IS-1 e IS-2 riguardano rispettivamente le violazioni in termini di riservatezza e di integrità dei servizi e delle attività del soggetto NIS; IS-3 è prevalentemente relativa alle violazioni in termini di disponibilità; IS-4 riguarda l’accesso non autorizzato o con abuso dei privilegi concessi. Il testo puntuale di ciascuna fattispecie non sta nelle FAQ ma negli allegati della Determinazione ACN 379907 del 19 dicembre 2025.
Un incidente causato da un’alluvione o da un errore umano va notificato?
Sì. ACN è esplicita: «La causa dell’incidente non è rilevante per determinare se si tratta di un incidente significativo o meno». Rientrano nell’obbligo anche gli incidenti significativi dovuti a eventi naturali, accidentali e di natura antropica. È l’effetto dell’approccio multi-rischio della direttiva NIS.
Le 72 ore decorrono dalla scoperta dell’incidente?
No, ed è l’errore più comune. La pre-notifica va trasmessa senza ingiustificato ritardo e comunque non oltre 24 ore da quando si è venuti a conoscenza dell’incidente. La notifica completa va trasmessa senza ingiustificato ritardo e comunque non oltre 72 ore «a seguito della pre-notifica»: il secondo termine decorre dalla pre-notifica, non dalla conoscenza.
Se l’incidente accade sui sistemi di un nostro fornitore, chi notifica?
Se l’incidente significativo occorre sui sistemi informativi e di rete del fornitore soggetto NIS, l’obbligo è in capo al fornitore, e anche al cliente se l’incidente si configura come significativo pure in relazione ai servizi e alle attività del cliente. Se invece occorre sui sistemi del cliente mentre il fornitore eroga servizi gestiti, l’obbligo è in capo al cliente, che potrà poi coinvolgere il fornitore nella gestione.
E nel caso di servizi cloud?
La regola vale per un incidente che occorre sui sistemi informativi e di rete del cliente soggetto NIS, in favore del quale un fornitore soggetto NIS eroga servizi cloud: in quel caso l’obbligo di notifica è in capo sia al cliente sia al fornitore. Con un’eccezione esplicita: quando il servizio erogato è di tipo IaaS o di hosting dell’infrastruttura del cliente, l’obbligo ricade sul solo soggetto NIS cliente.
Si possono notificare anche incidenti non significativi?
Sì. ACN conferma che «rimane sempre ferma la possibilità per i soggetti NIS di notificare, su base volontaria, incidenti non significativi, quasi-incidenti e minacce informatiche». È una facoltà, non un obbligo, e non va confusa con la notifica dovuta.
Fonte: Agenzia per la Cybersicurezza Nazionale, FAQ NIS — acn.gov.it, consultate il 27 agosto 2026. Questo articolo ne descrive il contenuto e non costituisce interpretazione autentica.