La maggior parte dei piani di resilienza viene ancora progettata attorno ai sistemi posseduti e gestiti direttamente da un’azienda – server, applicazioni interne e ambiente cloud primario. Tuttavia, il vero rischio non si concentra più lì e oggi la vulnerabilità risiede sempre più in ciò che un’azienda non possiede e non può controllare completamente, come le applicazioni Software-as-a-Service (SaaS) a cui si affida, i provider di identità, i piani di controllo da cui dipendono e, sempre più spesso, gli strumenti di intelligenza artificiale che vi operano.
In altre parole, la resilienza deve essere progettata attorno alle dipendenze esterne al proprio controllo, non più solo sui sistemi interni.
Tutto è più connesso, i guasti si propagano più velocemente
Oggi le organizzazioni si reggono su un ecosistema articolato e frammentato di applicazioni SaaS, piattaforme di identità, piani di controllo e API, tutti fortemente integrati e interdipendenti tra loro. Tale interconnessione garantisce un’elevata efficienza, ma implica anche che un’interruzione di un singolo componente possa generare un effetto a cascata su molti altri. Il ripristino non si riduce a un semplice riavvio di tutto, ma deve essere sequenziato, basandosi spesso su un livello fondamentale di servizi condivisi – tra cui identità, DNS e servizi di directory – dai quali dipende tutto il resto, prima che una qualsiasi applicazione possa tornare operativa.
La stessa dinamica si osserva negli ambienti di Operational Technology (OT) dei settori manifatturiero, chimico e petrolifero, dove da sempre un firewall mantiene separati il mondo IT e quello OT. Man mano che le aziende collegano AI e servizi cloud all’OT per guadagnare in velocità o efficienza, tale separazione si assottiglia e la posta in gioco si alza. In questo contesto, un guasto non porta con sé solo un problema di inattività, ma può trasformarsi in un reale rischio per la sicurezza di persone e impianti.
L’adozione dell’AI corre più rapida della sua governance
L’impulso ad accelerare è ormai evidente. In uno studio condotto da Cisco nel febbraio 2025 su oltre 2.500 CEO, il 97% ha dichiarato di pianificare l’integrazione dell’AI nelle proprie operations, ma solo il 1,7% si è detto pienamente preparato a farlo. Questo divario porta con sé conseguenze concrete: Gartner prevede che oltre il 40% dei progetti di agentic AI verrà cancellato entro la fine del 2027, principalmente a causa di un valore di business incerto, dell’escalation dei costi e di controlli del rischio inadeguati.
Lo stesso divario emerge nello specifico all’interno delle strutture di sicurezza e IT. Il report CIO MarketPulse, “Peer insights on AI adoption and the disaster recovery gap”, ha coinvolto oltre 300 responsabili IT e di sicurezza in Stati Uniti, Europa e Asia-Pacifico. Il 53% ha dichiarato di aver già implementato in modo completo sistemi e strumenti di agentic AI nella propria azienda per il 67% i propri team IT e di sicurezza ne mantengono pieno controllo e chiara governance. Al contempo, però, il 55% ha espresso forte preoccupazione per la scarsa comprensione dei rischi legati all’AI. L’adozione sta chiaramente superando la governance necessaria per gestirla in modo sicuro.
La sovranità dipende dal controllo, non dall’autosufficienza
Il tema della sovranità dei dati emerge costantemente nel confronto con i clienti, ma viene spesso frainteso e interpretato come la necessità di sviluppare e ospitare ogni risorsa al proprio interno. Nella pratica, è più utile scindere la sovranità applicativa – la capacità di possedere ed eseguire ogni sistema in modo indipendente, attività in realtà onerosa e poco pragmatica per la maggior parte delle aziende – dalla sovranità dei dati. Quest’ultima consiste nel garantire il pieno controllo sulle proprie informazioni, la possibilità di accedervi in locale e la capacità di migrarle, indipendentemente da ciò che accade a un singolo provider. Si tratta di un obiettivo concreto che la maggior parte delle organizzazioni può raggiungere, ed è ciò che conta davvero quando un hyperscaler o un fornitore SaaS subisce un blocco dei servizi.
Un framework pratico, non l’ennesimo audit
Certificazioni come ISO 27001 e SOC 2 Type 2, così come i framework legati a normative quali la Direttiva NIS2 dell’UE, CMMC (Cybersecurity Maturity Model Certification), HIPAA e DORA rappresentano la linea di partenza, non il traguardo. Nessuno di questi strumenti, da solo, è in grado di garantire la capacità reale di un’azienda di superare un incidente critico.
A questo proposito, sono tre i principi guida fondamentali:
- Categorizzare la criticità
Si tratta di una decisione di business, non un semplice task informatico. La criticità di un sistema o di un processo deve essere definita insieme al dipartimento che ne dipende – il responsabile delle operations o del finance, il direttore di stabilimento, ovvero chiunque si assuma il rischio di business in caso di fermo – e non solo con il team IT che lo mantiene in funzione. L’IT può identificare ciò che è tecnicamente fragile, ma solo il business può stabilire cosa sia davvero critico e formalizzare tale decisione prima che si verifichi un incidente, non mentre è in corso. - Modello di Minimum Viable Recovery
L’ordine di ripristino deve essere stabilito da quegli stessi responsabili di business, non definito dall’IT nel corso di un’emergenza. Occorre concordare in anticipo con i responsabili coinvolti cosa debba tornare online e in quale ordine. Ignorare questo passaggio porta a scenari già visti fin troppo spesso, con ogni dipartimento che pretende la massima priorità, in assenza di un criterio predefinito a cui fare riferimento. - Testare regolarmente
È necessario effettuare test periodici a ogni livello, comprese le componenti dell’ambiente aziendale che non si controllano direttamente. Le esercitazioni teoriche sono utili, ma i test più rivelatori sono quelli che simulano l’interruzione di un’applicazione SaaS, di un provider di identità o di un’altra dipendenza di terze parti, condotti da figure diverse da chi ha redatto le procedure operative.
C’è però un aspetto che spesso non riceve la dovuta attenzione: il ripristino non si conclude nel momento in cui i sistemi tornano operativi. È capitato di osservare aziende riprendersi completamente da un attacco ransomware nel giro di poche settimane dal punto di vista tecnico, per poi scoprire che le persone coinvolte nell’emergenza avevano a loro volta bisogno di tempo per ripristinare. La direzione si aspetta spesso un ritorno immediato alla normalità non appena le macchine ripartono, ma le persone non sempre sono in grado di garantirlo all’istante. La pianificazione della resilienza deve quindi farsi carico anche del fattore umano, non solamente dell’infrastruttura.
L’insegnamento principale
La resilienza va progettata attorno alle dipendenze che sfuggono al proprio controllo diretto. Deve diventare parte integrante della strategia IT e di intelligenza artificiale complessiva, non un elemento secondario aggiunto a posteriori per ogni nuova adozione SaaS. È fondamentale definire la criticità dei processi e testarla con scadenze regolari su scenari reali, inclusi quelli che non si possiedono
I punti di ingresso possono variare, ma la conclusione resta la stessa: le aziende che riescono a superare indenni una grave crisi sono quelle che hanno saputo pianificare anche per le componenti di rete e di software non controllate direttamente.
Di Kim Larsen, Group Chief Information Security Officer di Keepit
