Incident Reporting NIS2 — Tempistiche e Processi per non Sbagliare • Meteora Web Agency

Un ransomware nella notte. Clienti che non accedono. Alle 8 di mattina arriva la richiesta: "dobbiamo avvisare l'Authority?". Se lavori in una delle aziende soggette a NIS2, la risposta non è "sì", ma "quanto tempo è già passato?". Perché la direttiva non guarda solo il danno che hai subito: guarda quanto sei stato rapido a raccontarlo. E le scadenze non sono consigli, sono obblighi con multe che colpiscono anche chi firma il bilancio.

Noi, di Meteora Web, veniamo dalla contabilità: sappiamo che una scadenza mancata è un costo, non una scusa. E abbiamo passato anni a gestire emergenze tecniche sul campo. Incident reporting NIS2 non è un modulo burocratico: è un processo operativo che va costruito prima dell'emergenza. Questa guida ti mostra le tempistiche reali, come si struttura la notifica in tre fasi e cosa devi preparare oggi.

Incident reporting NIS2 — perché i tempi sono cambiati davvero?

Prima di NIS2, le notifiche di incidente erano un'ottima intenzione. Alcuni settori le facevano, altri no, e le autorità avevano pochi strumenti per intervenire. NIS2 cambia lo scenario: le scadenze diventano perentorie, i vertici aziendali diventano responsabili penalmente in alcuni casi, e l'incident reporting diventa un indicatore del tuo livello di sicurezza.

Non è difficile capire perché l'UE ha insistito su questo punto. Se un attaccante entra in un fornitore di servizi digitali e nessuno lo segnala, l'attacco può propagarsi ad altre aziende senza che nessuno possa reagire. La notifica serve al sistema, oltre che alla singola azienda. Tempistiche e processi di segnalazione sono il meccanismo che permette alle autorità di coordinare la risposta e avvisare gli altri soggetti a rischio.

Da un punto di vista pratico, la scadenza parte da un momento preciso: il momento in cui l'azienda viene a conoscenza dell'incidente, non il momento in cui l'incidente è avvenuto. Questo cambia tutto. Se scopri un accesso non autorizzato tre giorni dopo, il timer è già scattato tre giorni prima. E nessuna autorità accetta "non ce ne eravamo accorti" come giustificazione.

Le conseguenze per chi non notifica sono salate: sanzioni fino a 10 milioni di euro o al 2% del fatturato mondiale, e per i vertici aziendali anche l'interdizione temporanea dalla carica. Non sono cifre simboliche. Se ti interessa il quadro completo dell'adeguamento, parti dalla nostra guida pillar su NIS2 e normativa cybersecurity UE. Qui entriamo nello specifico: cosa inviare, quando, e come organizzarsi.

Il primo errore da evitare è aspettare di avere tutti i dettagli prima di notificare. Le autorità sanno che nei primi momenti l'incidente è confuso. Per questo NIS2 prevede una notifica lampo, poi una completa, poi un rapporto finale. Ma se perdi la prima scadenza, le altre diventano quasi irrilevanti.

Incident reporting NIS2 — quali sono le scadenze reali?

La direttiva NIS2 (Direttiva UE 2022/2555) definisce tre momenti obbligatori. Li chiamiamo early warning, notification e final report. Ecco le tempistiche precise.

Prima notifica — early warning entro 24 ore. Appena l'azienda viene a conoscenza di un incidente significativo, deve inviare un'allerta iniziale. Questa comunicazione è breve: serve a dire "siamo sotto attacco, stiamo indagando". Non servono dettagli tecnici, non serve la causa, non serve l'impatto esatto. Serve il fatto che l'incidente esiste.

Seconda notifica — notification entro 72 ore. Qui si entra nel dettaglio. Entro tre giorni dalla conoscenza dell'incidente, l'azienda deve aggiornare l'autorità con una valutazione dell'incidente: gravità, impatto, indicatori di compromissione se disponibili, misure già adottate. Questa notifica è il cuore del processo di incident reporting NIS2.

Terza notifica — final report entro un mese. L'ultimo rapporto ha l'obiettivo di chiudere il cerchio: descrizione completa dell'incidente, causa root, impatto effettivo, misure di mitigazione implementate e lezioni imparate. Le autorità lo usano per capire se l'azienda ha capito cosa è successo e se può evitare che si ripeta.

