Piano di incident response NIS2: contenuti e modello

Per la NIS2 il piano di incident response (nelle misure ACN, piano per la gestione degli incidenti) deve contenere almeno cinque cose: fasi e procedure di gestione e notifica con ruoli e responsabilità, le procedure per le relazioni al CSIRT Italia, i contatti per la segnalazione, la comunicazione interna ed esterna e la reportistica. Lo approvano gli organi di amministrazione e si riesamina almeno ogni due anni.

Lo prevede la misura RS.MA-01 degli allegati 1 e 2 della Determinazione ACN 379907/2025, identica per soggetti importanti ed essenziali. Qui sotto: cos'è il piano, cosa chiedono D.Lgs. 138/2024 e ACN, le fasi da coprire, un modello da copiare sezione per sezione e come provarlo prima che serva.

Cos'è un piano di incident response, e cosa non è

Il piano risponde a tre domande nel momento peggiore: chi comanda, cosa si fa adesso, chi va avvisato e entro quando. Sta in mezzo a documenti con cui viene spesso confuso.

• La politica di gestione degli incidenti fissa principi e perimetro. Il piano la traduce in ruoli con un nome, passi e contatti.
• I playbook sono le procedure per uno scenario preciso: ransomware, compromissione della posta, esfiltrazione di dati, account cloud violato. Il piano dice quando parte ciascun playbook e chi lo esegue. Come si scrivono è spiegato in playbook e procedure del SOC.
• Il piano di continuità operativa tiene in piedi le attività critiche mentre i sistemi sono fermi. Il piano di incident response si occupa dell'attacco. Il NIST, nella SP 800-61 Rev. 3, raccomanda di sincronizzarli, perché un incidente può minare la resilienza dell'azienda.

Il D.Lgs. 138/2024 definisce la gestione degli incidenti come «le azioni e le procedure volte a prevenire, rilevare, analizzare e contenere un incidente o a rispondervi e recuperare da esso» (art. 2, comma 1, lettera z). Un piano che descrive solo la bonifica tecnica copre una parte di questa definizione, non tutta.

Cosa chiedono NIS2 e ACN

D.Lgs. 138/2024: una decisione degli organi di amministrazione

L'art. 24, comma 2, lettera b) mette la gestione degli incidenti tra le misure minime, comprese le procedure e gli strumenti per eseguire le notifiche. L'art. 23 chiede agli organi di amministrazione e direttivi di approvare le modalità di implementazione delle misure e di sovrintendere agli obblighi, e prevede che siano informati degli incidenti e delle notifiche. Il piano, quindi, è un documento approvato dal vertice, non un runbook dell'IT chiuso in una cartella condivisa. Il quadro completo delle misure è in misure di sicurezza NIS2, articolo 21.

La misura RS.MA-01 delle specifiche di base ACN

La Determinazione ACN 379907/2025 traduce l'obbligo in requisiti. Al punto 1 della misura RS.MA-01 chiede un piano per la gestione degli incidenti e la notifica al CSIRT Italia, in accordo all'art. 25 del decreto, che comprenda almeno:

1. le fasi e le procedure di gestione e notifica, con ruoli e responsabilità;
2. le procedure per preparare e trasmettere le relazioni intermedia, mensile e finale (art. 25, comma 5, lettere c, d ed e);
3. le informazioni di contatto per la segnalazione degli incidenti;
4. le modalità di comunicazione interna, compreso il coinvolgimento degli organi di amministrazione e direttivi, ed esterna;
5. la reportistica per documentare l'incidente.

Il punto 2 vuole il piano approvato dagli organi di amministrazione e direttivi. Il punto 3 ne chiede il riesame periodico e comunque almeno ogni due anni, e ogni volta che ci sono incidenti significativi, integrando le lezioni apprese, o cambia l'esposizione alle minacce. Due misure collegate completano il quadro: RS.CO-02, sulla comunicazione ai destinatari dei servizi, e RC.RP-01, che chiede dentro lo stesso piano le procedure per il ripristino dei sistemi colpiti.

I termini per adottare le misure sono due: 18 mesi dalla comunicazione di inserimento nell'elenco, cioè ottobre 2026, per chi è entrato nel 2025, e il 31 luglio 2027 per chi è entrato nel 2026 (Determinazione ACN 127434/2026, art. 1).

I tempi della notifica

L'art. 25, comma 5 fissa la sequenza verso il CSIRT Italia per gli incidenti significativi:

