Cosa è successo

Nella tarda serata di lunedì 19 e per tutta la mattina di martedì 20 ottobre 2026 la regione cloud europe-west2 di Google Cloud, che si ritiene sia quella di Londra, ha subito un'interruzione che Google ha attribuito a un "power event", cioè a un problema di alimentazione elettrica. Gli effetti sono stati errori e cadute di rete intermittenti su diversi servizi della regione, con ricadute a catena su molti clienti.

Il caso più visibile è quello di Revolut: la pagina di stato ha segnalato 28 servizi parzialmente non disponibili, fra cui accessi, pagamenti con carta, bonifici, cambio valuta, trading e chat di assistenza. In serata la società ha collegato il disservizio all'incidente di Google Cloud e ha comunicato il ripristino di tutti i servizi, ribadendo che denaro e dati dei clienti sono rimasti al sicuro. Secondo la stampa britannica sono stati coinvolti anche il servizio di videoconferenza cloud dei tribunali di Inghilterra e Galles (con ripercussioni su un'udienza in corso), l'app di budgeting Emma e, con segnalazioni di problemi, utenti di Lloyds, HSBC e Halifax, oltre a Royal Mail, DPD e Rightmove. Google si è scusata e ha suggerito ai clienti di spostare i carichi di lavoro su un'altra zona o regione; a metà giornata la maggior parte dei carichi risultava in ripresa.

Per correttezza: al momento non ci sono elementi che indichino un attacco informatico, e la causa indicata è fisica. Non sono noti, nelle fonti consultate, durata esatta del guasto per singolo cliente né causa tecnica di dettaglio; è probabile che Google pubblichi un'analisi post-incidente.

Perché è comunque una notizia di cybersecurity

La sicurezza delle informazioni si fonda su tre proprietà, e la disponibilità è una di esse. Un'interruzione non dolosa che ferma pagamenti e udienze giudiziarie è un evento di sicurezza nel senso che interessa a un risk manager. Il dato più istruttivo è che, secondo quanto riportato, la regione di Londra sembra essere l'unica regione Google Cloud nel Regno Unito: chi ha scelto di tenere i dati nel Paese per ragioni di residenza dei dati o di latenza ha di fatto scelto un singolo punto di guasto geografico, a meno di non aver progettato l'architettura per sopravvivere alla perdita della regione.

È il tipico rischio di concentrazione: molte organizzazioni, apparentemente indipendenti, dipendono dallo stesso fornitore nella stessa area. Quando il fornitore ha un problema, i guasti si correlano e la ridondanza interna di ciascun cliente non basta. Il fatto che lo stesso giorno siano stati colpiti una fintech, una compagnia postale, un corriere, un portale immobiliare e un servizio giudiziario mostra quanto la dipendenza sia diffusa e poco visibile.

Cosa significa per le aziende italiane

Il caso non riguarda direttamente l'Italia, ma lo schema è replicabile in qualunque regione. Molte imprese italiane usano le regioni cloud di Milano o di Francoforte, ognuna con zone di disponibilità: una zona può cadere senza che cada la regione, ma quando il problema è a livello di regione (alimentazione, rete, errore di configurazione del fornitore) la scelta "una sola regione" diventa un punto di guasto unico. Per una PMI che gestisce un e-commerce, un gestionale o la fatturazione su una singola regione, la domanda pratica è: se questa regione è fuori uso per mezza giornata, che cosa succede al mio fatturato e ai miei obblighi verso i clienti?

Un secondo punto riguarda la dipendenza indiretta. Revolut è un cliente di Google Cloud; chi si appoggia a Revolut per pagare fornitori o incassare ha, senza saperlo, una dipendenza da quella regione. Mappare i fornitori di secondo livello (i fornitori dei propri fornitori critici) è difficile ma è proprio ciò che chiedono le norme più recenti.

Contesto normativo

Per banche, assicurazioni, intermediari e fintech europee il riferimento è il regolamento DORA, applicabile dal 17 gennaio 2025: impone gestione del rischio ICT, test di resilienza, gestione dei fornitori critici di servizi ICT (compresi i cloud provider) con un registro dei contratti, strategie di uscita e valutazione esplicita del rischio di concentrazione. I gravi incidenti ICT vanno segnalati all'autorità di vigilanza con le tempistiche previste dal regolamento. Per i soggetti NIS2 non finanziari, la sicurezza della catena di approvvigionamento e la continuità operativa (gestione del backup, ripristino in caso di disastro, gestione delle crisi) sono misure minime obbligatorie, e un incidente significativo che comprometta la disponibilità di un servizio va notificato ad ACN con pre-notifica entro 24 ore e notifica entro 72 ore. Anche un disservizio causato da un terzo ricade nell'obbligo se ha impatto significativo sul proprio servizio. In sede di audit, il consulente si aspetta di vedere un piano di continuità testato, non solo scritto.

Cosa fare subito

  • Elencare quali servizi critici girano su cloud e in quale regione e zona; verificare se esiste una sola regione per ciascun servizio essenziale.
  • Definire obiettivi di ripristino (RTO e RPO) per ciascun servizio e confrontarli con ciò che l'architettura attuale può davvero garantire in caso di perdita di una regione.
  • Valutare un'architettura multi-regione (anche solo in modalità standby a caldo) per i servizi che non possono fermarsi, e copie di backup fuori dalla regione e preferibilmente fuori dal fornitore.
  • Provare il failover almeno una volta l'anno con un test reale, documentando tempi e problemi emersi.
  • Mappare le dipendenze dai fornitori di secondo livello (pagamenti, logistica, identity provider, servizi SaaS critici) e prevedere procedure manuali o alternative.
  • Preparare una comunicazione ai clienti pronta all'uso e un canale di stato indipendente dal servizio che si sta ripristinando.
  • Per chi è in perimetro DORA o NIS2, aggiornare il registro dei fornitori ICT e la valutazione del rischio di concentrazione, e verificare i criteri interni di classificazione e notifica degli incidenti causati da terzi.