Per mesi l’obbligo di notifica previsto dalla Legge 28 giugno 2024, n. 90 è rimasto una specie di “ordine giusto, istruzioni vaghe”: devi segnalare e notificare, ma quali incidenti esattamente?

Il 17 febbraio 2026, con pubblicazione in Gazzetta Ufficiale, Agenzia per la Cybersicurezza Nazionale ha adottato la tassonomia che mancava. Risultato: l’obbligo diventa finalmente operativo, misurabile e (soprattutto) difendibile in audit.

E c’è un dettaglio che molti sottovaluteranno fino al primo incidente “vero”: la stessa determina chiarisce che la tassonomia Legge 90 è coerente con le fattispecie di “incidenti significativi di base” del decreto NIS e, in ottica di semplificazione, se fai prenotifica/notifica NIS (art. 25) puoi considerare assolto anche l’obbligo Legge 90. Tradotto: meno doppioni, ma solo se hai un processo unico fatto bene.

Perché questa tassonomia conta davvero

La Legge 90 ha introdotto per alcuni soggetti pubblici (e perimetri collegati) un dovere chiaro: prima segnalazione entro 24 ore dalla conoscenza dell’incidente e notifica completa entro 72 ore. Se non lo fai, non è “peccato”: ci sono conseguenze, anche economiche.

Fin qui, teoria. Il problema pratico era sempre lo stesso: senza una classificazione condivisa, ogni ente rischiava di interpretare “incidente da notificare” con la fantasia del momento (o, peggio, con il coraggio che gli rimane alle 3 di notte).

La tassonomia ACN serve proprio a togliere ossigeno a quella zona grigia.

I tre codici (IS-1, IS-2, IS-3): pochi, ma chirurgici

L’Allegato A della determina ACN introduce tre sole categorie. Non è minimalismo: è una scelta di governance. Poche etichette, ma abbastanza nette da attivare automaticamente playbook e decisioni.

• IS-1 – Perdita di riservatezza (verso l’esterno): scatta quando l’organizzazione ha evidenza della perdita di riservatezza verso l’esterno di dati digitali di cui è titolare o su cui esercita controllo (anche parziale).
• IS-2 – Perdita di integrità (con impatto verso l’esterno): scatta quando c’è evidenza di perdita di integrità con impatto verso l’esterno su dati digitali propri o sotto controllo (anche parziale).
• IS-3 – Violazione dei livelli di servizio attesi: scatta quando l’organizzazione ha evidenza della violazione dei livelli di servizio attesi dei propri servizi/attività, sulla base dei livelli stabiliti dal soggetto stesso.

Qui la stoccata (meritata) è evidente: se non hai definiti davvero i livelli di servizio attesi, non hai solo un problema di ITSM… hai un problema di compliance e responsabilità.

Il punto più “cattivo” della tassonomia: la parola “evidenza”

La determina usa una formula ripetuta e volutamente concreta: “il soggetto ha evidenza”.

Bello, ma significa una cosa molto poco romantica: senza logging, detection, correlazione e procedure di triage, l’evidenza non arriva. E quando non arriva non è che “non notifichi”: più spesso notifichi tardi, male, o in modo incoerente.

In altre parole: questa tassonomia non chiede “se hai avuto un incidente”. Ti chiede se sei in grado di accorgertene e di classificarlo in tempi compatibili con 24/72 ore.

L’innesto con NIS2: stessa lingua, stesso sportello

La stessa determina Legge 90 richiama esplicitamente la determinazione ACN NIS di fine 2025 sulle “specifiche di base” e sugli incidenti significativi, e dichiara la coerenza tra i due impianti.

Qui entra in gioco il documento che hai caricato. La determinazione ACN NIS “di prima applicazione” stabilisce, tra le altre cose:

• l’adozione di misure di sicurezza di base (allegati 1 e 2) e degli incidenti significativi di base (allegati 3 e 4);
• le tempistiche: 18 mesi (misure) e 9 mesi (obbligo di notifica incidenti di base) che decorrono dalla ricezione della comunicazione di inserimento nell’elenco dei soggetti NIS;
• l’applicazione a decorrere dal 15 gennaio 2026 e la sostituzione della precedente determinazione del 14 aprile 2025;
• un regime transitorio e, per gli operatori telco, esempi/soglie minime legate a durata e percentuale di utenza impattata.

Se metti insieme i pezzi, l’indicazione strategica è chiara: ACN sta spingendo verso una tassonomia e un processo “unificabili” tra Legge 90 e NIS. Non è un favore: è un modo per far funzionare le notifiche quando gli incidenti aumentano (e i team restano gli stessi).

Cosa dovrebbero fare subito gli enti (prima che lo faccia l’incidente al posto loro)

Senza trasformare tutto in un esercizio di carta, ci sono tre mosse “da adulti” che dovrebbero fare subito gli enti (prima che lo faccia l’incidente al posto loro):

1. Mappare gli eventi tecnici sui tre codici IS (IS-1/2/3) e decidere chi può dichiarare che c’è “evidenza” (SOC? CSIRT interno? fornitore?). Se la risposta è: “dipende”, sei già in ritardo.
2. Definire e misurare i livelli di servizio attesi (IS-3) con criteri verificabili: quali servizi, quali orari, quali KPI, quali soglie. Se gli SL sono “a sentimento”, la notifica diventa arbitraria.
3. Unificare il flusso Legge 90 e NIS in un unico playbook, perché la stessa determina ti dice che una notifica fatta bene nel canale NIS può valere anche per Legge 90. Ottimo: ma solo se il playbook è uno, gli owner sono chiari e le evidenze sono tracciate.

Meno codici, più responsabilità

IS-1, IS-2, IS-3 sembrano pochi. In realtà sono una trappola (utile): ti costringono a scegliere prima cosa consideri incidente “o riconosci e con quali prove.

E, in un Paese dove spesso il primo “SIEM” è la telefonata del fornitore (“eh, stanotte c’era qualcosa…”), questa tassonomia è un messaggio piuttosto chiaro: la cybersecurity non è più solo tecnologia, è disciplina organizzativa.

E adesso ha anche un vocabolario ufficiale.