Le Linee guida NIS – Specifiche di base sulla definizione del processo di gestione degli incidenti di sicurezza informatica di ACN datate 31 dicembre 2025 sulla gestione degli incidenti NIS2 prevedono un processo obbligatorio in cinque fasi per i soggetti essenziali e importanti: dalla preparazione documentata al miglioramento continuo. L'Incident Response diventa parte della governance, superando il semplice intervento tecnico. Vediamole nel dettaglio.

IL PROCESSO STRUTTURATO DELLA GESTIONE DEGLI INCIDENTI

ACN chiarisce  in modo strutturato come deve essere progettato, implementato e mantenuto il processo di Incident Response e definisce un ciclo di gestione completo, articolato in cinque fasi:

• Preparazione: occorre formalizzare e approvare politiche di sicurezza, gestione degli incidenti, ruoli, responsabilità, matrici RACI, inventari e misure organizzative e tecniche. Non basta gestire gli incidenti; serve un modello aggiornato, coerente e conforme alla normativa NIS. I documenti vecchi e mai rivisti non sono più accettabili.
• Rilevamento e risposta: è necessario distinquere chiaramente tra evento, incidente e incidente significativo. Il documento analizza le logiche di detection, l'importanza degli strumenti di monitoraggio e la necessità di un metodo strutturato che riduca rumore e cecità operativa. Si sottolinea che la notifica verso il CSIRT Italia parte dall'evidenza dell'incidente; non è necessario individuare subito la causa, ma solo riconoscere l'esistenza dell'incidente nelle casistiche previste.
• Ripristino e miglioramento: La gestione non si conclude con il ripristino tecnico dei sistemi. ACN ribadisce l’importanza della fase di miglioramento continuo: analisi post-incidente, lesson learned, aggiornamento delle procedure e del piano di gestione degli incidenti.

Il messaggio è chiaro: la gestione degli incidenti non è un’attività reattiva, ma una capacità organizzativa strutturale, che deve essere governata, documentata e verificabile.

LE NUOVE FAQ CHE CHIARISCONO CHI DEVE NOTIFICARE L’INCIDENTE

Vengono inoltri chiariti con delle nuove FAQ i ruoli di chi deve notificare un incidente che coinvolge un rapporto  cliente–fornitore tra soggetti NIS e quando entrano in gioco servizi cloud. Ecco perché “chi rileva” non sempre coincide con “chi notifica”

Il presupposto è che l’obbligo di notifica  non si sposta perché esiste un contratto con un fornitore o perché è stato esternalizzato un pezzo di operatività. Si sposta (solo) se la norma lo prevede, chiarendo così il perimetro con più nettezza. Vediamo gli scenari previsti

Scenario 1 (FAQ ISB.F.1): incidente sui sistemi del cliente, con fornitore che eroga servizi

ACN considera il caso in cui un cliente NIS abbia uno o più fornitori di servizi, anche gestiti, ma l’incidente coinvolga i sistemi informativi e di rete del cliente. In questo caso, la notifica al CSIRT Italia spetta al cliente, non al fornitore, che deve comunque supportare la gestione dell’incidente.

È fondamentale che nei requisiti contrattuali il cliente richieda al fornitore di segnalare tempestivamente gli eventi di sicurezza che impattano i suoi servizi, così da poter notificare in tempo. Affidarsi ai servizi gestiti non esonera dalla responsabilità: servono clausole e processi specifici per garantirne la corretta governance.

Scenario 2 (FAQ ISB.F.2): incidente sui sistemi del fornitore, con impatto sul cliente

Le aziende spesso commettono errori quando un incidente avviene dal lato fornitore, ma l’impatto colpisce il cliente, poiché i servizi influenzano le sue attività. ACN ha stabilito che il fornitore soggetto NIS deve notificare l’incidente al CSIRT Italia; inoltre, anche il cliente deve notificare se l’incidente è significativo per lui. Quindi può essere necessaria una doppia notifica. Il problema non è la duplicazione, ma il rischio di informazioni incoerenti tra cliente e fornitore: due versioni diverse complicano la gestione dell’incidente e danno un’immagine di disordine. Serve quindi coordinamento su tempistiche, descrizione e prove. La compliance qui dipende dalla qualità del processo decisionale.

Scenario 3 (FAQ ISB.F.3): cloud tra soggetti NIS, e l’eccezione che conta

ACN distingue chiaramente tra servizi cloud: l'obbligo di notifica al CSIRT Italia spetta sia al cliente NIS che al fornitore NIS, tranne nei casi di IaaS o hosting dell’infrastruttura, dove è solo responsabilità del cliente. Questa distinzione, più organizzativa che tecnica, sottolinea l’importanza di conoscere contratti e modelli di servizio. Senza chiarezza nei ruoli, gestire incidenti diventa difficile; inoltre, ricevere informazioni tempestive dal fornitore è fondamentale anche quando l’obbligo legale è del cliente.

IN SINTESI

Ricapitolando

• se l’incidente è sui sistemi del cliente, notifica il cliente;
• se l’incidente è sui sistemi del fornitore ma impatta il cliente, potrebbero dover notificare entrambi;
• sul cloud, in generale notificano entrambi, ma in IaaS/hosting dell’infrastruttura del cliente resta solo il cliente;

Diventa quindi necessario regolamentare con chiarezza il rapporto cliente fornitore in modo da gestire correttamente le emergenze tecniche e non avere inutili esitazioni operative