Business continuity: cos'è e come si costruisce

La business continuity, in italiano continuità operativa, è la capacità di un'azienda di continuare a consegnare i propri prodotti e servizi, a un livello accettabile deciso prima, mentre qualcosa la blocca: un ransomware, un guasto al data center, un incendio, un fornitore che si ferma. Il business continuity management (BCM) è il modo di gestirla: analisi degli impatti, strategie, piani, test e revisione periodica.

Per un'azienda del mid-market non è più solo una buona pratica. Il D.Lgs. 138/2024, che recepisce la NIS2, mette la continuità operativa tra le misure minime di sicurezza; il Regolamento DORA la chiede alle entità finanziarie; la ISO 22301 la rende certificabile. Qui sotto cosa significa in concreto, come si distingue dal disaster recovery, come si costruisce e cosa chiedono le tre fonti.

Business continuity, BCM, piano: i termini

Le parole si sovrappongono, e conviene separarle subito:

• Business continuity (continuità operativa): il risultato. L'azienda continua a lavorare durante un'interruzione, magari a capacità ridotta, e torna alla normalità entro tempi stabiliti.
• Business continuity management (BCM): il processo che produce quel risultato e lo tiene aggiornato nel tempo.
• BCMS (business continuity management system): il sistema di gestione per la continuità operativa descritto dalla ISO 22301, cioè il BCM organizzato in modo da poter essere verificato da un ente terzo.
• Piano di continuità operativa (business continuity plan, BCP): il documento che dice chi fa cosa quando l'interruzione arriva.

La NIST SP 800-34 Rev. 1, la guida del NIST alla pianificazione della continuità, definisce il BCP come l'insieme di istruzioni e procedure stabilite in anticipo che descrivono come i processi di un'organizzazione vengono mantenuti durante e dopo un'interruzione significativa (resa nostra dall'inglese). La parola chiave è processi: la continuità operativa parte dal business, non dai server.

Business continuity e disaster recovery: la differenza

È la confusione più comune, e ha conseguenze pratiche: chi ha un buon piano di disaster recovery spesso crede di avere anche la continuità operativa.

• Il piano di continuità operativa guarda ai processi: come si continua a ricevere ordini, spedire, fatturare, pagare gli stipendi mentre qualcosa non funziona. Comprende anche le alternative manuali, le persone di riserva, la sede alternativa, i fornitori sostitutivi.
• Il piano di disaster recovery (DRP) guarda ai sistemi informativi: come si riportano in funzione applicazioni, dati e infrastruttura dopo un'interruzione grave. Nella NIST SP 800-34 è un piano centrato sui sistemi, pensato per ripristinarli in un sito alternativo, e può sostenere il piano di continuità recuperando i sistemi su cui i processi poggiano.

In breve: il disaster recovery è una parte della continuità operativa, non il suo sinonimo. Lo dice anche la struttura delle misure ACN per la NIS2, che chiedono tre piani distinti: continuità operativa, ripristino in caso di disastro e gestione delle crisi informatiche. Quest'ultima, cioè chi decide quando la situazione esce dai piani, è trattata nell'articolo sul crisis management aziendale.

Da quali interruzioni ci si prepara

Il D.Lgs. 138/2024, all'articolo 24, comma 2, chiede misure basate su un approccio multi-rischio, che coprono i sistemi informativi e di rete e anche il loro ambiente fisico. Nella pratica conviene ragionare per effetto, non per causa, perché le cause sono troppe da elencare e gli effetti sono pochi:

• sistemi non disponibili: ransomware, guasto, errore di configurazione, attacco alla disponibilità;
• sede non accessibile: incendio, allagamento, blackout prolungato;
• persone non disponibili: assenze contemporanee, competenze concentrate su una sola persona;
• fornitore fermo: un servizio cloud, un gestionale in outsourcing, un fornitore unico di un componente.

Un piano che prevede questi quattro effetti copre la maggior parte delle cause, anche quelle che nessuno aveva immaginato.

Come si costruisce la continuità operativa, passo per passo

1. Perimetro e mandato della direzione. Quali prodotti, servizi e sedi sono dentro, e chi risponde del programma. Senza un mandato del vertice, le scelte che costano (siti di riserva, ridondanze, contratti) non si fanno.
2. Business impact analysis. Per ogni attività, che danno produce il fermo con il passare delle ore e dei giorni, e quanto fermo è tollerabile. Il metodo è spiegato nell'articolo sulla business impact analysis (BIA).
3. Valutazione del rischio. Quali minacce possono colpire le attività critiche emerse dalla BIA, e con che probabilità.
4. Obiettivi e strategie. Quanto si può restare fermi e quanti dati si possono perdere, sistema per sistema, e con quali mezzi rispettarlo: backup, replica, sito secondario, procedure manuali, fornitori alternativi. I due parametri tecnici sono spiegati nell'articolo su RPO e RTO, la parte backup in quello sul backup cloud per aziende.
5. Piani. Continuità operativa, disaster recovery e gestione della crisi, con ruoli, contatti e condizioni di attivazione.
6. Esercitazioni e riesame. Un piano mai provato è un'ipotesi. Si prova con esercitazioni a tavolino e test di ripristino, si annota cosa non ha funzionato, si aggiorna.

