Piano di risposta agli incidenti: guida pratica per PMI

Un piano di risposta agli incidenti è un documento scritto e approvato dalla direzione. Dice chi fa cosa, in quale ordine ed entro quali tempi quando un attacco informatico colpisce l’azienda: un ransomware che cifra i server, un account email compromesso, una linea di produzione ferma per un malware. Serve a contenere il danno nelle prime ore, a rispettare gli obblighi di notifica previsti da NIS2 e GDPR e a tornare operativi senza improvvisare. In questa guida trovate la struttura del piano, le sei fasi da coprire, i ruoli da assegnare, le scadenze italiane e il modo per mettere tutto alla prova con un’esercitazione tabletop.

In breve

• Il piano copre sei fasi: preparazione, identificazione, contenimento, eradicazione, ripristino e lezioni apprese (modello PICERL).
• Per i soggetti NIS2 la notifica al CSIRT Italia prevede una pre-notifica entro 24 ore e una notifica entro 72 ore; per un data breach il Garante va avvisato entro 72 ore.
• Serve un responsabile della gestione dell’incidente che non lavori sul tecnico, ma governi tempi, decisioni e comunicazioni.
• Una copia cartacea del piano e dei contatti è indispensabile: durante un ransomware email e chat possono essere irraggiungibili.
• Un piano mai testato è un’ipotesi: le esercitazioni tabletop rivelano le lacune prima di un incidente reale.

Indice

• Cos’è un piano di risposta agli incidenti, e cosa non è
• Le sei fasi del piano
• Ruoli e catena decisionale
• Le scadenze di notifica in Italia
• Cosa scrivere nel documento
• Fabbrica e macchine connesse: l’incidente non è solo IT
• Esercitazioni tabletop: mettere il piano alla prova
• Dopo l’incidente: analisi senza colpevoli
• Il nostro punto di vista
• Domande frequenti
• Fonti

Cos’è un piano di risposta agli incidenti, e cosa non è

L’Agenzia per la Cybersicurezza Nazionale descrive la gestione degli incidenti come un processo strutturato in fasi, pensato per dare coerenza e sistematicità alle azioni di risposta. Il piano è la traduzione aziendale di quel processo: istruzioni operative per rilevare un attacco, limitarne le conseguenze e documentare ogni passaggio.

La CISA statunitense aggiunge un punto spesso trascurato: il piano è un documento formalmente approvato dall’alta direzione, che accompagna l’organizzazione prima, durante e dopo un incidente sospetto o confermato. Senza quell’approvazione mancano budget, persone e soprattutto l’autorità per decidere in fretta, per esempio di spegnere un server che fattura.

Il piano di risposta non coincide con altri documenti che spesso gli stanno accanto:

I tre documenti devono richiamarsi a vicenda. Il ripristino previsto nel piano di risposta si appoggia sulle procedure di disaster recovery, e le decisioni sul fermo produttivo si appoggiano sulla continuità. Se state costruendo anche quest’ultima parte, trovate un approfondimento nelle nostre best practice per la continuità operativa.

Le sei fasi del piano

Il modello più usato, richiamato anche dalle linee guida ACN e dal modello compilabile del governo canadese, divide la risposta in sei fasi. Per ognuna il piano deve dire cosa si fa, chi lo fa e cosa si registra.

1. Preparazione

È la fase che si svolge prima di qualsiasi attacco, ed è quella che decide l’esito di tutte le altre. Comprende l’inventario dei sistemi critici, la rubrica dei contatti interni ed esterni, gli accessi di emergenza, i backup verificati e offline, gli strumenti di registrazione dei log e la formazione del personale. Se non sapete da dove partire, un assessment di cybersecurity aziendale vi dà la fotografia di partenza.

2. Identificazione

Qui si stabilisce se un evento anomalo è davvero un incidente e quanto è grave. Il piano deve fissare criteri di classificazione semplici: quali sistemi sono coinvolti, se ci sono dati personali, se la produzione o i clienti sono impattati. Da questa valutazione partono gli orologi delle notifiche, quindi conviene annotare data e ora di ogni scoperta.

3. Contenimento

