.svg)
Da qualche parte, in un drive condiviso aziendale, c’è quasi sempre un file che si chiama “Piano di Disaster Recovery – versione finale”. Aggiornato l’anno scorso. Testato, sulla carta, sempre l’anno scorso, magari in una sala riunioni con un tabellone e un caffè freddo.
Nel frattempo, però, l’infrastruttura che quel piano dovrebbe proteggere è già diventata un’altra cosa: nuovi servizi cloud, nuovi fornitori, integrazioni aggiunte in corsa, magari un paio di agenti AI che ormai gestiscono processi che fino a poco tempo fa erano manuali. È lo scarto più comune nella gestione del rischio IT: continuare a trattare la resilienza come una fotografia, quando servirebbe seguirla come un film. I numeri, ormai, lo confermano.
Uno studio di Splunk, società Cisco, pubblicato a maggio 2026 insieme a Oxford Economics su un campione di 2.000 dirigenti di aziende Global 2000, stima in 600 miliardi di dollari l’anno il costo complessivo del downtime non pianificato, cresciuto del 50% in due anni. Il costo medio ha toccato i 15.000 dollari al minuto. Un singolo episodio di inattività porta con sé, in media, anche un calo del 3,4% del valore azionario. E ogni azienda perde in media 95 milioni di dollari l’anno di fatturato, quasi il doppio rispetto al 2024.
Nello stesso periodo sono cresciute in modo analogo anche le sanzioni regolamentari e i riscatti pagati per attacchi ransomware, entrambi quasi triplicati, complice anche un’applicazione più severa di normative come il GDPR e il DORA. Difficile, quindi, continuare a considerarlo solo un problema del reparto IT.
Perché l’audit annuale non basta più
Il motivo per cui l’audit annuale non basta più è abbastanza semplice: fotografa un ambiente che, quando arriva davvero il momento della crisi, è già cambiato. Architetture cloud-native, microservizi, dipendenze da fornitori terzi, workflow orchestrati da agenti AI: si muove tutto in continuazione.
Una mappa delle dipendenze critiche disegnata sei mesi fa descrive un’azienda che, in buona parte, non esiste più. E non è nemmeno un problema legato principalmente ad attacchi esterni. Lo stesso studio Splunk conferma che l’errore umano resta la causa principale del downtime lungo tutto lo stack tecnologico, tanto che due terzi dei responsabili IT operations stanno spostando budget sull’automazione proprio per ridurne il peso.
È più facile sbagliare una configurazione che subire un attacco sofisticato. Ed è anche più difficile intercettarlo con un test pianificato con mesi di anticipo. C’è poi un fattore che, negli ultimi due anni, ha reso la fotografia ancora più veloce a invecchiare: gli agenti AI.
Quando un processo aziendale è orchestrato da un agente autonomo, un errore di configurazione non produce più un singolo malfunzionamento isolato, ma una sequenza di azioni concatenate, eseguite a velocità machine-speed e spesso senza un intervento umano nel mezzo a fare da freno.
Non a caso, la maggior parte dei leader tecnologici intervistati da Splunk sta investendo in osservabilità e automazione potenziate dall’AI proprio per tenere sotto controllo comportamenti che altrimenti sfuggirebbero a una revisione umana periodica.
Mappare le dipendenze critiche, oggi, significa anche capire che cosa un agente può decidere di fare per conto dell’azienda, non solo quali sistemi tocca.
Dalle normative al cloud: la resilienza diventa continua
È più o meno il principio su cui l’Unione Europea ha costruito il DORA, il Digital Operational Resilience Act, pienamente applicabile dal gennaio 2025 e che nel 2026 sta entrando nella sua fase di vigilanza vera e propria.
Il regolamento non chiede solo di avere un piano di continuità scritto bene: impone test di resilienza operativa non episodici, proporzionati al rischio, capaci di simulare scenari severi ma plausibili, fino ai Threat-Led Penetration Test per le realtà più esposte.
In sostanza bisogna dimostrare, con evidenze ripetute nel tempo, che l’organizzazione sa assorbire un incidente e recuperare. Non solo di averlo scritto da qualche parte. Per ora questo obbligo specifico riguarda il settore finanziario, ma la stessa logica si sta allargando molto oltre.
La direttiva NIS2, che nel 2026 sta passando dalla fase di adempimento formale a quella sostanziale, estende obblighi di gestione del rischio e di risposta agli incidenti a diciotto settori: energia, trasporti, sanità, acqua, infrastrutture digitali, pubblica amministrazione, tra gli altri. In Italia coinvolge oltre 20.000 organizzazioni tra soggetti essenziali e importanti.
La logica che c’è dietro entrambe le normative sta quindi diventando lo standard implicito con cui guardare alla continuità operativa in generale, regolamentati o no: la resilienza non è uno stato che si raggiunge una volta, è una capacità che va tenuta allenata. Anche i grandi fornitori cloud sembrano muoversi nella stessa direzione, e non è un fenomeno isolato a un solo vendor.
Microsoft, ad esempio, ha introdotto in preview Azure Infrastructure Resiliency Manager, di cui si è parlato di recente anche nella rubrica mensile di Francesco Molfese su Cloud Community. La soluzione è pensata per analizzare la resilienza a livello di zona, individuare gap architetturali e simulare scenari di guasto prima che accadano davvero, invece di scoprirli a incidente in corso.
Nello stesso periodo AWS ha annunciato la disponibilità generale della nuova generazione di AWS Resilience Hub, il servizio con cui i clienti valutano, tracciano e migliorano nel tempo la resilienza delle proprie applicazioni.
Non è un caso isolato: è il segnale che anche l’infrastruttura di base sta iniziando a trattare la resilienza come una funzione nativa di piattaforma, da tenere sotto controllo giorno per giorno, e non come un allegato al contratto di manutenzione da rispolverare una volta l’anno.
Tre fronti su cui allenare la resilienza
Tradurre questo principio in azioni concrete significa soprattutto lavorare su tre fronti. E nessuno dei tre riguarda solo l’IT.
- Il primo è trattare la mappa delle dipendenze critiche come un dato vivo, non come un documento da riaprire una volta l’anno. Sistemi, fornitori cloud, terze parti e ormai anche gli agenti AI che orchestrano processi aziendali vanno tracciati con la stessa cura riservata agli asset fisici. Non è un dettaglio tecnico. Lo stesso studio Splunk mostra che, tra le aziende con i costi di downtime più bassi, il 98% considera la visibilità end-to-end sui propri sistemi fondamentale o della massima importanza. Eppure, una visibilità realmente completa resta rara nella maggior parte delle organizzazioni.
- Il secondo fronte riguarda la logica del test. Meglio simulazioni frequenti e circoscritte, un componente alla volta, in ambiente controllato, che un grande test annuale che in pochi vogliono davvero portare fino in fondo perché troppo costoso o troppo rischioso da fermare.
È più o meno l’idea alla base del chaos engineering, la pratica nata anni fa in Netflix e oggi adottata da molte organizzazioni, che consiste nell’introdurre guasti controllati nei propri sistemi per scoprire i punti deboli prima che lo faccia un incidente vero.Non richiede necessariamente strumenti sofisticati per iniziare. Spesso basta scegliere un singolo componente non critico, spegnerlo in un ambiente di test e osservare cosa succede a valle. Il punto non è la sofisticazione tecnica, è la disciplina di farlo con regolarità.
- Il terzo fronte è la governance, ed è probabilmente quello che richiede il cambiamento culturale più profondo. La resilienza non può restare un problema delegato all’IT, perché le decisioni che contano riguardano il business tanto quanto la tecnologia: quanto downtime è accettabile per ciascun processo, quali sistemi sono davvero critici, dove vale la pena investire in ridondanza e dove invece il rischio residuo è accettabile. Non è più solo buon senso organizzativo.
La stessa NIS2 impone esplicitamente agli organi di amministrazione dei soggetti coinvolti di approvare le misure di gestione del rischio informatico e di sovrintendere alla loro attuazione, oltre a seguire una formazione specifica in materia. È un cambio di paradigma che vale la pena adottare anche fuori dal perimetro stretto della norma: se il rischio di continuità operativa arriva in consiglio di amministrazione per obbligo di legge in alcuni settori, prima o poi diventerà una buona pratica attesa ovunque.
Conclusione: la domanda non è più “abbiamo un piano?”
Nella pratica, però, il motivo per cui poche organizzazioni ci sono già arrivate non è quasi mai la mancanza di consapevolezza. Difficilmente un responsabile IT o security negherebbe che la resilienza andrebbe trattata come un processo continuo. Il freno più comune è culturale, prima ancora che tecnico.
Simulare guasti in produzione mette a disagio anche quando è fatto in modo controllato, perché sposta il rischio percepito da “qualcosa che potrebbe succedere” a “qualcosa che stiamo causando noi”. E investire tempo e budget in test che, se tutto va bene, non producono nulla di visibile è difficile da giustificare quando in agenda ci sono priorità che promettono risultati immediati.
È lo stesso paradosso di ogni investimento in prevenzione: funziona meglio proprio nei momenti in cui sembra non stia servendo a nulla. Quel file “versione finale” nel drive condiviso non è inutile. Ma da solo non risponde più alla domanda che oggi conta davvero, e che vale per un CIO tanto quanto per chi siede in consiglio di amministrazione.
Non “abbiamo un piano?”, quanto piuttosto: “siamo sicuri che funzioni ancora, con l’infrastruttura che abbiamo adesso e non con quella di un anno fa?”.
