Un errore comune è associare la vulnerabilità al social engineering alla scarsa competenza tecnica. In realtà, i profili a rischio sono trasversali e spesso sorprendono.
I ruoli maggiormente esposti sono quelli con accesso a risorse critiche e di solito abituati a ricevere richieste da persone esterne o da figure di autorità. Per esempio HR (accesso a dati personali e sistemi di payroll), finance (autorizzazioni di pagamento), helpdesk IT (reset di credenziali, accesso privilegiato), nuovi assunti (meno familiari con le procedure interne, più inclini a non mettere in discussione le richieste).
Ma anche i profili tecnici non sono immuni. Un DevOps può cadere in un pretexting ben costruito che simula una richiesta urgente da parte del team di sicurezza. Uno sviluppatore può essere convinto a clonare un repository malevolo spacciato per una libreria legittima.
Il vero fattore di rischio non è la competenza tecnica, ma la combinazione di privilegio di accesso e pressione contestuale. Più un ruolo ha accesso a sistemi critici, più diventa un bersaglio di valore. Più è esposto a situazioni di urgenza o autorità, più è vulnerabile alla manipolazione.

La risposta organizzativa più comune al rischio di social engineering è la formazione annuale sulla sicurezza: di solito un modulo e-learning da trenta minuti, un test finale con domande a risposta multipla, attestato archiviato nel cassetto.
Questa soluzione è necessaria, a volte obbligatoria per la normativa, ma da sola è insufficiente per diversi problemi.

Un problema di memoria: le informazioni apprese in un singolo momento formativo si degradano rapidamente senza rinforzo. Senza ripetizione, la maggior parte dei contenuti viene dimenticata entro poco tempo, lo dice la neuroscienza.
Il problema della “security fatigue”. I dipendenti sono sommersi da avvisi, policy, notifiche di sicurezza. L’eccesso di segnali porta inevitabilmente all’assuefazione: si smette di leggere, si clicca “accetto”, si ignora l’alert. La formazione che si aggiunge senza differenziarsi viene trattata allo stesso modo.
Il problema delle simulazioni punitive. Molte organizzazioni conducono campagne di phishing simulato e comunicano pubblicamente chi è “caduto nella trappola”. Questa pratica genera più risentimento che apprendimento e nei casi peggiori crea una cultura della colpa che disincentiva la segnalazione degli incidenti reali.
Il problema delle metriche sbagliate. Il tasso di click su email di phishing simulate è una metrica facile da raccogliere, ma racconta poco. Un dipendente che non clicca sul link di test potrebbe comunque fornire la propria password al telefono. La metrica più significativa è il tasso di segnalazione: quante persone, di fronte a qualcosa di sospetto, lo hanno comunicato al team di sicurezza?

La sicurezza si costruisce con una cultura non con le procedure. La differenza non è semantica: la procedura definisce cosa si deve fare, la cultura definisce cosa si fa istintivamente, anche quando nessuno guarda.
Costruire una cultura della sicurezza richiede un approccio sistematico e continuativo. Invece di un unico corso annuale, sono più efficaci interventi più brevi, frequenti e contestualmente rilevanti. Una notifica sul riconoscimento del quishing quando si usa un QR code in azienda. Un promemoria sul vishing durante un periodo di intense campagne di smishing documentate pubblicamente. Il contenuto giusto, al momento giusto, nella forma giusta.
Le simulazioni di phishing funzionano quando l’obiettivo è l’apprendimento, non la misurazione della colpa. Chi “cade” dovrebbe ricevere immediatamente una spiegazione di cosa è successo e perché, non una comunicazione al proprio responsabile. La discussione costruttiva trasforma un errore in un momento di apprendimento ad alto impatto.
Infine, ma non per importanza: il management deve agire come modello. Nessun programma di awareness funziona se il management non vi partecipa attivamente e visibilmente. Se il CEO bypassa le procedure di sicurezza per comodità, il messaggio implicito è più forte di qualsiasi corso di formazione. La sicurezza deve essere percepita come una priorità dall’alto verso il basso.
L’obiettivo finale di una azienda resistente agli attacchi non è azzerare gli errori, perché è impossibile, ma ridurre il tempo tra l’errore e la sua segnalazione. Un’organizzazione in cui le persone segnalano prontamente i comportamenti sospetti è più resiliente di una in cui la paura di essere giudicati porta a nascondere gli incidenti.

Ogni euro investito in firewall, EDR, SIEM e autenticazione multifattore è un euro ben speso. Ma nessuna di queste tecnologie può proteggere un’organizzazione da un dipendente che, sotto pressione, fornisce le proprie credenziali a qualcuno che sa come chiederle nel modo giusto.
Il fattore umano non è la parte più debole della catena di sicurezza: è la parte più complessa. E come tale, richiede un investimento proporzionale alla sua importanza: un programma continuativo, integrato nella cultura aziendale, supportato dal vertice.

Nel 2025, con l’AI che abbassa il costo e innalza la qualità degli attacchi di ingegneria sociale, non investire sugli esseri umani e sulla loro resilienza non è più una scelta neutrale. È un rischio che si sceglie deliberatamente di correre.