Il guasto è di Microsoft, ma la valutazione dell’incidente spetta anche all’azienda che ne utilizza i servizi. Dopo i disservizi del 12 e 13 novembre 2026, l’Agenzia per la cybersicurezza nazionale (ACN) richiama i soggetti NIS all’obbligo di notifica al CSIRT Italia quando l’impatto configura un incidente significativo.
Per la disponibilità, conta il superamento dei livelli di servizio documentati dall’organizzazione. La causa tecnica del blackout non esclude l’adempimento.
Prima di attivare la procedura occorre, però, verificare da quando decorre l’obbligo: per i soggetti inseriti per la prima volta nell’elenco NIS nel 2026, la determinazione ACN n. 127434/2026 lo fa partire dal 1° gennaio 2027; per quelli inseriti nel 2025 e confermati nel 2026 restano i termini precedenti. L’appartenenza al perimetro e la decorrenza della notifica sono due informazioni da leggere insieme.
Decorrenza delle notifiche di base: due gruppi distinti
| Soggetti | Decorrenza | Cosa verificare |
| Inseriti nel 2025 e confermati nel 2026 | Nove mesi dalla ricezione della comunicazione di inserimento | Data della comunicazione e termini applicabili al soggetto |
| Inseriti per la prima volta nel 2026 | 1° gennaio 2027 | La decorrenza riguarda gli incidenti significativi di base; verificare eventuali altri regimi |
Fonti: ACN, determinazione 379907/2025, art. 3, e determinazione 127434/2026, art. 1. Quadro applicabile al 14 novembre 2026.
Indice degli argomenti
Disservizi Microsoft: che cosa è successo e perché riguarda la NIS2
Negli aggiornamenti Microsoft ripubblicati dall’Università della Pennsylvania, l’incidente MO1550821 risulta classificato come ripristinato nella rilevazione del 14 novembre. L’azienda attribuisce l’evento a un problema introdotto durante un precedente ampliamento della capacità di rete, emerso dopo una modifica successiva, ed esclude un’origine cyber o legata ad agenti AI.
La comunicazione descrive un recupero graduale e annuncia un rapporto post-incidente: il ripristino va comunque verificato sui servizi effettivamente utilizzati da ciascuna organizzazione.
Il coinvolgimento di Exchange Online ha prodotto difficoltà nell’accesso alla posta e ritardi di consegna, con effetti sulle funzioni di altri prodotti dipendenti da email, calendari e dati Exchange. Microsoft ha segnalato anche problemi nell’accesso a pagine di Defender XDR e in alcune funzioni di Purview. Il perimetro era diverso secondo la funzionalità: le componenti indipendenti da Exchange potevano continuare a funzionare.
In Italia, il Ministero della Giustizia ha segnalato ripercussioni anche sull’applicativo APP: il redattore degli atti utilizza i servizi online Microsoft e poteva presentare problemi di apertura, redazione e salvataggio. È un esempio di dipendenza applicativa: un guasto esterno raggiunge un’attività dell’organizzazione attraverso una funzione incorporata nel suo processo di lavoro.
Per un soggetto NIS questa catena impone di ricostruire quali attività siano state realmente compromesse. Il numero di segnalazioni mondiali di Outlook dice poco sulla singola azienda: servono evidenze dell’impatto locale, dalla durata dei malfunzionamenti alle operazioni rimaste bloccate.
Quando scatta la notifica: i livelli di servizio del soggetto NIS
Nel chiarimento sui disservizi, ACN afferma che “la cosiddetta root cause non è determinante”. Il soggetto deve verificare le fattispecie della determinazione n. 379907/2025. Il richiamo alla FAQ ISB.F.2 riguarda proprio gli incidenti del fornitore che diventano significativi anche per servizi e attività del cliente NIS: l’eventuale adempimento del fornitore non sostituisce la valutazione del cliente.
Negli incidenti di base per i soggetti importanti, la fattispecie IS-3 riguarda l’evidenza della violazione dei livelli di servizio attesi per servizi o attività. La stessa fattispecie compare nell’allegato per i soggetti essenziali. Il confronto si fonda sui livelli definiti ai sensi della misura DE.CM-01.
La misura DE.CM-01 delle specifiche di base richiede strumenti per rilevare tempestivamente gli incidenti significativi e livelli di servizio attesi documentati. Operativamente, l’organizzazione deve poter collegare un’anomalia tecnica a un servizio: quali utenti coinvolge, quali operazioni impedisce e quale livello atteso è stato violato. Lo SLA contrattuale del cloud provider è un elemento dell’analisi; va ricondotto ai servizi e alle attività del soggetto.
Si pensi, come esempio ipotetico, a due imprese che utilizzano la stessa piattaforma: nella prima, un canale alternativo mantiene l’attività entro i livelli attesi; nella seconda, l’indisponibilità della posta blocca un processo rilevante oltre il livello documentato. La stessa anomalia del fornitore conduce a valutazioni diverse perché cambia l’effetto sui servizi del cliente.
Chi deve notificare ora e quali termini deve rispettare
Questa valutazione va letta insieme al calendario applicabile al soggetto. L’articolo 3 della determinazione 379907/2025 fissa la decorrenza degli obblighi di notifica degli incidenti di base a nove mesi dalla ricezione della comunicazione di inserimento nell’elenco. Per i nuovi ingressi 2026 vale invece la data del 1° gennaio 2027 stabilita dalla determinazione 127434/2026. Restano da considerare gli eventuali ulteriori obblighi applicabili all’organizzazione in forza di altri regimi.
Per chi è già obbligato, l’articolo 25 del D.lgs. 138/2024, che recepisce la NIS2 in Italia, fa partire i termini dalla conoscenza dell’incidente significativo. Pre-notifica entro 24 ore e notifica entro 72 ore sono limiti massimi, accompagnati dal dovere di procedere senza ingiustificato ritardo. Non si aggiungono 72 ore alle prime 24.
La sequenza consente di comunicare mentre l’accertamento è in corso. Le linee guida ACN sulla gestione degli incidenti prevedono una prima trasmissione con le informazioni effettivamente disponibili, seguita dagli approfondimenti.
Attendere il rapporto conclusivo Microsoft rischierebbe di far perdere tempo utile per descrivere conseguenze che l’organizzazione conosce già.
La sequenza delle notifiche NIS
Sequenza ordinaria delle notifiche NIS: termini massimi, senza ingiustificato ritardo. Le prime due scadenze partono dalla conoscenza dell’incidente significativo. Per i prestatori di servizi fiduciari, la notifica degli incidenti sui servizi fiduciari è entro 24 ore. Fonte: D.lgs. 138/2024, art. 25, commi 5 e 6. Quadro al 14 novembre 2026.
La trasmissione avviene attraverso il portale delle segnalazioni ACN. Per prepararla, il referente CSIRT deve ricevere dai tecnici e dai responsabili delle attività una ricostruzione condivisa: servizio compromesso, impatto, evidenze temporali e misure adottate. Il codice dell’incidente Microsoft serve a collegare il caso all’evento del fornitore, mentre la descrizione deve rendere visibili le conseguenze sul soggetto notificante.
Che cosa raccogliere durante il disservizio
La ricostruzione diventa più affidabile se parte dai processi aziendali. Il responsabile IT può misurare gli errori di connessione, ma chi gestisce il servizio deve spiegare quali richieste non vengono lavorate, quali scadenze sono esposte e se il canale alternativo sta reggendo. Un registro unico evita che ticket tecnici e impatti operativi rimangano in archivi separati.
Conviene annotare orari e fusi, momento della rilevazione e della conoscenza della significatività, utenti e sedi coinvolti, funzioni indisponibili e risultati dei tentativi di continuità. Conservare ticket, estratti dei monitoraggi e comunicazioni del provider permette di ricostruire la decisione anche dopo il ripristino. Se la valutazione conclude che la fattispecie non ricorre, è utile registrarne ragioni ed evidenze e riesaminarla al mutare degli impatti.
Vanno conservati anche i riscontri delle verifiche di ripristino: accesso alle caselle, consegna dei messaggi in coda, esecuzione dei flussi collegati e disponibilità degli strumenti di sicurezza utilizzati. Una dashboard del provider migliorata può precedere il recupero dell’ultimo processo aziendale rimasto fermo. La chiusura operativa deve basarsi su prove coerenti con il servizio che l’organizzazione deve erogare.
Gestire l’emergenza quando anche i canali di risposta sono coinvolti
Se il guasto coinvolge posta, collaborazione e accesso alle console, può rallentare anche il gruppo incaricato di gestirlo. Per questo è opportuno predisporre canali di emergenza indipendenti dalle dipendenze interessate: recapiti dei referenti disponibili offline, modalità alternative per coordinarsi e accessi autorizzati verificati in anticipo. La prova utile consiste nel simulare l’indisponibilità della piattaforma abituale e completare comunque l’escalation.
Le deroghe temporanee richiedono altrettanta disciplina. Per recuperare un flusso di lavoro è preferibile utilizzare alternative già autorizzate, con responsabile, durata e successiva revoca delle eccezioni. Spostare documenti su account personali o ridurre indiscriminatamente i controlli può aggiungere un problema di sicurezza al guasto iniziale. Il registro dell’incidente dovrebbe tenere traccia anche delle modifiche adottate per continuare a lavorare.
L’urgenza aumenta, inoltre, l’esposizione ai falsi interventi di assistenza. ACN invita a prestare attenzione a chiamate, e-mail, link, chat e pubblicità che impersonano Microsoft. È opportuno confermare ogni richiesta tramite recapiti già conosciuti e seguire gli aggiornamenti sui canali ufficiali, evitando di autorizzare accessi remoti o consegnare credenziali a chi si presenta durante il disservizio.
Dopo il ripristino: correggere le dipendenze che hanno fermato i servizi
Le evidenze raccolte devono servire anche a rivedere la continuità operativa. Per ciascun processo fermato, l’organizzazione può confrontare livello atteso, durata effettiva dell’interruzione e capacità della soluzione alternativa. Se il canale di riserva dipende dalla stessa posta o dagli stessi servizi indisponibili, occorre correggere quella dipendenza e ripetere la prova.
Il confronto con il fornitore deve poi produrre informazioni utilizzabili: cronologia tecnica, componenti coinvolte, cause accertate e interventi preventivi. Questi elementi permettono di completare il fascicolo dell’incidente e valutare le misure adottate.
Le priorità di investimento emergono dai processi che non hanno retto e dai tempi misurati per ripristinarli: sono questi risultati a indicare dove un’alternativa indipendente, un accesso di emergenza o una procedura diversa possono ridurre il prossimo fermo.
Partecipa alla community