Incidenti significativi NIS2: perché IS-4 separa i soggetti essenziali da quelli importanti

Gli allegati 3 e 4 della determinazione ACN 379907/2025 elencano fattispecie diverse per le due categorie di soggetti NIS. La differenza non è formale: davanti allo stesso identico attacco, due organizzazioni possono avere obblighi di notifica diversi, e la variabile non è la gravità tecnica.

Un caso concreto per rendere visibile la differenza

Conviene partire da uno scenario reale, perché la distinzione che segue è astratta finché non la si prova su un fatto.

All’inizio di settembre 2026 sono stati osservati i primi tentativi di sfruttamento della CVE-2026-19490, un authentication bypass con punteggio CVSS 9.3 che interessa le appliance Citrix NetScaler configurate come gateway di accesso remoto o come virtual server AAA. La caratteristica rilevante ai nostri fini è che l’attaccante che riesce non installa nulla: ottiene una sessione valida, indistinguibile a valle da quella di un dipendente. Chi se ne accorge, spesso, si trova con una traccia di accesso anomalo e con la difficoltà di stabilire che cosa quell’accesso abbia effettivamente raggiunto.

È esattamente la situazione in cui la qualificazione dell’incidente diventa difficile, e in cui la differenza tra allegato 3 e allegato 4 smette di essere una sottigliezza.

Dove stanno le fattispecie

Il quadro è fissato dalla determinazione ACN 379907/2025, firmata il 18 dicembre 2025 e applicabile dal 15 gennaio 2026, che aggiorna e sostituisce la determinazione 164179 del 14 aprile 2025. Adottata ai sensi dell’articolo 31 del D.Lgs. 138/2024, stabilisce in fase di prima applicazione le modalità e le specifiche di base per gli obblighi di cui agli articoli 23, 24, 25, 29 e 32 del decreto.

L’articolo 2 distribuisce la materia su quattro allegati: gli allegati 1 e 2 contengono le misure di sicurezza di base, rispettivamente per i soggetti importanti e per quelli essenziali; gli allegati 3 e 4 contengono gli incidenti significativi di base, con la stessa ripartizione.

Tre fattispecie per gli importanti, quattro per gli essenziali

L’allegato 3, che vale per i soggetti importanti, elenca tre tipologie:

• IS-1: il soggetto ha evidenza della perdita di riservatezza, verso l’esterno, di dati digitali di sua proprietà o sui quali esercita il controllo, anche parziale;
• IS-2: evidenza della perdita di integrità, con impatto verso l’esterno, degli stessi dati;
• IS-3: evidenza della violazione dei livelli di servizio attesi dei propri servizi o delle proprie attività, sulla base dei livelli di servizio stabiliti ai sensi della misura DE.CM-01.

L’allegato 4, per i soggetti essenziali, riprende le stesse tre e ne aggiunge una quarta:

• IS-4: il soggetto ha evidenza, anche sulla base dei parametri quali-quantitativi definiti ai sensi della misura DE.CM-01, dell’accesso, non autorizzato o con abuso dei privilegi concessi, a dati digitali di sua proprietà o sui quali esercita il controllo, anche parziale.

Che cosa aggiunge davvero IS-4

Qui si annidano due equivoci, e vale la pena scioglierli entrambi.

Il primo riguarda l’oggetto della fattispecie. IS-4 non si attiva perché qualcuno ha ottenuto una sessione: richiede evidenza dell’accesso non autorizzato a dati digitali. Un attaccante che sfrutta un bypass dell’autenticazione e si ferma alla sessione, senza raggiungere dati, sta in una zona che va valutata caso per caso. Un attaccante che da quella sessione arriva a dati, anche solo consultandoli, integra IS-4 in modo piano.

Il secondo equivoco è più insidioso, ed è quello che circola come slogan: che l’accesso non autorizzato sia notificabile per gli essenziali e non per gli importanti. Non è così, o non in modo così netto. Un attaccante esterno che legge dati produce con ogni probabilità anche una perdita di riservatezza verso l’esterno, quindi un IS-1, che sta nell’allegato 3 e vincola pure i soggetti importanti.

