Ogni incidente informatico — dal tentativo di phishing bloccato al ransomware che ferma la produzione — deve essere registrato, classificato e documentato. Non e solo una buona pratica: la NIS2 richiede esplicitamente che i soggetti obbligati mantengano un registro degli incidenti e siano in grado di fornirlo all'ACN in caso di ispezione.
Il registro degli incidenti serve a due scopi: rispettare gli obblighi normativi e imparare dagli errori. Senza un registro strutturato, ogni incidente e una lezione persa. Con un buon registro, i pattern emergono: forse il phishing colpisce sempre lo stesso reparto, forse le vulnerabilita vengono sfruttate sempre sugli stessi sistemi.
Cosa deve contenere il registro
| Campo | Descrizione | Esempio |
|---|---|---|
| Data/ora rilevamento | Quando l'incidente e stato scoperto | 2026-03-15 14:32 CET |
| Data/ora inizio | Quando l'incidente e realmente iniziato (se noto) | 2026-03-14 02:15 CET |
| Tipo di incidente | Classificazione secondo tassonomia | Ransomware, phishing, DDoS, insider threat |
| Severita | Impatto e urgenza | Critico, alto, medio, basso |
| Sistemi coinvolti | Asset impattati | Server ERP, file server, 23 workstation |
| Descrizione | Cosa e successo | Ransomware LockBit entrato via email phishing |
| Azioni intraprese | Contenimento, eradicazione, ripristino | Isolamento rete, ripristino backup, notifica CSIRT |
| Impatto | Conseguenze operative e finanziarie | Fermo produttivo 2 giorni, stima 150K EUR |
| Notifiche effettuate | CSIRT, Garante, management | Pre-notifica CSIRT 15/03 ore 16:00 |
| Lezioni apprese | Cosa migliorare | Implementare MFA su VPN, aggiornare policy phishing |
| Stato | Aperto, in corso, chiuso | Chiuso — relazione finale 10/04 |
Come classificare gli incidenti
Non tutti gli incidenti sono uguali. Una tassonomia chiara aiuta a gestirli e a produrre statistiche utili. La tassonomia ENISA e un buon punto di partenza: malware (ransomware, trojan, worm), compromissione account, vulnerabilita sfruttata, DDoS, social engineering, insider threat, perdita dati, disponibilita. Per ogni tipo, definisci i livelli di severita e le procedure di escalation.
Strumenti per la gestione degli incidenti
Per una PMI, un foglio Excel strutturato puo bastare come punto di partenza. Ma per organizzazioni piu grandi, servono strumenti dedicati: TheHive (open source, incident response e case management), ServiceNow SecOps, Jira Service Management con template di incident, o il modulo di incident management del SIEM. L'importante e che il registro sia centralizzato, accessibile al team di sicurezza e protetto da modifiche non autorizzate.
Conservazione e accesso
Il registro deve essere conservato per un periodo sufficiente — le best practice suggeriscono almeno 3 anni, per supportare analisi di trend e rispondere a eventuali richieste dell'ACN. L'accesso deve essere controllato: solo il team di sicurezza e il management possono leggere e scrivere. In caso di ispezione ACN, il registro e uno dei primi documenti richiesti.