Microsoft down, il vero problema non è il cloud: è chi ha deciso di dipenderne

Il disservizio Microsoft del 12 e 13 novembre 2026 ha riacceso il dibattito sull’affidabilità dei servizi cloud, sulla continuità operativa e sugli obblighi di notifica previsti dalla NIS2.

Come approfondito da Paolo Tarsitano nell’articolo “Disservizi Microsoft, l’ACN chiarisce gli obblighi NIS2: conta l’impatto, non la causa”, la responsabilità di valutare l’impatto di un incidente non scompare quando il problema nasce nell’infrastruttura di un fornitore.

Ma c’è una domanda che viene ancora prima dell’incidente e che raramente trova spazio nelle discussioni tecniche: chi ha deciso che così tante funzioni aziendali dovessero dipendere dallo stesso ecosistema tecnologico?

Non è una critica a Microsoft, né al modello cloud. È una questione di governo del rischio.

La concentrazione tecnologica è una scelta, anche quando non ce ne accorgiamo

Posta elettronica, identità digitali, collaborazione, gestione degli endpoint, archiviazione documentale, applicazioni aziendali e strumenti di sicurezza possono appartenere allo stesso ecosistema.

Questa integrazione offre vantaggi evidenti: semplifica l’amministrazione, riduce alcune complessità operative, facilita la gestione delle identità e permette di adottare controlli coerenti.

Il problema nasce quando i benefici dell’integrazione vengono valutati accuratamente, mentre il rischio derivante dalla concentrazione delle dipendenze resta implicito.

Un’organizzazione può aver scelto Microsoft 365 per la posta, aver introdotto Teams per la collaborazione, aver esteso Entra ID alla gestione delle identità e successivamente adottato Intune e Defender.

Ogni singola decisione può essere tecnicamente ed economicamente giustificabile. La somma di queste decisioni, però, può produrre un livello di dipendenza che nessuno ha mai valutato nel suo insieme.

Il rischio di concentrazione non nasce necessariamente da una decisione sbagliata. Può nascere da molte decisioni corrette, prese separatamente.

È qui che il problema smette di essere tecnologico e diventa una questione di governance.

Chi ha accettato il rischio?

In molte aziende la scelta delle piattaforme tecnologiche viene ancora considerata una prerogativa dell’IT.

Finché si parla di configurazioni, architetture o strumenti operativi, è ragionevole che il reparto tecnico mantenga un’adeguata autonomia.

Ma quando una scelta determina una dipendenza significativa, modifica la capacità di garantire la continuità dei processi o rende particolarmente onerosa la sostituzione di un fornitore, non siamo più davanti a una decisione esclusivamente tecnica.

Stiamo decidendo quanto rischio l’organizzazione è disposta ad assumersi.

Il CISO può identificare e valutare il rischio. L’IT può illustrare le alternative, stimare le complessità di migrazione e proporre misure compensative. Ma la decisione di accettare un rischio residuo rilevante deve essere assunta al livello organizzativo che possiede l’autorità per farlo.

L’articolo 23 del D.Lgs. 138/2024 richiama le responsabilità degli organi di amministrazione e direttivi dei soggetti essenziali e importanti: approvazione delle modalità di implementazione delle misure di gestione del rischio, supervisione degli obblighi e responsabilità previste dalla normativa.

Questo non significa che il Consiglio di amministrazione debba scegliere tra Microsoft, Google o altri fornitori. Significa che deve essere messo nelle condizioni di comprendere le conseguenze delle scelte che producono rischi rilevanti per l’impresa.

Un CdA non deve sapere configurare un tenant Microsoft. Deve sapere quanto costa, in termini di rischio aziendale, non poterne fare a meno.

La non fungibilità non è sempre una condizione inevitabile

Durante il confronto sui disservizi Microsoft è emerso più volte il concetto di fornitore non fungibile.

Ma dobbiamo evitare un equivoco: la non fungibilità non è necessariamente una caratteristica intrinseca del fornitore.

In molti casi è una condizione costruita dall’organizzazione nel corso degli anni.

Integrazioni applicative, automatismi, gestione centralizzata delle identità, formati documentali, competenze interne, personalizzazioni e processi operativi possono rendere la sostituzione di una piattaforma estremamente difficile.

Non perché sul mercato non esistano alternative, ma perché l’azienda ha progressivamente adattato il proprio funzionamento a quell’ecosistema.

Qui occorre distinguere due concetti: la rilevanza del fornitore ai fini NIS e la sua sostituibilità operativa.

