Una crisi digitale non comincia quando compare un commento negativo. Comincia quando un’organizzazione si accorge che le persone stanno cercando una risposta e nessuno sa ancora chi debba darla, con quali fatti e attraverso quale canale. Può trattarsi di un servizio non disponibile, di una campagna inviata per errore, di un fornitore compromesso o di un incidente che coinvolge dati e account. La tecnologia cambia, ma la domanda resta la stessa: che cosa dobbiamo dire adesso per ridurre l’incertezza senza promettere ciò che non possiamo mantenere?
Per questo considero la comunicazione di crisi digitale parte del sistema operativo dell’azienda, non un testo da affidare all’ultimo minuto a chi gestisce i social. Il messaggio pubblico è soltanto uno degli elementi: prima servono fatti verificati, ruoli, un canale affidabile e una sequenza di aggiornamenti.
La crisi comincia prima del comunicato
Il primo errore è confondere la velocità con la fretta. Pubblicare una frase generica può dare l’impressione di presenza, ma non aiuta chi deve capire se il problema lo riguarda, che cosa può fare e quando riceverà nuove informazioni. Al contrario, aspettare di conoscere ogni dettaglio può lasciare spazio a voci, schermate condivise e interpretazioni che l’organizzazione non riuscirà più a correggere facilmente.
Il punto di equilibrio è preparare prima una struttura minima. La revisione 3 di NIST SP 800-61, pubblicata nell’aprile 2025, tratta la risposta agli incidenti dentro la gestione del rischio e richiama anche il bisogno di comunicare con interlocutori interni ed esterni. La comunicazione, quindi, non è il rivestimento finale della risposta tecnica: accompagna preparazione, contenimento, ripristino e apprendimento.
Prima i fatti, poi la narrazione
Quando arriva una segnalazione, separerei subito quattro livelli: ciò che è stato osservato, ciò che è stato verificato, ciò che resta da accertare e ciò che le persone devono fare nell’immediato. Questa distinzione evita che un’ipotesi interna diventi una certezza pubblica. Evita anche il linguaggio assoluto: “nessun dato è stato coinvolto” non dovrebbe comparire se l’indagine non ha ancora escluso quella possibilità.
Il team editoriale può rendere comprensibili le informazioni, ma non dovrebbe decidere la portata tecnica o giuridica dell’incidente. Se sono coinvolti dati personali, accessi o obblighi di notifica, la valutazione deve passare dalle funzioni competenti e dalle procedure applicabili. Un articolo di metodo non sostituisce una consulenza legale: serve a far arrivare le competenze giuste al momento giusto.
Un piano è una rete di responsabilità
Un documento utile non contiene soltanto frasi pre-scritte. Indica chi attiva la risposta, chi verifica i fatti, chi può approvare un messaggio, chi parla a nome dell’organizzazione, chi aggiorna il sito e chi risponde alle domande ripetute. La guida CISA sui playbook di risposta a incidenti e vulnerabilità include tra le attività preparatorie una strategia di comunicazione, un canale fuori banda e un punto di coordinamento. Sono indicazioni operative che valgono anche per una realtà piccola, con nomi diversi e meno livelli gerarchici.
Assegnerei inoltre un sostituto a ogni ruolo. Una crisi non aspetta la persona che conosce la password del CMS, il referente legale o il portavoce ufficiale. Terrei in un luogo protetto contatti, autorizzazioni, canali alternativi e registro delle decisioni. L’obiettivo è impedire che un singolo account o una chat irraggiungibile blocchino la risposta.
Il primo aggiornamento deve essere breve e verificabile
Il primo messaggio non deve dimostrare che l’azienda ha già risolto tutto. Deve dimostrare che ha preso in carico il problema e sa come aggiornare le persone. Nella pratica includerei:
- un riconoscimento chiaro dell’evento, senza minimizzarlo;
- i fatti confermati e il perimetro ancora in verifica;
- l’azione concreta richiesta a clienti, utenti o dipendenti, se necessaria;
- il canale ufficiale per domande e aggiornamenti;
- un orario o una condizione per il prossimo aggiornamento.
Questa promessa temporale conta più di un tono rassicurante. “Vi faremo sapere” è debole; “pubblicheremo un aggiornamento entro le 16, anche se l’indagine sarà ancora in corso” è controllabile. Se l’orario salta, lo si comunica. La fiducia nasce dalla possibilità di confrontare ciò che è stato promesso con ciò che è stato fatto.
Ogni pubblico ha una domanda diversa
Un post pubblico, una mail ai clienti e un messaggio interno non sono tre copie dello stesso comunicato. Chi usa il servizio vuole sapere se può continuare, chi lavora nell’organizzazione deve sapere che cosa rispondere e chi gestisce un contratto può avere bisogno di informazioni più precise. Il contenuto di base deve restare coerente, ma il livello di dettaglio e l’azione richiesta cambiano.
Non affiderei tutto a un solo social network. Predisporrei una pagina stabile sul sito, un canale di supporto, un modo per raggiungere chi non segue i profili social e, quando serve, un canale alternativo non dipendente dall’infrastruttura sospettata. ENISA descrive la gestione delle crisi come coordinamento tra reti, Stati membri e altre istituzioni: anche in una realtà piccola, la pagina pubblica dovrebbe mostrare una cronologia e indicare chi coordina le risposte. Così chi arriva più tardi può ricostruire il contesto senza cercare vecchi post.
Trasparenza non significa pubblicare ogni dettaglio
Durante una crisi la trasparenza viene talvolta confusa con la pubblicazione integrale dell’indagine. Non è necessario esporre indicatori tecnici, nomi di persone, ipotesi non validate o informazioni che possono aumentare il danno. È però necessario dichiarare i limiti della conoscenza, spiegare perché alcuni dettagli non sono ancora disponibili e indicare chi sta lavorando alla verifica.
La guida CISA sul ransomware raccomanda di inserire nel piano procedure di comunicazione e notifiche, messaggi iniziali già impostati e un accordo sul livello di dettaglio da condividere con pubblico e interlocutori interni. Preparare una bozza non significa preparare una scusa: significa lasciare ai fatti il compito di aggiornare una struttura già leggibile.
Evito anche le formule promozionali. Una crisi non è il momento per trasformare un disservizio in una prova di “resilienza” o per inserire una call to action commerciale. Il linguaggio deve essere diretto, rispettoso e proporzionato. Il marketing può aiutare a scegliere parole comprensibili; non dovrebbe usare la vulnerabilità del pubblico per recuperare attenzione.
La fase di ripristino è ancora comunicazione
Quando il servizio torna disponibile, la risposta non è conclusa. Le persone vogliono sapere che cosa è stato ripristinato, quali limitazioni restano, se devono compiere un’azione e quando arriverà una spiegazione più completa. La comunicazione di recupero deve seguire l’evoluzione tecnica, non sostituirla con una frase celebrativa.
NIST indica che gli aggiornamenti sul ripristino devono raggiungere gli interlocutori designati attraverso metodi approvati e includere, quando appropriato, i passi intrapresi per evitare una ricorrenza. Per me questa è la differenza tra una risposta che chiude il ticket e una risposta che ricostruisce affidabilità: dire che cosa è cambiato, che cosa è stato imparato e quale controllo verrà verificato di nuovo.
Misurare se la comunicazione ha aiutato
Non userei il numero di visualizzazioni come misura principale. In una crisi, una grande portata può indicare che il problema è stato amplificato, non che il messaggio è stato utile. Guarderei il tempo tra rilevazione e primo aggiornamento verificato, le domande che si ripetono, la coerenza tra sito e canali secondari e il tempo necessario per correggere un’informazione imprecisa.
Dopo l’evento raccoglierei anche le frizioni: quale ruolo non era chiaro, quale autorizzazione mancava, quale pagina era difficile da trovare, quale domanda non aveva risposta. Le metriche servono a migliorare la procedura, non a costruire una classifica reputazionale. Una crisi ben comunicata non è una crisi che genera applausi; è una crisi nella quale le persone ricevono abbastanza informazioni per prendere decisioni prudenti.
La prova va fatta prima della crisi
Una volta al trimestre sceglierei uno scenario realistico e farei una simulazione breve: un servizio non raggiungibile, una newsletter sbagliata, un accesso sospetto. In un’ora il gruppo dovrebbe identificare i ruoli, preparare il primo messaggio, indicare il canale alternativo e definire il prossimo aggiornamento. Poi si controllerebbe se le persone riescono davvero a trovare contatti, pagine e autorizzazioni.
Nel mio lavoro tratterei questo esercizio come una revisione editoriale con conseguenze operative. La domanda finale non sarebbe “il testo suona bene?”, ma “una persona preoccupata capisce che cosa è successo, che cosa deve fare e quando torneremo a parlarne?”. Se la risposta è no, il piano non è pronto.
Fonti
- NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
- CISA, Cybersecurity Incident and Vulnerability Response Playbooks.
- CISA, #StopRansomware Guide.
- ENISA, EU incident response and cyber crisis management.
Nota di trasparenza: questo articolo è stato elaborato con l'aiuto dell'intelligenza artificiale e con supervisione e responsabilità editoriale umana.