Continuità operativa: cos’è, piano e obblighi NIS2

Quanto può restare ferma la vostra azienda prima di non riprendersi più?
È la domanda da cui dovrebbe partire ogni ragionamento sulla sicurezza, e quasi nessuno se la pone prima che sia troppo tardi. Provate a rispondere ora, a mente fredda: se domani mattina un ransomware cifrasse i vostri server e bloccasse il gestionale, la produzione, la posta, per quanti giorni potreste andare avanti prima che il danno diventi irreversibile? Un giorno? Una settimana? E sapreste dire con precisione quali processi salvare per primi, chi fa cosa nelle prime ore, in quanto tempo tornereste operativi?

Se la risposta è un’alzata di spalle, non è un problema di tecnologia: è l’assenza di un piano di continuità operativa. La continuità operativa — in inglese business continuity — è la disciplina che trasforma quell’alzata di spalle in un numero deciso in anticipo. Non promette che l’incidente non accada: organizza l’azienda perché, quando accade, sappia esattamente quanto può reggere e come ripartire. In questa guida rispondiamo, una alla volta, a tutte le domande che si nascondono dietro quella iniziale.

1. Cosa significa davvero “continuità operativa”?
2. Non è la stessa cosa del backup o del disaster recovery?
3. Come si stabilisce quanto a lungo possiamo restare fermi?
4. Cosa sono RTO e RPO, in pratica?
5. Come si costruisce concretamente il piano?
6. È un obbligo di legge? Cosa dicono NIS2 e DORA
7. Perché tanti piani falliscono proprio quando servono?
8. Domande frequenti

Cosa significa davvero “continuità operativa”?

Significa una cosa sola: l’azienda continua a funzionare, o si ferma solo per il tempo che ha deciso in anticipo di poter tollerare, anche quando qualcosa va storto. Quel “qualcosa” può essere un attacco informatico, un guasto hardware, un incendio, un’alluvione o l’improvvisa indisponibilità di un fornitore critico. La causa, ai fini della continuità, conta meno del risultato.

Il punto che sfugge più spesso è che non si tratta di uno strumento da acquistare, ma di un approccio da pianificare. La continuità operativa riguarda i processi aziendali prima ancora dei sistemi informatici, e ragiona al contrario rispetto alla sicurezza preventiva. La prevenzione si chiede “come impedisco che accada”; la continuità parte dall’assunto opposto — prima o poi qualcosa accadrà — e si chiede “come faccio a reggere l’urto e ripartire nei tempi che mi sono dato”. È questa inversione di prospettiva a renderla efficace: smette di scommettere sull’invulnerabilità e si concentra sulla capacità di recupero.

Non è la stessa cosa del backup o del disaster recovery?

No, ed è la confusione che genera le pianificazioni più fragili. Sono tre cose diverse, in rapporto gerarchico tra loro.

Il backup è la copia dei dati. Necessario, ma da solo non garantisce nulla in termini di continuità: avere i dati salvati non significa poter tornare operativi in fretta. Un backup che richiede tre giorni per essere ripristinato non vi salva da un fermo di tre giorni, ed è il motivo per cui, come abbiamo spiegato altrove, il backup è utile ma non basta.

Il disaster recovery è il livello tecnico: le procedure e le infrastrutture che rimettono in piedi i sistemi IT dopo un disastro. Riguarda server, reti, applicazioni.

La continuità operativa è il livello che comprende e supera entrambi, perché riguarda l’intera azienda e non solo l’IT: le persone e chi fa cosa nell’emergenza, i processi e come si lavora se i sistemi principali non ci sono, le sedi alternative, la comunicazione con clienti e fornitori. Detto in una riga: il disaster recovery ripristina i sistemi, la continuità operativa fa sì che l’azienda funzioni anche mentre i sistemi vengono ripristinati. Ogni piano di continuità contiene un piano di disaster recovery; non è vero il contrario.

Come si stabilisce quanto a lungo possiamo restare fermi?

Torniamo alla domanda d’apertura, perché qui ha la sua risposta tecnica. Non si stabilisce a intuito: si misura, con uno strumento che si chiama Business Impact Analysis (BIA). È il primo passo di ogni piano serio, e consiste nell’identificare i processi critici e nel quantificare cosa succede, ora dopo ora, quando si fermano.

