Incidenti di Sicurezza NIS2

Scadenza: 15 gennaio 2026

A partire dal 1 gennaio 2026 scatta l’obbligo, previsto dalla NIS2 (decreto NIS), di rispettare le tempistiche e le modalità di comunicazione degli incidenti cyber.

L’ultima Determina ACN è la 379887 del 19 dicembre 2025 (data di pubblicazione). Questa Determina chiarisce che “…le previsioni transitorie inerenti all’obbligo di notifica per gli operatori di servizi essenziali e per gli operatori telco rimangono in vigore fino al 14 gennaio 2026, per poi essere abrogate dalla disciplina generale dell’obbligo di notifica che si applica dal 15 gennaio 2026” e la stessa “…aggiorna e sostituisce la determinazione ACN n. 164179 del 14 aprile 2025…”.

Al fine di supportare i soggetti obbligati, l’ACN ha pubblicato le Linee Guida.

Tassonomia Cyber ACN

L’ACN ha pubblicato la nuova Tassonomia Cyber (TC-ACN), pensata proprio per favorire lo scambio di informazioni e facilitare il processo di notifica degli incidenti.

È online anche uno strumento gratuito che può aiutare a compilare i campi descrittivi richiesti dalla nuova tassonomia. Tramite questo strumento è possibile:
- la generazione guidata dei cosiddetti “vettori incidente” secondo la tassonomia ACN, compilando passo a passo gli attributi richiesti;
- l’esportazione delle informazioni in un formato adatto per la notifica all’ACN e al CSIRT, o per la condivisione interna tra i reparti di sicurezza;
- l’aggiornamento costante dello strumento, integrando eventuali revisioni della tassonomia o nuove specifiche da parte dell’ACN.

Le 4 macrocategorie della TC-ACN, ovvero i suoi elementi strutturali più di alto livello, sono:
- BC (Baseline Characterization): rappresenta il livello introduttivo dell’analisi, in cui si valutano l’entità dei danni, la natura dell’attacco e le componenti organizzative coinvolte;
- TT (Threat Type): approfondisce gli elementi tecnici dell’incidente (ad esempio i vettori di infezione, le vulnerabilità sfruttate, le tipologie di malware);
- TA (Threat Actor): identifica la “mano” dietro l’evento (gruppi criminali, singoli hacker, stati-nazione, insider malintenzionati, ecc.) e ne valuta motivazioni e competenze;
- AC (Additional Context): fornisce ulteriori informazioni contestuali, come la classificazione dei sistemi colpiti, eventuali correlazioni con incidenti passati, strumenti di difesa implementati e possibili scenari di escalation.

Notifica

Cosa va notificato

La normativa richiede la notifica di “incidenti significativi”. Un incidente è considerato significativo (art. 24) se:

• impatto sulle operazioni dell’Entità: l’incidente deve aver “causato o essere in grado di causare una significativa interruzione dei servizi o una perdita finanziaria rilevante per l’entità interessata”;
• impatto su terze parti: l’incidente deve aver “interessato o essere in grado di interessare altre persone fisiche o giuridiche causando danni materiali o immateriali considerevoli”. Questo criterio amplia l’ambito di applicazione per includere le possibili conseguenze su clienti, utenti, partner o altre parti interessate.

La valutazione per determinare se si è in presenza di una “significativa interruzione dei servizi” dovrebbe considerare:

• la criticità delle reti e dei sistemi informativi coinvolti per l’erogazione dei servizi dell’entità;
• la gravità e la natura tecnica della minaccia informatica;
• le vulnerabilità sfruttate;
• le esperienze pregresse dell’entità con incidenti simili.

Fattori da considerare (specifici indicatori rilevanti nella valutazione della gravità dell’interruzione):

• estensione dell’impatto sui servizi: quanto significativamente l’incidente ha compromesso la capacità dell’entità di erogare i propri servizi?
• durata dell’incidente: l’interruzione è ancora in corso e, in tal caso, per quanto tempo si è protratta?
• numero di utenti coinvolti: quante persone od organizzazioni che dipendono dai servizi dell’entità sono state colpite?

È importante ricordare che la definizione della Direttiva si concentra sia sul danno effettivo che potenziale. Un incidente non deve necessariamente aver già causato interruzioni significative o danni per attivare gli obblighi di segnalazione, se esiste una ragionevole probabilità che possa portare a tali conseguenze.

Procedura di notifica

Tempistiche stringenti (Multi-fase): la notifica non è un evento singolo, ma un processo articolato in più fasi con scadenze molto strette:

