L'Incident Response Plan (IRP) è uno dei documenti più critici richiesti dalla NIS2. L'Art. 23 del D.Lgs. 138/2024 impone tempi strettissimi di notifica — e senza un piano pre-definito, rispettarli è quasi impossibile. Ma un IRP che rimane nel cassetto non serve a niente: deve essere pratico, testato e conosciuto da chi deve usarlo.
La struttura di un IRP efficace
1. Classificazione della severity
Il primo elemento è una matrice di classificazione chiara. Quanti livelli di severity? Chi decide? In quanto tempo? Senza questa decisione pre-fatta, durante un incidente reale si perde tempo prezioso a discutere di gravità invece di agire.
2. Il team IRT con ruoli chiari
Chi fa cosa durante un incidente deve essere scritto prima che accada. Il CISO coordina. L'IT manager gestisce il contenimento tecnico. Il DPO valuta gli obblighi GDPR. Il management autorizza le spese straordinarie. La comunicazione gestisce clienti e stampa. Ogni ruolo deve avere un sostituto designato.
3. Le procedure fase per fase
L'IRP deve descrivere le azioni concrete per ogni fase: rilevazione → contenimento → eradicazione → ripristino → post-incident review. Non procedure generiche: procedure specifiche per i sistemi e le tecnologie della tua azienda.
4. I template di comunicazione
Preparare in anticipo i template di notifica ACN (prenotifica 24h, notifica 72h, relazione finale) risparmia ore critiche durante l'emergenza. Sapere già cosa scrivere — lasciando solo i dettagli specifici da completare — fa la differenza tra rispettare e non rispettare le scadenze normative.
5. I contatti di emergenza
Una lista aggiornata con i contatti di CSIRT Italia (csirt.gov.it), del provider hosting, del provider cloud, del consulente legale, dell'assicurazione cyber e di eventuali partner di incident response. Numeri di cellulare, non solo email.
Come testarlo: il tabletop exercise
Il modo più efficace per testare un IRP è il tabletop exercise: il team si riunisce e il facilitatore descrive uno scenario di incidente (es. ransomware alle 3 di notte, data breach scoperto da un cliente). I partecipanti discutono le decisioni che prenderebbero. Non serve bloccare i sistemi — basta simulare le decisioni.
Un tabletop di 2-3 ore all'anno è sufficiente per mantenere il piano vivo e identificare i punti deboli prima che diventino problemi reali.
L'errore più comune
Il 90% degli IRP che ho visto ha un problema comune: sono scritti pensando allo scenario ideale (tutti presenti, sistemi funzionanti, informazioni complete). Un buon IRP deve funzionare anche nello scenario peggiore: notte del venerdì, CISO in ferie, sistemi di comunicazione interni compromessi dal ransomware.
