Crisis management: come si gestisce una crisi aziendale

La risposta breve: il crisis management, o gestione della crisi aziendale, è la capacità di un'organizzazione di prendere decisioni strategiche quando un evento minaccia la sua operatività, la sua reputazione o la sua stessa tenuta. Si regge su tre elementi preparati prima: un comitato di crisi con ruoli e deleghe chiari, un piano di gestione della crisi e una catena di comunicazione verso dipendenti, clienti e autorità. Oggi la crisi più probabile per un'azienda del mid-market nasce da un incidente cyber, e per chi rientra nella NIS2 la gestione delle crisi è anche un obbligo di legge.

Questa guida spiega cosa distingue una crisi da un incidente, chi deve sedere al tavolo, cosa scrivere nel crisis management plan, come si incastra con la business continuity e la ISO 22301, e cosa succede nelle prime 72 ore di una crisi da attacco informatico.

Crisi, incidente, emergenza: dove passa il confine

Non ogni problema è una crisi, e trattarlo come tale è già un errore di gestione. La distinzione pratica è questa:

• Un incidente è un evento che si gestisce con procedure operative già scritte: un server compromesso, un account violato, un malware isolato. Se ne occupa il team tecnico, eventualmente con il SOC.
• Un'emergenza riguarda la sicurezza delle persone e dei luoghi, e ha già i suoi piani: evacuazione, primo soccorso, antincendio.
• Una crisi è una situazione in cui le procedure non bastano più: l'impatto tocca il business nel suo insieme, le informazioni sono incomplete, il tempo stringe e le decisioni hanno conseguenze che nessun manuale ha previsto. Serve il vertice, non solo l'IT.

Un ransomware che cifra i sistemi di produzione e blocca le spedizioni parte come incidente e diventa crisi in poche ore: ci sono clienti da avvisare, fornitori da coordinare, un'autorità da informare e una scelta da fare su quando e come ripartire.

Cosa chiedono la NIS2 e l'ACN sulla gestione delle crisi

Per i soggetti essenziali e importanti la gestione della crisi non è una buona pratica facoltativa. L'articolo 24, comma 2, lettera c) del D.Lgs. 138/2024, che recepisce la NIS2 in Italia, elenca tra le misure minime di gestione del rischio la "continuità operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi".

L'ACN ha tradotto quell'obbligo in requisiti puntuali. Nelle misure di sicurezza di base (allegati 1 e 2 della determinazione ACN 379907/2025, per soggetti importanti ed essenziali), la misura ID.IM-04 chiede, per almeno i sistemi informativi e di rete rilevanti, tre piani distinti: continuità operativa, ripristino in caso di disastro e gestione delle crisi informatiche. Il piano di crisi deve contenere almeno:

• i ruoli e le responsabilità del personale e, se opportuno, dei fornitori, con l'assegnazione dei ruoli in situazione di crisi e le procedure da seguire;
• le modalità di comunicazione tra i soggetti e le autorità competenti.

La stessa misura aggiunge due condizioni che spesso si dimenticano: i piani sono approvati dagli organi di amministrazione e direttivi, e vanno riesaminati almeno ogni due anni e comunque dopo un incidente significativo o un cambiamento dell'esposizione alle minacce. È coerente con l'articolo 23 del decreto, che chiede agli organi di amministrazione di approvare le modalità di attuazione delle misure e di essere informati degli incidenti e delle notifiche. Il quadro completo degli obblighi è nella guida completa alla NIS2.

Il comitato di crisi: chi siede al tavolo e chi decide

Il comitato di crisi è il gruppo ristretto che prende le decisioni strategiche durante la crisi. Non sostituisce il team tecnico che contiene l'attacco: gli dà priorità e decide quello che il team tecnico non può decidere da solo.

La composizione tipica

• Un crisis leader con mandato del vertice, di solito l'amministratore delegato o un suo delegato formale. Deve poter spendere, fermare la produzione e parlare a nome dell'azienda.
• IT e sicurezza (IT manager, CISO, eventualmente il referente del SOC esterno): portano il quadro tecnico e le opzioni di ripristino.
• Legale e privacy (legale interno, DPO): valutano gli obblighi di notifica e le implicazioni contrattuali.
• Operations: sa quali processi si possono fermare, per quanto e con quali alternative.
• Comunicazione: prepara i messaggi verso dipendenti, clienti, stampa.
• Finanza: stima l'impatto economico e gestisce il rapporto con l'assicurazione cyber, se c'è.

Le regole che contano più dei nomi

Ogni ruolo ha un sostituto, perché la crisi non aspetta il rientro dalle ferie. Le soglie di attivazione sono scritte: chi convoca il comitato, in base a quali condizioni. E i canali di comunicazione del comitato sono indipendenti dai sistemi colpiti: se la posta aziendale è cifrata, una rubrica su carta e un gruppo di messaggistica fuori dal dominio aziendale permettono al comitato di riunirsi anche quando l'infrastruttura è ferma.

Nella catena va inserita anche la persona che tiene i rapporti con l'ACN per la NIS2, con i suoi sostituti: le notifiche vanno al CSIRT Italia, che opera presso l'Agenzia, come spiegato nell'articolo su cos'è un CSIRT e come lavora.

Il crisis management plan: cosa ci va scritto

Un piano di crisi utile si legge sotto pressione. Oltre ai due contenuti minimi richiesti dall'ACN, conviene che contenga:

1. Criteri di attivazione: quando un incidente diventa crisi, con esempi concreti (fermo di un processo critico, dati di clienti esposti, richiesta di riscatto).
2. Composizione del comitato e deleghe, con recapiti fuori banda e sostituti.
3. Il calendario degli obblighi: notifiche NIS2, notifica al Garante privacy, comunicazioni contrattuali a clienti e fornitori.
4. Modelli di comunicazione già scritti per i pubblici principali, da adattare e non da inventare.
5. Il registro delle decisioni: chi ha deciso cosa, a che ora, con quali informazioni. Serve per le relazioni successive e per il riesame.
6. I criteri di chiusura: quando la crisi rientra nella gestione ordinaria e il controllo passa al piano di ripristino.

Crisis management e business continuity: la ISO 22301 e la ISO 22361

Crisis management e business continuity si confondono spesso, ma rispondono a domande diverse. La business continuity chiede come mantenere o riprendere le attività critiche entro tempi accettabili. Il crisis management chiede come si decide quando la situazione non è prevista da nessun piano.

La ISO 22301:2019 (aggiornata dall'emendamento 1 del 2024) definisce i requisiti del sistema di gestione della continuità operativa, il BCMS, ed è la norma certificabile. Il punto di contatto con la crisi sta nella clausola 8.4, dedicata a piani e procedure di continuità: la 8.4.2 è dedicata alla struttura di risposta (Response structure), la 8.4.3 ad allerta e comunicazione (Warning and communication). La clausola 8.5 riguarda il programma di esercitazioni, che è il modo in cui un piano smette di essere un documento.

La ISO 22361:2022, Security and resilience, Crisis management, Guidelines, è invece il documento specifico sul crisis management. È una linea guida, quindi non si certifica: dà indicazioni su come costruire una capacità di gestione della crisi a livello strategico. È organizzata attorno a sette principi (governance, strategia, gestione del rischio, processo decisionale, comunicazione, etica, apprendimento) e dedica capitoli distinti alla leadership in crisi, alle decisioni strategiche, alla comunicazione di crisi e alla formazione con esercitazioni. Nell'introduzione la norma colloca il crisis management accanto a discipline interdipendenti come la business continuity, la sicurezza delle informazioni e la risposta agli incidenti.

In pratica: la ISO 22301 dà la struttura certificabile e i piani di continuità, la ISO 22361 dà il metodo per la parte decisionale.

Le prime 72 ore di una crisi da incidente cyber

Qui il crisis management incontra scadenze di legge precise. L'articolo 25, comma 5, del D.Lgs. 138/2024 fissa la sequenza verso il CSIRT Italia per gli incidenti significativi:

• Entro 24 ore da quando si è venuti a conoscenza dell'incidente significativo: una pre-notifica che, ove possibile, indichi se l'incidente può derivare da atti illegittimi o malevoli o avere impatto transfrontaliero.
• Entro 72 ore: la notifica dell'incidente, con una valutazione iniziale di gravità e impatto e, se disponibili, gli indicatori di compromissione.
• Su richiesta del CSIRT Italia: una relazione intermedia.
• Entro un mese dalla notifica: la relazione finale, con descrizione dettagliata, causa originale, misure di attenuazione e, se noto, impatto transfrontaliero. Se l'incidente è ancora in corso, si inviano relazioni mensili e una relazione finale entro un mese dalla chiusura.

Lo stesso articolo contiene tre punti utili al comitato. Il comma 3 stabilisce che la notifica non espone il soggetto a una responsabilità maggiore di quella derivante dall'incidente: notificare non è ammettere una colpa. Il comma 8 prevede che, se si sospetta un reato, il CSIRT Italia dia orientamenti anche sulla segnalazione alle autorità di contrasto. Il comma 9 prevede che, sentito il CSIRT Italia e se opportuno, si comunichino ai destinatari dei servizi gli incidenti che possono ripercuotersi sulla fornitura. Il dettaglio operativo è nell'articolo sulla notifica degli incidenti NIS2.

Se l'incidente coinvolge dati personali, corre in parallelo l'orologio del GDPR: l'articolo 33 del Regolamento (UE) 2016/679 chiede di notificare la violazione al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore, e l'articolo 34 chiede di avvisare gli interessati quando il rischio per loro è elevato. Sono due canali distinti, con destinatari diversi, e il piano deve prevederli entrambi.

Tutte queste scadenze partono da un presupposto: accorgersi dell'incidente. Un attacco rilevato dopo giorni lascia al comitato di crisi un margine che non esiste più. Per questo il tempo di rilevamento, discusso nell'articolo su quanto tempo serve per accorgersi di un attacco, è una variabile del crisis management tanto quanto la composizione del comitato.

Esercitarsi prima: il tabletop exercise

Un piano mai provato nasconde spesso un recapito sbagliato, una delega mancante o un passaggio che nessuno sa fare. Il modo più economico di scoprirlo è un'esercitazione a tavolino: il comitato si riunisce, qualcuno presenta uno scenario realistico (ransomware di venerdì sera, fornitore compromesso, dati di clienti pubblicati) e il gruppo prende le decisioni come se fosse vero, con i tempi della NIS2 sul tavolo.

Dopo ogni esercitazione si aggiorna il piano. È la logica del programma di esercitazioni della ISO 22301 (clausola 8.5) e del riesame periodico previsto dalla misura ID.IM-04 dell'ACN.

Da dove partire

Se oggi il crisis management della tua azienda è un paragrafo dentro un documento di sicurezza, i passi in ordine sono: definire i criteri di attivazione, nominare il comitato con sostituti e canali fuori banda, scrivere il calendario delle notifiche, preparare i modelli di comunicazione e fissare la prima esercitazione. Chi vuole inserire tutto questo in un sistema di continuità verificabile può partire dal percorso di certificazione ISO 22301, o dalla versione accelerata del percorso se i tempi sono stretti.