1. allerta rapida (early warning): entro 24 ore dal momento in cui si è venuti a conoscenza dell’incidente significativo (art. 23(4.a)). Questa prima comunicazione (preallarme) serve a segnalare che si sospetta o si è verificato un incidente, fornendo le informazioni disponibili in quel momento (anche se incomplete);
2. notifica dell’incidente: entro 72 ore dal momento in cui si è venuti a conoscenza. Questa notifica deve aggiornare l’allerta rapida e includere una valutazione iniziale dell’incidente, comprendendone la gravità, l’impatto e, se disponibili, gli indicatori di compromissione (IoC);
3. relazione intermedia: su richiesta del CSIRT/ACN, l’azienda potrebbe dover fornire aggiornamenti sullo stato dell'incidente;
4. relazione finale: entro un mese dalla notifica dell’incidente (o dalla risoluzione dell’incidente, se questo è ancora in corso al momento della scadenza del mese). Questa relazione deve contenere una descrizione dettagliata dell’incidente (causa principale, impatti, misure correttive adottate, eventuale impatto transfrontaliero).

Chi deve notificare

La notifica deve essere eseguita da:

- Soggetti Essenziali;
- Soggetti Importanti.

A chi notificare

Al CSIRT Italia / ACN. La notifica avverrà tramite le piattaforme e i canali designati dall’ACN (il portale: portale.acn.gov.it). È importante notare che se l’incidente coinvolge anche una violazione di dati personali (data breach), resta fermo l’obbligo di notifica separata al Garante per la Protezione dei Dati Personali entro 72 ore dalla scoperta, ai sensi del GDPR.

Per conformarsi l’azienda dovrà, quindi, rivedere le procedure interne per:

• rilevare tempestivamente gli incidenti;
• valutare rapidamente la loro significatività secondo i criteri NIS 2;
• raccogliere le informazioni necessarie per le diverse fasi di notifica;
• effettuare le comunicazioni ad ACN rispettando le scadenze di 24 e 72 ore.

La mancata notifica o il ritardo possono comportare sanzioni significative.

Incidenti significativi per Soggetti Essenziali

Gli incidenti significativi che i soggetti essenziali devono notificare sono definiti nell’Allegato 4 della Determina ACN 164179/2025 (sostituita dalla Determina 19 dicembre 2025), e si basano su quattro categorie principali. Questi incidenti devono essere comunicati senza ingiustificato ritardo al CSIRT Italia, secondo quanto previsto dall’art. 25 del decreto NIS.

⚠️ Incidenti significativi da notificare

IS-1: Perdita di Riservatezza

• Descrizione: si verifica quando dati digitali, di cui l’azienda è proprietaria o che gestisce per conto di terzi, diventano accessibili a soggetti esterni non autorizzati. L’incidente consiste nella “fuga” di informazioni sensibili.
• Esempio concreto (Hosting/Cloud/Domini): un gruppo di cybercriminali sfrutta una vulnerabilità non ancora nota (zero-day) nel software di gestione del database clienti dell’azienda. Tramite questo attacco, riescono a copiare ed esfiltrare (scaricare) l’intero database anagrafico dei clienti. Questo archivio contiene:
  • Nomi, cognomi, indirizzi fisici e indirizzi email dei clienti;
  • Hash delle password di accesso ai pannelli di controllo;
  • Informazioni sui servizi acquistati (nomi a dominio, piani di hosting);
  • Negli scenari peggiori, dati parziali di pagamento (es. ultime 4 cifre della carta di credito e data di scadenza).
  L’azienda rileva l’incidente tramite i suoi sistemi di monitoraggio che segnalano un’anomala e massiccia trasmissione di dati verso un server esterno sconosciuto. Questo evento costituisce una grave perdita di riservatezza, poiché informazioni private dei clienti sono finite in mani sbagliate.

IS-2: Perdita di Integrità

• Descrizione: avviene quando i dati vengono modificati o alterati senza autorizzazione, e questa modifica ha un impatto percepibile all’esterno, ad esempio compromettendo un servizio o fornendo informazioni errate agli utenti.
• Esempio concreto (Hosting/Cloud/Domini): un aggressore, utilizzando credenziali rubate a un cliente, accede al pannello di controllo per la gestione dei nomi a dominio. Una volta dentro, modifica i record DNS (Domain Name System) di un dominio di alto profilo (es. un noto sito di e-commerce). In particolare, cambia l’indirizzo IP associato al dominio (A record), reindirizzando tutto il traffico web destinato al sito legittimo verso un server clone malevolo, gestito dall’attaccante. L’impatto esterno è immediato:
  • gli utenti che cercano di visitare il sito e-commerce vengono indirizzati a una copia fraudolenta che ruba le loro credenziali di accesso o i dati della carta di credito (phishing).
  • la reputazione del cliente e del fornitore di servizi viene gravemente danneggiata.
  In questo caso, l’integrità del dato fondamentale (il record DNS) è stata compromessa, causando un disservizio e un pericolo diretto per gli utenti finali.

