1. La gestione di un incidente è una questione di governance, non solo IT
Avere un SOC (Security Operations Center) significa poter contare su monitoraggio, detection e analisi degli eventi di sicurezza. È un elemento importante, ma non coincide con la gestione completa di un incidente.
La domanda che una PMI dovrebbe porsi è semplice: cosa succede dopo che il SOC ha rilevato un incidente potenzialmente significativo?
Chi decide come classificarlo? Chi coordina IT, sicurezza e management? Chi raccoglie le evidenze? Chi valuta gli eventuali obblighi di notifica NIS2? Chi gestisce le comunicazioni verso il CSIRT Italia? E chi verifica che ogni decisione sia tracciata?
Queste domande riguardano la tecnologia, ma anche la governance. Nel quadro NIS2, la sicurezza informatica deve essere collegata alla gestione del rischio, alla continuità operativa e alle responsabilità del management.
Gli organi di amministrazione e direzione non devono sostituirsi ai tecnici, ma devono poter contare su ruoli, procedure e informazioni adeguate per governare il rischio cyber.
Il contesto rende il tema particolarmente attuale. Secondo il Rapporto Clusit 2026, nel 2025 sono stati censiti 507 incidenti cyber gravi che hanno coinvolto l'Italia, rispetto ai 357 censiti nel 2024 (+42%). Il dato riguarda gli eventi osservati e documentati nel perimetro metodologico del Rapporto e non rappresenta il totale di tutti gli incidenti cyber avvenuti nel Paese.
Per un'organizzazione soggetta alla NIS2, quindi, la capacità di reagire a un incidente non può essere considerata esclusivamente una questione tecnica.
2. Notifiche NIS2: il tempo conta, ma l'analisi non deve essere già conclusa
Uno degli aspetti più delicati della gestione di un incidente significativo riguarda le tempistiche di comunicazione al CSIRT Italia.
L'art. 25, comma 5, del D.Lgs. 138/2024 stabilisce una sequenza precisa. Dal momento in cui il soggetto viene a conoscenza di un incidente significativo:
- la pre-notifica deve essere effettuata senza ingiustificato ritardo e comunque entro 24 ore;
- la notifica dell'incidente deve essere effettuata senza ingiustificato ritardo e comunque entro 72 ore;
- la relazione finale deve essere trasmessa entro un mese dalla trasmissione della notifica dell'incidente;
- se l'incidente è ancora in corso, sono previsti aggiornamenti mensili e la relazione finale entro un mese dalla conclusione della gestione dell'incidente.
Il punto importante è che la notifica entro 72 ore non presuppone necessariamente che l'azienda abbia già completato l'analisi forense.
La notifica deve contenere una valutazione iniziale della gravità e dell'impatto dell'incidente e, ove disponibili, gli indicatori di compromissione. Le informazioni possono quindi essere integrate man mano che l'analisi procede.
Il problema operativo è che nelle prime ore l'azienda potrebbe non conoscere ancora tutti i dettagli. Potrebbero essere disponibili soltanto l'orario del rilevamento, i sistemi coinvolti, alcuni indicatori di compromissione, i primi effetti sull'operatività e le attività di contenimento.
Per questo la notifica deve essere inserita in un processo capace di evolvere insieme all'incidente, aggiornando progressivamente le informazioni disponibili.
Chi è il Referente CSIRT NIS2?
Il soggetto NIS deve disporre di un Referente CSIRT, persona fisica designata dal Punto di contatto tramite il Portale ACN.
Il Referente rappresenta l'interlocutore operativo con CSIRT Italia e cura, per conto del soggetto, le notifiche previste. ACN consente inoltre di individuare uno o più sostituti.
Il Referente CSIRT non coincide automaticamente con il Punto di contatto NIS né con altre figure aziendali che possono avere responsabilità in materia di cybersecurity.
In una PMI le funzioni possono eventualmente convergere sulla stessa persona, ma le responsabilità devono rimanere chiare.
Il Referente deve essere integrato nel processo di Incident Response e sapere quando viene attivato, con chi deve coordinarsi, quali informazioni devono essere raccolte e come vengono gestite le comunicazioni previste.
La designazione formale, quindi, non dovrebbe essere considerata un adempimento isolato: il valore della figura emerge quando è collegata a ruoli, escalation e procedure realmente utilizzabili.
3. Il gap tipico delle PMI: detection sì, coordinamento e notifica no
Molte PMI hanno già investito in firewall, EDR/XDR, backup, MFA, vulnerability assessment, SIEM o SOC gestiti. Il punto debole può essere un altro: il collegamento tra detection, Incident Response e governance.
Il SOC può rilevare un'anomalia alle 2 di notte. Ma se non è stato definito in anticipo chi deve essere contattato, chi coordina la risposta, chi valuta l'impatto, chi verifica gli obblighi di notifica NIS2 e quali evidenze devono essere conservate, la tecnologia rischia di essere accompagnata da un processo improvvisato.
SOC e CSIRT: qual è la differenza?
Il SOC ha principalmente una funzione di sicurezza operativa. Si occupa di monitoraggio, detection, analisi degli alert, correlazione degli eventi, triage, threat hunting ed escalation.
L'Incident Response organizza invece la risposta all'incidente: analisi, classificazione, contenimento, coordinamento, raccolta delle evidenze, recovery e attività post-incidente.
Il Referente CSIRT presidia, per quanto di competenza, l'interlocuzione e le notifiche previste verso il CSIRT Italia.
Il SOC aiuta a vedere e analizzare la minaccia. L'Incident Response organizza la risposta. Il Referente CSIRT presidia il processo di comunicazione previsto verso il CSIRT Italia.
Le funzioni devono quindi parlarsi. Avere un SOC non significa automaticamente avere un processo completo di Incident Response o una gestione pronta delle notifiche.
È in questo spazio che può inserirsi anche un modello CSIRT as a Service: un supporto esterno può integrare le capacità interne di detection con competenze dedicate alla gestione coordinata degli incidenti.
4. Il playbook minimo da avere prima di un'ispezione NIS2
Una PMI dovrebbe poter dimostrare non soltanto di avere documentazione, ma di possedere un processo utilizzabile e testato.
Il primo elemento è un Incident Response Playbook, semplice abbastanza da essere consultato durante una crisi e sufficientemente dettagliato da evitare decisioni improvvisate.
Ruoli e responsabilità
Devono essere identificati, in funzione della struttura aziendale:
- Punto di contatto;
- Referente CSIRT ed eventuali sostituti;
- responsabile IT e sicurezza;
- referente SOC;
- management coinvolto;
- eventuale DPO;
- consulenti e fornitori critici.
I contatti devono essere aggiornati e le persone coinvolte devono conoscere il proprio ruolo.
Runbook operativo
Il processo può seguire una sequenza essenziale:
Detection → Triage → Classificazione → Escalation → Containment → Valutazione dell'impatto → Valutazione della notifica → Comunicazione → Recovery → Post-Incident Review
Per ogni fase dovrebbero essere chiari responsabile, criteri di escalation e informazioni da raccogliere.
Evidenze e tracciabilità
Il playbook dovrebbe indicare anche quali evidenze conservare: log, alert SOC, timestamp, indicatori di compromissione, ticket, timeline, azioni di contenimento, comunicazioni e decisioni prese.
La domanda da porsi è: se l'incidente dovesse essere ricostruito settimane dopo, l'azienda sarebbe in grado di spiegare cosa è successo, quando, chi ha deciso cosa e quali azioni sono state effettuate?
Test ed esercitazioni
Una procedura mai testata rimane un'ipotesi. Sono quindi utili tabletop exercise, simulazioni ransomware, test delle escalation e verifica dei contatti e dei tempi di risposta.
L'obiettivo non è dimostrare che tutto funziona perfettamente, ma individuare prima dell'incidente reale dove il processo si blocca.
Per i soggetti inclusi nell'elenco nazionale NIS nel 2025, ACN prevede l'adozione delle misure di sicurezza di base entro 18 mesi dalla ricezione della comunicazione individuale di inserimento. Per molti il termine ricade nell'ottobre 2026, ma non si tratta di una scadenza universale del 31 ottobre: fa fede la comunicazione ricevuta e il relativo ciclo di inclusione. Per il quadro completo delle scadenze, leggi il nostro articolo su NIS2 e PMI italiane: cosa scade tra giugno e ottobre 2026.
5. Come strutturare l'Incident Response con Delta Infor
Per una PMI non è sempre necessario costruire internamente un team completo di cybersecurity e Incident Response. Un supporto esterno può affiancare le competenze interne, mantenendo chiari ruoli e responsabilità.
Delta Infor può supportare l'azienda nella valutazione della propria preparazione, verificando il collegamento tra sicurezza tecnica, gestione degli incidenti e governance.
Un primo passo può essere una Gap Analysis NIS2 orientata anche alla IR Readiness, per verificare:
- presenza e chiarezza dei ruoli;
- integrazione del Referente CSIRT;
- procedure di escalation;
- rapporto tra SOC e Incident Response;
- Incident Response Plan e runbook;
- gestione delle evidenze;
- processo di gestione delle notifiche;
- aggiornamento dei contatti;
- esercitazioni e test;
- capacità di coinvolgere rapidamente il management.
L'obiettivo non è necessariamente sostituire il SOC esistente, ma capire se intorno al SOC esiste un processo completo e verificato.
Un modello efficace può essere sintetizzato così:
SOC → Detection
Incident Response → Analisi, contenimento e coordinamento
Referente CSIRT → Interlocuzione e notifiche previste verso il CSIRT Italia
Management → Governance, decisioni e responsabilità
Post-Incident Review → Evidenze, lesson learned e miglioramento
La cybersecurity NIS2 non finisce con la detection
Per una PMI soggetta alla NIS2, avere un SOC è una componente importante della sicurezza, ma non esaurisce la capacità di risposta.
Servono anche ruoli formalizzati, procedure di escalation, Incident Response, gestione delle evidenze, capacità di gestire le notifiche previste, esercitazioni e coinvolgimento del management.
Il passaggio fondamentale è quindi da "abbiamo un sistema che ci avvisa quando succede qualcosa" a "abbiamo un processo verificato che ci dice cosa fare quando succede qualcosa".
Una Gap Analysis NIS2 e una verifica di IR Readiness possono essere un punto di partenza per individuare eventuali lacune tra detection, coordinamento, governance e gestione delle notifiche.
Delta Infor può affiancare la tua azienda in questa valutazione, con un approccio orientato alle priorità concrete e alla preparazione operativa.