L’obiettivo è fermare la propagazione: isolare le macchine infette, disattivare account compromessi, bloccare connessioni verso l’esterno. Il piano deve distinguere il contenimento a breve termine, che si decide in minuti, da quello a lungo termine, che può richiedere di far girare l’azienda in modalità ridotta. Le prove vanno preservate: spegnere tutto in fretta può cancellare le tracce utili all’analisi.

4. Eradicazione

Si elimina la causa: malware, backdoor, credenziali rubate, vulnerabilità sfruttata. Senza questa fase l’attaccante rientra dalla stessa porta, spesso dopo pochi giorni.

5. Ripristino

Si riportano in produzione i sistemi puliti, partendo da quelli critici, e si monitora con attenzione nelle settimane successive. Il piano deve indicare l’ordine di ripristino concordato con le funzioni aziendali: prima la fatturazione o prima la logistica? Deciderlo durante la crisi costa ore.

6. Lezioni apprese

A incidente chiuso si analizza cosa ha funzionato e cosa no, e si aggiorna il piano. L’ACN indica la gestione degli incidenti come un processo che deve rilevare, segnalare e valutare gli incidenti e migliorare nel tempo. Ne parliamo più avanti, perché è la fase più spesso saltata.

Ruoli e catena decisionale

Un piano fallisce più spesso per confusione sulle responsabilità che per mancanza di competenze tecniche. La CISA consiglia di nominare un responsabile dell’incidente che non svolga compiti tecnici: il suo lavoro è tenere il tempo, coordinare e far circolare le informazioni. Sotto stress la percezione del tempo si distorce, e qualcuno deve ricordare al gruppo che la finestra delle 24 ore si sta chiudendo.

In una PMI i ruoli si sommano spesso nella stessa persona. Va bene, purché ogni ruolo abbia un titolare e un sostituto.

La comunicazione merita un capitolo a sé. Un attacco diventa spesso anche un problema di reputazione, con clienti preoccupati, recensioni negative e voci sui social. Per preparare questa parte è utile ispirarsi a un protocollo di difesa della reputazione online, che aiuta a definire in anticipo canali, toni e tempi delle risposte pubbliche.

Un ultimo dettaglio pratico: stampate il piano e la rubrica dei contatti. La CISA ricorda che durante un incidente email, chat e servizi cloud possono essere inaccessibili proprio quando servono di più. Una cartellina in ufficio e una a casa del responsabile risolvono il problema.

Le scadenze di notifica in Italia

Il piano deve contenere le scadenze di legge, con i moduli e i canali già individuati. In Italia valgono due regimi distinti, che possono sovrapporsi nello stesso incidente.

Per i soggetti NIS2 le linee guida ACN collocano la notifica dentro il processo di gestione, e la sequenza completa dei tre tempi di notifica al CSIRT Italia si chiude con la relazione finale entro un mese. Le modalità e specifiche di base pubblicate dall’ACN chiariscono quali incidenti significativi vanno notificati e da quando, in base alla data di inserimento nell’elenco nazionale NIS. Se non sapete ancora se la vostra azienda rientra nel perimetro, partite dalla nostra guida su cosa prevede la NIS2.

Per il GDPR, il Garante spiega che il titolare deve notificare la violazione entro 72 ore dal momento in cui ne è venuto a conoscenza, salvo che sia improbabile un rischio per i diritti delle persone. Attenzione al secondo obbligo, quello verso gli interessati. Nel maggio 2026 il Garante ha sanzionato una società per 85mila euro perché, pur avendo notificato la violazione nei termini, non aveva informato tempestivamente le persone coinvolte. Il piano deve quindi contenere anche un modello di comunicazione agli interessati, non solo il modulo per l’autorità.

Quando un caso concreto vi lascia dubbi su cosa notificare e a chi, coinvolgete subito il DPO o un legale esperto di protezione dei dati: la valutazione del rischio per le persone è una scelta giuridica, non solo tecnica.

Cosa scrivere nel documento

Un buon piano per una PMI sta in poche pagine, ma deve essere completo. Questa è la struttura minima che consigliamo:

1. Scopo e campo di applicazione: sistemi, sedi e stabilimenti coperti.
2. Approvazione e revisione: firma della direzione, data, versione, prossima revisione.
3. Definizioni e classificazione: cosa è un evento, cosa è un incidente, livelli di gravità.
4. Ruoli e contatti: titolari, sostituti, numeri di cellulare, fornitori, assicurazione cyber, CSIRT Italia, Garante.
5. Procedure per fase: dalla preparazione alle lezioni apprese, con checklist.
6. Playbook per scenari: ransomware, phishing con furto di credenziali, data breach, attacco a macchine connesse.
7. Notifiche: moduli precompilati, scadenze, responsabili.
8. Comunicazione: messaggi tipo per dipendenti, clienti, fornitori.
9. Registro dell’incidente: chi ha fatto cosa e quando, utile per le autorità e per l’assicurazione.
10. Allegati: inventario dei sistemi, schema di rete, procedure di ripristino dei backup.

I playbook sono la parte più utile nella pratica. Un playbook ransomware, per esempio, dice in dieci righe quali macchine isolare, chi chiama il fornitore dei backup, chi decide se fermare la produzione e chi apre la pre-notifica.

Fabbrica e macchine connesse: l’incidente non è solo IT

Nelle aziende manifatturiere un attacco può fermare PLC, linee e sistemi MES, non solo la posta. Il piano deve prevedere chi può mettere in sicurezza un impianto, come passare a una gestione manuale e quali reti di stabilimento isolare senza creare rischi per le persone. Isolare in fretta un sistema di controllo può essere più pericoloso dell’attacco stesso, se non lo fa chi conosce l’impianto: il responsabile di produzione deve sedere al tavolo di crisi.

Abbiamo raccolto i punti principali nelle best practice per la sicurezza delle macchine connesse e nella guida alla cybersecurity per aziende manifatturiere.

Esercitazioni tabletop: mettere il piano alla prova

Il NIST definisce la tabletop come un’esercitazione basata sulla discussione, in cui le persone con un ruolo nel piano si riuniscono per validarne i contenuti discutendo cosa farebbero durante un’emergenza. Nessun sistema viene toccato: si lavora attorno a un tavolo, con uno scenario che evolve.

La CISA mette a disposizione oltre 100 pacchetti di esercitazione pronti, adattabili alla propria realtà. Ecco come organizzarne una in azienda:

1. Scegliete lo scenario: un ransomware che cifra il gestionale un venerdì sera è un buon punto di partenza.
2. Nominate un facilitatore: presenta lo scenario e introduce gli imprevisti, senza partecipare alle decisioni.
3. Convocate i ruoli veri: direzione, IT, produzione, privacy, comunicazione. Ognuno interpreta il proprio ruolo.
4. Fate evolvere lo scenario: dopo 30 minuti i dati compaiono su un sito di estorsione, dopo un’ora chiama un cliente importante.
5. Mettete sotto stress la catena decisionale: le indicazioni CISA per le tabletop suggeriscono di simulare anche l’assenza di figure chiave, per esempio il titolare in volo senza connessione.
6. Registrate le lacune: numeri di telefono mancanti, decisioni senza titolare, passaggi non chiari.
7. Aggiornate il piano: entro due settimane, con un responsabile per ogni correzione.

L’obiettivo non è superare la prova, ma scoprire i punti deboli. Un’esercitazione in cui tutto va liscio, di solito, era troppo facile. Due tabletop all’anno, con scenari diversi, bastano a una PMI per mantenere il piano vivo. Le tabletop funzionano meglio se la formazione di base è già diffusa: una solida cultura della sicurezza informatica sul lavoro riduce gli incidenti causati dall’errore umano e rende i dipendenti i primi sensori dell’azienda.

Dopo l’incidente: analisi senza colpevoli

La fase delle lezioni apprese funziona solo se nessuno teme di parlare. L’analisi post-incidente non cerca il dipendente che ha cliccato sul link sbagliato, ma le cause di sistema: perché quel messaggio è arrivato in casella, perché l’account aveva privilegi eccessivi, perché il backup non è stato ripristinato in tempo.

Un report utile risponde a cinque domande: cosa è successo, come lo abbiamo scoperto, quanto tempo è passato tra ogni fase, cosa ha rallentato la risposta, cosa cambiamo. Ogni azione correttiva ha un responsabile e una scadenza. Conservate il report insieme al registro dell’incidente: serve all’assicurazione, alle autorità e a chi gestirà il prossimo evento.

