Un piano di incident response che sta in un cassetto non serve a niente. Serve un documento pratico, concreto, che chiunque nella tua azienda può tirare fuori alle 3 di notte e seguire passo dopo passo. Quello che trovi qui è il template che usiamo con i nostri clienti, adattato per le PMI italiane.
Un Incident Response Plan (IRP) non è un documento di conformità da produrre per un auditor. È lo strumento che decide se la tua azienda torna operativa in un giorno o resta ferma per settimane. La differenza tra un'azienda con un IRP testato e una senza è misurabile: i tempi di risposta calano del 50-70%, i costi dell'incidente si riducono fino all'80%.
La NIS2 lo richiede esplicitamente
L'articolo 21 della direttiva NIS2 richiede "la gestione degli incidenti" come una delle 10 misure minime di sicurezza. Per i soggetti essenziali e importanti, un IRP documentato e testato non è più facoltativo.
Sezione 1: Ruoli e Responsabilità
Prima di qualsiasi procedura, servono nomi e cognomi. Non "il reparto IT" o "la direzione". Persone specifiche con numeri di telefono personali, perché durante un incidente l'email aziendale potrebbe non funzionare.
Incident Commander
Prende le decisioni operative durante l'incidente. Di solito è il responsabile IT o il referente MSP. Ha l'autorità di spegnere sistemi, isolare reti, autorizzare spese urgenti.
Team Tecnico
Chi mette le mani sui sistemi: tecnici IT interni, MSP, eventuali specialisti esterni per forensics. Devono avere credenziali di accesso pronte e aggiornate.
Referente Comunicazione
Gestisce la comunicazione verso dipendenti, clienti, fornitori e media. Una sola voce evita messaggi contraddittori che peggiorano la crisi.
Referente Legale/Privacy
DPO o consulente privacy. Gestisce le notifiche al Garante (72 ore GDPR), al CSIRT Italia (NIS2) e coordina con lo studio legale per gli aspetti contrattuali.
Per ogni ruolo, il piano deve contenere: nome, cognome, telefono personale, email alternativa (non aziendale), sostituto designato in caso di assenza. Aggiorna questi dati ogni trimestre.
Sezione 2: Classificazione degli Incidenti
Non tutti gli incidenti sono uguali. Un dipendente che clicca su un link di phishing senza conseguenze non richiede la stessa risposta di un ransomware che cifra il file server. La classificazione serve a calibrare la risposta e a non sprecare risorse.
Critico (Livello 1)
Ransomware attivo, data breach con esfiltrazione dati, compromissione del domain controller, sistemi critici non disponibili. Risposta immediata, coinvolgimento di tutto il team IRP.
Alto (Livello 2)
Account admin compromesso, malware su più endpoint, BEC (Business Email Compromise) con danno economico, accesso non autorizzato ai server. Risposta entro 1 ora, escalation alla direzione.
Medio (Livello 3)
Malware su singolo endpoint (contenuto), phishing con click ma senza compromissione, accesso sospetto bloccato da MFA, tentativo DDoS mitigato. Risposta entro 4 ore.
Basso (Livello 4)
Email di phishing ricevuta e segnalata senza click, scansione porte dall'esterno, tentativo di login fallito da IP sconosciuto. Gestione ordinaria, documentazione e monitoraggio.
Sezione 3: Procedure di Escalation
L'escalation non è un segno di debolezza, è un segno di maturità. Il template prevede una catena chiara che evita due problemi: sottovalutare un incidente grave o sovrareagire a un falso allarme.
Chi avvisa chi, e quando
- Qualsiasi dipendente che nota un'anomalia (file cifrati, comportamento strano del PC, email sospetta con conseguenze) avvisa il referente IT o chiama il numero di emergenza MSP
- Referente IT / MSP valuta la classificazione, attiva l'Incident Commander se Livello 1 o 2
- Incident Commander avvisa la direzione se Livello 1 o 2, attiva il referente legale/privacy se ci sono dati personali coinvolti
- Direzione autorizza la comunicazione esterna se necessaria, contatta l'assicurazione cyber
Il tempo massimo tra la scoperta e l'attivazione dell'Incident Commander deve essere 15 minuti per incidenti critici, 1 ora per incidenti di livello alto. Se il referente IT non risponde entro 10 minuti, il sostituto designato prende il suo posto.
Sezione 4: Checklist per Tipo di Incidente
Ogni tipo di incidente richiede azioni specifiche. Queste checklist sono pensate per essere seguite da chiunque, anche sotto stress. Ogni voce è un'azione concreta, non un principio generico.
Checklist Ransomware
Per la procedura dettagliata minuto per minuto, leggi la nostra guida Attacco Ransomware: I Primi 60 Minuti. In sintesi:
- Isola le macchine dalla rete (NON spegnere)
- Disconnetti backup e NAS raggiungibili via rete
- Chiama MSP / team IR
- Identifica il tipo di ransomware e lo scope
- Verifica integrità dei backup
- Preserva le prove (screenshot, log, ransom note)
- Avvia il ripristino dai backup verificati
- Notifica Garante Privacy entro 72 ore se dati personali coinvolti
- Denuncia alla Polizia Postale
Checklist Data Breach
- Identifica quali dati sono stati esfiltrati o esposti
- Chiudi il vettore di accesso (revoca credenziali, patch vulnerabilità)
- Valuta il rischio per gli interessati (dipendenti, clienti, fornitori)
- Documenta tutto per la notifica al Garante
- Notifica al Garante Privacy entro 72 ore (GDPR art. 33)
- Comunica agli interessati se rischio elevato (GDPR art. 34)
- Verifica se dati sono in vendita su dark web
- Implementa misure correttive per prevenire recidive
Checklist Business Email Compromise (BEC)
- Blocca l'account compromesso
- Verifica regole di inoltro create dall'attaccante
- Controlla email inviate dall'account compromesso (fatture false?)
- Avvisa colleghi e clienti potenzialmente raggiunti da email fraudolente
- Se sono stati effettuati bonifici fraudolenti, contatta la banca immediatamente
- Attiva MFA sull'account e su tutti gli account non ancora protetti
- Verifica accessi in Azure AD / Microsoft 365 audit log
- Resetta la password e revoca tutti i token di sessione
Checklist Phishing con Conseguenze
- Se l'utente ha inserito credenziali: cambia password subito, attiva MFA
- Se l'utente ha aperto un allegato: scansione EDR dell'endpoint, isola se positivo
- Verifica se altri utenti hanno ricevuto la stessa email
- Blocca il mittente e i domini malevoli su email gateway e firewall
- Aggiorna le regole di filtraggio email
- Usa l'incidente come caso formativo (senza colpevolizzare)
Checklist DDoS
- Verifica la portata dell'attacco (volumetrico, applicativo?)
- Attiva le protezioni anti-DDoS del firewall o del provider
- Se hai un CDN (Cloudflare, Akamai): attiva la modalità under attack
- Contatta il provider internet per filtraggio a monte
- Monitora la situazione e documenta gli IP sorgente
- Valuta se il DDoS è una diversione per un attacco più sofisticato in corso
Sezione 5: Piano di Comunicazione
La comunicazione durante un incidente è tanto importante quanto la risposta tecnica. Messaggi sbagliati amplificano il danno: i clienti perdono fiducia, i dipendenti si agitano, i media costruiscono narrazioni peggiori della realtà.
Comunicazione interna
I dipendenti devono sapere cosa sta succedendo, cosa devono fare (o non fare) e a chi rivolgersi. Un messaggio chiaro e tempestivo via canale alternativo (gruppo WhatsApp personale, SMS, chiamata) previene il panico e le azioni avventate.
Template di comunicazione interna:
"Stiamo gestendo un incidente informatico. Per precauzione, NON accendete i computer e NON collegatevi alla rete aziendale fino a nuova comunicazione. Il team tecnico sta lavorando al ripristino. Per domande urgenti, contattate [nome] al [numero]. Vi aggiorneremo entro [ora]."
Comunicazione verso clienti e fornitori
Se l'incidente impatta i servizi ai clienti o coinvolge dati di terzi, la comunicazione deve essere trasparente, tempestiva e factual. Niente minimizzazioni, niente promesse che non puoi mantenere. I clienti perdonano gli incidenti, non le bugie.
Comunicazione verso autorità
- Garante Privacy: notifica entro 72 ore se dati personali coinvolti (modulo online sul sito del Garante)
- CSIRT Italia: segnalazione per soggetti NIS2 (portale CSIRT)
- Polizia Postale: denuncia/querela per reati informatici
- Assicurazione cyber: notifica secondo i termini della polizza
Sezione 6: Contatti di Emergenza
Questa pagina va stampata e appesa in sala server, negli uffici IT e distribuita ai responsabili di ogni sede. Durante un incidente, cercare un numero di telefono può costare minuti preziosi.
MSP / Supporto IT
Nome azienda, numero emergenza H24, email supporto, referente tecnico dedicato
Direzione Aziendale
CEO/Amministratore, telefono personale, sostituto designato
DPO / Consulente Privacy
Nome, telefono, email. Responsabile notifiche al Garante
Studio Legale
Riferimento per aspetti contrattuali, responsabilità verso terzi, contenzioso
Assicurazione Cyber
Compagnia, numero polizza, numero verde sinistri, broker di riferimento
CSIRT Italia
Portale: csirt.gov.it | Email: csirt@pec.acn.gov.it
Garante Privacy
Portale notifiche data breach: servizi.gpdp.it/databreach
Polizia Postale
Commissariato online: commissariatodips.it | Numero locale
Sezione 7: Post-Incident Review
Ogni incidente è un'opportunità per migliorare. La post-incident review va condotta entro 2 settimane dall'incidente, con tutti i coinvolti. Non è una caccia al colpevole: è un processo strutturato per imparare.
Template della review
- Timeline dell'incidente: cosa è successo, quando, in che ordine
- Causa principale (root cause): come è entrato l'attaccante, quale vulnerabilità è stata sfruttata
- Cosa ha funzionato: procedure seguite correttamente, tempi di risposta rispettati
- Cosa non ha funzionato: ritardi, errori, procedure mancanti
- Impatto: downtime totale, dati persi, costo economico stimato
- Azioni correttive: cosa va cambiato nel piano, nella tecnologia, nella formazione
- Responsabile e deadline per ogni azione correttiva
Un Piano Non Testato Non È un Piano
Questo è il punto più importante dell'intero articolo. Un IRP scritto e dimenticato in un cassetto è inutile come un estintore scarico. Il piano va testato, e va testato regolarmente.
Il dato che fa riflettere
Il 78% delle PMI che hanno subito un attacco ransomware aveva un piano di incident response. Ma solo il 12% lo aveva testato almeno una volta nell'ultimo anno. Le aziende con piani testati hanno recuperato in media in 2 giorni, quelle senza test in 23 giorni.
Come testare il piano: Esercitazione Tabletop
Un'esercitazione tabletop è una simulazione a tavolino. Riunisci il team IRP e presenta uno scenario ipotetico: "È venerdì sera, i server sono cifrati, il backup più recente ha 48 ore. Cosa facciamo?"
Ogni partecipante descrive le azioni che prenderebbe secondo il piano. Le lacune emergono subito: numeri di telefono sbagliati, procedure ambigue, ruoli non chiari, backup non verificati. Meglio scoprirlo in una riunione che durante un vero attacco.
Frequenza consigliata: almeno una tabletop all'anno, idealmente ogni sei mesi con scenari diversi (ransomware, data breach, BEC). Dopo ogni test, aggiorna il piano con le lezioni apprese.
Come BullTech Ti Aiuta con l'Incident Response
Costruire un IRP da zero richiede esperienza specifica che la maggior parte delle PMI non ha internamente. Come MSP, noi di BullTech includiamo la creazione e il test dell'IRP nel contratto di assistenza:
Stesura del piano personalizzato
Non un template generico, ma un IRP calibrato sulla tua infrastruttura, i tuoi sistemi, il tuo settore e le normative che ti riguardano (NIS2, GDPR, ISO 27001).
Esercitazioni tabletop annuali
Simulazioni con scenari realistici, coinvolgendo il tuo team e il nostro. Ogni esercitazione genera un report con gap identificati e azioni correttive.
Risposta H24 in caso di incidente reale
Quando la telefonata arriva, il nostro team tecnico interviene immediatamente. Monitoraggio con Atera, contenimento, analisi forense e ripristino.
Backup Veeam con restore testato
Il piano migliore del mondo non serve se il backup non funziona. Test di restore trimestrali documentati, copie immutabili e replica off-site in cloud.
Aggiornamento continuo del piano
Il piano viene aggiornato a ogni modifica dell'infrastruttura, dopo ogni incidente e dopo ogni esercitazione. Un piano statico diventa obsoleto in 6 mesi.
Domande Frequenti
Cos'è un Incident Response Plan?
Un Incident Response Plan (IRP) è un documento che descrive le procedure da seguire quando si verifica un incidente di sicurezza informatica. Definisce ruoli, responsabilità, procedure di escalation e checklist operative per ogni tipo di incidente.
Ogni PMI ha bisogno di un Incident Response Plan?
Sì. Il 43% degli attacchi informatici colpisce le PMI, e la direttiva NIS2 richiede un piano di gestione degli incidenti. Anche senza obblighi normativi, un IRP riduce i tempi di risposta del 50-70% e limita i danni economici.
Ogni quanto va testato il piano?
Almeno una volta l'anno con un'esercitazione tabletop. Idealmente ogni sei mesi con scenari diversi. Dopo ogni incidente reale va rivisto e aggiornato.
Chi deve essere coinvolto nel team di incident response?
Il team minimo include: un Incident Commander, il referente IT/MSP, un rappresentante della direzione, il DPO o referente privacy e un referente comunicazione.
Quanto costa creare un Incident Response Plan?
Con un MSP come BullTech, l'IRP è generalmente incluso nel contratto di assistenza. Da un consulente esterno, il costo varia da 2.000 a 8.000 euro. Il costo di NON averlo è molto più alto: un incidente mal gestito costa 10-50 volte di più.