Piano business continuity cybersecurity: come progettare la resilienza operativa
Un piano business continuity cybersecurity efficace è ciò che separa un’organizzazione che assorbe un attacco e torna operativa in poche ore da una che resta paralizzata per settimane. Non è un documento da archiviare per soddisfare un auditor, ma l’infrastruttura decisionale che entra in funzione nel momento esatto in cui i sistemi cadono, i dati sono cifrati da un ransomware o un guasto blocca l’erogazione dei servizi. In un contesto in cui la continuità non è più un tema riservato all’IT ma una responsabilità diretta degli organi di amministrazione, progettarlo bene significa tradurre la postura di sicurezza in capacità di recupero misurabile.
La distinzione tra continuità operativa e ripristino tecnologico è il primo passo per non costruire un piano monco. Troppe organizzazioni confondono il backup con la resilienza, scoprendo durante l’incidente che avere le copie dei dati non equivale a saperle ripristinare nei tempi che il business può tollerare.
Business continuity e disaster recovery: due piani complementari
I termini business continuity e disaster recovery vengono spesso usati come sinonimi, ma descrivono due livelli diversi dello stesso problema. La business continuity riguarda la capacità complessiva dell’organizzazione di continuare a erogare prodotti e servizi a un livello accettabile durante e dopo un evento disruptivo: include processi, persone, sedi alternative, fornitori e comunicazione di crisi. Il disaster recovery è il sottoinsieme tecnologico: le procedure che riportano in funzione sistemi, applicazioni e dati.
In altre parole, il piano di continuità risponde alla domanda “come continuiamo a operare”, mentre il piano di ripristino risponde a “come rimettiamo in piedi l’infrastruttura”. Un’azienda può avere un disaster recovery impeccabile sul piano tecnico e fallire comunque la continuità, perché non ha previsto chi prende le decisioni quando il responsabile è irraggiungibile, come si informano i clienti o dove lavorano le persone se la sede è inaccessibile. La sicurezza informatica si colloca all’intersezione dei due: un incidente cyber è oggi una delle cause più frequenti di interruzione, e va trattato con la stessa serietà di un evento fisico.
La business impact analysis come fondamento
Nessun piano regge senza una business impact analysis (BIA) seria. La BIA è l’attività che identifica le funzioni critiche dell’organizzazione, le interdipendenze tra processi e sistemi, e soprattutto traduce l’impatto di un’interruzione in parametri quantitativi. È da qui che nascono le metriche che governano ogni scelta successiva.
Il Recovery Time Objective (RTO) definisce il tempo massimo entro cui una funzione o un sistema deve essere ripristinato dopo l’interruzione. Il Recovery Point Objective (RPO) indica la quantità massima di dati, misurata in tempo, che l’organizzazione può permettersi di perdere: un RPO di un’ora significa backup almeno orari. A monte di entrambi si colloca il Maximum Tolerable Period of Disruption (MTPD), il tempo oltre il quale le conseguenze di un’interruzione diventano insostenibili per la sopravvivenza dell’attività. La regola pratica è semplice: l’RTO deve sempre essere inferiore all’MTPD, con un margine di sicurezza adeguato, perché un ripristino che arriva esattamente al limite di tollerabilità non lascia spazio agli imprevisti.
Definire questi valori non è un esercizio teorico. Un RTO di quattro ore impone soluzioni di ridondanza e automazione completamente diverse rispetto a un RTO di tre giorni, con costi proporzionati. Stabilirli senza una BIA equivale a dimensionare la resilienza a sentimento, sovrainvestendo su processi marginali e lasciando scoperti quelli vitali.
Come strutturare un piano business continuity cybersecurity
Un piano business continuity cybersecurity completo si articola su alcuni pilastri che vanno oltre l’elenco di procedure tecniche. Il primo è la governance: chi attiva il piano, con quale catena di comando, quali soglie fanno scattare la dichiarazione di crisi. In un incidente reale, l’ambiguità sui ruoli costa più del guasto tecnico.
Il secondo pilastro sono le strategie di continuità vere e proprie: ridondanza dei sistemi critici, siti alternativi, accordi con i fornitori, modalità di lavoro degradate ma operative. Per la componente cyber, questo significa progettare backup isolati dalla rete primaria, immutabili dove possibile, e ambienti di ripristino non raggiungibili da un attaccante che ha già compromesso la produzione.
Il terzo è la gestione della crisi e della comunicazione: procedure per informare dipendenti, clienti, autorità e, quando previsto, l’opinione pubblica, con messaggi predefiniti e canali alternativi che funzionano anche quando la posta aziendale è ferma. Il quarto pilastro è il piano di ripristino operativo, con procedure passo-passo, criteri per dichiarare il ritorno alla normalità e verifiche di integrità sui dati recuperati. Trascurare quest’ultima parte è un errore ricorrente: ripristinare dati corrotti o già compromessi reintroduce in produzione la stessa minaccia da cui si stava cercando di uscire.
Gli standard di riferimento: ISO 22301 e ISO/IEC 27031
Chi progetta un piano non parte da zero. Lo standard internazionale di riferimento è la ISO 22301, che definisce i requisiti per un sistema di gestione della continuità operativa (BCMS) basato sul ciclo Plan-Do-Check-Act. La norma struttura l’intero percorso, dalla comprensione del contesto e degli stakeholder fino alla BIA, alla definizione delle strategie, all’attuazione, al test e al miglioramento continuo. Adottarla, anche senza puntare alla certificazione, fornisce un linguaggio comune e una griglia che riduce il rischio di dimenticare componenti essenziali.
Sul versante tecnologico interviene la ISO/IEC 27031, aggiornata nel 2025, che riguarda specificamente l’ICT readiness for business continuity (IRBC), ovvero la prontezza dei sistemi informativi a sostenere gli obiettivi di resilienza. Non è una norma certificabile e non sostituisce un BCMS: la sua funzione è raccordare la sicurezza delle informazioni e la continuità operativa, spiegando come le funzioni ICT debbano prepararsi, monitorare e ripristinare i servizi. A livello operativo, molte organizzazioni integrano questi standard con la guida NIST SP 800-34 sul contingency planning, particolarmente diffusa per la pianificazione dei sistemi informativi.
Cosa chiedono NIS2 e DORA
La continuità operativa non è più solo una buona pratica: è un obbligo normativo per fasce crescenti di organizzazioni. La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, include la continuità operativa tra le misure di gestione del rischio dell’articolo 21, che al paragrafo 2 lettera c) cita espressamente “continuità operativa, come la gestione del backup e il ripristino in caso di disastro, e gestione delle crisi”. È una delle dieci misure minime che i soggetti essenziali e importanti devono adottare, con termine ultimo indicato a ottobre 2026 per le misure di base. Per specifiche categorie di fornitori di infrastrutture e servizi digitali (tra cui cloud, data center, servizi gestiti e DNS) i requisiti tecnici sono ulteriormente dettagliati dal Regolamento di esecuzione (UE) 2024/2690, mentre per gli altri soggetti in perimetro l’attuazione è demandata alla determinazione dell’ACN. Sul tema, ICT Security Magazine ha approfondito le misure di sicurezza NIS2 introdotte dalla normativa europea.
Nel settore finanziario il riferimento è il Regolamento (UE) 2022/2554, noto come DORA. Qui la disciplina è più granulare: l’articolo 11 impone una politica di continuità operativa ICT esaustiva, con piani di risposta e ripristino da testare almeno una volta all’anno e a ogni modifica di rilievo, includendo per i soggetti diversi dalle microimprese scenari di attacco informatico. L’articolo 12 entra nel dettaglio operativo di backup, restore e recovery: prescrive obiettivi di punti di ripristino (RPO) e tempi di ripristino (RTO) calibrati sulla criticità delle funzioni, sistemi di ripristino fisicamente e logicamente separati da quelli di origine, e verifiche multiple con controlli incrociati per garantire l’integrità dei dati recuperati. Per le banche e le assicurazioni il quadro è già pienamente esigibile, come ricostruito nella guida agli adempimenti DORA per il settore finanziario.
Il filo comune tra le due normative è netto: la continuità non si delega più solo all’IT, ma diventa responsabilità documentata e verificabile dei vertici aziendali, con sanzioni significative per chi non la presidia.
Testare il piano: l’errore di fermarsi alla carta
Un piano mai testato è un’ipotesi, non una garanzia. La differenza tra le due si scopre sempre nel momento peggiore. Il test non è un adempimento formale: serve a misurare se gli RTO e gli RPO dichiarati sono davvero raggiungibili, se le persone sanno cosa fare, se i backup si ripristinano effettivamente.
Esistono diversi livelli di verifica, da combinare nel tempo. Le tabletop exercise simulano uno scenario a tavolino e mettono alla prova decisioni e comunicazione. I test di ripristino verificano che le copie dei dati siano integre e utilizzabili: un backup che non si ripristina è solo spazio disco occupato, e questo è precisamente il punto in cui molte difese contro il ransomware si rivelano illusorie. Le esercitazioni complete, fino al full failover sui sistemi ridondanti, sono le più costose ma anche le uniche che mostrano i colli di bottiglia reali. La frequenza minima dovrebbe essere annuale, da innalzare per le funzioni più critiche e dopo ogni cambiamento rilevante dell’infrastruttura.
Ogni test produce lezioni apprese che vanno reintegrate nel piano, chiudendo il ciclo Plan-Do-Check-Act. Un piano business continuity cybersecurity vive di questo aggiornamento continuo: cristallizzarlo in un documento statico significa lasciarlo invecchiare al ritmo, rapidissimo, con cui cambiano minacce, sistemi e organizzazione.
Dalla carta alla resilienza
Progettare la continuità operativa è un investimento che si ripaga una sola volta, ma quella volta vale tutte le altre. La sequenza è chiara: una business impact analysis che fotografa cosa conta davvero, obiettivi di ripristino calibrati sul rischio reale, strategie tecniche e organizzative coerenti con quegli obiettivi, e un programma di test che trasforma il documento in capacità verificata. Gli standard ISO e gli obblighi di NIS2 e DORA offrono la struttura; la differenza la fa la serietà con cui l’organizzazione la riempie di contenuti propri. Perché la resilienza non si dichiara: si dimostra il giorno in cui qualcosa si rompe.