Il nostro punto di vista

Nel nostro lavoro con le PMI italiane vediamo spesso lo stesso schema. Il piano di risposta esiste, magari scritto per un audit, ma vive in una cartella condivisa che durante un attacco nessuno riesce ad aprire. I nomi sono quelli di due anni fa, i fornitori sono cambiati, le scadenze NIS2 non ci sono.

Per noi un piano di risposta è uno strumento operativo, non un adempimento. Deve parlare la lingua dei processi reali dell’azienda: la linea di produzione, il magazzino, il gestionale, la reception di un hotel o l’agenda di uno studio dentistico. Per questo lo costruiamo partendo dall’inventario di ciò che conta davvero per l’operatività, e lo leghiamo alle misure richieste da GDPR, ISO 27001 e NIS2.

Il vero bivio non è tra uomo e macchina, ma tra un’innovazione subita e una guidata con consapevolezza. Vale anche per la sicurezza: un incidente subito senza piano costa più di quanto serva per prepararsi. Noi scegliamo la seconda strada, e aiutiamo i nostri clienti a fare lo stesso.

— Ufficio

Se volete partire da una base concreta, il nostro servizio di cybersecurity per PMI affianca l’azienda nell’adeguamento NIS2, ISO 27001 e GDPR: valutazione iniziale, definizione dei processi di gestione degli incidenti e protezione dei dati, con prodotti e competenze sviluppati interamente in Italia. Per capire se è il momento giusto, leggete anche quando serve una consulenza cybersecurity.

Domande frequenti

Una piccola impresa fuori dal perimetro NIS2 ha bisogno di un piano di risposta?

Sì. Il GDPR si applica a ogni azienda che tratta dati personali, e la notifica al Garante entro 72 ore vale anche per una PMI con dieci dipendenti. Oltre all’obbligo, un piano riduce i tempi di fermo e i costi di un attacco, che per una piccola impresa possono essere difficili da assorbire.

Ogni quanto va aggiornato il piano?

Almeno una volta l’anno e comunque dopo ogni incidente reale, ogni esercitazione e ogni cambiamento rilevante: nuovi sistemi, nuovi fornitori, persone che cambiano ruolo. La rubrica dei contatti va controllata più spesso, perché è la parte che invecchia per prima.

Qual è la differenza tra piano di risposta agli incidenti e disaster recovery?

Il piano di risposta gestisce l’attacco: lo riconosce, lo contiene e lo elimina. Il disaster recovery riporta in funzione sistemi e dati dopo il danno. I due documenti lavorano insieme: la fase di ripristino del piano di risposta si appoggia sulle procedure di disaster recovery.

Quanto dura un’esercitazione tabletop?

Per una PMI bastano in genere due o tre ore, compresa la discussione finale. Conta più la qualità dello scenario e la presenza delle persone giuste che la durata. Il risultato atteso è un elenco di lacune con un responsabile per ciascuna.

Cosa succede se notifico il data breach al Garante ma non avviso i clienti?

Se la violazione comporta un rischio elevato per le persone, la comunicazione agli interessati è un obbligo distinto dalla notifica all’autorità. Il Garante ha già sanzionato aziende che avevano notificato nei termini ma informato gli interessati in ritardo. In caso di dubbio, fate valutare subito il rischio al DPO.

Fonti

• ACN, Linee guida NIS: definizione del processo di gestione degli incidenti
• ACN, Domini della cybersicurezza: Event, Threat and Incident Management
• ACN, Modalità e specifiche di base NIS
• Garante Privacy, Data breach: violazioni di dati personali
• Garante Privacy, Newsletter del 21 maggio 2026
• ioProgrammo, NIS2 e automazione industriale
• CISA, Incident Response Plan Basics
• CISA, Cybersecurity Tabletop Exercise Tips
• CISA, Tabletop Exercise Packages
• NIST CSRC, Tabletop Exercise: glossario
• Governo del Canada, Develop an Incident Response Plan

Raccomandati

• Best practice backup per PMI: guida operativa
• Analisi rischi informatici PMI efficace
• PMI: valutare il rischio cyber in 5 passaggi con BIA e impatto econ
• Migliori soluzioni disaster recovery per PMI