Cosa deve contenere un piano di continuità operativa

Una base concreta, e per i soggetti NIS2 obbligatoria, è la misura ID.IM-04 delle misure di base ACN (allegati 1 e 2 della determinazione 379907/2025). Per almeno i sistemi informativi e di rete rilevanti, il piano di continuità operativa comprende almeno:

• le finalità, comprese le esigenze di continuità operativa, e l'ambito di applicazione;
• i ruoli e le responsabilità;
• i contatti principali e i canali di comunicazione, interni ed esterni;
• "le condizioni per l'attivazione e la disattivazione del piano";
• le risorse necessarie, compresi i backup e le ridondanze.

Il piano di ripristino in caso di disastro ha la stessa struttura e aggiunge l'ordine di ripristino delle operazioni e le procedure di ripristino, con gli obiettivi di ripristino. La stessa misura chiede che i piani siano approvati dagli organi di amministrazione e direttivi e riesaminati almeno ogni due anni, e comunque dopo incidenti significativi o cambiamenti dell'esposizione alle minacce.

Due accorgimenti che l'elenco non dice ma che fanno la differenza: il piano deve essere leggibile anche quando i sistemi aziendali sono fermi (una copia fuori dalla rete aziendale, recapiti su canali indipendenti), e deve essere scritto per chi lo eseguirà sotto pressione, non per l'auditor.

Cosa chiedono NIS2, DORA e ISO 22301

NIS2

La direttiva (UE) 2022/2555, all'articolo 21, paragrafo 2, lettera c), include la continuità operativa tra le misure di gestione dei rischi. In Italia il D.Lgs. 138/2024 la riprende all'articolo 24, comma 2, lettera c), che elenca tra le misure minime la "continuità operativa, ivi inclusa la gestione di backup, il ripristino in caso di disastro, ove applicabile, e gestione delle crisi". Le misure di base ACN la traducono nei tre piani della ID.IM-04 e nella misura PR.DS-11, che chiede backup periodici di dati e configurazioni coerenti con le esigenze individuate in quei piani, con copie offline per i sistemi rilevanti; per i soggetti essenziali anche la verifica periodica dell'utilizzabilità dei backup con test di ripristino. Il quadro completo è nella guida completa alla NIS2.

DORA

Per enti creditizi, istituti di pagamento, imprese di assicurazione e le altre entità finanziarie elencate nell'articolo 2, l'articolo 11 del Regolamento (UE) 2022/2554 chiede una politica di continuità operativa delle TIC, attuata con piani e procedure documentati, e una BIA delle esposizioni a gravi perturbazioni. Il paragrafo 6 chiede di testare i piani di continuità e i piani di risposta e ripristino almeno una volta all'anno, e in caso di modifiche di rilievo ai sistemi che sostengono funzioni essenziali o importanti. Il paragrafo 4 richiama in modo specifico le funzioni essenziali o importanti esternalizzate o appaltate a fornitori terzi di servizi TIC, e il paragrafo 7 chiede alle entità diverse dalle microimprese una funzione di gestione delle crisi. Restano fuori dagli articoli da 5 a 15 le entità del quadro semplificato dell'articolo 16. Il contesto è nell'articolo su gestione del rischio ICT e registro dei fornitori.

ISO 22301

La ISO 22301:2019, aggiornata dall'emendamento 1 del 2024, è recepita in Italia come UNI EN ISO 22301:2019+A1:2024. Specifica i requisiti di un BCMS e, come le altre norme sui sistemi di gestione (ISO 9001, ISO/IEC 27001), segue il ciclo PDCA: contesto (punto 4), leadership (5), pianificazione (6), supporto (7), attività operative (8), valutazione delle prestazioni (9), miglioramento (10). Secondo la premessa della norma, i requisiti specifici della continuità operativa stanno quasi tutti nel punto 8: BIA e valutazione del rischio (8.2), strategie (8.3), piani e procedure (8.4), programma di esercitazione (8.5).

La norma è volontaria. L'introduzione elenca più modi per dimostrare la conformità, dall'autodichiarazione alla certificazione da parte di un organismo esterno; per chi deve rispondere a NIS2 o DORA, la certificazione dà evidenze ordinate su piani, test e approvazioni della direzione.

Gli errori che svuotano un programma di continuità

• Affidarla solo all'IT. Ne esce un buon disaster recovery e nessuna risposta su come si spedisce o si fattura con i sistemi fermi.
• Dimenticare i fornitori. Se il gestionale è in cloud o in outsourcing, la continuità dipende anche dal contratto: tempi di ripristino promessi, uscita, alternative.
• Un piano che vive sui sistemi che dovrebbe far ripartire. Se l'unica copia sta sulla rete cifrata dal ransomware, il piano non c'è.
• Mai provarlo. I tempi reali di ripristino si scoprono in esercitazione o durante il fermo. Il primo modo costa meno.

Da dove partire

Se oggi la continuità operativa della tua azienda coincide con il backup, il primo passo è una BIA sulle attività che portano ricavi, il secondo un piano scritto con ruoli e condizioni di attivazione, il terzo un'esercitazione. Chi vuole un sistema di continuità verificabile da un ente terzo, e utile anche come evidenza per NIS2 e DORA, può partire dal percorso di certificazione ISO 22301.