La BIA risponde a tre domande per ciascun processo. Quali sono i processi senza i quali l’azienda non può operare? Quanto costa, in denaro e in reputazione, ogni ora o giorno della loro interruzione? E qual è il tempo massimo entro cui devono ripartire prima che il danno diventi insostenibile? È un lavoro che coinvolge i responsabili di ogni area, non solo l’IT, perché solo chi gestisce un processo sa cosa accade davvero quando si blocca. Il risultato è la mappa su cui si costruisce tutto il resto: senza sapere quali processi contano e quanto possono restare fermi, qualsiasi piano è costruito alla cieca.

Cosa sono RTO e RPO, in pratica?

Sono i due numeri in cui la BIA traduce la risposta alla nostra domanda iniziale, e da cui discende ogni scelta tecnica successiva.

L’RTO (Recovery Time Objective) è il tempo massimo entro cui un sistema deve tornare operativo. Risponde esattamente a “quanto a lungo possiamo restare fermi?”: un RTO di quattro ore significa che oltre le quattro ore il danno diventa inaccettabile. L’RPO (Recovery Point Objective) è invece la quantità massima di dati che potete permettervi di perdere, misurata in tempo, e risponde a “a quale momento possiamo tornare?”: un RPO di un’ora significa accettare di perdere al massimo l’ultima ora di lavoro, e quindi impone backup almeno orari.

La chiave è che questi due numeri vanno fissati processo per processo, non una volta per tutta l’azienda. Il gestionale di produzione avrà RTO e RPO stringenti, l’archivio storico consultato di rado potrà permetterseli larghi. Calibrarli su misura è ciò che rende un piano sostenibile: pretendere il ripristino in pochi minuti su qualunque sistema è tecnicamente possibile ma costosissimo, e quasi sempre ingiustificato.

Come si costruisce concretamente il piano?

Il piano di continuità operativa (Business Continuity Plan, BCP) è il documento che mette insieme tutte le risposte precedenti e stabilisce chi fa cosa quando qualcosa va storto. Si costruisce per fasi:

1. Analisi dei rischi e Business Impact Analysis, per sapere cosa proteggere e con quale priorità.
2. Definizione di RTO e RPO per ogni processo critico.
3. Progettazione delle strategie: disaster recovery, sedi alternative, procedure manuali di emergenza, ridondanze.
4. Stesura operativa: ruoli, responsabilità, catena di comando, comunicazione interna ed esterna durante la crisi.
5. Test periodici, perché un piano mai provato è un’ipotesi, non una garanzia.
6. Revisione continua, a ogni cambiamento di processi, sistemi o organizzazione.

Le ultime due fasi sono quelle che separano i piani veri da quelli che esistono solo in un cassetto. Un BCP non si redige una volta e si archivia: è uno strumento vivo, da testare con simulazioni realistiche e da aggiornare mentre l’azienda cambia.

È un obbligo di legge? Cosa dicono NIS2 e DORA

Per un numero crescente di aziende italiane, sì. La continuità operativa è passata da buona pratica facoltativa a requisito normativo, e due provvedimenti lo rendono esplicito.

La NIS2, recepita in Italia con il D.Lgs. 138/2024, all’articolo 24 elenca tra le misure di gestione del rischio obbligatorie proprio la continuità operativa, la gestione dei backup e il disaster recovery. Per i soggetti essenziali e importanti che rientrano nel suo perimetro, avere un piano non è più una scelta: è conformità. Gli aspetti tecnici del recepimento li abbiamo trattati nell’articolo su come recepire la NIS2 in Italia.

La DORA (Digital Operational Resilience Act, Regolamento UE 2022/2554), applicabile dal 17 gennaio 2025, mette la resilienza operativa digitale al centro per il settore finanziario: banche, assicurazioni, società di investimento e i loro fornitori ICT devono poter resistere agli incidenti e ripristinare le funzioni critiche entro tempi definiti, con RTO e RPO documentati e testati. Il filo che lega le due norme è netto: il legislatore non si accontenta più che la continuità sia dichiarata, vuole che sia documentata e dimostrata con i test.

Perché tanti piani falliscono proprio quando servono?

Perché esistono sulla carta ma non nella realtà. Nella nostra esperienza i motivi ricorrono: il backup che nessuno ha mai provato a ripristinare e che si rivela inservibile nel momento decisivo; il piano scritto una volta e mai più aggiornato, che descrive un’azienda che non esiste più; gli RTO promessi sulla carta ma irraggiungibili con le soluzioni effettivamente in uso.

