Molte aziende hanno un piano di risposta agli incidenti informatici. Poche lo hanno davvero testato. Ancora meno lo aggiornano con continuità. Quando un attacco ransomware blocca i sistemi di produzione o un accesso non autorizzato compromette l’archivio clienti, la differenza tra un piano funzionante e un documento fermo in una cartella condivisa diventa immediatamente evidente.

Secondo il Cost of a Data Breach Report 2024 di IBM, il costo medio di una violazione dei dati in Italia ha raggiunto i 4,37 milioni di euro nel 2024, con un incremento del 23% rispetto al 2023, il maggior aumento registrato dai tempi della pandemia. Parte di questo costo è direttamente legata al tempo che intercorre tra l’inizio dell’incidente e il suo contenimento: le aziende italiane analizzate hanno impiegato in media 218 giorni per identificare e contenere gli incidenti.

Un piano di risposta strutturato e operativo non elimina il rischio di subire un incidente, ma riduce l’impatto economico, operativo e reputazionale quando questo si verifica.

Cosa si intende per incidente informatico

Un evento di sicurezza è qualsiasi accadimento osservabile che potrebbe avere implicazioni per la sicurezza dei sistemi o dei dati. Un incidente è un evento che ha effettivamente compromesso, o ha la ragionevole probabilità di compromettere, la riservatezza, l’integrità o la disponibilità delle informazioni e dei sistemi.

La distinzione è rilevante per due ragioni. Sul piano operativo, definisce quando attivare il piano e con quale livello di escalation. Sul piano normativo, determina quando scattano gli obblighi di notifica previsti da NIS2 e GDPR, che saranno trattati più avanti.

Il modello di riferimento più consolidato a livello internazionale è quello del NIST, aggiornato ad aprile 2025 con la pubblicazione della Special Publication 800-61 Revision 3. Questa nuova versione allinea la gestione degli incidenti alle sei funzioni del NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond, Recover. Riconosce che la risposta agli incidenti non è più un insieme discreto di attività circoscritte ai giorni immediatamente successivi all’evento, ma parte integrante della gestione continuativa del rischio cyber.

Le tipologie di incidente più comuni in contesti aziendali includono: accessi non autorizzati a sistemi o dati, infezioni da malware o ransomware, esfiltrazione di dati, attacchi di tipo denial of service che impattano la continuità operativa, compromissione di credenziali, e incidenti originati da fornitori terzi o dalla supply chain.

Gli obblighi normativi: NIS2, GDPR e le tempistiche

La gestione degli incidenti non è più una scelta organizzativa opzionale. Per le organizzazioni soggette alla Direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024 e operativa dal 15 gennaio 2026, le tempistiche di notifica sono vincolanti e le sanzioni per il mancato rispetto sono significative.

La procedura di notifica NIS2 si articola in tre fasi, come riportato nell’art. 25 del D.Lgs. 138/2024 in Gazzetta Ufficiale: pre-notifica al CSIRT Italia entro 24 ore dalla rilevazione dell’incidente significativo, notifica completa con valutazione iniziale di gravità, impatti e indicatori di compromissione entro 72 ore, e relazione finale entro un mese dalla notifica a 72 ore.

Queste tempistiche si sommano con altri obblighi paralleli: nei casi in cui l’incidente comporti una violazione di dati personali, permane l’obbligo di notifica separata al Garante per la Protezione dei Dati Personali entro 72 ore dalla conoscenza della violazione, previsto dall’articolo 33 del GDPR. Le due notifiche sono indipendenti e possono essere entrambe necessarie per lo stesso incidente. La gestione coordinata richiede processi maturi e un piano che preveda esplicitamente questo scenario.

Un incident response plan che non integra le procedure di notifica normativa non è adeguato agli obblighi vigenti. La pre-notifica entro 24 ore richiede che al momento dell’incidente siano già definiti i processi di classificazione, escalation e comunicazione. Non è possibile costruirli durante la crisi.

Piano di risposta agli incidenti: cosa contiene il documento

Il piano di risposta agli incidenti è un documento operativo che definisce come un’organizzazione rileva, gestisce e si riprende da un incidente di sicurezza informatica. Descrive ruoli, responsabilità, procedure operative e criteri di notifica. Per essere efficace deve essere aggiornato, testato e compreso da chi lo utilizzerà. Un incident response plan ben costruito include almeno questi elementi:

• Politica e scopo. Una dichiarazione formale dell’impegno dell’organizzazione nella gestione degli incidenti, con il perimetro di applicazione chiaramente definito.

• Definizioni operative. Cosa si intende per evento, incidente, incidente significativo. Scala di gravità con criteri espliciti per ogni livello.

• Ruoli e responsabilità. Chi compone il team di risposta, chi ha autorità decisionale nelle diverse fasi, chi deve essere notificato e quando. Il NIST raccomanda di estendere il perimetro del team ben oltre il gruppo tecnico, includendo la direzione aziendale, i team legali, le risorse umane e le relazioni pubbliche, e prevede la possibilità di un modello a responsabilità condivisa in cui parte delle operazioni è affidata a terze parti specializzate.

• Procedure operative per tipologia di incidente. Playbook specifici per ransomware, phishing, accesso non autorizzato, data breach, attacchi alla supply chain. Le procedure generiche non bastano sotto pressione.

• Contatti e canali di comunicazione. Numeri di emergenza interni, contatti con il fornitore di incident response, riferimenti delle autorità competenti (CSIRT Italia, Garante Privacy), contatti legali.

• Gestione delle evidenze. Procedure per la raccolta, conservazione e catena di custodia delle prove digitali, necessarie sia per l’analisi interna sia per eventuali procedimenti legali.

