NIS2 Art. 23: Notifica degli incidenti (24h, 72h, 1 mese) – guida pratica per CEO, IT e Compliance
Obiettivo: evitare ritardi, dimostrare governance e ridurre rischi di non conformità durante un incidente reale.
In breve
L’Art. 23 impone un processo strutturato di notifica degli “incidenti significativi” alle autorità competenti (CSIRT/autorità), con comunicazioni progressive (early warning, notifica, eventuali aggiornamenti, report finale).
In parallelo, quando l’incidente può influire negativamente sui servizi, va gestita anche la comunicazione verso i destinatari del servizio (clienti/utenti/partner) con indicazioni pratiche.
Quando un incidente diventa “significativo” (test rapido)
- Discontinuità operativa severa: il servizio core non è erogabile o è degradato in modo rilevante.
- Impatto economico: perdite dirette o rischio economico non trascurabile.
- Danno a terzi: impatti rilevanti su clienti/utenti/partner (anche reputazionali o non materiali).
- Awareness: il timer parte quando, dopo una prima valutazione, c’è ragionevole certezza che l’incidente significativo sia reale.
Timeline di notifica (playbook)
- Entro 24 ore: Early warning (info essenziali; richiesta supporto; indicazione sospetta origine malevola e possibile impatto cross-border).
- Entro 72 ore: Incident notification (aggiornamento + prima valutazione di severità/impatti; indicatori disponibili).
- Su richiesta: Intermediate report (stato, avanzamento, decisioni, nuovi elementi).
- Entro 1 mese: Final report (descrizione dettagliata; causa probabile/root cause; mitigazioni applicate e in corso; impatto anche cross-border se presente).
- Se incidente ancora in corso: Progress report + final report entro 1 mese dalla chiusura/gestione completa.
Regola d’oro: “senza ingiustificato ritardo” significa notificare appena possibile, senza aspettare sempre la scadenza massima.
Ruoli e responsabilità (CEO / IT / Compliance)
CEO & Top Management
- Approvare una policy “decisioni in emergenza” (chi decide, in quanto tempo, con quali soglie).
- Garantire disponibilità di risorse (forensic, legale, comunicazione) e sblocco rapido budget in crisi.
- Presidiare il rischio reputazionale: messaggi coerenti e basati su fatti verificati.
IT & Security
- Gestire triage e contenimento con priorità, evitando che la compliance blocchi l’operatività.
- Raccogliere evidenze minime “a prova di audit”: timeline, sistemi impattati, IoC, azioni di mitigazione, stato recovery.
- Preparare “pacchetti informativi” per early warning e per notifica 72h (aggiornabili a blocchi).
Compliance / Risk / Legal
- Definire criteri di “incidente significativo” e un flusso di approvazione rapido (senza colli di bottiglia).
- Gestire la comunicazione ai destinatari del servizio quando richiesta, con linguaggio chiaro e indicazioni pratiche.
- Coordinare obblighi paralleli (es. privacy/data breach) senza confondere canali e tempistiche.
Evidenze pronte (prima dell’incidente)
- Procedura Incident Response con RACI + reperibilità + contatti “autorità/CSIRT”.
- Modelli (template) per: early warning, notifica 72h, report intermedio, report finale.
- Registro incidenti con campi minimi: data/ora, scope, impatto servizi, impatto economico stimato, impatti su terzi.
- Playbook comunicazione verso clienti/utenti: canali, approvazioni, messaggi “azioni che l’utente può fare”.
- Checklist raccolta evidenze: log retention, snapshot/immagini, chain-of-custody, elenco asset coinvolti.
FAQ
La notifica può aspettare “perché non abbiamo ancora capito tutto”?
No: la logica NIS2 è progressiva. Si invia un primo avviso con informazioni essenziali e si aggiorna con dati più solidi nelle fasi successive.
