Cosa ci insegna il down dei servizi Microsoft: business continuity e governance

Quando Microsoft 365 si ferma, non si ferma un’applicazione: si ferma il modo in cui un’azienda comunica, condivide i documenti e prende decisioni. Il disservizio del 12 e 13 novembre 2026 è un caso di studio per la business continuity Microsoft 365, indipendentemente da come si sia originato e da come si sia risolto.

In queste pagine ripercorriamo prima i fatti, poi rispondiamo a una domanda che molti si pongono in questi momenti: i grandi fornitori cloud non dovrebbero essere sempre disponibili? Infine ci concentriamo sulla parte che dipende da noi, cioè le scelte di governance e di business continuity che permettono a un’organizzazione di continuare a lavorare quando un servizio esterno, per quanto solido, smette di rispondere.

Il punto di vista è quello di chi deve garantire la continuità operativa, non di chi segue la cronaca. Per questo l’attenzione va soprattutto alla dipendenza dai servizi, e non solo alla posta elettronica, che è stata la più visibile: anche i servizi legati ai file, come SharePoint e OneDrive, sono parte della stessa catena di dipendenze.

Cosa è successo il 12 e 13 novembre 2026

Il disservizio è iniziato nel pomeriggio di giovedì 12 novembre e si è trascinato per gran parte di venerdì 13, colpendo prima di tutto Exchange Online, cioè la posta di Outlook, e poi, a catena, altri servizi dell’ecosistema Microsoft 365. Secondo Forbes, gli utenti non riuscivano ad aprire le caselle e le email arrivavano in ritardo; risultavano coinvolti anche Teams, SharePoint Online, Microsoft 365 Copilot e Defender XDR. Le segnalazioni su Downdetector hanno toccato quota 130.000 nel pomeriggio di giovedì.

La portata è stata globale. Sky TG24 riporta che Downdetector ha registrato problemi in 74 Paesi e territori, con l’estensione del problema nel giro di circa un’ora. Tra le conseguenze, il ministero degli Esteri della Nuova Zelanda ha comunicato di non poter ricevere email, con effetti anche su ambasciate e consolati.

Le tappe dell’incidente

Cosa ha dichiarato Microsoft

La spiegazione è cambiata man mano che l’indagine procedeva. All’inizio Microsoft ha parlato di carico anomalo su una parte dell’infrastruttura. In seguito ha precisato, come riferisce Forbes, che l’aumento di carico non dipendeva da un picco di traffico degli utenti, ma dal fatto che alcuni server erano diventati inaspettatamente non disponibili, mettendo sotto pressione quelli rimasti attivi. Un processo incaricato di stabilire le connessioni sicure si è sovraccaricato e i server coinvolti hanno smesso di rispondere. Per contenere il problema l’azienda ha sospeso i rilasci, ridistribuito il traffico verso server non interessati e rimesso progressivamente in servizio quelli compromessi.

Al momento della stesura di questo articolo Microsoft non aveva ancora pubblicato una causa radice definitiva e aveva promesso un resoconto completo dopo la mitigazione. Per quello che ci interessa, però, il dettaglio tecnico conta meno del meccanismo: un problema su un componente condiviso dell’infrastruttura si è propagato a servizi che gli utenti considerano separati.

I grandi colossi non sono sempre disponibili?

No, e non lo sono mai stati: nessun grande fornitore cloud promette una disponibilità del 100%, e i contratti lo dicono chiaramente. La percezione contraria nasce dal fatto che, nella stragrande maggioranza dei giorni, il servizio funziona così bene da diventare invisibile. Ci sono quattro ragioni per cui l’interruzione resta comunque possibile.

1. La disponibilità è un obiettivo contrattuale, non una garanzia assoluta

Per Exchange Online, SharePoint Online, OneDrive e Teams l’impegno di Microsoft è un’uptime del 99,9%, misurato per singolo servizio e su base mensile, come ricorda Office 365 for IT Pros. Tradotto in tempo, significa che un servizio può restare fermo circa 43 minuti al mese, quasi 9 ore in un anno, senza violare l’accordo. Quando la soglia viene superata, il rimedio previsto è di norma un credito sul canone di quel servizio, non un risarcimento del danno subito, e spesso va richiesto dal cliente documentando l’impatto.

2. La scala amplifica ogni errore

Microsoft 365 conta oltre 450 milioni di licenze a pagamento, secondo i risultati fiscali citati nella stessa analisi di Office 365 for IT Pros. Su un sistema di queste dimensioni, un difetto che in un’azienda di medie dimensioni passerebbe inosservato diventa un evento globale nel giro di pochi minuti: a novembre il problema si è esteso a 74 Paesi in circa un’ora.

3. I servizi «separati» condividono componenti critici

