Incident reporting, le prime ore di un incidente cyber diventano una prova di governance
Segnalare un incidente cyber non è più solo un adempimento verso l’autorità. È una prova di maturità organizzativa: richiede tempi certi, ruoli chiari, informazioni affidabili e capacità di gestire la crisi senza perdere il controllo.
Alle 8:40 arriva il primo alert. Un’attività anomala su un sistema critico, un accesso sospetto, un servizio che rallenta, un fornitore che comunica un disservizio, un’anomalia nei log che non torna.
Alle 9:15 non è ancora chiaro se si tratti di un falso positivo, di un errore interno, di un attacco in corso o di qualcosa che ha già prodotto effetti su dati, clienti o servizi. Alle 10:00 il tema non è più solo tecnico. Il legale chiede se esista un obbligo di notifica. Il management vuole sapere l’impatto. La comunicazione chiede cosa si possa dire. I tecnici stanno ancora cercando di capire cosa sia successo davvero.
È qui che comincia l’incident reporting.
Non quando si compila il documento finale. Non quando l’incidente è già stato ricostruito. Non quando tutte le informazioni sono certe. La capacità di notificare nasce nelle prime ore, quando l’organizzazione deve distinguere un evento minore da un incidente rilevante, capire quali obblighi si attivano e decidere chi deve essere informato, con quali contenuti e in quali tempi.
Per questo l’incident reporting non è un modulo. È una disciplina di governo della crisi.
Non tutti gli incidenti sono attacchi
Il primo errore è parlare solo di attacchi informatici.
Un incidente cyber può nascere da un’azione malevola, ma anche da un errore di configurazione, da un guasto, da un aggiornamento mal riuscito, da un disservizio cloud, da un problema su un fornitore ICT o da una vulnerabilità sfruttata in un prodotto digitale. A seconda del contesto, l’impatto può riguardare dati personali, servizi essenziali, continuità operativa, clienti, cittadini, autorità o terze parti.
Questo cambia il modo di guardare alla notifica.
Non si tratta soltanto di chiedersi se ci sia stato un attacco. La domanda corretta è più ampia: l’evento ha prodotto, o può produrre, un impatto che rientra in un obbligo di comunicazione?
Un data breach rilevante ai fini GDPR non coincide sempre con un incidente significativo ai fini NIS2. Un incidente ICT nel settore finanziario può attivare obblighi DORA anche senza esposizione di dati personali. Un produttore di software o dispositivi con elementi digitali dovrà guardare al Cyber Resilience Act quando emergono vulnerabilità attivamente sfruttate o incidenti gravi che incidono sulla sicurezza del prodotto.
La complessità nasce qui. Le norme non guardano tutte allo stesso oggetto. Alcune guardano ai dati. Altre ai servizi. Altre ai sistemi ICT. Altre ancora ai prodotti digitali immessi sul mercato.
L’organizzazione deve essere in grado di capire rapidamente quale piano si è attivato.
Tempi diversi, stesso problema organizzativo
GDPR, NIS2, DORA e Cyber Resilience Act non impongono lo stesso tipo di notifica. Cambiano i destinatari, le soglie, i contenuti e le tempistiche. Ma il problema organizzativo è comune: nelle prime ore bisogna avere informazioni abbastanza affidabili per prendere decisioni.
Il GDPR ruota attorno alla violazione dei dati personali. Quando la violazione presenta un rischio per i diritti e le libertà delle persone, il titolare deve notificare l’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne viene a conoscenza.
NIS2 introduce una scansione più articolata per gli incidenti significativi: una prima allerta entro 24 ore, una notifica più completa entro 72 ore e un rapporto finale entro un mese. Il senso è chiaro: l’autorità non aspetta la ricostruzione perfetta, ma vuole sapere presto che l’incidente è stato riconosciuto, preso in carico e gestito.
DORA, per il settore finanziario, porta il tema dentro la resilienza operativa digitale. Gli incidenti ICT rilevanti non vengono valutati solo per la loro natura tecnica, ma per l’effetto sui servizi, sui clienti, sulla continuità e sulla stabilità dell’operatore finanziario.
Il Cyber Resilience Act aggiunge un ulteriore livello per i produttori di prodotti con elementi digitali. Dal settembre 2026, vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza del prodotto dovranno essere notificati secondo tempi stringenti.
Il punto non è memorizzare una tabella di scadenze. Il punto è costruire un’organizzazione capace di rispettarle. Senza log affidabili, ruoli chiari, escalation rapide e criteri di classificazione condivisi, ogni termine diventa un rischio.
La notifica dipende da ciò che si sa nelle prime ore
Una notifica fatta bene dipende dalla qualità delle informazioni disponibili quando l’incidente è ancora confuso.
Quali sistemi sono coinvolti? Quali servizi sono impattati? L’incidente è ancora in corso? Ci sono dati personali compromessi? Esistono effetti su clienti, cittadini, partner o fornitori? L’evento è circoscritto o può propagarsi? Quali evidenze sono già disponibili? Quali sono ancora ipotesi?
Sono domande tecniche, ma producono conseguenze di governance. Da quelle risposte dipende se notificare, quando farlo, a chi rivolgersi e con quale livello di dettaglio.
Se i log sono incompleti, la ricostruzione rallenta. Se i ruoli non sono definiti, la decisione si perde tra funzioni diverse. Se IT, legal, compliance, comunicazione e management lavorano separati, la notifica rischia di diventare tardiva, contraddittoria o incompleta.
L’incident reporting costringe quindi l’organizzazione a prepararsi prima. Non basta avere un team tecnico capace di contenere l’incidente. Serve una catena che sappia trasformare l’analisi tecnica in decisione organizzativa.
Chi classifica l’evento? Chi valuta l’obbligo normativo? Chi informa il vertice? Chi autorizza la comunicazione esterna? Chi aggiorna l’autorità se il quadro cambia? Chi conserva le evidenze?
Se queste risposte vengono cercate durante la crisi, l’organizzazione è già in ritardo.
Notificare non significa dire tutto subito
Uno dei timori più frequenti è comunicare troppo presto, quando le informazioni non sono ancora complete.
È un timore comprensibile, ma spesso mal posto. L’incident reporting non richiede di avere subito tutte le risposte. Richiede di comunicare in modo tempestivo ciò che è noto, distinguendo i fatti dalle ipotesi e aggiornando il quadro quando l’analisi procede.
Il problema non è dire “non lo sappiamo ancora”. Il problema è non sapere cosa si sa, cosa non si sa e chi sta lavorando per chiarirlo.
Una notifica iniziale può essere necessariamente parziale. Ma deve essere coerente, tracciabile e basata su evidenze. Deve mostrare che l’organizzazione ha riconosciuto l’incidente, lo sta gestendo, ha identificato gli impatti preliminari e sa quali informazioni dovranno essere aggiornate.
Questa distinzione è decisiva anche per la reputazione.
Clienti, cittadini, partner e autorità non si aspettano che ogni organizzazione sia immune dagli incidenti. Si aspettano che sia capace di reagire senza improvvisare, senza nascondere, senza produrre versioni contraddittorie.
Il silenzio può sembrare prudente nelle prime ore. Ma se diventa ritardo ingiustificato, opacità o perdita di controllo della narrazione, può fare più danni dell’incidente stesso.
Autorità, clienti, board e fornitori: non è una sola comunicazione
Parlare di incident reporting al singolare rischia di semplificare troppo.
Durante una crisi, l’organizzazione può dover gestire comunicazioni diverse. La notifica all’autorità competente. L’informazione al board. Il coordinamento con CSIRT, fornitori o partner tecnologici. La comunicazione a clienti, cittadini o interessati. L’allineamento con funzioni interne che devono continuare a operare.
Sono piani collegati, ma non identici.
L’autorità ha bisogno di informazioni strutturate sull’incidente, sugli impatti e sulle misure adottate. Il board deve capire il rischio per l’organizzazione, le decisioni da prendere e le conseguenze possibili. I clienti hanno bisogno di informazioni comprensibili, non di dettagli tecnici inutili. I fornitori devono essere coinvolti in modo operativo, soprattutto quando l’incidente passa da sistemi o servizi gestiti da terzi.
Confondere questi piani genera caos. Una comunicazione pensata per l’autorità non è automaticamente adatta ai clienti. Un aggiornamento tecnico non è automaticamente utile al
management. Una ricostruzione interna non può essere diffusa senza valutare implicazioni legali, reputazionali e operative.
Prepararsi all’incident reporting significa anche preparare questa architettura di comunicazione. Non per controllare artificialmente il messaggio, ma per evitare che la crisi produca versioni diverse dello stesso fatto.
Cosa preparare prima dell’incidente
L’incident reporting non si improvvisa quando l’attacco è in corso o quando il servizio è già fermo.
Serve una preparazione concreta. Playbook di incident response, criteri di classificazione, soglie di escalation, contatti aggiornati, canali di comunicazione alternativi, modelli minimi di raccolta delle informazioni, procedure di conservazione delle evidenze e ruoli chiari tra IT, cybersecurity, legal, compliance, comunicazione e management.
La parte tecnica è altrettanto determinante.
Senza logging affidabile, monitoraggio, tracciabilità degli eventi, asset inventory, gestione degli accessi e capacità di correlare le evidenze, la notifica diventa fragile. L’organizzazione può sapere di avere un problema, ma non riuscire a descriverlo con sufficiente precisione.
Anche le simulazioni contano. Un tabletop exercise ben costruito può mostrare lacune che un documento non rivela: contatti non aggiornati, decisioni senza proprietario, tempi di analisi troppo lunghi, dipendenze da fornitori non considerate, canali di comunicazione non utilizzabili durante la crisi.
Un’organizzazione pronta a notificare non è quella che ha il modulo giusto. È quella che sa leggere rapidamente ciò che le sta accadendo.
Notificare significa governare la crisi
L’obbligo di incident reporting non va letto come una formalità amministrativa da completare dopo l’emergenza.
È una disciplina di governo della crisi.
Un’organizzazione pronta a notificare sa vedere, capire, decidere e documentare. Sa distinguere un evento minore da un incidente rilevante. Sa coinvolgere le funzioni corrette. Sa comunicare con le autorità. Sa aggiornare le informazioni senza contraddirsi. Sa spiegare cosa è noto, cosa è ancora in verifica e quali misure sono state adottate.
Questo non elimina il rischio di subire un incidente. Riduce però il rischio di affrontarlo nel caos, senza ruoli, senza dati affidabili e senza una linea di responsabilità.
La vera domanda non è soltanto: “abbiamo subito un incidente?”.
È più precisa: “siamo in grado di spiegare cosa è successo, cosa stiamo facendo e quali effetti può produrre?”.
Nelle prime ore di una crisi cyber, questa risposta vale più di qualsiasi dichiarazione di conformità.