La differenza reale è di soglia probatoria. Per un soggetto essenziale è sufficiente l’evidenza dell’accesso non autorizzato, o dell’abuso dei privilegi concessi, perché l’obbligo scatti. Per un soggetto importante occorre poter affermare che si è prodotta una perdita di riservatezza verso l’esterno, e quando l’analisi forense non riesce a stabilire se i dati siano stati effettivamente letti o portati fuori, quell’affermazione non è sostenibile.

Il risultato pratico è che due organizzazioni colpite dallo stesso attacco, con la stessa dinamica e lo stesso livello di incertezza sull’esito, possono avere obblighi diversi: l’essenziale notifica sulla base di ciò che ha osservato, l’importante potrebbe legittimamente non avere nulla da notificare. La variabile non è la gravità tecnica dell’attacco, è la classificazione del soggetto unita a quanto si riesce a ricostruire.

C’è poi un’estensione di IS-4 che si tende a trascurare, perché non riguarda gli attacchi: la fattispecie copre anche l’abuso dei privilegi concessi, quindi condotte interne prive di qualsiasi proiezione verso l’esterno. Un amministratore che consulta dati fuori dalle proprie necessità funzionali rientra in IS-4 per un soggetto essenziale, e resta fuori dal perimetro di notifica per un soggetto importante.

Una avvertenza di metodo, per onestà verso il lettore: gli allegati non definiscono l’espressione “verso l’esterno”, e la lettura proposta qui è interpretativa. Su un punto che decide se una notifica va fatta o meno, il confronto con il proprio consulente legale non è un passaggio formale.

DE.CM-01, la misura senza la quale IS-4 non è applicabile

La formulazione di IS-4 rinvia ai parametri quali-quantitativi definiti ai sensi della misura DE.CM-01, e questo rinvio ha una conseguenza che va colta.

Le linee guida ACN sulla definizione del processo di gestione degli incidenti ricordano che, per i soggetti essenziali, i punti 4, 5 e 6 di quella misura richiedono, per almeno i sistemi informativi e di rete rilevanti, di impiegare strumenti di analisi e filtraggio sul traffico in ingresso, di monitorare gli accessi da remoto, l’attività dei sistemi perimetrali come router e firewall, gli eventi amministrativi di rilievo e gli accessi eseguiti o falliti verso risorse di rete, punti terminali e applicativi, e infine di definire, monitorare e documentare parametri quali-quantitativi per rilevare gli accessi non autorizzati o con abuso dei privilegi concessi.

Gli esempi che le linee guida portano sono istruttivi perché molto concreti: un indicatore quantitativo può essere il superamento di una soglia di interrogazioni a una banca dati da parte di un singolo utente; uno qualitativo, l’accesso di un amministratore di sistema al di fuori dell’orario di servizio.

Chi quei parametri non li ha definiti e documentati si trova nella posizione peggiore possibile. Non dispone degli elementi per qualificare l’incidente, quindi non è in grado di stabilire se abbia o meno un obbligo di notifica; e l’assenza di quei parametri è a sua volta una carenza rispetto alle misure di base. È il caso in cui una lacuna organizzativa si traduce direttamente in un rischio sanzionatorio su due fronti.

I termini, e da quando decorrono davvero

L’articolo 3 della determinazione fissa le decorrenze a partire dalla ricezione della comunicazione di inserimento nell’elenco dei soggetti NIS: diciotto mesi per l’adozione delle misure di sicurezza di base, nove mesi per l’obbligo di notifica degli incidenti significativi di base previsto dall’articolo 25 del decreto.

Nella propria comunicazione l’ACN affianca a quei termini le date di ottobre 2026 e gennaio 2026, riferite a chi ha ricevuto la comunicazione nella prima tornata. Per i soggetti inseriti nell’elenco per la prima volta nel 2026 i termini sono stabiliti da una determinazione successiva, quindi le date vanno ricalcolate e non date per scontate.

