Il 12 settembre 2026 la società fintech Revolut ha confermato quella che ha definito una sofisticata truffa di impersonificazione esterna: una parte non autorizzata ha usato un indirizzo email su un dominio legittimo di un'agenzia governativa per inviare richieste fraudolente di informazioni sui clienti. Le richieste sono state soddisfatte prima che lo schema venisse scoperto.

Ciò che rende questo incidente degno della tua attenzione è che non contiene alcuna violazione nel senso consueto. Nessuna vulnerabilità del software, nessuna password trapelata, nessun malware. La stessa Revolut ha dichiarato che i suoi sistemi e i fondi dei clienti non sono stati colpiti. Qualcuno ha chiesto i dati nel modo corretto, attraverso il canale corretto, e li ha ricevuti. È proprio per questo che la vicenda riguarda ogni azienda che conserva dati dei clienti, non solo le banche.

Cosa è effettivamente confermato

Ci limitiamo a ciò che l'azienda ha annunciato e a ciò che hanno riportato le testate specializzate, perché l'indagine è in corso e molto resta non divulgato:

  • Il metodo: email inviate da un account non autorizzato all'interno di un dominio appartenente a una vera agenzia governativa, con il peso di una richiesta di informazioni ufficiale.
  • I dati: dati identificativi e di contatto tra cui data di nascita, indirizzo postale, indirizzo email e numero di telefono, oltre a copie di documenti d'identità come passaporti e patenti di guida, insieme alle immagini di verifica facciale raccolte durante i controlli di adeguata verifica della clientela (know your customer).
  • La portata: l'azienda ha parlato di un numero limitato di clienti e non ha diffuso alcuna cifra.
  • L'agenzia: Revolut ha rifiutato di nominare l'ente governativo il cui dominio è stato usato, citando l'indagine in corso.
  • La risposta: l'indirizzo è stato bloccato, i clienti coinvolti sono stati avvisati direttamente e l'azienda ha allertato l'agenzia governativa interessata, le forze dell'ordine, le autorità di vigilanza finanziaria e le autorità per la protezione dei dati.

Un ricercatore di sicurezza nel settore crypto noto come ZachXBT ha valutato che gli obiettivi sembravano essere clienti con patrimoni elevati, il che suggerisce la costruzione di profili dettagliati piuttosto che una raccolta indiscriminata. Si tratta della valutazione di un ricercatore e non di una dichiarazione dell'azienda, e la citiamo come tale.

Perché la richiesta ha funzionato: l'autenticazione non è autorizzazione

La maggior parte dei sistemi di posta aziendali si basa su controlli tecnici che confermano che un messaggio proviene davvero dal dominio che dichiara. Questi controlli funzionano bene contro le falsificazioni ordinarie: chi impersona un dominio che non controlla viene respinto. Ma sono stati costruiti per rispondere esattamente a una sola domanda: questo messaggio è partito da quel dominio?

Non è questa la domanda a cui ti serve una risposta. La tua domanda è se la persona che ha scritto il messaggio è autorizzata a chiedere ciò che chiede. Nessun controllo delle email risponde a questo. La distanza tra le due domande è la distanza tra autenticazione e autorizzazione, ed è il varco attraverso cui è passata l'intera operazione. Quando l'account mittente si trova all'interno del dominio autentico, che sia compromesso o configurato per errore, ogni indicatore di fiducia che il tuo team può vedere sarà verde.

La conseguenza pratica: il compito del tuo gateway di posta finisce con la consegna integra della richiesta. Giudicare la richiesta è un lavoro umano, e richiede una procedura scritta anziché l'istinto individuale.

La tua azienda riceve la stessa richiesta in forma più semplice

È facile archiviare tutto questo come la storia lontana di una fintech europea. Ma le richieste che arrivano ogni giorno alle aziende saudite sono la stessa cosa con un abito più semplice: un'email che chiede l'estratto conto di un cliente, un messaggio che richiede i dati dei dipendenti per una finalità normativa, una telefonata che chiede di confermare i dettagli di un contratto, una comunicazione da un indirizzo con un nome ufficiale familiare che chiede documenti per completare una pratica.

Nella maggior parte delle piccole e medie imprese quella richiesta viene gestita così: arriva a un dipendente, il mittente sembra ufficiale, rifiutare un ente ufficiale sembra più rischioso che assecondarlo, e il file viene inviato. Non resta traccia di chi ha chiesto, di cosa è uscito o di quando. Non c'è alcun passaggio di verifica indipendente. Quando il problema emerge più tardi, l'azienda non ha nulla con cui ricostruire i fatti.

Nota anche la pressione esercitata. Urgenza e apparenza ufficiale, insieme, sono ciò che disattiva la verifica. Un dipendente che teme di essere accusato di ostacolare una procedura governativa salterà la telefonata di conferma, e questo è l'effetto voluto dell'approccio, non un effetto collaterale.

