Che cosa si può insegnare con un incidente interno senza esporre nessuno

Quando in un’azienda succede qualcosa, la storia circola comunque, è un dato di fatto. Qualcuno racconta in chat il poco che sa, qualcun altro aggiunge quello che immagina, e dopo pochi giorni la storia che circola non somiglia più a quella che è successa. Intanto, la versione che spiega passo per passo come ha funzionato l’inganno non compare da nessuna parte. Ed è l’unica che servirebbe a evitare che succeda di nuovo. Perché resta chiusa nel cassetto? Perché raccontarla per intero sembra obbligarci a dire chi è stato, e lì il racconto si ferma. È un peccato, perché quell’incidente interno è il materiale di Cybersecurity awareness più forte che abbia un’azienda, ed è già pagato.

Perché l’incidente interno insegna più dell’esempio da manuale?

Perché un esempio da manuale descrive un inganno che ha funzionato da un’altra parte, e l’incidente interno ne descrive uno che ha funzionato qui. Per chi ascolta sono due cose molto diverse. Con l’esempio esterno dobbiamo metterci del nostro, perché tocca immaginare come sarebbe quella mail nel nostro ruolo, con i nostri sistemi e con le persone che ci scrivono ogni giorno. Quando il racconto arriva da dentro non c’è niente da immaginare, perché compaiono i nomi degli strumenti che usiamo, il tipo di richiesta che circola qui e il momento in cui una richiesta del genere non stona.

E c’è dell’altro, che nessun contenuto acquistato può dare. L’incidente interno dimostra che qui succede. Finché il rischio si spiega con casi altrui, tendiamo ad ascoltarlo come si ascolta una notizia, con interesse e con la sensazione che riguardi altri. Un caso interno accorcia quella distanza meglio di qualsiasi statistica.

Detto questo, è quella stessa forza a renderlo delicato. Il racconto che insegna di più è anche quello che più facilmente lascia esposta una persona, quindi prima di raccontarlo bisogna decidere come si racconta.

Che cosa togliere dal racconto prima di raccontarlo

Il nome è la prima cosa che esce ed è la parte facile. Il difficile viene dopo, perché in un racconto dettagliato ci sono parecchi dati che ricostruiscono la persona senza nominarla: l’area quando è piccola, il giorno e l’ora, il cliente che compariva nella mail, l’importo, la versione del sistema che usa una sola squadra. Mettendo quei dati uno accanto all’altro, chi lavora con quella persona sa di chi stiamo parlando.

Qui entra in gioco un criterio semplice, ed è raccontare il meccanismo completo e il contesto minimo. Dal meccanismo non togliamo niente, dato che lì sta tutto quello che si impara. E quanto è il contesto minimo? Quello che serve a capire l’inganno, e non un dato di più. Supponiamo che la bozza sia pronta e che a leggerla sia la squadra della persona coinvolta. Se da lì la si può indicare, ci manca ancora lavoro.

Quello che resta nel racconto descrive l’attacco, e niente di tutto ciò punta a una persona:

• La richiesta e il canale da cui è arrivata. Che cosa chiedeva il messaggio, con quale urgenza e da dove è entrato, per riconoscere lo stesso tentativo la volta successiva.
• Il segnale che era sotto gli occhi. Il dettaglio che non tornava, raccontato senza ironia, perché si vede facilmente una volta che conosciamo il finale.
• Come è stato rilevato e che cosa lo ha fermato. La segnalazione, la telefonata di verifica o il controllo che è scattato, cioè la parte che mostra che il sistema ha fatto il suo lavoro.

E resta un’ultima cosa, che non riguarda il testo. Alla persona coinvolta lo diciamo prima, anche se il racconto esce senza nessun dato che la riguardi. Scoprire da una comunicazione interna che la propria storia viene usata come materiale fa sì che, la volta successiva, la storia resti chiusa.

Quando si racconta?

La norma è che questa decisione non sia scritta da nessuna parte. Il Cyber Security Breaches Survey 2025/2026 del Governo del Regno Unito ha misurato che il 57% delle medie imprese e il 76% delle grandi ha un piano formale di risposta agli incidenti, quindi una grande azienda su quattro non ne ha nessuno. E il sondaggio conta come piano chi avvisare, chi fa che cosa e quando segnalare all’esterno. Raccontare l’incidente dentro l’azienda, perché se ne impari qualcosa, non rientra in quell’elenco.

Non si racconta mentre si sta contenendo. In quelle ore il racconto compete con il lavoro di risolverlo, e non sappiamo ancora bene che cosa sia successo, quindi quello che esce sarà la prima versione, quella che di solito viene corretta dopo pochi giorni. Non si racconta nemmeno così tardi che l’azienda lo abbia archiviato, perché un racconto che arriva quando l’argomento si è raffreddato si legge come una pratica burocratica.

La finestra che funziona meglio è quando l’incidente è chiuso e ricordiamo ancora che è successo qualcosa. In quel momento c’è una curiosità che poi si spegne, e quella curiosità è attenzione che non abbiamo dovuto fabbricare, la stessa che costa tanto ottenere il resto dell’anno. Lasciarla passare costa caro, perché la stessa storia raccontata mesi dopo richiede uno sforzo enorme perché qualcuno la legga.

