Down Microsoft e NIS2, l’ACN: si notifica per l’impatto, non per la causa

Dopo il disservizio Microsoft del 12-13 novembre, l'ACN ricorda ai soggetti NIS che la notifica dipende dall'impatto. Ecco come valutare il caso e ridurre la dipendenza da un solo fornitore.

Down Microsoft e NIS2, l'ACN: si notifica per l'impatto, non per la causa
  • Il richiamo dell’ACN: dopo i disservizi Microsoft del 12 e 13 novembre 2026, l’Agenzia per la cybersicurezza nazionale ricorda ai soggetti NIS l’obbligo di notifica al CSIRT Italia quando l’impatto configura un incidente significativo.
  • Impatto, non causa: anche un guasto tecnico del fornitore può richiedere la notifica, se il disservizio supera i livelli di servizio attesi.
  • Chi è appena entrato nel perimetro: per i nuovi soggetti NIS del 2026 l’obbligo di notifica parte nel 2027. Per tutti resta aperto il tema della dipendenza da un unico fornitore.

Il guasto è di Microsoft, ma la valutazione dell’incidente spetta anche a chi ne usa i servizi. È il senso del chiarimento dell’ACN, riportato da Cybersecurity360, dopo il disservizio che fra il 12 e il 13 novembre ha bloccato Outlook, Teams e Copilot. Per aziende, PA e operatori soggetti alla NIS2 la domanda da porsi non è «di chi è la colpa», ma «quanto ci ha colpito».

Cosa è successo

Secondo TRIESTE.news, fra il 12 e il 13 novembre Outlook, Teams e Copilot hanno smesso di funzionare in 74 paesi, con un disservizio durato oltre dodici ore. La testata sottolinea che non si è trattato di un attacco informatico e che, almeno fino al momento della pubblicazione, Microsoft non aveva spiegato con chiarezza la causa del problema. Il quadro descritto è quello di uffici fermi, riunioni saltate, caselle di posta irraggiungibili e malfunzionamenti a singhiozzo.

Su questo sfondo si inserisce il richiamo dell’ACN. Come riporta Cybersecurity360, per i soggetti NIS già obbligati i disservizi Microsoft richiedono la notifica se superano i livelli di servizio attesi: l’Agenzia chiarisce che conta l’impatto, anche quando la causa è tecnica. In altre parole, il fatto che l’origine del problema sia esterna all’organizzazione e non dolosa non esclude l’obbligo di notificare al CSIRT Italia, se le conseguenze configurano un incidente significativo. La stessa testata precisa che per i soggetti entrati nel perimetro NIS nel 2026 l’obbligo di notifica parte nel 2027.

Un secondo contributo di Cybersecurity360 allarga lo sguardo: il disservizio ha riportato al centro il rischio di concentrazione tecnologica. Tante scelte IT, singolarmente corrette, possono sommarsi fino a creare dipendenze critiche per il business. La NIS2, ricorda l’articolo, richiama le responsabilità del management: non basta affidarsi a un fornitore, occorre conoscere, valutare e governare i rischi delle proprie scelte.

Non è un caso isolato

TRIESTE.news ricorda alcuni precedenti: a ottobre 2025 un guasto ad Amazon Web Services ha messo fuori uso molti siti e app nel mondo. Il 29 ottobre è toccato a Microsoft Azure, per una configurazione errata, secondo le ricostruzioni, nel servizio Azure Front Door; in Olanda i distributori di biglietti e i sistemi di pianificazione dei viaggi delle ferrovie sono rimasti offline per ore. Nel luglio 2024 c’era stato il caso CrowdStrike. La testata cita inoltre la stima secondo cui oltre il 70 per cento del mercato cloud europeo è controllato da Amazon, Microsoft e Google, avvertendo però che la cifra va presa con cautela perché le stime variano a seconda di chi misura.

Perché riguarda anche te