Esistono casi in cui la tempistica può essere diversa: per i fornitori di DNS, marketplace online e motori di ricerca, NIS2 prevede scadenze più strette. E se l'incidente coinvolge dati personali, si aggiunge l'obbligo di notifica al Garante Privacy entro 72 ore ai sensi del GDPR. Attenzione: sono due canali separati, con logiche diverse.

Un punto cruciale è il momento di partenza. Il regolamento parla di "senza indebito ritardo e in ogni caso entro 24 ore" dalla conoscenza. Questo significa che non puoi aspettare una conferma formale per inviare l'early warning. Anche un sospetto fondato va comunicato. L'autorità preferisce una segnalazione imprecisa ma puntuale, a una segnalazione perfetta ma tardiva.

Come calcolare le scadenze senza errori

Il calcolo delle 24 ore, 72 ore e 30 giorni si fa dal timestamp di scoperta dell'incidente, non da quello di notifica. Per non sbagliare, abbiamo preparato uno script bash che puoi usare sul tuo server. Salva il file, rendilo eseguibile e passagli come argomento la data di rilevamento.

#!/bin/bash
# Uso: ./deadline_nis2.sh "2026-03-15 10:00:00"
DETECTION=$(date -d "$1" +%s)

EARLY=$(date -d "@$((DETECTION + 86400))" "+%Y-%m-%d %H:%M:%S")
NOTIF=$(date -d "@$((DETECTION + 259200))" "+%Y-%m-%d %H:%M:%S")
FINAL=$(date -d "@$((DETECTION + 2592000))" "+%Y-%m-%d %H:%M:%S")

echo "Early warning (24h):      $EARLY"
echo "Notification (72h):       $NOTIF"
echo "Final report (30 giorni): $FINAL"

Lo script usa gli strumenti GNU date disponibili sulle distribuzioni Linux standard. È solo un supporto operativo: la responsabilità di registrare con precisione il momento della scoperta resta tua.

Incident reporting NIS2 — come funziona il processo in tre fasi?

Ogni fase ha un contenuto minimo da trasmettere all'autorità competente. In Italia, l'autorità nazionale è l'ACN (Agenzia per la Cybersicurezza Nazionale). Il portale di notifica è il canale ufficiale, ma è fondamentale avere un canale alternativo interno per raccogliere i dati mentre l'emergenza è in corso.

Fase 1 — Early warning (entro 24h). Contenuto minimo: identificativo dell'azienda, data e ora della scoperta, tipo di incidente, stato di compromissione se noto. Non serve altro. L'obiettivo è avvisare l'ecosistema.

Fase 2 — Notification (entro 72h). Contenuto minimo: aggiornamento sullo scenario, numero di utenti o servizi impattati, durata dell'interruzione, misure di contenimento attivate, eventuali indicatori di compromissione. Qui puoi inserire anche una prima ipotesi di causa.

Fase 3 — Final report (entro 30 giorni). Contenuto minimo: analisi della causa, impatto effettivo, misure di mitigazione conclusione o ancora in corso, raccomandazioni, eventuali prove digitali da conservare. Questo documento è quello che le autorità useranno per valutare la tua gestione.

Per standardizzare il lavoro, predisponi un template JSON come questo: i campi vanno riempiti in emergenza con calma ma rapidità.

{
  "incident_id": "NIS2-2026-0001",
  "entity_name": "Nome Azienda",
  "sector": "Servizi digitali",
  "incident_date": "2026-03-15T10:00:00Z",
  "detection_date": "2026-03-15T10:30:00Z",
  "classification": "significativo",
  "impact": {
    "service_disruption": true,
    "service_disruption_hours": 8,
    "data_breach": true,
    "users_affected": 1200
  },
  "root_cause": "phishing",
  "measures_taken": ["revoca credenziali", "isolamento host"],
  "contact": "it-security@azienda.it"
}

Questo template non è un modulo ufficiale, ma ti aiuta a raccogliere i dati mentre l'incidente è in corso. Il secondo errore comune è improvvisare la struttura del report nel momento del panico. Se hai un template pronto, il lavoro di notifica si riduce a riempire i campi.

Incident reporting NIS2 — cosa va notificato e quando un incidente è grave?

Non tutti gli incidenti vanno notificati. NIS2 richiede la notifica per gli incidenti significativi. Ma cosa rende un incidente significativo? La direttiva indica criteri: numero di utenti affetti, durata dell'interruzione, estensione geografica, entità del danno materiale o immateriale. Un singolo computer infettato da malware, se isolato subito, probabilmente non è significativo. Ma se quel computer gestisce i backup di tutto il sistema, lo è.

