Immagina: è lunedì mattina, un dipendente chiama in panico perché i file del server sono tutti criptati. Ransomware. E tu non sai da dove cominciare. Chi chiami? Stacchi tutto? Paghi il riscatto? Chiami la polizia? Senza un piano scritto, il panico prende il sopravvento e un incidente gestibile in ore diventa un disastro da settimane. Il dato è impietoso: solo il 14% delle PMI europee ha un piano di risposta agli incidenti (fonte ENISA), mentre gli attacchi alle PMI italiane sono cresciuti del 65% nel 2025. Questa guida ti mostra come creare un Incident Response Plan (IRP) — il tuo “piano di emergenza informatico” — pragmatico, testabile e conforme alla NIS2. Fa parte del percorso sulla cybersecurity per PMI.
Indice dei Contenuti
- 1. Perché Ogni PMI Ha Bisogno di un IRP
- 2. Le 6 Fasi NIST dell'Incident Response
- 3. Template IRP per PMI: Struttura e Contenuti
- 4. Ruoli e Responsabilità del Team di Risposta
- 5. Communication Plan: Chi Avvisare e Quando
- 6. I 7 Errori Più Comuni nell'Incident Response
- 7. Compliance NIS2: Obblighi di Notifica
- 8. Domande Frequenti
Perché Ogni PMI Ha Bisogno di un Incident Response Plan
Un Incident Response Plan è semplicemente un documento che dice cosa fare, chi chiamare e come muoversi quando qualcosa va storto con la sicurezza informatica. È la differenza tra reagire con metodo e limitare i danni, oppure farsi travolgere dal panico e peggiorare la situazione.
Con IRP vs senza IRP: il confronto
Con un IRP documentato e testato
- Tempo medio di contenimento: 75 giorni
- Costo medio dell'incidente: €28.000
- Notifica GDPR entro 72 ore: rispettata
Senza un IRP
- Tempo medio di contenimento: 280 giorni
- Costo medio dell'incidente: €68.000
- Notifica GDPR: spesso in ritardo
I numeri parlano chiaro: avere un piano testato dimezza i costi di un incidente e taglia i tempi di contenimento del 73%. Come spiego nella guida cybersecurity PMI, l'incident response è uno degli investimenti con il ritorno più alto in assoluto.
Le 6 Fasi NIST dell'Incident Response
Il NIST (l'ente americano di standardizzazione) ha definito 6 fasi per gestire un incidente informatico (SP 800-61 Rev. 3). Sembra roba da multinazionale, ma funziona benissimo anche per una PMI da 20 persone:
Fase 1: Preparazione
La preparazione è il 90% del lavoro. Include: inventario degli asset critici (server, database, applicativi), definizione del team di risposta e dei contatti di emergenza, predisposizione degli strumenti (EDR, backup, VPN di emergenza), formazione del personale e test periodici. Una PMI ben preparata può rispondere a un incidente in ore, non settimane.
- Inventario asset critici con classificazione di severità
- Contatti di emergenza (MSP, legale, assicurazione cyber, Garante Privacy)
- Strumenti pre-configurati: EDR, backup verificato, VPN di emergenza
- Runbook per i 5 scenari più probabili (ransomware, phishing, data breach, DDoS, insider threat)
Fase 2: Identificazione
Rilevare e classificare l'incidente: è un falso allarme, un incidente minore o una crisi? L'identificazione rapida dipende dagli strumenti di monitoraggio: EDR, SIEM, log analysis, alert di sicurezza. Senza monitoraggio proattivo, molti incidenti vengono scoperti settimane dopo — quando il danno è già fatto.
- Definisci cosa costituisce un “incidente” vs un “evento”
- Classifica la severità: Bassa, Media, Alta, Critica
- Implementa monitoraggio 24/7 con un servizio SOC/MDR
- Canale di segnalazione rapido per tutti i dipendenti
Fase 3: Contenimento
Fermare l'emorragia senza distruggere le prove. Il contenimento ha due livelli: a breve termine (isola il sistema compromesso dalla rete) e a lungo termine (patcha la vulnerabilità, cambia credenziali, implementa blocchi). Errore critico: spegnere i server. Così perdi le evidenze in RAM necessarie per l'analisi forense.
- Contenimento a breve: isolamento rete, disattivazione account compromessi
- Contenimento a lungo: patching, cambio credenziali, blocco IP malevoli
- Preserva le evidenze forensi: NON spegnere, NON reinstallare
- Documenta ogni azione con timestamp
Fase 4: Eradicazione
Eliminare la causa dell'incidente: rimuovi il malware, patcha la vulnerabilità sfruttata, chiudi le backdoor installate dall'attaccante, cambia tutte le credenziali che potrebbero essere state compromesse. Questa fase richiede competenze specialistiche: un MSP con esperienza di incident response è fondamentale.
- Rimozione completa del malware (non basta cancellare un file)
- Patching della vulnerabilità che ha permesso l'accesso iniziale
- Verifica di backdoor e persistence mechanism
- Reset credenziali di tutti gli account potenzialmente compromessi
Fase 5: Ripristino
Riportare i sistemi alla normalità in modo sicuro. Ripristina da backup verificati (attenzione: se il backup è stato compromesso, stai ripristinando il problema). Monitora intensivamente per 30-60 giorni dopo il ripristino per individuare ricorrenze. Il ripristino graduale è preferibile: prima i sistemi critici, poi gli altri.
- Ripristino da backup verificato (testa PRIMA di mettere in produzione)
- Ripristino graduale: prima i servizi critici, poi gli altri
- Monitoraggio intensivo per 30-60 giorni post-ripristino
- Validazione dell'integrità dei dati ripristinati
Fase 6: Lezioni Apprese
La fase più trascurata e una delle più importanti. Entro 2 settimane dall'incidente, riunisci il team per un'analisi post-mortem: cosa ha funzionato, cosa no, cosa migliorare. Documenta tutto e aggiorna l'IRP. Le aziende che conducono post-mortem rigorosi riducono il rischio di incidenti ricorrenti dell'80%.
- Meeting post-mortem entro 2 settimane (senza colpevolizzare)
- Documentazione completa: timeline, azioni, decisioni, risultati
- Aggiornamento dell'IRP con le lezioni apprese
- Formazione specifica sulle lacune emerse
Template IRP per PMI: Struttura e Contenuti
Tranquillo, un IRP per una PMI non è un mattone da 100 pagine. Deve essere corto, pratico e aggiornato. Ecco come strutturarlo:
Scopo e ambito
Definisci cosa copre il piano: quali sistemi, quali tipi di incidente, chi è coinvolto. 1 pagina.
Definizioni e classificazione
Cosa è un “incidente” vs un “evento”. 4 livelli di severità con criteri chiari. 1 pagina.
Ruoli e responsabilità
Chi fa cosa durante l'incidente. Contatti di emergenza. Escalation matrix. 2 pagine.
Procedure per scenari
Runbook specifici per ransomware, phishing/BEC, data breach, DDoS, insider threat. 5-10 pagine.
Communication plan
Chi avvisare, quando, come. Template email/comunicazioni. 2 pagine.
Contatti di emergenza
MSP, legale, assicurazione cyber, CSIRT Italia, Garante Privacy, forze dell'ordine. 1 pagina.
Appendici
Inventario asset, diagramma di rete, checklist operative, template notifica GDPR/NIS2. 3-5 pagine.
Totale: 15-20 pagine. Non di più. Il punto è che deve essere un documento vivo: aggiornalo almeno una volta l'anno e dopo ogni incidente. Se vuoi una mano a scriverlo, lo facciamo come parte della consulenza IT e della sicurezza informatica.
Ruoli e Responsabilità del Team di Risposta
Anche con 20 dipendenti servono ruoli chiari. Non devi assumere nessuno: basta decidere in anticipo chi fa cosa quando succede il guaio.
Incident Commander (IC)
Coordina la risposta, prende le decisioni critiche, comunica con la direzione. Di solito: il responsabile IT o il titolare. In una PMI senza IT interno, questo ruolo è svolto dall'MSP.
Technical Lead
Gestisce le operazioni tecniche: isolamento, analisi, eradicazione, ripristino. Di solito: il tecnico IT senior o l'MSP. Deve avere accesso admin a tutti i sistemi critici.
Communication Lead
Gestisce le comunicazioni interne (dipendenti) ed esterne (clienti, fornitori, autorità, media). Di solito: il responsabile marketing/comunicazione o il titolare.
Legal/Compliance Lead
Valuta gli obblighi legali: notifica GDPR al Garante Privacy (72 ore), notifica NIS2 al CSIRT (24 ore), comunicazione agli interessati, rapporti con le forze dell'ordine. Di solito: consulente legale esterno + DPO.
Se non hai un reparto IT interno, un MSP come BullTech fa da Incident Commander e Technical Lead per te. Il nostro servizio di SOC/MDR include monitoraggio 24/7 e gestione degli incidenti: quando succede qualcosa, ci siamo già noi.
Communication Plan: Chi Avvisare e Quando
Comunicare bene durante un incidente è importante quanto risolverlo tecnicamente. Se avvisi tardi, dici cose sbagliate o crei confusione, il danno alla reputazione peggiora e rischi anche sanzioni legali.
| Chi avvisare | Quando | Come |
|---|---|---|
| MSP / Team IT | Immediatamente | Telefono + email encrypted |
| Direzione aziendale | Entro 1 ora | Telefono diretto |
| Consulente legale / DPO | Entro 4 ore | Telefono + email encrypted |
| Garante Privacy (se dati personali) | Entro 72 ore | Portale telematico del Garante |
| CSIRT Italia (se soggetti NIS2) | Entro 24 ore (alert iniziale) | Portale CSIRT + email PEC |
| Clienti / fornitori coinvolti | Dopo la valutazione legale | Email + comunicazione dedicata |
| Assicurazione cyber | Entro 24-48 ore | Secondo le condizioni di polizza |
| Forze dell'ordine (se reato) | Dopo consulenza legale | Polizia Postale / Carabinieri |
I 7 Errori Più Comuni nell'Incident Response
In anni di gestione incidenti per PMI in Lombardia, vediamo sempre gli stessi errori. Eccoli, così li eviti:
1. Spegnere i server per “fermare l'attacco”
Spegnendo il server perdi le evidenze in RAM (processi in esecuzione, connessioni di rete) essenziali per l'analisi forense. Isola dalla rete, non spegnere.
2. Pagare il riscatto ransomware
Nel 40% dei casi non ricevi la chiave di decrittazione. Nel 60% vieni re-attaccato entro 6 mesi. Finanzi organizzazioni criminali. Il backup immutabile è l'alternativa.
3. Nascondere l'incidente
Tentare di risolvere in silenzio porta a ritardi nella risposta, violazione degli obblighi GDPR/NIS2 e sanzioni molto più severe. La trasparenza è sempre la scelta migliore.
4. Comunicare troppo presto (e male)
Inviare un'email a tutti i clienti 30 minuti dopo l'incidente, senza aver capito cosa è successo, causa panico inutile. Prima analizza, poi comunica con informazioni verificate.
5. Non preservare le evidenze
Reinstallare il sistema operativo, cancellare i log, formattare il disco: ogni azione distrugge prove che servono per capire cosa è successo e chi è responsabile.
6. Colpevolizzare il dipendente
Il dipendente che ha cliccato sul phishing è una vittima, non il colpevole. Colpevolizzare crea una cultura del silenzio dove gli incidenti vengono nascosti.
7. Non fare il post-mortem
Risolvere l'incidente e tornare al “business as usual” senza analizzare cosa è andato storto garantisce che lo stesso incidente si ripeterà.
Compliance NIS2: Obblighi di Notifica degli Incidenti
La Direttiva NIS2 introduce obblighi stringenti di notifica per i soggetti essenziali e importanti. Anche le PMI della supply chain di soggetti NIS2 possono essere coinvolte. Ecco le tempistiche:
Early warning (entro 24 ore)
CRITICONotifica iniziale al CSIRT Italia con le informazioni disponibili: tipo di incidente, sistemi coinvolti, impatto stimato. Non serve un'analisi completa.
Notifica dettagliata (entro 72 ore)
CRITICOAggiornamento con: valutazione iniziale dell'incidente, severità, impatto, indicatori di compromissione (IoC). Se coinvolge dati personali, notifica parallela al Garante Privacy.
Rapporto finale (entro 1 mese)
ALTOReport completo: descrizione dettagliata, causa, azioni di contenimento e eradicazione, impatto effettivo, misure correttive implementate per evitare ricorrenze.
Il mancato rispetto di queste tempistiche comporta sanzioni fino al 2% del fatturato annuo e responsabilità personale dei dirigenti. Un IRP ben strutturato, con i template di notifica già pronti e i contatti del CSIRT, rende la compliance quasi automatica. Approfondisci con la nostra guida su NIS2 e supply chain e il nostro servizio di consulenza GDPR.
Domande Frequenti sull'Incident Response
Quanto tempo serve per creare un Incident Response Plan?
Per una PMI da 20-50 dipendenti, servono 2-4 settimane: la prima per fare l'inventario di cosa hai e capire i rischi, la seconda per scrivere il piano e assegnare i ruoli, la terza per revisione e approvazione, la quarta per formare il team e fare il primo test. Se ti fai aiutare da un MSP come noi, si può fare in 1-2 settimane.
Serve un IRP anche se la mia azienda ha meno di 20 dipendenti?
Sì, anche se siete in 5. Il piano sarà più semplice — magari 3-5 pagine — ma sapere chi chiamare, come isolare un PC compromesso e quando avvisare il Garante Privacy è fondamentale anche per una micro-impresa. Senza un piano scritto, quando succede qualcosa si va nel panico e si fanno scelte che peggiorano le cose.
La NIS2 richiede un Incident Response Plan?
Sì, la Direttiva NIS2 (recepita in Italia nel 2024, con piena applicazione dal 2026) richiede esplicitamente ai soggetti essenziali e importanti di adottare politiche di “gestione degli incidenti” (Art. 21, comma 2, lettera b). Include l'obbligo di notifica degli incidenti significativi entro 24 ore (alert iniziale), 72 ore (notifica dettagliata) e 1 mese (rapporto finale) al CSIRT Italia. Anche le aziende non direttamente soggette alla NIS2 possono essere coinvolte come fornitori di soggetti obbligati.
Ogni quanto devo testare l'Incident Response Plan?
La best practice prevede: un tabletop exercise (simulazione a tavolino) ogni 6 mesi, un test tecnico completo (simulazione di incidente reale) almeno 1 volta l'anno, e una revisione/aggiornamento del piano dopo ogni incidente reale o cambiamento significativo nell'infrastruttura IT. I tabletop exercise sono economici (1-2 ore con il team) e molto efficaci per identificare lacune nel piano. Non dimenticare di aggiornare i contatti di emergenza ogni trimestre.
Cosa succede se non ho un IRP e subisco un attacco?
Succede il caos. Ci metti giorni invece che ore a capire cosa è successo. Le decisioni prese in panico peggiorano le cose (tipo spegnere il server, che cancella le prove forensi). La comunicazione è confusa e fa ulteriori danni alla reputazione. Non rispetti i tempi del GDPR (72 ore per la notifica) e ti becchi sanzioni extra. Risultato: i costi totali dell'incidente aumentano del 40-60%. I numeri: un'azienda senza piano ci mette in media 280 giorni per contenere un breach, contro i 75 di un'azienda preparata.
Un piano di risposta agli incidenti non è un lusso da grande azienda: è il documento che decide se il tuo business sopravvive a un attacco o ne viene travolto. La buona notizia è che non devi farlo da solo. Parliamone — ti aiutiamo a creare il tuo IRP su misura, partendo dalla cybersecurityche hai già.