C’è poi un punto cieco più insidioso, ed è tecnico. Un piano di continuità dà per scontato che i sistemi su cui poggia — i server di backup, le infrastrutture di disaster recovery, gli ambienti alternativi — siano sicuri. Ma se quegli stessi sistemi contengono vulnerabilità sfruttabili, un attaccante può comprometterli insieme a quelli primari, mandando in fumo l’intero piano nel momento esatto in cui dovrebbe salvarvi. È già successo con ransomware costruiti apposta per cercare e cifrare anche i backup. Verificare che le fondamenta tecniche della continuità siano prive di vulnerabilità note non è un dettaglio: è ciò che distingue un piano affidabile da uno solo teorico.

Un piano di continuità operativa regge solo se l’infrastruttura su cui poggia è solida. Cyberment affianca le imprese italiane con il Vulnerability Assessment e il Penetration Test certificati ISO 27001, che individuano e verificano le vulnerabilità dei sistemi, inclusi quelli di backup e ripristino su cui si fonda la vostra continuità, prima che lo faccia un attaccante. La formazione mette inoltre i team nelle condizioni di gestire correttamente l’emergenza.

Domande frequenti

Cos’è la continuità operativa?

È la capacità di un’organizzazione di continuare a erogare i propri servizi a livelli accettabili durante e dopo un evento che ne interrompe il normale funzionamento, come un attacco informatico o un guasto. È un approccio organizzativo che si pianifica, non uno strumento che si acquista, e riguarda l’intera azienda, non solo l’IT.

Che differenza c’è tra continuità operativa e disaster recovery?

Il disaster recovery è il livello tecnico che ripristina i sistemi IT dopo un disastro; la continuità operativa è il livello più ampio che fa in modo che l’intera azienda continui a funzionare anche mentre i sistemi vengono ripristinati, includendo persone, processi e comunicazione. Ogni piano di continuità contiene un piano di disaster recovery, ma non viceversa.

Cosa sono RTO e RPO?

L’RTO (Recovery Time Objective) è il tempo massimo entro cui un sistema deve tornare operativo dopo un’interruzione. L’RPO (Recovery Point Objective) è la quantità massima di dati che ci si può permettere di perdere, misurata in tempo. Vanno definiti per ciascun processo critico sulla base dell’impatto della sua interruzione.

Cos’è la Business Impact Analysis?

È l’analisi che identifica i processi aziendali critici e quantifica l’impatto della loro interruzione nel tempo. Risponde a quali processi sono indispensabili, quanto costa ogni ora di fermo e entro quanto vanno ripristinati. È il punto di partenza di ogni piano di continuità: senza, il piano è costruito alla cieca.

La NIS2 obbliga ad avere un piano di continuità operativa?

Sì, per i soggetti che rientrano nel suo perimetro. Il D.Lgs. 138/2024, che recepisce la NIS2 in Italia, all’articolo 24 include la continuità operativa, la gestione dei backup e il disaster recovery tra le misure di gestione del rischio obbligatorie, con requisiti di documentazione e test.

Cosa prevede la DORA in materia di continuità?

La DORA (Regolamento UE 2022/2554), applicabile dal 17 gennaio 2025, pone la resilienza operativa digitale al centro per il settore finanziario: banche, assicurazioni e i loro fornitori ICT devono garantire la capacità di resistere agli incidenti e ripristinare le funzioni critiche entro tempi definiti, con RTO e RPO documentati e testati.

Ogni quanto va testato un piano di continuità?

Un piano andrebbe testato con simulazioni realistiche almeno una volta l’anno e ogni volta che cambiano processi, sistemi o organizzazione. Un piano mai testato è solo un’ipotesi: i test servono a scoprire i punti deboli prima che lo faccia un incidente reale.

Il backup è sufficiente a garantire la continuità operativa?

No. Il backup è la copia dei dati ed è necessario, ma da solo non garantisce la continuità: se il ripristino richiede troppo tempo, o se i backup stessi sono compromessi da un attacco, l’azienda resta comunque ferma. Il backup è un tassello del disaster recovery, che a sua volta è un tassello della continuità operativa.
Lo schema FAQ JSON-LD è identico a quello che ti ho dato prima (le FAQ non sono