Chi lavora da anni nel mondo dell’ICT, della sicurezza informatica e della compliance sviluppa una competenza particolare, che raramente compare nei CV ma che si affina con l’esperienza: la capacità di riconoscere i problemi strutturali prima che diventino incidenti. Non servono strumenti sofisticati né audit approfonditi; spesso bastano pochi minuti di conversazione, qualche risposta vaga, una frase detta con troppa sicurezza.

Esiste infatti un modello ricorrente, talmente diffuso da apparire quasi inevitabile, che descrive con impressionante precisione il modo in cui molte organizzazioni, pubbliche e private, affrontano tecnologia, rischio e responsabilità. Non è normato, non è certificato, non ha sponsor istituzionali, ma funziona sempre. Possiamo chiamarlo, senza pretese accademiche, il Modello a Tre Ondate dell’Esperto Aziendale.

La prima ondata è quella che arriva sempre per prima, ed è anche la più rassicurante.

È l’epoca di Ammiocuggino

Ammiocuggino è una figura trasversale, adattabile, resiliente. Costa poco, promette molto, disturba pochissimo. È la scelta ideale quando l’obiettivo implicito non è gestire il rischio, ma dimostrare di averlo delegato. È la fase dell’ottimismo organizzativo, del “non complichiamoci la vita”, del convincimento che la sicurezza sia un problema teorico, finché non diventa improvvisamente concreto.

Ammiocuggino può essere il sistemista tuttofare che “ha sempre fatto così e non è mai successo niente”. Può essere il consulente junior venduto come senior perché, in fondo, “sono cose semplici”. Può essere l’amico dell’amico che lavora in una grande azienda e quindi, per una curiosa forma di trasferimento di competenza, viene ritenuto automaticamente affidabile. Può essere una società low cost con un sito curato, molte parole inglesi e pochissime responsabilità contrattuali.

Il suo vero valore non sta nelle competenze tecniche, che possono essere variabili, ma nella capacità di parlare la lingua giusta. Ammiocuggino non parla di rischio sistemico, di impatti cumulativi o di scenari plausibili. Parla di normalità. Di consuetudine. Di rassicurazione. Usa frasi che funzionano sempre bene in consiglio di amministrazione: "non serve esagerare", "lo fanno tutti", "non complichiamo", "abbiamo altre priorità".

Il problema non è che Ammiocuggino esista. Il problema nasce quando gli viene chiesto di valutare ambiti che non è in grado di comprendere fino in fondo, mentre chi gli affida il compito non possiede gli strumenti culturali per rendersi conto del limite. È qui che si consuma il grande equivoco del rischio ICT.

Molti dirigenti sono perfettamente in grado di valutare rischi finanziari, legali o industriali. Sanno leggere un bilancio, interpretare una clausola, stimare una penale. Il rischio informatico, però, è diverso: è intangibile, non produce segnali immediati, non segue i cicli contabili e non compare nei KPI tradizionali. Un’infrastruttura fragile può funzionare per anni senza mostrare alcun problema, fino al giorno in cui qualcuno chiede conto di ciò che è stato fatto.

In una media azienda del settore servizi, per esempio, la gestione degli accessi era affidata da tempo a un fornitore storico. Prezzo competitivo, rapporto umano ottimo, nessuna documentazione strutturata, account condivisi, logging minimale. Tutto sembrava funzionare, finché un cliente enterprise, durante una due diligence, ha chiesto evidenze puntuali sui controlli di sicurezza. Non un incidente, non un attacco: una richiesta formale. In quel momento è emerso che non esisteva nulla di realmente difendibile.

Nella Pubblica Amministrazione lo schema è ancora più evidente. Sistemi stratificati nel tempo, fornitori diversi, competenze disperse, documenti replicati per inerzia. La sicurezza viene gestita come un adempimento formale, spesso delegato a contratti storici che nessuno ha più il coraggio o la competenza di rimettere in discussione. Finché arriva un’ispezione, una richiesta dell’autorità o un incidente che non può più essere ignorato.

È a quel punto che entra in scena la seconda ondata:

Lo Spalaletame