IS-3: Violazione dei Livelli di Servizio (SLA)

• Descrizione: si tratta di un’interruzione o un degrado significativo delle prestazioni dei servizi offerti, tale da violare i livelli di servizio (Service Level Agreement - SLA) che l’azienda garantisce contrattualmente ai propri clienti.
• Esempio concreto (Hosting/Cloud/Domini): il fornitore garantisce per i suoi servizi di “Cloud VPS” un’uptime del 99,95% su base mensile. A causa di un aggiornamento del firmware fallito su uno degli switch di rete principali del data center, metà dell’infrastruttura di virtualizzazione diventa irraggiungibile. Di conseguenza, centinaia di server virtuali dei clienti e i siti web su di essi ospitati risultano offline. La risoluzione del problema richiede 8 ore di lavoro da parte dei tecnici. Un’interruzione di 8 ore supera ampiamente il tempo di disservizio consentito da un SLA del 99,95% (che corrisponde a circa 22 minuti di downtime al mese). Questo incidente, pur non essendo causato da un attacco esterno, rappresenta una violazione dei livelli di servizio attesi e ha un impatto diretto e grave sull’operatività dei clienti.

IS-4: Accesso non autorizzato o Abuso di Privilegi

• Descrizione: si ha evidenza che qualcuno (un soggetto esterno o un dipendente) abbia avuto accesso a dati digitali senza averne il permesso, oppure, pur avendo un permesso, lo abbia usato per scopi illeciti o non pertinenti alle proprie mansioni. A differenza della perdita di riservatezza (IS-1), qui il dato potrebbe essere stato solo “visto” e non necessariamente rubato o diffuso all’esterno.
• Esempio concreto (Hosting/Cloud/Domini): un tecnico del supporto di primo livello, che dispone di credenziali con privilegi elevati per assistere i clienti, abusa del suo potere. Spinto da curiosità personale, utilizza i suoi accessi per navigare all’interno dello spazio di archiviazione (file system) di un server cloud di proprietà di una startup fintech di cui ha letto sui giornali. Non modifica né cancella alcun file, ma apre e legge documenti contenenti piani industriali e strategie di business riservate. L’azione viene scoperta grazie ai sistemi di log e auditing dell’azienda, che tracciano tutti gli accessi ai dati dei clienti. Il sistema rileva che l’impiegato ha avuto accesso ai dati senza che vi fosse un ticket di assistenza aperto o un’altra valida giustificazione lavorativa. Questo è un chiaro caso di abuso di privilegi, un incidente di sicurezza significativo anche se nessun dato è stato esfiltrato all’esterno dell’azienda.

Note operative

• Gli incidenti devono essere notificati secondo le procedure definite nel piano di gestione degli incidenti (RS.MA-01).
• Se ritenuto opportuno, e sentito il CSIRT Italia o su richiesta dell’ACN, il soggetto può (o deve):
  • informare gli utenti dei servizi interessati;
  • comunicare misure correttive ai destinatari potenzialmente esposti;
  • rendere pubblico l’incidente (se intimato da ACN).

Esempi di incidenti

Le violazioni più frequenti:

• dati liberamente accessibili modificando un URL (mancanza di autenticazione, URL prevedibile), ad esempio la semplice modifica di un numero nella barra degli indirizzi consente l'accesso ai documenti di altre persone;
• politica sulle password non conforme alle raccomandazioni in materia di password;
• trasmissione di password in chiaro, ad esempio quando si crea un account online;
• trasmissione di dati su canali non crittografati (HTTP), ad esempio nel caso di un modulo online utilizzato per inviare dati personali;
• assenza di blocco automatico delle sessioni di postazione di lavoro, che consente a terzi di accedere a un sistema informativo contenente dati personali;
• l’insufficienza di test per verificare l’assenza di vulnerabilità prima di implementare un nuovo sistema. Questo è il caso quando un'organizzazione sviluppa un nuovo strumento (applicazione, sito web, modulo) che elabora dati personali, senza prevedere una fase di test per identificare possibili vulnerabilità.