• Comunicazione esterna. Criteri e procedure per la comunicazione verso clienti, partner, media e autorità. Chi può parlare, cosa può dire, in quale momento.

• Criteri di escalation e chiusura. Quando un incidente viene classificato come risolto e con quali verifiche. Chi ha autorità per dichiarare la chiusura formale.

Perchè un documento non basta

Il problema più frequente non è l’assenza di un piano, ma la sua inutilizzabilità nel momento critico. Un documento redatto anni prima, mai revisionato, con riferimenti a sistemi dismessi, a persone che non lavorano più in azienda o a procedure che non corrispondono all’infrastruttura attuale, è peggio di nessun piano: genera falsa sicurezza.

Un incident response plan efficace è uno strumento operativo, non un adempimento formale. Deve essere compreso dalle persone che lo useranno, testato in condizioni realistiche e aggiornato ogni volta che cambia qualcosa di rilevante nell’organizzazione o nell’infrastruttura tecnologica.

Il NIST raccomanda che le procedure siano testate o esercitate periodicamente per verificarne l’accuratezza e possano essere utilizzate per formare il personale nuovo. Non si tratta di un suggerimento accessorio: è il presupposto perché il piano funzioni sotto pressione.

Come testare il piano: dal tabletop exercise alla simulazione completa

Un piano non testato è un piano non validato. Il test non è un’attività straordinaria: dovrebbe essere pianificata con cadenza regolare, almeno annuale, e ogni volta che il piano viene aggiornato in modo significativo. Esistono diversi livelli di test, con complessità crescente. La revisione documentale verifica la coerenza interna del piano: le procedure sono aggiornate? I contatti sono corretti? I playbook coprono gli scenari più probabili? È il livello minimo, ma non sufficiente da solo.

Il tabletop exercise è una simulazione verbale guidata: il team di risposta viene posto di fronte a uno scenario realistico e deve dichiarare le azioni che intraprende, passo dopo passo. Non si opera sui sistemi, ma si valutano i processi decisionali, le lacune procedurali e i punti di frizione tra funzioni diverse. È lo strumento più adatto per coinvolgere il management e le funzioni non tecniche.

Le simulazioni funzionali testano specifici componenti del piano in condizioni controllate: la procedura di isolamento di un endpoint, il processo di notifica al CSIRT, il ripristino di un sistema da backup. Le simulazioni complete (full-scale exercise) invece, riproducono uno scenario realistico dall’inizio alla fine, attivando tutti i componenti del piano. Sono più impegnative da organizzare ma forniscono la validazione più completa.

I risultati di ogni test devono essere documentati e tradursi in azioni correttive tracciabili. Un esercizio senza follow-up non produce miglioramento.

Quando costruire il piano internamente e quando affidarsi a un partner esterno

La costruzione di un incident response plan richiede competenze che spesso non sono tutte disponibili internamente: esperienza tecnica in analisi forense e gestione degli incidenti, conoscenza dei framework normativi, capacità di coordinamento cross-funzionale e esperienza nel condurre esercitazioni.

Molte organizzazioni scelgono un approccio ibrido: costruiscono il piano con il supporto di un consulente esterno, lo mantengono e lo aggiornano internamente, e si affidano a un provider specializzato per la risposta agli incidenti più complessi o per quelli che richiedono competenze forensi avanzate.

Questo modello ha una logica chiara: un incidente grave è raro ma ad alto impatto. Mantenere internamente un team di incident response con le competenze per gestire scenari critici ha un costo fisso elevato, spesso non giustificabile per organizzazioni di dimensione media. Il ricorso a un partner esterno con accordi di servizio predefiniti (retainer) consente di avere capacità di risposta disponibile senza il costo di strutturarla interamente in proprio.

La scelta del partner dovrebbe avvenire prima dell’incidente, non durante. Avere un piano di risposta agli incidenti è il punto di partenza. Sapere se funziona richiede un passo in più.
Se la tua organizzazione vuole costruire o rivedere il proprio incident response plan, testarne l’efficacia con tabletop exercise o definire le procedure di notifica coerenti con NIS2 e GDPR, il team di Cyberack può supportarti in ogni fase — dalla progettazione del piano alla simulazione degli scenari critici.

---

---

FAQ

Cos’è un piano di risposta agli incidenti informatici? È un documento operativo che definisce come un’organizzazione rileva, gestisce e si riprende da un incidente di sicurezza informatica. Descrive ruoli, responsabilità, procedure operative e criteri di notifica. Per essere efficace deve essere aggiornato, testato e compreso da chi lo utilizzerà.

Quali aziende sono obbligate ad avere un piano di risposta agli incidenti? Le organizzazioni soggette alla Direttiva NIS2 hanno l’obbligo di dotarsi di procedure strutturate per la gestione e la notifica degli incidenti significativi. Anche le organizzazioni soggette al GDPR devono essere in grado di gestire le violazioni di dati personali con procedure documentate. Al di là degli obblighi normativi, qualsiasi organizzazione che dipende dai propri sistemi informatici per operare ha un interesse concreto a costruire questa capacità.

Qual è la differenza tra incident response plan e disaster recovery plan? L’incident response plan gestisce la risposta operativa e di sicurezza a un incidente: rilevazione, contenimento, eradicazione. Il disaster recovery plan definisce le procedure tecniche per ripristinare i sistemi e i dati entro tempi definiti. I due documenti si integrano ma hanno scopi e momenti di attivazione distinti.

Con quale frequenza va aggiornato un piano di risposta agli incidenti? Almeno una volta all’anno, oppure ogni volta che cambia in modo significativo l’infrastruttura tecnologica, la struttura organizzativa, i fornitori critici o il quadro normativo di riferimento. Va aggiornato anche dopo ogni incidente reale o esercitazione che abbia evidenziato lacune.