• Pre-notifica senza ingiustificato ritardo e comunque entro 24 ore da quando si è venuti a conoscenza dell'incidente, indicando se possibile se è frutto di atti illegittimi o malevoli o se può avere impatto transfrontaliero.
• Notifica dell'incidente entro 72 ore, con una valutazione iniziale di gravità e impatto e, se disponibili, gli indicatori di compromissione.
• Relazione intermedia su richiesta del CSIRT Italia.
• Relazione finale entro un mese dalla trasmissione della notifica, con descrizione dettagliata, tipo di minaccia o causa originale, misure di attenuazione e impatto transfrontaliero se noto. Se l'incidente è ancora in corso, si invia una relazione mensile sui progressi e la relazione finale entro un mese dalla conclusione della gestione.

Le linee guida ACN sul processo di gestione degli incidenti precisano due cose utili per il piano. L'orologio parte quando il soggetto ha evidenza dell'incidente, cioè dispone di elementi oggettivi da cui risulta che si è verificato. E le notifiche si trasmettono dal portale segnalazioni.acn.gov.it. Il dettaglio operativo è nella guida alla notifica degli incidenti NIS2.

Due binari possono correre in parallelo. Se l'incidente è anche una violazione di dati personali, l'art. 33 del GDPR chiede la notifica al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore, salvo che sia improbabile un rischio per le persone. Le entità finanziarie soggette a DORA seguono invece i tempi del Regolamento delegato (UE) 2025/301, art. 5: notifica iniziale entro 4 ore dalla classificazione come grave e non oltre 24 ore da quando ne sono venute a conoscenza, relazione intermedia entro 72 ore dalla notifica iniziale, relazione finale entro un mese dall'ultima relazione intermedia.

Le fasi che il piano deve coprire

Le linee guida ACN propongono un modello di processo costruito sulla NIST SP 800-61 Rev. 3, uscita ad aprile 2025. Le fasi sono cinque:

1. Preparazione. Governo, identificazione e misure preventive: ruoli, contatti, inventario dei sistemi, fonti di log, playbook, un canale di comunicazione che funzioni anche se la posta è compromessa, contratti con i fornitori di risposta firmati prima che servano.
2. Rilevamento. Come un allarme o una segnalazione di un utente diventa un incidente dichiarato, chi ne valuta la gravità, chi decide se è significativo.
3. Risposta. Segnalazione, investigazione, contenimento ed eradicazione: isolare macchine, disattivare account, bloccare indicatori, eliminare la persistenza, chiudere il punto di ingresso, conservare le prove.
4. Ripristino. Riportare i sistemi allo stato precedente da backup puliti, in un ordine definito, controllando che l'attaccante non rientri.
5. Miglioramento. Attraversa tutto il processo: causa originale, cronologia, cosa ha funzionato, cosa cambiare nei controlli e nel piano.

Cosa sia l'incident response in generale, al di là della NIS2, e come si organizza in azienda è spiegato in incident response: cos'è, fasi e piano di risposta.

Modello di piano di incident response

Copia la struttura, sostituisci i segnaposto tra parentesi quadre e tieni il documento principale breve, abbastanza da leggerlo durante un incidente. Il dettaglio va nei playbook e negli allegati. Tra parentesi, dove serve, il requisito di RS.MA-01 a cui la sezione risponde.

1. Controllo del documento

• Responsabile del piano: [ruolo, non persona]
• Approvato da: [organo di amministrazione], il [data] (RS.MA-01, punto 2)
• Versione, data del prossimo riesame, lista di distribuzione
• Dove si trova la copia consultabile offline: [luogo]

2. Scopo e perimetro