Per l’utente, posta, file, chat e riunioni sono applicazioni diverse. Dietro le quinte, però, condividono identità e autenticazione, rete, bilanciamento del carico e sistemi di gestione. Quando si rompe uno di questi strati, il guasto non rispetta i confini tra i prodotti. Lo mostra anche l’incidente di novembre, in cui un processo dedicato alle connessioni sicure, sovraccaricato, ha coinvolto servizi diversi dalla sola posta.

4. Molti incidenti nascono da modifiche, non da guasti fisici

Negli ultimi mesi le cause dichiarate riguardano spesso configurazioni e rilasci, cioè il lavoro ordinario di evoluzione della piattaforma, più che eventi eccezionali. La tabella raccoglie alcuni episodi recenti, con la causa come comunicata da Microsoft o riportata dalle fonti indicate.

Due elementi emergono dal quadro. Il primo è che l’incidente di novembre non è un’eccezione, ma un episodio di una serie. Il secondo riguarda i file: nei casi di luglio e agosto SharePoint e OneDrive sono stati colpiti direttamente, non solo di riflesso. Chi ha ragionato come se i documenti fossero «al sicuro» perché la posta è il servizio più esposto ha fatto una valutazione incompleta.

La conclusione che conta

Il fornitore è responsabile di far funzionare il servizio e di ripristinarlo; l’organizzazione è responsabile di continuare a lavorare nel frattempo. È il principio della responsabilità condivisa, e vale anche per i grandi nomi. La domanda utile dopo un down non è «perché Microsoft si è fermata?», ma «cosa succede alla nostra azienda quando succede?».

Business continuity Microsoft 365: come possiamo, o potevamo, difenderci?

Non si può impedire a un fornitore di fermarsi, ma si può decidere in anticipo quanto costa all’organizzazione quel fermo. Le misure che seguono sono di governance prima che di tecnologia: richiedono decisioni, responsabilità assegnate e prove periodiche, e quasi nessuna richiede di abbandonare Microsoft 365.

1. Sapere da cosa dipendiamo davvero

Il punto di partenza è una analisi d’impatto sull’attività (BIA) che comprenda anche i servizi collaborativi, e non solo i gestionali. Per ogni processo critico va chiarito quali servizi lo sostengono, quanto tempo di fermo è tollerabile (RTO) e quanta perdita di dati è accettabile (RPO). Spesso emergono dipendenze che nessuno aveva mai scritto: il modulo d’ordine che vive in una libreria SharePoint, il flusso di approvazione che parte da una casella condivisa, il calendario di Teams da cui dipende un turno di reperibilità.

Il risultato è una mappa semplice: processo, servizio da cui dipende, tempo massimo di fermo, alternativa disponibile. Se la colonna dell’alternativa è vuota, quel processo è esposto.

2. Trattare i file come un servizio critico, non come un archivio

SharePoint e OneDrive ospitano spesso contratti, procedure, anagrafiche, listini e documentazione di sicurezza. Tre accorgimenti riducono l’esposizione:

• Individuare i documenti davvero indispensabili per continuare a operare (procedure di emergenza, contatti di fornitori e clienti, contratti in essere, credenziali di ripristino custodite in modo sicuro) e dichiararli come tali.
• Tenerne una copia accessibile fuori dal tenant, aggiornata con una frequenza coerente con l’RPO e raggiungibile anche se l’autenticazione cloud non risponde.
• Usare la sincronizzazione locale come ripiego, non come piano. I file mantenuti sul dispositivo possono servire per qualche ora, ma dipendono dallo stesso account e dalla stessa sincronizzazione: non coprono chi non li aveva scaricati e non proteggono dalle versioni non allineate.

Questo vale per i casi in cui anche i servizi file sono interessati direttamente, come è accaduto in alcuni dei precedenti elencati prima, e non solo quando il guasto parte dalla posta.

3. Distinguere tra backup e disponibilità

Il modello di responsabilità condivisa assegna al fornitore la disponibilità della piattaforma e al cliente la protezione dei propri dati. Un backup indipendente, realizzato con uno strumento di terze parti e custodito fuori dal perimetro Microsoft, protegge da cancellazioni, errori e perdite di dati. È però fondamentale non confonderlo con la continuità: durante un down serve sapere se quel backup è consultabile subito, da chi e con quali strumenti, oppure se serve un ripristino completo che richiede ore. La differenza si misura con una prova, non con la documentazione commerciale.

4. Garantire l’accesso di emergenza all’identità

Molti incidenti, compreso quello di agosto, toccano l’autenticazione. Governare questo rischio significa prevedere account amministrativi di emergenza («break-glass»), custoditi con procedure formali, esclusi dalle regole che potrebbero bloccarli e monitorati per ogni utilizzo. Significa anche sapere chi può gestire il tenant quando la console di amministrazione risponde lentamente o non risponde.