Il racconto ha una seconda vita, questo sì. Quando entrano persone nuove, l’incidente che per noi è vecchio torna a essere informazione utile. Per loro non è storia vecchia, e spiega meglio di qualsiasi politica interna perché qui chiediamo quello che chiediamo.

Il tono decide se la volta dopo qualcuno avvisa

Questa è la parte cara da sbagliare. Un racconto che finisce in morale si legge come un avvertimento, e capiamo in fretta che cosa ci aspetta se un giorno tocca a noi. Quello che si rompe lì è il canale di segnalazione. La persona successiva a cui capiterà qualcosa impiegherà qualche ora in più ad avvisare, oppure proverà prima a sistemare da sola, e il tempo fra l’errore e la segnalazione è ciò che decide la dimensione dell’incidente. Un programma può perdere con una sola comunicazione scritta male buona parte della fiducia che ha impiegato anni a costruire.

C’è una regola semplice da applicare quando la teniamo presente, ed è che il soggetto delle frasi del racconto è l’inganno e il sistema. La mail chiedeva questo, arrivava da un indirizzo simile a quello del fornitore e risultava credibile perché qui le richieste di quel tipo arrivano così. Tutto questo descrive l’attacco con precisione e lascia fuori dal racconto la decisione di una persona. Non serve nemmeno aggiungere che la colpa non è stata di nessuno, dato che nominare la colpa la installa.

E c’è una parte del racconto che pesa più di quanto sembri, cioè il finale. Se la storia finisce in come è stato rilevato, con il nome del controllo o del canale che lo ha fermato, ci resta installato il riflesso di avvisare, ed è esattamente il comportamento che cerchiamo per la volta successiva.

Che cosa fare quando l’incidente non si può raccontare

A volte non si può, e le ragioni sono buone. C’è un cliente coinvolto, un’indagine aperta, un obbligo di notifica con scadenze proprie o un contratto che definisce che cosa si può dire. Quando succede, aspettare che si possa equivale di solito a non raccontarlo mai. L’insegnamento va perso, allora? Non tutto, perché ci resta la versione spostata, che racconta il meccanismo senza il caso.

Invece di “ci è successo questo”, la comunicazione avvisa che sta circolando una richiesta di questo tipo, con queste caratteristiche, e spiega come verificarla prima di rispondere. Perde la prova che qui succede, che era la parte più preziosa, e guadagna qualcosa che compensa parecchio, perché si può pubblicare mentre il meccanismo è ancora attivo.

L’altra strada dura di più, perché invece di comunicare trasforma il meccanismo in qualcosa che possiamo riutilizzare.

Da aneddoto isolato a materiale che dura

Un racconto fatto una volta arriva fin dove è arrivato quel giorno. Col tempo ci sono persone nuove, persone che erano in ferie e persone che lo hanno letto di sfuggita, quindi perché l’incidente continui a insegnare bisogna toglierlo dal formato comunicazione e portarlo dentro il programma.

Il modo più diretto è portare il meccanismo dentro una simulazione propria. Nelle simulazioni di phishing di SMARTFENSE si possono modificare i contenuti predefiniti o crearne di nuovi da zero, così lo stesso tipo di richiesta, con lo stesso stile di mittente e la stessa scusa, torna a circolare settimane dopo senza che nessuno sia esposto. Per chi compie l’azione a rischio, un Momento Educativo spiega in quell’istante che cosa è successo e come riconoscere l’inganno la volta successiva, con una domanda di validazione che conferma che il contenuto è stato letto. È la differenza fra prevenire e correggere applicata a un caso che conosciamo a memoria.

Qui c’è un limite che vale la pena rispettare, ed è più stretto di quello della comunicazione. La simulazione replica il meccanismo e il caso resta fuori. Se riproduce l’incidente con i suoi dettagli riconoscibili espone di nuovo la persona che l’ha vissuto, questa volta davanti a tutta l’azienda e con il timbro del programma sopra.

Il resto degli usi è più tranquillo e non ci chiede nessuna decisione difficile. Il meccanismo entra nel materiale di chi arriva, torna una volta all’anno come promemoria e dà alla politica interna l’esempio che le mancava.

Quale versione vogliamo che circoli

Torniamo alle versioni dell’inizio. La storia circolerà comunque. L’unica cosa che l’azienda decide è quale di tutte ha i dettagli, spiega il meccanismo e arriva a tutti, ed è una decisione che si prende nei giorni successivi all’incidente oppure si perde.

In definitiva, la versione che serve ha una forma abbastanza riconoscibile. Racconta con precisione come ha funzionato l’inganno, non permette di indicare nessuno, finisce in come è stato rilevato e ci lascia un’idea chiara di che cosa fare se domani ci arriva qualcosa di simile.

Se nella tua azienda è già successo qualcosa e nessuno l’ha ancora raccontato, forse questo è un buon momento per scrivere quella versione. Perché l’incidente lo abbiamo già pagato, e quello che resta da decidere è se ci insegna anche qualcosa.