• Sistemi, sedi, società e servizi coperti: [elenco, collegato all'inventario]
• Norme applicabili: [D.Lgs. 138/2024, GDPR, DORA se pertinente, obblighi contrattuali di notifica]
• Collegamenti con la politica di gestione degli incidenti, il piano di continuità operativa e il piano di gestione delle crisi

3. Ruoli e poteri di decisione (lettera a)

• Responsabile della gestione dell'incidente e sostituto: [nomi, reperibilità 24/7]
• Referente tecnico (team interno, SOC o MSSP), IT, ufficio legale, comunicazione, DPO, risorse umane
• Referente CSIRT e sostituti, che effettuano le notifiche
• Decisioni riservate al vertice: [fermo della produzione, gestione di una richiesta di riscatto, comunicazioni pubbliche, denuncia all'autorità]

4. Contatti (lettera c)

• Catena di chiamata interna con sostituti
• CSIRT Italia e portale di segnalazione, Garante privacy, Polizia Postale: [recapiti]
• Fornitori di risposta, assicurazione cyber, legali, fornitori e cloud provider critici
• Canale di riserva se posta o chat sono compromesse: [canale]

5. Classificazione e gravità

• Categorie: [ransomware, account compromesso, esfiltrazione, interruzione del servizio, abuso interno]
• Livelli di gravità e criteri: [fermo operativo, perdita economica, dati coinvolti, utenti o clienti colpiti, durata]
• Verifica di notificabilità sulle tipologie ACN: IS-1 perdita di riservatezza verso l'esterno, IS-2 perdita di integrità con impatto verso l'esterno, IS-3 violazione dei livelli di servizio attesi, più IS-4 accesso non autorizzato o con abuso di privilegi per i soggetti essenziali

6. Attivazione ed escalation (lettere a e d)

• Chi può dichiarare l'incidente e attivare il piano, a qualsiasi ora
• Soglie di escalation: [gravità 1: vertice informato entro X ore]
• Quando subentrano il piano di continuità e la gestione della crisi

7. Procedure di risposta e ripristino (lettera a, RC.RP-01)

• Investigazione, contenimento, eradicazione e ripristino, con il playbook da usare per ogni categoria
• Gestione delle prove: cosa conservare, dove stanno i log, catena di custodia
• Ordine di ripristino: [prima i servizi critici, con i relativi obiettivi di ripristino]

8. Notifica e comunicazione (lettere b e d)

• Cronologia: pre-notifica entro 24 ore, notifica entro 72 ore, relazione finale entro un mese dalla notifica; binari GDPR e DORA se pertinenti
• Chi redige, chi approva, chi trasmette
• Clienti, fornitori, personale e stampa: testi pronti e percorso di approvazione (RS.CO-02)

9. Registri e modelli di report (lettera e)

• Registro dell'incidente con orari, a partire dal momento dell'evidenza
• Modelli per pre-notifica, notifica, relazione finale e riesame post incidente

10. Riesame, test e manutenzione (punto 3)

• Riesame post incidente entro [X] giorni dalla chiusura, con azioni assegnate e datate
• Calendario delle esercitazioni: [tabletop e prove tecniche, frequenza]
• Riesame almeno ogni due anni e dopo incidenti significativi o cambi di esposizione alle minacce

Provare il piano

Un piano mai provato cede sulle cose piccole: un numero di telefono vecchio, un'approvazione che nessuno può dare alle due di notte, un backup che nessuno ha mai ripristinato. Tre formati coprono quasi tutto:

• Esercitazione tabletop. Uno scenario discusso con chi decide, vertice compreso, per verificare ruoli, escalation e le prime 24 ore.
• Prova tecnica. Isolare una macchina, ripristinare un server da backup, revocare accessi in blocco, misurando i tempi rispetto a quelli scritti nel piano.
• Riesame dopo gli incidenti veri. Anche quelli minori mostrano dove il piano diverge da quello che le persone fanno davvero.

Quando l'incidente diventa una crisi aziendale le decisioni passano al comitato di crisi: come si organizza è spiegato in crisis management aziendale.

Le lacune più comuni

• Rilevamento solo in orario d'ufficio. Se nessuno guarda gli allarmi di notte o nel fine settimana, un attacco può andare avanti per giorni prima che qualcuno ne abbia evidenza, e il contenimento parte tardi.
• Tutto su una persona. Nessun sostituto per chi gestisce l'incidente o per il referente CSIRT. Chi può esserlo e come si designa è spiegato in referente CSIRT NIS2.
• Il piano sta sui sistemi colpiti. Se l'unica copia è sul file server cifrato dal ransomware, nessuno la può leggere.
• Nessun potere di decisione. Il team tecnico aspetta il permesso di isolare un sistema di produzione mentre l'attacco si allarga. Le linee guida ACN chiedono di definire nel piano chi prende le decisioni che non spettano al referente CSIRT, nei casi più rilevanti gli organi di amministrazione.
• Fornitori esclusi. I contratti con MSP e cloud provider non dicono nulla su notifiche e supporto all'indagine. Il titolo stesso della misura RS.MA-01 parla di un piano eseguito in coordinamento con le terze parti interessate.

Dove entra un SOC gestito

Per un'azienda mid-market la parte più difficile del piano è coprire rilevamento e prima risposta 24 ore su 24. Un SOC gestito o un servizio MDR si occupa di monitoraggio, triage e supporto al contenimento; la titolarità del piano, le decisioni e le notifiche al CSIRT Italia restano all'azienda. Per chi vuole una squadra di risposta già ingaggiata prima dell'incidente esiste anche l'incident response retainer.

Se vuoi costruire o rivedere il tuo piano di incident response insieme a rilevamento e risposta continui, guarda i nostri servizi di cybersecurity.