Per un’organizzazione nel perimetro NIS2 il messaggio è operativo: non si può attendere la spiegazione del fornitore per decidere se notificare. Se la posta elettronica, la collaborazione o i flussi che dipendono da quei servizi sono rimasti fermi oltre quanto previsto dai propri livelli di servizio, la valutazione va fatta subito e documentata. Lo stesso vale, in prospettiva, per i soggetti entrati nel 2026: hanno tempo fino al 2027 per farsi trovare pronti, ma un episodio come questo è un’ottima esercitazione reale.

Per le PMI che non rientrano direttamente nella NIS2 ma lavorano come fornitori di soggetti obbligati, il tema è contrattuale e reputazionale: i clienti chiederanno sempre più spesso come si gestisce la continuità quando un servizio cloud si ferma. TRIESTE.news descrive bene il meccanismo del lock-in: identità elettronica, posta, documenti, calendari, videoconferenze e licenze sono intrecciati, e uscirne costa in denaro, tempo e formazione.

Anche famiglie e professionisti che usano Outlook per la posta personale hanno vissuto il problema in prima persona: caselle irraggiungibili per ore significano messaggi attesi che potrebbero non essere stati visti e scadenze a rischio.

Come proteggersi / Cosa fare

  1. Ricostruisci la timeline dell’impatto. Annota quali servizi si sono fermati, per quanto tempo, quali processi e quanti utenti sono stati coinvolti. Confronta questi dati con i livelli di servizio attesi: è il criterio richiamato dall’ACN.
  2. Valuta la significatività e documenta la decisione. Applica i criteri previsti per gli incidenti significativi. È buona pratica conservare traccia scritta anche della scelta di non notificare, con le motivazioni.
  3. Non aspettare la causa per notificare. Se l’impatto è significativo, la notifica al CSIRT Italia va fatta nei termini previsti dalla normativa, anche se il fornitore non ha ancora chiarito l’origine del guasto.
  4. Verifica la tua posizione nel perimetro. Soggetto già obbligato o nuovo ingresso 2026 con obbligo dal 2027? Nel secondo caso usa questi mesi per definire procedure, ruoli e soglie interne.
  5. Mappa le dipendenze da un singolo fornitore. Identità, posta, documenti e videoconferenze sullo stesso ecosistema sono un unico punto di guasto: rendilo visibile al management, che la NIS2 chiama a governare questi rischi.
  6. Prepara canali alternativi. Buona pratica di settore: una lista di contatti telefonici aggiornata, un canale di messaggistica di riserva e procedure scritte per lavorare in modalità degradata.
  7. Diversifica dove serve davvero. Per i servizi critici valuta architetture multi-cloud, connettività ridondante su percorsi e operatori diversi e colocation per i carichi che devono restare sotto controllo diretto.
  8. Per gli utenti di Outlook. Quando il servizio torna regolare, controlla che i messaggi attesi nei giorni del disservizio siano arrivati e, nel dubbio, chiedi al mittente di reinviarli. Diffida delle email che, con il pretesto del disservizio, chiedono di reinserire password o dati: è una tecnica di phishing ricorrente dopo i grandi guasti.

Il punto di vista Nexim

Da operatore di rete leggiamo il chiarimento dell’ACN come un cambio di prospettiva utile: la resilienza si misura sull’effetto per gli utenti, non sull’origine del guasto. Lo stesso principio vale per un attacco volumetrico che satura un collegamento o per un errore di configurazione a monte: in entrambi i casi il servizio non è disponibile e l’organizzazione deve saperlo rilevare, misurare e gestire. Per questo consigliamo di progettare la continuità su più livelli, dalla connettività ridondante alla protezione DDoS e sicurezza di rete, fino alla distribuzione dei carichi critici fra cloud e colocation. Nessuna architettura elimina il rischio, ma ridurre i punti unici di guasto rende anche la valutazione NIS2 più semplice e più rapida.

Fonti

#Nexim #NeximGlobal #NIS2 #Cybersecurity #ACN #CSIRTItalia #BusinessContinuity #Microsoft #Cloud #IncidentResponse #MultiCloud

Il video in 54 secondi