Lo Spalaletame arriva sempre dopo. Dopo l’incidente, dopo l’audit fallito, dopo la sanzione, dopo la PEC scomoda. Lavora in emergenza, con tempi impossibili e aspettative irrealistiche. Fa call notturne, weekend operativi, interventi rapidi. Mette pezze, costruisce workaround, ripristina ciò che è visibile e immediatamente contestabile. Il suo obiettivo non è creare un sistema sano, ma farlo tornare operativo il prima possibile.

In una PA locale, ad esempio, dopo un data breach di dimensioni limitate ma mediaticamente sensibile, è stata chiamata una task force esterna per “sistemare tutto”. In poche settimane sono stati introdotti nuovi controlli, procedure temporanee, strumenti aggiuntivi. Il servizio è ripartito, la pressione mediatica è scesa, il problema è stato considerato chiuso. Nessuno ha però affrontato le cause strutturali che avevano reso possibile l’incidente.

Lo Spalaletame, per definizione, non può risolvere i problemi strutturali. Non perché non ne sia capace, ma perché il contesto non glielo consente. Il budget è emergenziale, il tempo inesistente, il board vuole chiudere rapidamente la questione. Nasce così un modello tossico, che ottimizza il breve periodo e compromette il medio-lungo termine, producendo debito tecnico, architetture incoerenti e una pericolosa illusione di sicurezza. Le lesson learned vengono scritte, archiviate e, puntualmente, dimenticate.

La terza ondata è la più interessante e la meno frequente. È quella in cui qualcuno, all’interno dell’organizzazione, inizia a capire che il problema non è stato un incidente isolato, ma il risultato di una fragilità sistemica. È il momento in cui si pronuncia la frase più ambigua di tutte: “Facciamola bene, ma senza spendere troppo più di prima”. È il momento della terza figura:

Il vero Esperto

Entrano finalmente in gioco architetti, security engineer, specialisti di rischio e professionisti della compliance. Entrano però in un contesto carico di vincoli: budget compressi, aspettative irrealistiche, sistemi legacy intoccabili, tempi incompatibili con una progettazione seria. È il momento in cui l’organizzazione può davvero uscire dal ciclo, oppure prepararsi a rientrarvi dopo pochi anni.

Il ciclo è sempre lo stesso:
- si spende poco e il rischio resta invisibile;
- accade qualcosa e si spende moltissimo;
- si mettono pezze e si torna operativi;
- ci si dimentica di tutto e si riparte da capo.

Non è un ciclo razionale né economico, ma è perfettamente coerente con una cultura che considera ICT e sicurezza come costi accessori e non come fattori strutturali di continuità del servizio e del business.

Il problema, in fondo, non è che le organizzazioni sbaglino. Sbagliare è fisiologico, soprattutto in ambiti complessi come l’ICT e la sicurezza. Il problema è che sbagliano sempre allo stesso modo, con la stessa sicurezza e con la stessa sorprendente convinzione di essere state, ogni volta, “sfortunate”.

Il rischio informatico continua a essere percepito come qualcosa di teorico, di esagerato, quasi di ideologico, finché non si manifesta sotto forma di incidente, sanzione o figuraccia pubblica. A quel punto diventa improvvisamente urgentissimo, salvo tornare irrilevante non appena l’emergenza rientra e il rumore si abbassa.

La competenza costa, e questo è un fatto. Ma costa infinitamente meno del dilettantismo strutturato che molte organizzazioni continuano a scambiare per pragmatismo. E soprattutto costa meno di un modello decisionale che alterna superficialità e panico, risparmio miope e spesa isterica, fiducia mal riposta e reazioni tardive.

Finché l’ICT e la sicurezza resteranno un capitolo di spesa da comprimere invece che una funzione di governo, finché la compliance verrà trattata come burocrazia fastidiosa e non come strumento di controllo, finché gli esperti verranno ascoltati solo dopo il disastro, il ciclo non si interromperà. Si perfezionerà.

- Ammiocuggino continuerà a essere scelto perché rassicura.
- Lo Spalaletame continuerà a essere chiamato perché corre.
- Gli esperti veri continueranno a essere giudicati “troppo costosi”, “troppo complessi”, “troppo pessimisti”.

E quando qualcosa andrà storto, come inevitabilmente accadrà, si dirà che non si poteva prevedere, che è stato un evento eccezionale, che nessuno poteva immaginarlo.

Salvo poi immaginarlo perfettamente, la volta successiva.
Dopo averlo ignorato, ancora una volta, con grande coerenza.

Se non lo sai, sallo.