Cosa ti richiede la legge saudita

La Legge sulla protezione dei dati personali (PDPL) non lascia la questione aperta. Impone alla tua azienda un duplice obbligo: comunicare i dati solo dove è consentito, e segnalare quando sbagli.

  • L'articolo 15 stabilisce i casi in cui i dati personali possono essere comunicati, tra cui quando la parte richiedente è un ente pubblico e la richiesta serve una finalità di sicurezza, attua un'altra legge o soddisfa requisiti giudiziari, come specificato dal regolamento di attuazione.
  • L'articolo 16 disciplina i casi in cui la comunicazione deve essere negata, tra cui quando danneggerebbe la sicurezza nazionale, metterebbe in pericolo l'incolumità delle persone o interferirebbe con un'indagine in corso.
  • L'articolo 20 obbliga il titolare del trattamento a notificare all'autorità competente e agli interessati una violazione o una comunicazione illecita. Il regolamento di attuazione fissa un termine di 72 ore per notificare l'autorità competente tramite la National Data Governance Platform.

Leggendo i tre articoli insieme emerge il punto decisivo: la legge concede il diritto all'ente pubblico, non all'email. Una richiesta che arriva dal dominio di un ente pubblico non diventa per questo una sua richiesta. L'obbligo giuridico di verifica resta a te, in qualità di titolare del trattamento, e non si trasferisce a un mittente solo perché sembrava ufficiale.

Il punto di vista di Origami

Origami è un'azienda tecnologica che costruisce sistemi per le imprese saudite, e uno schema che vediamo di continuo è che quasi tutti gli investimenti in sicurezza vanno nella prevenzione degli accessi non autorizzati: password, autenticazione a due fattori, firewall. Sono necessari, ma sorvegliano una sola porta. L'incidente di cui parliamo non è mai passato dalla porta. Ha bussato, ha chiesto i dati e se li è visti consegnare. Nessuna impostazione tecnica impedisce a un dipendente autorizzato di inviare un file a qualcuno che lo ha chiesto in un modo che sembrava corretto.

Per questo trattiamo i dati in uscita dall'azienda come una procedura integrata nel sistema anziché come un'indicazione scritta in un manuale: chi detiene il permesso di esportare i dati dei clienti, se ogni esportazione viene registrata con chi l'ha fatta, quando e perché, e se le richieste di terzi seguono un percorso di approvazione. Un'azienda che sa rispondere in un minuto a quali dati sono usciti il mese scorso e perché ha qualcosa con cui difendersi. Un'azienda che non lo sa scoprirà la lacuna il giorno in cui avrà bisogno della risposta.

Una procedura di una pagina da adottare questa settimana

Non servono progetti né budget. Serve una regola scritta e resa pubblica che protegga il tuo dipendente dal dover decidere da solo sotto pressione:

  • Nessun dato di clienti o dipendenti esce sulla sola base di un messaggio ricevuto. Il messaggio apre la richiesta; non la esegue, per quanto ufficiale sembri il mittente e per quanto urgente sia il tono.
  • Verifica attraverso un canale indipendente. Non rispondere al messaggio e non chiamare un numero scritto al suo interno. Chiama il numero pubblicato sul sito ufficiale dell'ente. Quel solo passaggio avrebbe fermato l'intera operazione.
  • Un approvatore nominato. Una persona autorizzata a rilasciare dati a una parte esterna, con un sostituto nominato per le assenze. Distribuire il permesso a tutti significa che nessuno ne risponde.
  • Un registro scritto per ogni richiesta. Chi ha chiesto, in quale veste, quali dati, chi ha approvato, come è stata verificata e la data. Basta una riga in un foglio di calcolo, e il suo valore si vede un anno dopo, non oggi.
  • Invia il minimo. Se la richiesta è legittima, invia esattamente ciò che è stato chiesto, non l'intero fascicolo o l'intera tabella. Il volume che invii è l'entità del danno se la richiesta si rivela fraudolenta.
  • Conosci il percorso di segnalazione prima di averne bisogno. Chi notifica la SDAIA entro 72 ore, tramite quale piattaforma, con quali dettagli. Il tempo speso a cercare la procedura viene sottratto direttamente alla scadenza.

Il principio alla base di tutto è che la verifica non è un ostacolo. Un vero ente ufficiale non avrà nulla da obiettare a una telefonata di conferma fatta al proprio numero pubblicato, e chi si oppone a essere verificato è esattamente chi andrebbe verificato. Mettilo per iscritto per il tuo team, così che rifiutare una richiesta non sia mai un rischio personale che un singolo dipendente debba portare da solo.

Fonti