Sul momento in cui parte l’orologio le linee guida chiariscono l’equivoco più diffuso. Ciò che rileva non è il verificarsi dell’incidente ma l’evidenza dell’incidente, ossia il momento in cui il soggetto dispone di elementi oggettivi dai quali si evince che un incidente si è verificato. L’acquisizione dell’evidenza è tipicamente successiva al fatto ed è quella a far decorrere i termini. Il documento aggiunge un passaggio decisivo: ai fini dell’obbligo di notifica non è necessario valutare o risalire alla causa iniziale dell’incidente. Attendere la root cause prima di notificare non è prudenza, è un errore procedurale.

La sequenza verso il CSIRT Italia, da trasmettere tramite il portale segnalazioni.acn.gov.it a cura del referente CSIRT designato, è la seguente:

• pre-notifica entro 24 ore, indicando ove possibile se l’incidente possa ritenersi il risultato di atti illegittimi o malevoli e se possa avere impatto transfrontaliero;
• notifica entro 72 ore, che aggiorna le informazioni precedenti e aggiunge una valutazione iniziale di gravità e impatto e, ove disponibili, gli indicatori di compromissione;
• relazione intermedia, su richiesta del CSIRT Italia;
• relazione finale entro un mese dalla trasmissione della notifica, con descrizione dettagliata, tipo di minaccia o causa originale, misure di attenuazione adottate e in corso, impatto transfrontaliero ove noto;
• se l’incidente è ancora in corso al momento della relazione finale, relazione mensile sui progressi e relazione finale entro un mese dalla conclusione della gestione.

Il termine della relazione finale decorre dalla notifica delle 72 ore, non dall’evidenza dell’incidente: in fase di pianificazione è la differenza tra un calendario corretto e uno sbagliato di tre giorni.

Quasi-incidenti e doppio binario con il GDPR

Due corollari completano il quadro e vengono spesso trascurati.

Il primo riguarda i tentativi bloccati. Un attacco rilevato e fermato senza che si produca alcun impatto può ricadere nella nozione di quasi-incidente del decreto, che comprende gli eventi che avrebbero potuto configurare un incidente senza che questo si sia verificato, incluso il caso in cui l’incidente sia stato efficacemente evitato. Non fa scattare l’obbligo di notifica, ma può essere comunicato volontariamente al CSIRT Italia, facoltà che le linee guida richiamano espressamente. Su vulnerabilità la cui telemetria pubblica poggia su pochi operatori privati, la notifica volontaria non è un adempimento burocratico: è il modo in cui si costruisce un quadro nazionale che altrimenti non esiste.

Il secondo riguarda il GDPR. Se l’incidente comporta una violazione di dati personali, alla notifica al CSIRT Italia si affianca quella al Garante ai sensi dell’articolo 33 del Regolamento (UE) 2016/679, salvo che sia improbabile un rischio per i diritti e le libertà delle persone fisiche. Sono due binari autonomi, con destinatari, termini e valutazioni proprie, e vanno percorsi entrambi.

Che cosa conviene mettere a posto adesso

La lettura combinata degli allegati suggerisce tre verifiche che non richiedono un progetto e che conviene fare prima del prossimo incidente, non durante.

La prima è banale solo in apparenza: sapere con certezza se la propria organizzazione è classificata come essenziale o importante, perché da lì discende quale allegato si applica. La seconda è verificare se i parametri quali-quantitativi della misura DE.CM-01 esistono, sono documentati e sono effettivamente monitorati, perché senza di essi IS-4 resta inapplicabile e l’organizzazione è cieca proprio sulla fattispecie che la riguarda. La terza è accertarsi che il referente CSIRT sia designato, con i suoi sostituti, e che la procedura interna registri l’orario in cui si acquisisce evidenza di un incidente: è quell’orario, e non altro, a far partire le ventiquattro ore.

Tutte e tre sono verifiche documentali. Nessuna costa quanto una notifica tardiva.

Il caso Citrix NetScaler da cui siamo partiti è analizzato sul piano tecnico e di incident response nell’articolo dedicato alla CVE-2026-19490.