5. Avere canali di comunicazione alternativi

Se posta e Teams non funzionano, l’organizzazione deve comunque poter avvisare dipendenti, clienti e fornitori. Servono almeno un canale indipendente da Microsoft 365 (messaggistica aziendale, un sistema di notifica di massa, una lista telefonica aggiornata del gruppo di crisi) e messaggi pre-approvati per le situazioni più probabili, così che nessuno debba scriverli sotto pressione. Un aspetto spesso trascurato: anche il sito web e la segreteria telefonica possono diventare strumenti di comunicazione di emergenza.

6. Predisporre un runbook di degradazione, con ruoli e soglie

Un runbook efficace risponde a quattro domande: chi dichiara lo stato di crisi, in base a quali soglie (per esempio, interruzione superiore a un’ora di un servizio critico), chi comunica verso l’esterno, e quali attività passano in modalità manuale o alternativa. Deve prevedere livelli di gravità, perché un servizio lento non richiede la stessa risposta di un servizio fermo, e deve indicare chi è autorizzato a decidere eccezioni, come usare temporaneamente strumenti non standard senza creare rischi di sicurezza.

7. Monitorare lo stato del servizio e decidere con i dati

In un down, la prima informazione utile è sapere se il problema è interno o del fornitore. Conviene quindi che chi amministra il tenant segua le comunicazioni di stato del servizio nel centro di amministrazione, che esistano avvisi automatici e che l’esito venga registrato: ora di inizio, servizi colpiti, impatto sull’attività, azioni intraprese. Questi dati servono anche a valutare un’eventuale richiesta di crediti di servizio e a ricostruire l’accaduto nella revisione post-incidente.

8. Gestire il fornitore come rischio di terza parte

La dipendenza da un unico fornitore per posta, file, comunicazione e identità è un rischio di concentrazione e va trattata come tale: censita, valutata e portata all’attenzione di chi governa l’organizzazione. Per i soggetti che rientrano nella direttiva NIS2, e per il settore finanziario nel regolamento DORA, la gestione del rischio comprende esplicitamente continuità operativa, backup e sicurezza della catena di fornitura. Ma anche fuori da questi ambiti, standard come l’ISO 22301 offrono un riferimento solido per impostare la business continuity Microsoft 365 e, più in generale, un sistema di gestione della continuità.

In pratica, ciò significa verificare cosa dicono davvero gli SLA (misurazione, esclusioni, modalità di richiesta dei crediti), prevedere nei contratti obblighi di comunicazione e di analisi post-incidente, e valutare se per processi particolarmente critici sia ragionevole un’alternativa tecnica, anche solo parziale.

9. Provare, almeno una volta l’anno

Un piano di business continuity Microsoft 365 non provato è un’ipotesi. Un’esercitazione semplice, della durata di mezza giornata, in cui si simula l’indisponibilità di posta, file e identità e si osserva cosa accade davvero, è sufficiente a far emergere i punti deboli più gravi: contatti non aggiornati, copie obsolete, ruoli non chiari, procedure che nessuno conosce. Gli esiti vanno registrati e le azioni correttive assegnate con una scadenza.

Cosa quindi abbiamo imparato: dalla cronaca alla decisione

Il down del 12 e 13 novembre ricorda che la disponibilità dei servizi cloud, anche dei più grandi, è un obiettivo che il fornitore persegue e non un diritto acquisito. La business continuity Microsoft 365, invece, resta una responsabilità dell’organizzazione e si costruisce prima dell’incidente, con scelte semplici ma documentate e verificate.

Leggendo queste pagine, è probabile che più di una domanda abbia trovato la stessa risposta: «non l’abbiamo mai fatto», oppure «non lo so». Non abbiamo mai mappato da quali servizi dipende un processo, mai verificato un backup, mai stabilito chi decide in una crisi, mai provato a lavorare senza posta e senza file. Se è così, la conclusione è evidente: il problema non è il fornitore, ma l’assenza di una decisione. E una decisione, a differenza di un down, si può prendere quando si vuole.

Non è un’ipotesi teorica. Le aziende che seguiamo non hanno subito conseguenze particolari da questo down, se non, al più, per la posta elettronica. Non è stata fortuna: il problema era già stato valutato e avevano soluzioni in casa che hanno permesso di mitigarne gli effetti, senza criticità rilevanti. Il lavoro che conta si fa molto prima, in una giornata qualunque in cui nulla sembra andare storto.

Se leggendo ti sei accorto che da te qualcosa manca, puoi contattarci. Valutiamo insieme dove la tua organizzazione è esposta e quali soluzioni hanno senso nel tuo caso, così da non scoprirlo durante il prossimo disservizio.