Per non perdere tempo nelle prime ore, usa una logica di triage. Rispondi a queste tre domande:

L'incidente ha compromesso la disponibilità di un servizio? In tal caso, l'interruzione ha superato i limiti di tolleranza definiti dai tuoi SLA?
L'incidente ha compromesso la riservatezza di dati? Se sì, quanti soggetti sono coinvolti?
L'incidente ha compromesso l'integrità di sistemi o dati? Esistono prove di alterazione?

Se almeno una risposta è sì, molto probabilmente davanti a un incidente significativo e la notifica è obbligatoria. Se non sei sicuro, notifica comunque. L'early warning è pensato anche per questo: meglio un falso allarme che una sanzione.

Il terzo errore comune è confondere la notifica NIS2 con la denuncia penale. Sono canali separati. NIS2 non vuole un'indagine giudiziaria: vuole informazioni operative per proteggere l'ecosistema. Se i tuoi sistemi contengono tracce di un attacco, la conservazione di quelle prove va fatta in parallelo, ma non deve rallentare la comunicazione all'autorità.

Incident reporting NIS2 — come prepararsi prima che l'incidente accada?

Il processo di segnalazione non si improvvisa. Nel pieno di un ransomware, nessun team ha voglia di capire come e a chi mandare la notifica. Per questo prepariamo tutto con calma. Ecco i punti essenziali.

Designa un responsabile della notifica. Deve avere il potere di inviare all'autorità anche in assenza del titolare. Se la decisione è appannaggio del CEO, e il CEO è su un aereo senza connessione, le 24 ore scadono inutilmente.

Prepara i template. I modelli che abbiamo visto sopra vanno riempiti con i dati della tua azienda: partita IVA, settore, referente, canale preferenziale. In emergenza dovrai solo aggiungere i dettagli dell'incidente.

Configura un canale sicuro per le comunicazioni. L'autorità avrà un portale, ma per le comunicazioni con fornitori e consulenti usa un canale cifrato. Se usi la posta elettronica, attiva la cifratura S/MIME o una soluzione tipo PGP. Un incidente non deve diventare un'occasione per un secondo attacco tramite email intercettate.

Fai esercitazioni. Una volta all'anno, simula un incidente fittizio e prova a inviare le notifiche di prova. Scoprirai che il template non è compilato, che manca un contatto, che l'indirizzo del portale è cambiato. Meglio scoprirlo in una simulazione che durante un vero attacco.

Quando su un server si è rotto il rinnovo automatico dei certificati SSL, noi abbiamo risolto e automatizzato tutto senza far andare offline il cliente. Il principio è lo stesso: la preparazione operativa fa la differenza tra un problema gestito e un disastro.

Per automatizzare il calcolo delle scadenze e tenerle sotto controllo, integra lo script bash precedente nella tua procedura di incident response. Se un tecnico registra l'ora di scoperta in un file di log, il sistema può calcolare automaticamente le prossime scadenze e inviare un promemoria al responsabile.

Cosa fare adesso

Le regole di incident reporting NIS2 sono in vigore. Non servono altre attese. Ecco le azioni concrete da fare nei prossimi giorni:

Verifica se rientri nell'ambito NIS2. Non tutti i settori sono inclusi, ma moltissime PMI italiane lo sono senza saperlo. Il pillar NIS2 e normativa Cybersecurity EU ti aiuta a fare il check.
Nomina un incident manager. Una persona fisica, con un sostituto, autorizzata a inviare notifiche all'autorità in qualsiasi orario.
Scarica e adatta i template di notifica. Riempili ora con i dati della tua azienda, così in emergenza avrai solo i campi dinamici da compilare.
Fissa una esercitazione. Entro 60 giorni, simula un incidente con il tuo team. Coinvolgi anche il consulente tecnico, se non hai una struttura interna.
Integra lo script di calcolo scadenze nel tuo playbook. Il tempo non si ferma, e la prima scadenza è la più facile da rispettare se hai tutto pronto.

Noi lavoriamo ogni giorno con aziende che devono adeguarsi a NIS2. Il primo passo è sempre lo stesso: ammettere che un incidente può succedere. Da lì si costruisce una procedura di incident reporting che non lascia spazio all'improvvisazione.