Una fornitura ICT che rientra nei criteri previsti può essere rilevante indipendentemente dalla fungibilità. Il livello di lock-in, invece, descrive quanto sia concretamente difficile interrompere o sostituire quel rapporto.

Non dobbiamo confondere i due piani.

Il fornitore non diventa strategico soltanto perché offre un servizio importante. Diventa anche difficile da sostituire quando abbiamo costruito attorno a lui una parte consistente del nostro modello operativo.

Quanto costa davvero poter cambiare fornitore?

La domanda più scomoda non è se Microsoft sia affidabile.

È un’altra: se domani decidessimo di sostituire l’ecosistema Microsoft, quanto tempo e quali risorse sarebbero necessari per farlo senza compromettere il business?

Non parliamo semplicemente di esportare i dati o trasferire alcune caselle di posta.

Bisognerebbe valutare la migrazione delle identità, le dipendenze applicative, le integrazioni, le competenze necessarie, i contratti, gli automatismi e l’impatto sui processi aziendali.

Un piano di uscita credibile deve considerare questi fattori, anche quando non è economicamente opportuno realizzare una strategia multi-cloud o mantenere infrastrutture alternative permanentemente operative.

La ridondanza, infatti, non è gratuita e non sempre è la soluzione migliore. Aggiungere piattaforme può introdurre nuova complessità, costi e ulteriori rischi di sicurezza.

La governance non impone di duplicare tutto.

Impone di conoscere le alternative disponibili, valutarne costi e benefici e decidere consapevolmente quali dipendenze accettare.

Non possiamo eliminare ogni rischio tecnologico, ma possiamo evitare che rimanga sconosciuto o che venga assunto senza una decisione esplicita.

Quando la governance arriva dopo l’incidente

Il vero problema emerge quando un’interruzione mette in evidenza dipendenze che l’organizzazione non aveva mai considerato.

Il management scopre che un processo considerato autonomo utilizza un’identità centralizzata. Un’applicazione apparentemente indipendente richiede servizi Microsoft per funzionare. Uno strumento di sicurezza dipende, almeno in parte, da componenti dello stesso ecosistema.

A quel punto l’incidente non sta soltanto interrompendo un servizio: sta rivelando decisioni di architettura e di sourcing di cui l’organizzazione non aveva piena consapevolezza.

Questo non significa necessariamente che la governance sia assente. Significa che potrebbe aver governato singole tecnologie senza governare adeguatamente le dipendenze tra di esse.

Una corretta valutazione del rischio dovrebbe invece permettere di risalire dalle funzioni aziendali alle dipendenze tecnologiche e ai fornitori, individuando dove si concentrano gli elementi la cui indisponibilità può compromettere più attività contemporaneamente.

Ma questa conoscenza deve arrivare prima della crisi, perché durante un incidente serve a prendere decisioni, non a ricostruire da zero l’organizzazione.

La NIS2 come occasione per rimettere le decisioni al posto giusto

La NIS2 non nasce per imporre alle imprese uno specifico modello tecnologico e non vieta di concentrare servizi presso un unico grande provider.

Richiede piuttosto un approccio strutturato alla gestione dei rischi, alla sicurezza della catena di approvvigionamento e alla responsabilizzazione degli organi di governo.

È un passaggio che rischiamo di perdere quando trasformiamo l’adeguamento normativo in una sequenza di documenti da produrre.

La documentazione ha valore quando rende esplicite scelte, responsabilità e criteri decisionali.

Un registro dei fornitori dovrebbe contribuire a rendere visibili le dipendenze. Una valutazione del rischio dovrebbe aiutare a comprenderne le conseguenze. Un piano di trattamento dovrebbe documentare ciò che abbiamo deciso di mitigare e ciò che abbiamo consapevolmente accettato.

Non si tratta di produrre più carta, ma di utilizzare quella carta per orientare decisioni reali.

Il disservizio Microsoft, da questo punto di vista, è un caso esemplare.

Microsoft ha affrontato un problema infrastrutturale. Le organizzazioni hanno sperimentato le conseguenze delle proprie dipendenze tecnologiche.

Sono due responsabilità diverse, che non si escludono.

Possiamo delegare a un fornitore l’erogazione di un servizio. Non possiamo delegargli la responsabilità delle nostre scelte di rischio.

È proprio qui che si misura la maturità della governance: non nella capacità di spiegare perché Microsoft si sia fermata, ma nella capacità di dimostrare che l’organizzazione aveva compreso, valutato e accettato consapevolmente le conseguenze di quella dipendenza.