Un’interruzione dei servizi può nascere da un ransomware, da un aggiornamento software mal riuscito, dalla caduta di una rete o dall’indisponibilità di un fornitore. Le prime domande sono operative: quali attività devono proseguire? Quanto tempo può restare fermo un processo? Quali sistemi e dati occorre ripristinare per primi?
La business continuity risponde a queste domande. La business resilience ne aggiunge altre: l’azienda può continuare a perseguire i propri obiettivi se il fornitore resta indisponibile per settimane, una materia prima diventa introvabile o una piattaforma tecnologica non è più utilizzabile? Può modificare rapidamente processi, responsabilità e modalità di erogazione dei servizi?
La distinzione acquista peso anche alla luce dei dati italiani. Nel 2025 la Banca d’Italia ha rilevato 101 gravi eventi ICT, all’origine di 137 segnalazioni da parte degli intermediari vigilati. Il 23% degli eventi era legato alla cybersicurezza; la maggioranza aveva invece natura operativa, soprattutto malfunzionamenti software, problemi di rete ed errori introdotti durante modifiche ai sistemi. Nel 56% delle segnalazioni risultava coinvolto un fornitore di servizi, mentre il 70% indicava l’interruzione di un servizio come conseguenza dell’incidente. In cinque episodi le perdite hanno superato il milione di euro e soltanto in due casi il recupero è stato integrale.
Questi numeri aiutano a correggere una rappresentazione ancora diffusa, in base alla quale la resilienza digitale riguardi esclusivamente gli attacchi informatici. Un cambiamento applicativo, un guasto o una dipendenza non governata possono interrompere il business quanto un attacco esterno.
Indice degli argomenti
Cos’è la business resilience
La business resilience è la capacità di un’organizzazione di assorbire un evento avverso, continuare a erogare i prodotti e i servizi prioritari e adattarsi alle nuove condizioni. Coinvolge persone, cultura, processi, tecnologie, strutture fisiche, finanza e supply chain.
La business resilience è il risultato dell’integrazione tra business continuity management, disaster recovery, incident management, analisi degli impatti, gestione del rischio, comunicazione d’emergenza, test. La resilienza nasce quando queste discipline cessano di operare come compartimenti separati e concorrono a una capacità aziendale comune.
Al suo interno si possono distinguere almeno tre livelli:
- Resilienza organizzativa, riferita all’intera impresa e alla capacità di modificare decisioni, competenze, strutture e priorità.
- Resilienza operativa, concentrata sui servizi e sui processi che devono rimanere disponibili entro soglie di impatto prestabilite.
- Resilienza della supply chain, diretta a ridurre le dipendenze eccessive, predisporre alternative e recuperare rapidamente la capacità produttiva o distributiva.
Per un CIO, la resilienza passa quindi dall’architettura IT, ma comprende anche la capacità dell’organizzazione di prendere decisioni sotto pressione. Un’infrastruttura ridondata serve poco se durante l’incidente nessuno può autorizzare l’attivazione del sito secondario, il contratto con il cloud provider non chiarisce le responsabilità o i process owner non concordano su quale servizio ripristinare per primo.
La resilienza può inoltre richiedere una trasformazione permanente. Se un fornitore strategico fallisce, il piano di continuità attiva la soluzione sostitutiva già prevista; la strategia di resilienza rivede l’assetto della filiera e il livello di concentrazione accettabile.
Cos’è la business continuity
La business continuity è la capacità di mantenere o ripristinare le attività prioritarie durante e dopo un’interruzione, entro tempi e livelli di servizio considerati accettabili.
Il suo punto di partenza è la Business Impact Analysis, o BIA. L’analisi individua i processi prioritari, le risorse da cui dipendono, le conseguenze di un fermo e il tempo massimo tollerabile di interruzione. Da qui discendono parametri come il Recovery Time Objective, cioè il tempo entro il quale un servizio deve essere recuperato, e il Recovery Point Objective, che definisce la quantità massima di dati che l’organizzazione può permettersi di perdere.
Il piano di business continuity stabilisce responsabilità, procedure di escalation, modalità operative alternative, comunicazioni e criteri per il ritorno all’operatività. Il disaster recovery ne rappresenta la componente tecnologica: riguarda il ripristino di sistemi, applicazioni, dati e infrastrutture. Confondere i due piani significa ridurre la continuità aziendale al recupero dell’IT.
Un backup correttamente eseguito, per esempio, protegge una copia dei dati. Non dimostra che l’azienda sappia ripristinare un servizio entro il tempo richiesto. Occorre verificare l’integrità dei dati, ricostruire le dipendenze applicative, rendere disponibili identità e connessioni, coordinare i fornitori e controllare che il processo di business possa effettivamente ripartire.
Nel 2024, secondo dati Eurostat, il 79% delle imprese europee con almeno dieci addetti effettuava backup in una sede separata o nel cloud. M soltanto il 35% disponeva di documenti che definivano misure, prassi o procedure di sicurezza.
La presenza di una misura tecnica, dunque, non equivale alla capacità di gestire un’interruzione. È il motivo per cui i test end-to-end contano più della dichiarazione che “i backup sono attivi”.
Differenze e similitudini fra business continuity e business resilience
Business continuity e business resilience non sono approcci alternativi. La prima costituisce una delle basi operative della seconda.
| Dimensione | Business continuity | Business resilience |
|---|---|---|
| Obiettivo | Mantenere o ripristinare le attività prioritarie | Assorbire lo shock e adattare l’organizzazione |
| Orizzonte | Interruzione e fase di recupero | Prima, durante e dopo l’evento, anche nel lungo periodo |
| Unità di analisi | Processi, servizi e risorse necessarie | Impresa, ecosistema, supply chain e modello operativo |
| Risultato atteso | Ritorno a un livello di servizio accettabile | Capacità di operare anche in condizioni mutate |
| Strumenti principali | BIA, RTO, RPO, procedure, recovery e test | Scenari, soglie di impatto, alternative strategiche e apprendimento |
| Governance | Process owner e direzione IT | Vertice aziendale, funzioni operative, risk management, IT, supply chain, HR e comunicazione |
| Gestione dei fornitori | Recupero dei servizi contrattualizzati | Valutazione di concentrazione, possibilità di sostituzione e dipendenze di filiera |
Le similitudini restano ampie. Entrambe partono dall’identificazione dei servizi prioritari e delle relative dipendenze; impiegano analisi del rischio e degli impatti; definiscono responsabilità, comunicazioni e procedure di risposta; richiedono esercitazioni e revisioni periodiche.
La differenza si osserva soprattutto nel risultato. La business continuity serve per tornare a erogare un servizio. La resilienza valuta se quel servizio, quella tecnologia e quella modalità di erogazione siano ancora adeguati dopo lo shock.
Come creare un piano di business resilience
Un piano di resilienza efficace non dovrebbe diventare un documento parallelo ai piani già esistenti. Conviene costruirlo collegando continuità, disaster recovery, cyber incident response, crisis management, gestione dei fornitori e pianificazione strategica.
1. Definire i servizi importanti partendo dal cliente
L’analisi deve iniziare dai servizi che l’impresa si impegna a fornire, anziché dall’elenco delle applicazioni. Per ciascun servizio occorre individuare clienti e stakeholder coinvolti, obblighi contrattuali o normativi, conseguenze economiche e reputazionali e livello massimo di impatto tollerabile.
Questo passaggio evita che la priorità tecnica di un sistema venga scambiata per priorità di business. Un’applicazione apparentemente secondaria può sostenere un passaggio senza il quale l’intero servizio resta bloccato.
2. Mappare le dipendenze end-to-end
Persone, dati, applicazioni, infrastrutture, sedi, impianti OT, fornitori e subfornitori devono essere ricondotti ai servizi che sostengono. La mappa dovrebbe includere le concentrazioni nascoste: due fornitori commercialmente distinti potrebbero dipendere dallo stesso hyperscaler, dalla medesima rete o dallo stesso componente software.
Il dato della Banca d’Italia (fornitori coinvolti nel 56% delle segnalazioni del 2025) mostra perché i confini dell’azienda non coincidano più con quelli della resilienza.
3. Stabilire soglie e responsabilità
RTO e RPO restano necessari, ma vanno affiancati da tolleranze d’impatto misurate sul servizio: numero massimo di clienti coinvolti, volume di transazioni bloccate, perdita finanziaria, durata dell’indisponibilità, area geografica interessata e quantità di dati compromessi.
Le soglie devono essere approvate dal management. Il CIO può descrivere il rischio tecnico e le opzioni disponibili; l’accettazione del rischio residuo appartiene agli organi che rispondono dei risultati aziendali.
4. Costruire scenari plausibili
Le esercitazioni dovrebbero comprendere attacchi cyber, guasti, errori durante i cambiamenti, indisponibilità del cloud o delle telecomunicazioni, perdita di personale chiave, eventi climatici e crisi di filiera. Serve anche valutare scenari combinati, come un ransomware durante il passaggio a un nuovo ERP o un’interruzione del fornitore mentre il sito secondario è in manutenzione.
Lo scenario deve mettere alla prova decisioni e dipendenze, non indovinare la forma del prossimo incidente.
5. Predisporre alternative realmente attivabili
Ridondanza, multi-region, backup immutabili, procedure manuali, scorte e fornitori alternativi hanno valore se possono essere attivati nei tempi previsti. Questo richiede accessi verificati, dati compatibili, competenze disponibili, contratti coerenti ed eventuali procedure di uscita.
Anche la possibilità di rimodulare temporaneamente il livello di servizio può essere preferibile a un fermo completo: limitare temporaneamente alcune funzionalità, privilegiare clienti o transazioni prioritarie e spostare capacità da processi meno urgenti.
6. Eseguire test tecnici e organizzativi
Un piano letto durante una riunione non equivale a una prova. Occorrono restore test, simulazioni tabletop, esercitazioni con i fornitori, failover e test dei canali di comunicazione. Le prove più mature attraversano l’intero servizio: dall’incidente iniziale alla decisione del crisis team, fino alla verifica da parte degli utenti.
Il NIST Cybersecurity Framework 2.0 offre una sequenza utile per la componente digitale: Govern, Identify, Protect, Detect, Respond e Recover. L’aggiunta della funzione Govern nella versione 2.0 richiama la responsabilità del vertice, l’allineamento con l’enterprise risk management e il controllo della supply chain.
7. Trasformare gli incidenti in decisioni
Dopo ogni test, incidente o quasi incidente vanno registrati tempi effettivi, dipendenze inattese, decisioni ritardate e controlli inefficaci. Le azioni correttive devono avere un responsabile, una scadenza e un budget.
La resilienza diventa misurabile attraverso indicatori come la percentuale di servizi coperti da BIA aggiornata, il rispetto degli RTO durante i test, il tasso di ripristino riuscito, il numero di dipendenze senza alternativa e il tempo necessario al management per assumere una decisione durante la crisi.
Quali standard e framework utilizzare
Il riferimento principale per la business continuity rimane ISO 22301:2019, che definisce i requisiti di un Business Continuity Management System. Lo standard è affiancato dalla guida applicativa ISO 22313:2020 e dall’emendamento del 2024 relativo alla considerazione del cambiamento climatico. Una terza edizione di ISO 22301 è in preparazione, ma ad agosto 2026 si trova ancora allo stadio di Committee Draft: non sostituisce quindi la versione pubblicata.
Per la resilienza organizzativa il riferimento è ISO 22316:2017, dedicato a principi e attributi. Anche questo standard è in aggiornamento: la seconda edizione ha raggiunto lo stadio Final Draft International Standard e dovrebbe sostituire quella del 2017, che resta nel frattempo la versione vigente. Nel 2024 ISO ha inoltre pubblicato ISO 22336:2024, con indicazioni per sviluppare politica e strategia di resilienza.
DORA e NIS2 forniscono il quadro regolatorio europeo rispettivamente per la resilienza operativa digitale del settore finanziario e per la gestione del rischio cyber nei soggetti essenziali e importanti. Il NIST CSF 2.0, come accennato, può invece servire come tassonomia operativa per collegare governance, prevenzione, rilevazione, risposta e recupero.
Nessuno di questi riferimenti, preso isolatamente, costituisce un piano completo di business resilience. ISO 22301 struttura la continuità; ISO 22316 e ISO 22336 estendono la prospettiva organizzativa; NIST CSF approfondisce il rischio cyber; DORA e NIS2 introducono obblighi e responsabilità. Sta all’impresa ricomporli intorno ai servizi che deve proteggere.
Partecipa alla community