Disaster recovery e business continuity: tutto si decide su RTO e RPO, non sul piano

Disaster recovery e business continuity vengono spesso usati come sinonimi, ma indicano due cose distinte, e confonderle è il primo passo verso un ripristino che non regge alla prova dei fatti. La business continuity è l’obiettivo: tenere operative le funzioni essenziali di un’organizzazione mentre un evento avverso è in corso. Il disaster recovery è uno dei mezzi per raggiungerlo, la parte che riguarda il recupero dei sistemi informativi e dei dati dopo un’interruzione. Il primo è un problema di organizzazione, il secondo un problema di tecnologia, e l’errore ricorrente è trattare il secondo come se esaurisse il primo.

La distanza tra avere un piano e avere un piano che funziona si misura su due numeri: quanto a lungo l’organizzazione può restare ferma e quanto lavoro recente può permettersi di perdere. Sono il Recovery Time Objective e il Recovery Point Objective, RTO e RPO. Quasi tutto il valore di una strategia di continuità si concentra qui, e quasi tutti gli errori nascono dal modo in cui questi due valori vengono fissati: scelti dall’IT per comodità tecnica invece che derivati dall’impatto sul business, scritti su un documento e mai verificati con una prova reale.

Due piani, un solo obiettivo

La gerarchia tra i due concetti non è una sottigliezza terminologica, perché definisce chi decide cosa. La guida del NIST sul contingency planning descrive una suite di piani coordinati: il piano di continuità operativa fa da quadro generale e il disaster recovery è uno dei piani operativi della suite, dedicato al ripristino dei sistemi a supporto delle funzioni critiche. Accanto al disaster recovery convivono altri piani: la gestione della crisi, la comunicazione, la continuità delle operazioni. Vederli come un insieme coordinato, e non come documenti separati che vivono in cassetti diversi, è la differenza tra una risposta governata e una somma di reazioni scollegate.

Questa distinzione ha una conseguenza pratica immediata. Il disaster recovery risponde alla domanda tecnica: come riporto in funzione server, applicazioni e dati. La business continuity risponde a una domanda più ampia, quella che dà forma al piano di continuità operativa: quali processi devono restare in piedi, in quale ordine, con quali risorse alternative anche non informatiche. Un’organizzazione che ha costruito un solido piano di disaster recovery ma non ha definito le priorità di business si ritrova a ripristinare con efficienza sistemi che, in quel momento, non sono i più urgenti da riavere.

Disaster recovery senza metriche è solo una speranza

Il punto in cui i due piani si saldano sono gli obiettivi di ripristino, e qui conta la precisione. Il Recovery Time Objective è il tempo massimo entro cui un processo deve tornare operativo prima che il danno diventi inaccettabile. Il Recovery Point Objective è la quantità massima di dati che si può accettare di perdere, espressa come finestra temporale: un RPO di un’ora significa che, nel caso peggiore, si torna alla situazione di sessanta minuti prima dell’incidente. Sopra entrambi sta il Maximum Tolerable Period of Disruption, il periodo oltre il quale l’interruzione produce conseguenze irreversibili; l’RTO deve restare al di sotto di questa soglia, con un margine di sicurezza.

Questi valori non si inventano e non li sceglie il reparto tecnico in base a ciò che è comodo realizzare. Lo standard internazionale dedicato alla continuità operativa, la norma ISO 22301 nella versione del 2019, li fa discendere dall’analisi di impatto sul business, la business impact analysis, che misura per ciascuna attività il danno prodotto dal tempo di fermo. È da quel danno, non dalla disponibilità di un sito secondario, che derivano l’RTO e l’RPO. Invertire l’ordine, fissare gli obiettivi a partire da ciò che l’infrastruttura già consente, è l’errore che svuota di senso l’intero esercizio: si ottengono numeri raggiungibili ma scollegati da quanto l’organizzazione può davvero tollerare.

L’RPO, in particolare, è un requisito travestito da metrica. Dichiarare un RPO di quindici minuti e affidarsi a un backup notturno è una contraddizione che resta invisibile finché non arriva l’incidente, momento in cui ci si accorge che si sono persi non quindici minuti ma un’intera giornata di lavoro. La frequenza con cui si copiano o si replicano i dati deve discendere dall’RPO, non il contrario.

L’orologio normativo: ripristino e backup non sono più facoltativi

Per anni la continuità operativa è stata trattata come buona pratica, qualcosa che si faceva se restavano tempo e budget. Quella stagione è finita, perché il quadro regolatorio europeo l’ha trasformata in obbligo con requisiti verificabili. La direttiva NIS2, all’articolo 21, include esplicitamente tra le misure minime di gestione del rischio la continuità operativa, citando la gestione del backup, il ripristino in caso di disastro e la gestione delle crisi. Non è più una raccomandazione: è una delle condizioni a cui i soggetti essenziali e importanti devono conformarsi.

Per il settore finanziario il vincolo è ancora più dettagliato. Il regolamento DORA, applicabile dal gennaio 2025, impone all’articolo 11 una politica di continuità operativa ICT con piani di risposta e ripristino da testare almeno una volta l’anno, e all’articolo 12 politiche di backup che specifichino perimetro e frequenza minima in base alla criticità dei dati, con verifiche periodiche delle procedure di ripristino e controlli sull’integrità dei dati recuperati. Il messaggio comune alle due norme è netto: non basta possedere i piani, occorre dimostrarne il funzionamento con prove documentate. La continuità diventa così un processo misurabile, non una dichiarazione di intenti.

Perché i piani falliscono quando servono

I piani di continuità raramente falliscono per assenza. Falliscono perché non sono mai stati messi alla prova nelle condizioni che dovrebbero affrontare. Il caso più frequente è il disallineamento tra obiettivi dichiarati e capacità reali: un RTO di quattro ore che presuppone un failover automatico mai eseguito davvero, o un sito di ripristino che esiste sulla carta ma non è mai stato attivato sotto carico. Un secondo errore è ignorare le dipendenze: si ripristina l’applicazione critica ma non il servizio di autenticazione, la rete o il sistema da cui dipende, e il ripristino si blocca su un anello trascurato della catena.

C’è poi un punto cieco che riguarda proprio i dati. Le strategie di ripristino moderne danno per scontato di poter contare su una copia integra da cui ripartire, ma un ransomware che cifra anche i backup azzera questa premessa, ed è la ragione per cui la difesa del dato si è spostata verso copie immutabili e isolate. Infine, il fattore che pesa più di ogni tecnologia è la prova: un piano testato una volta all’anno in modo realistico, con tempi cronometrati e scenari plausibili, vale più di una documentazione perfetta mai esercitata. È nella prova che si scopre se l’RTO dichiarato è raggiungibile o è solo un numero gradevole su una slide.

Disaster recovery e business continuity, in conclusione, non si giudicano dallo spessore del piano ma dalla fedeltà dei suoi numeri alla realtà dell’organizzazione. Le aziende che si rialzano in fretta da un’interruzione non sono quelle con la documentazione più curata, ma quelle che hanno fissato RTO e RPO a partire dall’impatto sul business, li hanno tradotti in scelte tecniche coerenti e li hanno verificati prima che servissero. La continuità non è ciò che si scrive quando tutto funziona: è ciò che resta in piedi quando smette di funzionare.