"Non è questione di se verrai attaccato, ma di quando". Questo mantra della cybersecurity è particolarmente vero per le PMI italiane, che nel 2025 hanno subito un aumento del 65% degli attacchi. Eppure, secondo una ricerca ENISA, solo il 14% delle PMI europee ha un piano di risposta agli incidenti documentato. Senza un piano, un incidente che potrebbe essere gestito in ore diventa un disastro che si protrae per settimane. Questa guida, parte del nostro percorso sulla cybersecurity per PMI, ti mostra come creare un Incident Response Plan (IRP) pragmatico, testabile e conforme alla NIS2.
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 è un documento operativo che descrive cosa fare, chi chiamare e come agire quando si verifica un incidente di sicurezza informatica. È la differenza tra una risposta coordinata che limita il danno e il panico totale che lo amplifica.
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 non mentono: un IRP testato dimezza i costi di un incidente e riduce i tempi di contenimento del 73%. Come descritto nella nostra guida cybersecurity PMI, la pianificazione dell'incident response è il decimo step della checklist di sicurezza, ma il suo impatto economico è tra i più alti.
Le 6 Fasi NIST dell'Incident Response
Il framework NIST SP 800-61 Rev. 3 definisce 6 fasi per la gestione degli incidenti. Anche per una PMI con risorse limitate, questo framework è la base più solida per strutturare il proprio IRP:
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
Un IRP efficace per una PMI non deve essere un documento di 100 pagine. Deve essere conciso, pratico e aggiornato. Ecco la struttura raccomandata:
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 per un IRP completo. Deve essere un documento vivo, aggiornato almeno annualmente e dopo ogni incidente. BullTech offre la creazione dell'IRP come parte del servizio di consulenza IT e sicurezza informatica.
Ruoli e Responsabilità del Team di Risposta
Anche una PMI con 20 dipendenti ha bisogno di ruoli definiti. Non servono figure dedicate a tempo pieno: basta assegnare le responsabilità a persone specifiche che sapranno cosa fare in caso di emergenza.
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.
Per le PMI senza un reparto IT interno, un MSP come BullTech funge da Incident Commander e Technical Lead, garantendo competenze specialistiche e tempi di risposta rapidi. Il nostro servizio di SOC/MDR include il monitoraggio 24/7 e l'incident response come servizio.
Communication Plan: Chi Avvisare e Quando
La comunicazione durante un incidente è tanto critica quanto la risposta tecnica. Una comunicazione tardiva, incompleta o caotica amplifica il danno reputazionale e può portare a 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
Dopo anni di incident response per PMI lombarde, ecco gli errori che vediamo ripetersi. Conoscerli è il primo passo per evitarli:
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, un IRP efficace può essere creato in 2-4 settimane: 1 settimana per l'assessment e l'inventario degli asset, 1 settimana per la stesura del piano e l'assegnazione dei ruoli, 1 settimana per la revisione e l'approvazione, 1 settimana per la formazione del team e il primo test. Con il supporto di un MSP specializzato, il processo può essere accelerato a 1-2 settimane.
Serve un IRP anche se la mia azienda ha meno di 20 dipendenti?
Sì, anche una micro-impresa ha bisogno di un piano di risposta agli incidenti, seppure semplificato. Anche con 5 dipendenti, sapere chi chiamare, come isolare un sistema compromesso e quando notificare il Garante Privacy è fondamentale. Senza un piano, il panico prende il sopravvento e le decisioni sbagliate aggravano il danno. Un IRP base per una micro-impresa può essere un documento di 3-5 pagine con le procedure essenziali e i numeri di emergenza.
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?
Senza un piano strutturato, le conseguenze sono drammaticamente peggiori: il tempo di rilevamento e risposta si allunga (giorni invece che ore), le azioni improvvisate spesso aggravano il danno (es. spegnere il server cancella le evidenze forensi), la comunicazione caotica causa danni reputazionali aggiuntivi, il mancato rispetto delle tempistiche di notifica GDPR (72 ore) porta a sanzioni aggiuntive, e i costi totali dell'incidente aumentano del 40-60% rispetto ad aziende con un IRP testato. In media, un'azienda senza IRP impiega 280 giorni per contenere un breach, contro i 75 giorni di un'azienda preparata.
Un Incident Response Plan non è un lusso: è una necessità operativa e un obbligo normativo. La differenza tra un'azienda che sopravvive a un attacco e una che ne viene travolta sta nella preparazione. Contattaci per creare il tuo IRP personalizzato con il supporto dei nostri esperti di cybersecurity.