cm/controlmapping
Italiano
Fonti
Guida pratica · NIS2 · GDPR · ISO 27001

Costruire una procedura di segnalazione degli incidenti per le scadenze NIS2 di 24 e 72 ore

Le scadenze di segnalazione NIS2 decorrono dal momento in cui si viene a conoscenza di un incidente significativo, non dall'inizio della settimana lavorativa. Ecco come costruire una procedura che le rispetti.

Stampa in stile risografico di tre clessidre di dimensioni crescenti disposte in fila
Tre scadenze, un incidente.

L'articolo 23 della NIS2 fissa tre scadenze di segnalazione per gli incidenti significativi: un preallarme entro 24 ore dal momento in cui se ne viene a conoscenza, una notifica dell'incidente entro 72 ore e un rapporto finale entro un mese. ISO 27001 e la maggior parte dei framework richiedono la gestione degli incidenti, ma nessuno impone di notificare un'autorità di vigilanza entro questi termini. Ecco come costruire una procedura che li rispetti.

I tre rapporti

RapportoScadenzaContenuto
Preallarme24 ore dal momento della conoscenzaSe si sospetta che l'incidente sia di natura dolosa e se potrebbe avere un impatto transfrontaliero
Notifica dell'incidente72 ore dal momento della conoscenzaUn aggiornamento, una valutazione iniziale di gravità e impatto e gli indicatori di compromissione, ove disponibili
Rapporto finaleUn mese dopo la notificaDescrizione dettagliata, probabile causa radice, mitigazioni applicate e in corso, impatto transfrontaliero

L'autorità può anche richiedere aggiornamenti intermedi e, se l'incidente è ancora in corso dopo un mese, si fornisce un rapporto sullo stato di avanzamento e un rapporto finale entro un mese dalla conclusione della gestione.

Passo 1: definire "significativo" per la propria organizzazione

Il criterio dell'articolo 23, paragrafo 3, è ampio: grave interruzione operativa o perdita finanziaria, oppure danni materiali o immateriali considerevoli a terzi. Per alcuni fornitori digitali, il regolamento di esecuzione fissa criteri più specifici. Tradurli in una breve checklist decisionale che il responsabile di reperibilità possa applicare in pochi minuti, con esempi, e precisare che, in caso di dubbio, si invia il preallarme.

Passo 2: definire i ruoli

  • Chi decide la significatività (e un sostituto, a qualsiasi ora).
  • Chi invia la segnalazione al CSIRT o all'autorità, con accesso al portale di segnalazione testato in anticipo.
  • Chi approva il contenuto, senza che l'approvazione diventi un collo di bottiglia. Un preallarme richiede pochi dettagli.
  • Chi informa la direzione, che ai sensi dell'articolo 20 ne è responsabile.
Fotografia di un telefono appoggiato a faccia in giù su un comodino accanto a una lampada e a un bicchiere d'acqua in una stanza buia
Il conto alla rovescia delle 24 ore non aspetta l'orario d'ufficio.

Passo 3: collegarla al processo di gestione degli incidenti

Aggiungere un punto decisionale sulla segnalazione al piano di risposta agli incidenti esistente: in fase di triage, chiedersi "potrebbe essere significativo?" e avviare lì il registro dei tempi. Registrare con cura il momento della conoscenza; è il momento da cui si misurano tutte le scadenze.

Passo 4: coordinare gli altri termini

Un incidente significativo spesso fa scattare più di un obbligo:

  • GDPR: notificare l'autorità di controllo entro 72 ore se vengono violati dati personali (articolo 33).
  • Contratti: clausole di notifica ai clienti, spesso da 24 a 72 ore.
  • Altri regimi: circuiti di pagamento per i dati di carte, autorità di settore e DORA per le entità finanziarie.

Un unico coordinatore dovrebbe gestire l'elenco, così da evitare che una scadenza venga mancata perché un altro team riteneva fosse di sua competenza.

Passo 5: modelli e prove pratiche

Preparare modelli per ciascuno dei tre rapporti con i campi richiesti, precompilati con i dati aziendali. Quindi svolgere un'esercitazione almeno una volta l'anno, idealmente iniziando un venerdì sera, e cronometrarla.

Uno scenario di esercitazione

Per testare la procedura, svolgere un breve esercizio come questo, idealmente iniziando tardi di venerdì:

  1. Ora 0: il monitoraggio segnala un'attività di cifratura anomala su un file server che supporta un servizio rivolto ai clienti.
  2. Ora 2: l'ingegnere di reperibilità conferma un ransomware su diversi server; il servizio è degradato per alcuni clienti.
  3. Punto decisionale: è significativo? Applicare la checklist e registrare la decisione e l'orario.
  4. Prima dell'ora 24: inviare un preallarme usando il modello, indicando la sospetta attività dolosa e un possibile impatto transfrontaliero.
  5. Prima dell'ora 72: inviare la notifica con una valutazione iniziale e gli indicatori di compromissione.
  6. Termini paralleli: i dati personali fanno scattare la notifica GDPR? I contratti richiedono un avviso ai clienti?

Cronometrare ogni passaggio. Le lacune emerse (chi ha accesso al portale, chi può approvare, dove si trovano i modelli) sono i veri punti deboli della procedura.

Conservare le registrazioni

Registrare ogni incidente valutato per significatività, inclusi quelli per cui si è deciso di non effettuare la segnalazione, con le relative motivazioni. Le autorità di vigilanza chiederanno come si decide, non solo che cosa si è segnalato.

Le pagine tematiche Incident Response e Reporting confrontano i requisiti tra i diversi framework, mentre la guida NIS2 copre il resto del regolamento.

Domande

Cosa si considera incidente significativo ai sensi della NIS2?

Ai sensi dell'articolo 23, paragrafo 3, un incidente che ha causato o può causare una grave interruzione operativa o una perdita finanziaria per il soggetto, oppure che ha inciso o può incidere su altri causando danni materiali o immateriali considerevoli. Il regolamento di esecuzione fissa soglie più specifiche per alcuni fornitori digitali.

A chi si effettua la segnalazione ai sensi della NIS2?

Al CSIRT nazionale o all'autorità competente designata dalla legge NIS2 del proprio Stato membro. Alcuni paesi utilizzano un unico punto di contatto per la segnalazione.

Dati aggiornati al 2026-10-27: i numeri di questo articolo sono calcolati dal crosswalk attuale e si aggiornano quando questo cambia. Crosswalk una tabella di corrispondenza pubblicata (NIST, ENISA, CIS, PCI SSC) stabilisce il collegamento · Redazione Giudizio di ControlMapping dove non esiste una tabella di corrispondenza; la motivazione è indicata · Correlazione debole condivide solo un esito di CSF 2.0: da verificare, non è una mappatura · Nessuna mappatura nei nostri dati nessuna mappatura nei nostri dati; spesso si tratta di lavoro nuovo, ma verifica le note sulla copertura. Non è una consulenza di conformità.

Articoli correlati