Quando si parla di cyber security, il tempo è una variabile critica. La Direttiva NIS2 (Network and Information Security 2), recepita nell’ordinamento italiano con il D.lgs. 138/2024, ha introdotto uno degli obblighi più sfidanti per le organizzazioni classificate come soggetti essenziali o importanti: notificare un incidente significativo alle autorità competenti (in Italia il CSIRT nazionale) entro 24 ore dalla prima rilevazione.
Indice degli argomenti
Incident management e obblighi di notifica in 24 ore secondo NIS2
Non si tratta di una formalità burocratica: quella finestra di 24 ore è il cuore pulsante del sistema di allerta europeo e serve a mettere in moto una catena di risposta coordinata, a proteggere non solo l’organizzazione colpita ma l’intero ecosistema di infrastrutture critiche interconnesse.
E per rispettarla in modo affidabile, ripetibile e documentabile, l’incident management non può più essere un processo gestito a mano.
Questo articolo è una guida pratica per i team di sicurezza e i responsabili IT che devono trasformare l’obbligo normativo in un flusso operativo automatizzato. Il protagonista tecnologico è il SOAR (Security Orchestration, Automation and Response), ma il percorso parte molto più indietro: dalla comprensione di cosa sia davvero l’incident management e di come si integri nella governance aziendale.
Definizione e ruolo dell’incident management nella governance della sicurezza digitale aziendale
L’incident management è il processo strutturato attraverso cui un’organizzazione rileva, analizza, contiene, risolve e documenta un evento di sicurezza che impatta o potrebbe impattare la continuità operativa, la riservatezza dei dati o l’integrità dei sistemi.
È un processo di governance, non solo di tecnica: coinvolge persone, procedure, strumenti e responsabilità ben definite.
Nella moderna postura di sicurezza aziendale, l’incident management è il punto di convergenza tra il Security Operations Center (SOC), il team legale, la direzione e, in caso di incidenti significativi, le autorità esterne. Per questo motivo deve essere progettato con la stessa cura di qualsiasi altro processo critico di business.
Incident management vs incident response: differenze operative e processuali
I due termini vengono spesso usati come sinonimi, ma descrivono due livelli distinti di intervento.
L’incident response è la risposta tecnica immediata a un incidente in corso: contenimento, eradicazione, ripristino. È reattiva, rapida, focalizzata sulla risoluzione del problema nel più breve tempo possibile.
L’incident management è il framework più ampio che contiene l’incident response. Include la governance del processo, la comunicazione verso gli stakeholder interni ed esterni, la documentazione, il reporting alle autorità, le analisi post-incidente e il miglioramento continuo.
In altre parole: mentre l’incident response si chiede “come blocco l’attacco?”, l’incident management si chiede “cosa devo fare, chi devo avvisare, come devo documentarlo e cosa devo imparare?”.
Nel contesto NIS2, questa distinzione è cruciale: la norma non regolamenta le scelte tecniche di risposta, ma impone un framework di management preciso con scadenze, contenuti e destinatari definiti.
Fasi chiave del processo di incident management
Un processo di incident management maturo si articola in sei fasi principali, ciascuna con output definiti e responsabilità assegnate.
- La prima fase è il rilevamento e la classificazione: l’evento viene identificato tramite alert automatici, segnalazioni degli utenti o notifiche di terze parti. Viene classificato per severità e tipologia, e si determina se soddisfa i criteri di “incidente significativo” ai sensi della NIS2.
- La seconda fase è il triage e la prioritizzazione: si valuta l’impatto potenziale, si assegnano le risorse e si avvia il workflow di risposta. È in questa fase che scatta il timer delle 24 ore.
- La terza fase prevede contenimento e analisi: il team tecnico isola i sistemi compromessi, raccoglie evidenze e produce una prima valutazione dell’incidente. Questa analisi alimenta direttamente il contenuto della pre-notifica.
- La quarta fase è la notifica alle autorità: viene redatta e inviata la pre-notifica al CSIRT entro 24 ore, seguita dalla notifica dettagliata entro 72 ore e dalla relazione finale entro un mese.
- La quinta fase è l’eradicazione e il ripristino: rimozione della minaccia e ritorno alla normalità operativa.
- La sesta fase, spesso sottovalutata, è la revisione post-incidente: analisi delle cause radice, aggiornamento dei playbook, miglioramento dei controlli.
Norme NIS2 e dettagli sulle tempistiche di notifica agli enti competenti
La NIS2 introduce un regime di notifica a tre livelli che rappresenta uno dei cambiamenti più significativi rispetto alla precedente direttiva NIS1. Ogni livello ha un termine preciso, un destinatario specifico e un contenuto minimo obbligatorio.
Capire questa struttura è il prerequisito per poterla automatizzare.
Che cos’è un incidente significativo secondo NIS2
Non tutti gli eventi di sicurezza attivano l’obbligo di notifica. La NIS2 definisce “incidente significativo” quello che causa o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato, oppure che incide o è in grado di incidere su altre persone fisiche o giuridiche causando notevoli danni materiali o immateriali.
In termini operativi, i criteri di significatività includono: interruzione di servizi essenziali superiore a soglie definite, violazione di dati personali su larga scala, compromissione di infrastrutture critiche, attacchi che si propagano a fornitori o clienti (supply chain).
Il team di incident management deve essere in grado di valutare questi criteri in tempi rapidi, idealmente entro i primi minuti dalla rilevazione, per determinare se il timer delle 24 ore è attivo.
Fase di pre-notifica entro 24 ore: requisiti minimi di contenuto
La pre-notifica è il primo atto formale verso le autorità e deve contenere informazioni essenziali anche se l’incidente è ancora in corso. I requisiti minimi includono:
- identificazione del soggetto notificante;
- data e ora della prima rilevazione;
- natura dell’incidente (tipologia di attacco o evento);
- sistemi e servizi impattati;
- stima preliminare dell’impatto;
- misure di contenimento già adottate.
La pre-notifica non richiede un’analisi completa, non sarebbe possibile in 24 ore, ma deve essere sufficientemente informativa da consentire al CSIRT di valutare se attivare misure di coordinamento a livello nazionale o europeo.
Questo significa che il sistema di incident management deve essere in grado di aggregare queste informazioni in modo automatico, attingendole dai sistemi di monitoring, SIEM e dai log di sistema, senza richiedere un intervento manuale esteso.
Soluzioni tecniche per accelerare l’incident management: ruolo del SOAR e dell’automazione
Rispettare la scadenza delle 24 ore con processi manuali è possibile in scenari ideali: team disponibile, incidente chiaro, sistemi funzionanti. Ma nella realtà operativa, gli incidenti accadono di notte, nei weekend, durante picchi di carico o in concomitanza con altre crisi.
L’unico modo per garantire la conformità in modo sistematico è automatizzare il processo con strumenti progettati per questo scopo.
Cosa è un sistema SOAR e come funziona nel ciclo di risposta agli incidenti
SOAR è l’acronimo di Security Orchestration, Automation and Response. È una piattaforma che integra strumenti di sicurezza eterogenei, automatizza workflow di risposta predefiniti e gestisce il ciclo di vita degli incidenti dall’apertura alla chiusura.
A differenza di un semplice sistema di ticketing, un SOAR è in grado di eseguire azioni concrete sui sistemi: isolare un endpoint, bloccare un indirizzo IP, disabilitare un account compromesso, raccogliere evidenze forensi.
Nel contesto dell’incident management NIS2, il SOAR svolge tre funzioni chiave. Prima funzione: la detection e il triage automatizzato. Ricevuto un alert dal SIEM o da altri sensori, il SOAR esegue automaticamente una serie di controlli (correlazione con threat intelligence, verifica dei precedenti, analisi del contesto) e assegna un punteggio di severità.
Se l’incidente supera la soglia di “significatività”, attiva il workflow NIS2.
Seconda funzione: la raccolta automatica dei dati per la notifica. Il SOAR interroga i sistemi coinvolti, aggrega i log rilevanti, identifica gli asset impattati e popola automaticamente il template di pre-notifica con le informazioni disponibili.
Terza funzione: la gestione delle scadenze. Il SOAR monitora il timer delle 24 ore, invia alert escalation al team responsabile e può, se correttamente configurato, inviare automaticamente la notifica al CSIRT attraverso i canali ufficiali.
SOAR e SIEM: come integrare strumenti per detection e automazione
Il SOAR non lavora in isolamento: la sua efficacia dipende dalla qualità dei dati che riceve. Il SIEM (Security Information and Event Management) è tipicamente il motore di detection: raccoglie, normalizza e correla log da sorgenti eterogenee (come firewall, endpoint, applicazioni, cloud) e genera alert quando individua pattern anomali o noti.
L’integrazione SIEM-SOAR è il cuore del moderno SOC automatizzato. Il SIEM rileva e genera l’alert; il SOAR riceve l’alert tramite API o webhook, arricchisce il contesto (threat intelligence, asset inventory, vulnerabilità note), esegue le azioni di risposta automatica e traccia ogni passaggio in un log di audit immutabile.
Questo log è fondamentale sia per la notifica NIS2 che richiede evidenze documentate, sia per il processo di audit interno e le eventuali indagini post-incidente.
Playbook operativi per l’automazione dell’incident management
Un SOAR senza playbook ben progettati è come un motore senza carburante. I playbook sono i workflow automatizzati che definiscono, passo per passo, cosa deve accadere al verificarsi di un determinato tipo di incidente.
Sono il cuore operativo dell’automazione e richiedono una progettazione accurata, test approfonditi e aggiornamento continuo.
Esempi di playbook per eventi comuni di sicurezza
Il playbook per un attacco ransomware è tra i più critici nel contesto NIS2. Al trigger dell’alert, il sistema isola automaticamente gli endpoint infetti dalla rete, blocca la propagazione laterale, avvia la raccolta di snapshot forensi, verifica la disponibilità dei backup, notifica il team di incident response e, se i criteri di significatività sono soddisfatti, popola il template di pre-notifica e avvia il countdown delle 24 ore con escalation automatica.
Il playbook per una violazione di dati personali segue una logica simile ma con focus sulla classificazione dei dati coinvolti. Il SOAR interroga i sistemi DLP e di data classification per identificare la tipologia e il volume dei dati potenzialmente esposti, determina se la soglia che attiva anche l’obbligo di notifica al Garante Privacy (72 ore ai sensi del GDPR) è raggiunta, e coordina i due workflow di notifica in parallelo.
Il playbook per un attacco DDoS su infrastrutture critiche è invece orientato alla continuità operativa: attiva le misure di mitigazione (scrubbing center, rate limiting, rerouting del traffico), monitora i SLA dei servizi impattati e valuta se la durata e l’intensità dell’attacco superano le soglie di significatività NIS2.
Ruoli e responsabilità: chi deve attivare il workflow automatico
Bisogna però tenere in considerazione che l’automazione non elimina la responsabilità umana: la ridefinisce.
In un processo di incident management maturo, il SOAR esegue le azioni di bassa e media complessità in autonomia, mentre le decisioni ad alto impatto come l’invio definitivo della notifica alle autorità richiedono l’approvazione di una persona autorizzata.
I ruoli chiave includono il SOC Analyst (Tier 1/2), responsabile del triage iniziale e della validazione degli alert automatici; l’Incident Manager, che gestisce il processo end-to-end e ha l’autorità di dichiarare un incidente significativo; il CISO o delegato, che approva la notifica alle autorità; il Data Protection Officer, coinvolto quando l’incidente ha implicazioni per i dati personali; e il team legale, che verifica la correttezza formale della notifica.
La matrice RACI (utilizzata per definire e mappare ruoli e responsabilità all’interno di un progetto ) di questi ruoli deve essere codificata all’interno del SOAR: ogni fase del playbook deve avere un responsabile identificato e un meccanismo di escalation automatica in caso di mancata risposta entro i tempi previsti.
Metriche e automazione per verificare la conformità alle scadenze NIS2
Automatizzare il processo è necessario, ma non sufficiente. Le organizzazioni devono anche essere in grado di dimostrare la propria conformità alle autorità di supervisione, in Italia è l’ACN (Agenzia per la Cybersicurezza Nazionale), attraverso evidenze documentali tracciabili e metriche operative misurabili.
Indicatori di compromissione (IoC) e dati di supporto alla notifica
Gli Indicatori di Compromissione (IoC) sono artefatti tecnici che attestano l’avvenuta compromissione di un sistema: hash di file malevoli, indirizzi IP di command and control, domini utilizzati per l’esfiltrazione, pattern di traffico anomali.
La raccolta sistematica degli IoC è fondamentale sia per la risposta tecnica, in quanto alimenta i sistemi di blocco automatico, sia per la notifica alle autorità, che può includere questi artefatti per supportare l’analisi a livello nazionale.
Il SOAR, integrato con piattaforme di threat intelligence come MISP o OpenCTI, automatizza la raccolta e l’arricchimento degli IoC: ogni alert viene correlato con le basi di conoscenza disponibili, i nuovi IoC vengono estratti automaticamente dall’analisi dell’incidente e condivisi in modo controllato con la comunità di sicurezza tramite il CSIRT.
Reporting continuo e audit interno
Le metriche operative dell’incident management devono essere monitorate in modo continuativo, non solo in occasione di incidenti.
I KPI fondamentali includono:
- Mean Time to Detect (MTTD), il tempo medio dalla compromissione alla rilevazione;
- Mean Time to Notify (MTTN), il tempo medio dalla rilevazione all’invio della pre-notifica;
- tasso di rispetto delle scadenze NIS2;
- numero di playbook attivati per tipologia di incidente;
- percentuale di fasi del workflow completate automaticamente vs manualmente.
Questi dati devono essere disponibili in una dashboard accessibile al CISO e al management, con trend storici che consentano di identificare deterioramenti nel tempo.
Un audit interno trimestrale del processo di incident management che includa esercitazioni simulate con scenari NIS2 realistici è la pratica migliore per mantenere l’organizzazione in stato di prontezza operativa e dimostrare un approccio proattivo alla conformità.
Casi di successo e lezioni apprese nella gestione automatizzata degli incidenti
Analizzando i pattern emersi dalle organizzazioni che hanno implementato con successo un processo di incident management automatizzato in ottica NIS2, emergono alcune lezioni ricorrenti che vale la pena sistematizzare come framework di riferimento.
La prima lezione è che la tecnologia è necessaria ma non sufficiente. Le organizzazioni che hanno fallito nel rispettare le scadenze NIS2 non erano necessariamente quelle meno tecnologicamente avanzate, ma quelle in cui i playbook erano stati progettati senza coinvolgere il team legale e il DPO. Il risultato: workflow tecnici impeccabili che generavano notifiche formalmente incomplete. La progettazione del playbook deve essere interdisciplinare sin dall’inizio.
La seconda lezione riguarda il falso comfort dell’automazione totale. Alcuni team, entusiasti delle possibilità del SOAR, hanno configurato workflow completamente autonomi, incluso l’invio automatico delle notifiche senza approvazione umana. In diversi casi, questo ha portato all’invio di pre-notifiche per eventi che si sono poi rivelati falsi positivi, con conseguenti richieste di chiarimento da parte delle autorità. Il punto di equilibrio ottimale è l’automazione della preparazione e dell’escalation, con approvazione umana nell’atto finale di invio.
La terza lezione riguarda la gestione degli incidenti durante orari non lavorativi. Le organizzazioni più resilienti hanno implementato un sistema di on-call rotation con SLA interni più stringenti di quelli normativi: se la NIS2 richiede 24 ore, il target interno è 8 ore. Questo margine di sicurezza assorbe i ritardi inevitabili nella realtà operativa e garantisce la conformità anche negli scenari più sfavorevoli.
La quarta e forse più preziosa lezione è che gli incidenti sono opportunità di apprendimento. Le organizzazioni più mature hanno istituzionalizzato il processo di revisione post-incidente come momento formativo obbligatorio, con output documentati che alimentano direttamente l’aggiornamento dei playbook. In questo modo, ogni incidente — anche quello più critico — diventa un investimento nel miglioramento della postura di sicurezza futura.
L’incident management automatizzato non è un traguardo da raggiungere una volta per tutte: è un processo in evoluzione continua, che deve adattarsi alla mutevolezza del panorama delle minacce, alle evoluzioni normative e alla trasformazione tecnologica dell’organizzazione.
Chi lo comprende e lo pratica non si limita a rispettare la NIS2: costruisce una capacità di resilienza digitale che va ben oltre la compliance.
