Articolo Pubblicazioni
Esercitazioni tabletop: simulare un incidente con il management
di Vincenzo Calabrò · Pubblicato il 14 novembre 2026
Abstract
Un’esercitazione tabletop mette intorno a un tavolo dirigenti e responsabili per affrontare un incidente simulato, prendendo decisioni sulla base di informazioni che arrivano un po’ alla volta. L’articolo spiega a che cosa serve, come si sceglie lo scenario, chi partecipa, come si conduce la sessione con le iniezioni di eventi e come si trasforma il risultato in un piano di miglioramento.
A che cosa serve
Un piano di risposta agli incidenti scritto bene può fallire perché nessuno sa chi decide, perché manca un numero di telefono o perché il consiglio di amministrazione scopre durante la crisi di dover scegliere se pagare un riscatto. Un’esercitazione tabletop serve a scoprire questi problemi a tavolino. Non si tocca nessun sistema, si discute uno scenario realistico e si prendono decisioni come se fosse vero. NIS2 chiede agli organi di amministrazione di sovrintendere alla gestione del rischio, e un’esercitazione documentata è un modo concreto per farlo.
Lo scenario
Lo scenario deve essere plausibile per l’organizzazione e abbastanza difficile da mettere alla prova le decisioni. Un ransomware con esfiltrazione dei dati, la compromissione di un fornitore critico, la caduta prolungata di un servizio cloud o la diffusione di dati riservati sui social sono scenari che toccano insieme tecnica, legale, comunicazione e business. Lo scenario si costruisce come una sequenza di momenti, ognuno con informazioni nuove che costringono a cambiare o confermare le decisioni.
I ruoli
- Facilitatore, che conduce la sessione, introduce gli eventi e fa le domande, e non deve essere uno dei decisori;
- Partecipanti, cioè direzione, responsabili di IT e sicurezza, legale, protezione dei dati, comunicazione, risorse umane e responsabili dei processi colpiti;
- Osservatori, che annotano decisioni, tempi, dubbi e informazioni mancanti senza intervenire;
- Esperti da consultare, come il fornitore di risposta agli incidenti o l’assicuratore, quando lo scenario lo richiede.
La conduzione
Una sessione dura di solito da due a quattro ore. Il facilitatore presenta la situazione iniziale e lascia che il gruppo decida le prime azioni. Poi introduce le iniezioni, cioè eventi nuovi come la richiesta di riscatto, un giornalista che chiama, i backup risultati compromessi, un cliente importante che minaccia di recedere, la scadenza della notifica. Per ogni passaggio chiede chi decide, sulla base di quali informazioni, con quali tempi e come si comunica. Conviene lasciare che il gruppo sbagli, perché è dagli errori che emergono le lacune del piano.
Dopo l’esercitazione
Subito dopo si fa un breve confronto a caldo su che cosa ha funzionato e che cosa no. Entro qualche giorno il facilitatore e gli osservatori preparano una relazione con le lacune emerse, come contatti mancanti, ruoli poco chiari, decisioni che il piano non prevedeva o tempi incompatibili con le scadenze di notifica, e un piano di miglioramento con responsabili e date. L’esercitazione successiva verifica che le correzioni siano state applicate.
Errori comuni
- scenari troppo tecnici, in cui i dirigenti diventano spettatori;
- scenari troppo facili, che confermano il piano senza metterlo alla prova;
- un facilitatore che guida il gruppo verso le risposte giuste;
- nessuna relazione finale, per cui gli stessi problemi si ripresentano l’anno successivo.
Un esempio di scenario
Uno scenario tipico per un’azienda di servizi parte un lunedì mattina. L’help desk riceve segnalazioni di file illeggibili sulle cartelle condivise, e in un’ora il gestionale smette di rispondere. Prima iniezione, dopo venti minuti di discussione, una nota di riscatto compare sugli schermi con un link a un sito in cui gli attaccanti mostrano un campione dei dati sottratti, fra cui buste paga e contratti con i clienti. Seconda iniezione, un giornalista di una testata locale chiama l’ufficio stampa chiedendo conferma. Terza iniezione, il responsabile IT riferisce che anche i backup sul NAS risultano cifrati e che resta solo una copia in cloud di cinque giorni prima. Quarta iniezione, il cliente principale scrive che sospenderà gli ordini finché non avrà garanzie sulla sicurezza dei propri dati.
Ogni iniezione costringe il gruppo a decidere qualcosa di concreto. Chi decide se staccare la rete, chi parla con il giornalista e con quali parole, se e quando notificare al Garante e al CSIRT Italia, se ripristinare dalla copia in cloud accettando di perdere cinque giorni di lavoro, che cosa dire al cliente e chi lo chiama. Le risposte, e soprattutto i dubbi, sono il materiale della relazione finale.
Le domande da porre
- chi ha l’autorità per decidere lo spegnimento dei sistemi o il pagamento di un riscatto, e chi lo sostituisce se è irraggiungibile;
- dove si trovano i contatti di fornitori, assicurazione, consulenti e autorità, se la posta e la rubrica aziendali non funzionano;
- quale soglia fa scattare la notifica e chi la firma;
- quali attività possono proseguire in modo manuale e per quanto tempo;
- chi informa i dipendenti, con quale canale e con quali istruzioni.
Frequenza e varianti
Un’esercitazione all’anno con il vertice è un buon punto di partenza, accompagnata da sessioni più brevi e tecniche con i gruppi operativi. Conviene cambiare scenario ogni volta e alzare la difficoltà man mano che i processi maturano, per esempio introducendo l’assenza di una persona chiave o un fornitore che non risponde. Le esercitazioni si possono svolgere anche con partner e fornitori critici, per verificare che i contratti e le procedure congiunte funzionino davvero, e possono preparare a test più complessi come le simulazioni tecniche dal vivo.
Un facilitatore esterno porta neutralità e scenari realistici tratti da casi reali, mentre uno interno conosce meglio processi e persone. Una buona soluzione è alternare le due figure, o affiancarle nella preparazione.
Vedi anche: l’articolo del 2026 NIS2 e organi di amministrazione: responsabilità e formazione obbligatoria e l’articolo del 2024 Incident Management: raccomandazioni per un’implementazione ottimale.
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn