I quasi-incidenti che il board non vedrà mai
Featured

I quasi-incidenti che il board non vedrà mai

Ogni near-miss ignorato è intelligence di governance che evapora — e nessuna normativa oggi obbliga a trattenerla

L'incidente che non c'è stato

La vostra organizzazione ha quasi subito un incidente grave. Qualcuno ha detto "per fortuna". Poi tutti sono tornati a lavorare. Quel quasi-incidente conteneva più intelligence difensiva di molti breach report pubblicati, ma nessuno l'ha documentato, nessuno l'ha analizzato, nessuno l'ha portato al tavolo dove si decidono budget e priorità.

Il trend emergente è chiaro: le organizzazioni condividono, poco e male, i breach conclamati, ma ignorano sistematicamente i near-miss. Eppure i quasi-incidenti rappresentano una fonte informativa enormemente più ricca e meno tossica dal punto di vista reputazionale. La proposta che circola con crescente insistenza tra figure di primo piano del settore, tra cui Wendy Nather e Bob Lord, è concreta: costruire un canale volontario e anonimizzato per la condivisione dei near-miss, con un safe harbor regolatorio esplicito che protegga chi decide di contribuire. Non è un obbligo normativo esistente. È una direzione di governance che il mercato sta iniziando a reclamare.

Il costo invisibile del silenzio operativo

Quando un tentativo di compromissione viene fermato dall'architettura difensiva o dalla pura fortuna, l'organizzazione perde l'occasione di capire tre cose: quali controlli hanno effettivamente funzionato, quali ipotesi di rischio erano sbagliate, e dove il sistema sta silenziosamente driftando verso una soglia critica. Il near-miss non documentato non è un evento neutro. È un fallimento di governance invisibile.

Le evidenze di settore confermano che elevare i quasi-incidenti ai vertici aziendali equivale ad aprire una miniera d'oro informativa. Ma la blame culture, la paura delle conseguenze regolatorie e l'assenza di incentivi strutturali impediscono che queste informazioni raggiungano chi prende le decisioni sulla resilienza. Il risultato è un board che alloca risorse sulla base dei breach che conosce, ignorando completamente il profilo di rischio che i near-miss disegnano in modo molto più granulare. La domanda non è se potete permettervi di raccogliere queste informazioni. È se potete permettervi di continuare a perderle.

Dove la root cause diventa alibi

La frizione operativa è strutturale. Quando qualcosa va quasi storto, il sistema organizzativo premia il silenzio. L'errore umano viene usato come conclusione dell'indagine, non come punto di partenza. La cosiddetta root cause analysis si trasforma troppo spesso nell'etichetta che l'organizzazione piazza sulla propria decisione di smettere di cercare. Come ha osservato Bob Lord, esperto di sicurezza con un lungo percorso nelle policy pubbliche, la root cause è il punto in cui ci fermiamo, non il punto in cui troviamo la verità.

Il ciclo è prevedibile: la responsabilità viene scaricata sull'individuo, il sistema che ha creato le condizioni del quasi-incidente resta intatto, e il near-miss evapora senza lasciare traccia nella memoria organizzativa. Non si corregge il processo, non si aggiorna il modello di rischio, non si informa il board. L'indagine si chiude con un nome, non con una causa. E il prossimo near-miss troverà esattamente le stesse condizioni ad attenderlo.

Il vuoto normativo che nessuno sta colmando

NIS2, all'articolo 23, e il regolamento DORA impongono obblighi di notifica per gli incidenti significativi. Ma nessuna delle due normative prevede meccanismi strutturati per la condivisione volontaria dei near-miss, né un safe harbor per chi decide di comunicarli. Il vuoto è reale e misurabile. La normativa europea incentiva la trasparenza post-incidente, il breach va notificato, documentato, gestito, ma non crea le condizioni per la trasparenza pre-incidente, quella che potrebbe prevenire il breach successivo.

NIS2 promuove la cooperazione e lo scambio di informazioni all'articolo 29, ma senza un framework dedicato ai quasi-incidenti quel mandato resta strutturalmente incompleto. Non si tratta di una violazione normativa: nessuna organizzazione è oggi in difetto per non aver condiviso un near-miss. Si tratta di un'opportunità di governance che la normativa attuale non copre e che il mercato non ha ancora saputo costruire autonomamente. Il recepimento italiano della NIS2 non aggiunge nulla su questo fronte. Lo spazio per un'iniziativa volontaria, settoriale o cross-settoriale, è interamente aperto.

La domanda che non arriva mai al tavolo giusto

Quanti quasi-incidenti ha assorbito la vostra organizzazione nell'ultimo anno? Quanti di questi sono stati documentati con un livello di dettaglio sufficiente a estrarne intelligence operativa? E quanti, questa è la domanda che conta, sono mai arrivati al tavolo dove si decidono i budget di resilienza e le priorità strategiche?

Nelle organizzazioni europee si osserva un pattern ricorrente: il near-miss viene celebrato come fortuna, gestito come aneddoto e poi dimenticato. Il team operativo lo riconosce, lo archivia nella memoria informale, e procede. Il board non ne viene informato perché non c'è un framework per farlo, non c'è un linguaggio condiviso per raccontarlo, e non c'è un incentivo strutturale per portarlo all'attenzione di chi governa il rischio. La perdita non è tecnica. È una perdita di governance pura: l'organizzazione rinuncia a imparare da ciò che non è ancora andato storto, e si condanna a reagire solo a ciò che è già accaduto.


Ogni organizzazione ha un registro degli incidenti. Quasi nessuna ha un registro dei quasi-incidenti. La differenza tra le due non è burocratica, è la differenza tra governare il rischio e aspettare che si materializzi.

We use cookies

Utilizziamo i cookie sul nostro sito Web. Alcuni di essi sono essenziali per il funzionamento del sito, mentre altri ci aiutano a migliorare questo sito e l'esperienza dell'utente (cookie di tracciamento). Puoi decidere tu stesso se consentire o meno i cookie. Ti preghiamo di notare che se li rifiuti, potresti non essere in grado di utilizzare tutte le funzionalità del sito.