Punti chiave
- L'RPO misura quanti dati si possono perdere (dal guasto all'ultima copia buona), l'RTO quanto un sistema può restare fermo: il primo guarda indietro, il secondo avanti.
- L'RPO dipende da frequenza dei backup, snapshot e replica; l'RTO da tutto ciò che serve per ripartire: decisione, ripristino, dipendenze, verifica dei dati.
- Secondo la NIST SP 800-34 l'RTO deve essere normalmente più breve del tempo massimo di interruzione tollerabile (MTD), mentre l'RPO non fa parte di quel tempo.
- Con un ransomware l'RPO reale si misura dall'ultima copia utilizzabile: CISA raccomanda backup offline e cifrati, perché molte varianti cercano i backup raggiungibili.
- Il DORA (art. 12, par. 6, Reg. UE 2022/2554) chiede di fissare obiettivi di punto e tempo di ripristino per ciascuna funzione; il Reg. delegato 2024/1774 li porta nel registro delle risorse ICT.
- Per la NIS2 le misure ACN non usano le sigle, ma la ID.IM-04 chiede piani di ripristino con gli obiettivi di ripristino e la PR.DS-11 backup coerenti con quei piani.
RPO e RTO misurano due cose diverse di un fermo. L'RPO (Recovery Point Objective) dice quanti dati si possono perdere: è la distanza tra il guasto e l'ultima copia da cui si riparte. L'RTO (Recovery Time Objective) dice quanto a lungo un sistema può restare fermo prima che il danno diventi inaccettabile. Il primo guarda indietro, il secondo avanti, e si raggiungono con mezzi diversi: l'RPO con frequenza di backup e replica, l'RTO con la capacità di ripristino.
Confonderli porta a errori costosi: un backup notturno non dice niente su quanto tempo serve per ripartire, e un sito di riserva pronto in un'ora non recupera gli ordini delle ultime dodici. Qui sotto le definizioni, un esempio, cosa li determina, come si fissano e cosa chiedono DORA, NIS2 e ISO 22301.
Le definizioni
Una fonte pubblica e chiara è la NIST SP 800-34 Rev. 1, la guida del NIST alla pianificazione della continuità dei sistemi informativi. Nella sezione 3.2 definisce i due parametri così (resa nostra dall'inglese):
- RPO: il punto nel tempo, prima dell'interruzione, a cui i dati di un processo possono essere recuperati, data la copia di backup più recente. Misura quanta perdita di dati il processo può tollerare.
- RTO: il tempo massimo per cui una risorsa di sistema può restare indisponibile prima di produrre un impatto inaccettabile sulle altre risorse, sui processi che sostiene e sul tempo massimo di interruzione tollerabile del processo (MTD).
La stessa guida aggiunge due precisazioni utili. L'RTO deve essere normalmente più breve dell'MTD, perché dopo il ripristino tecnico serve altro tempo, per esempio per rielaborare i dati rimasti indietro. L'RPO invece non fa parte dell'MTD: non è una questione di tempo di fermo, ma di dati persi.
MTD, RTO e RPO non si inventano a tavolino: escono dalla business impact analysis (BIA), che stabilisce quali attività sono critiche e quanto fermo e quanta perdita di dati possono sopportare.
La differenza in un esempio
Un esempio di fantasia, ma tipico. Il gestionale di un'azienda fa il backup ogni notte alle 2:00. Alle 15:00 un guasto lo blocca. Il sistema torna disponibile alle 19:00, ripristinato dal backup della notte.
- Dati persi: tutto quello che è stato registrato tra le 2:00 e le 15:00, cioè 13 ore di ordini, movimenti di magazzino, fatture. È il lato RPO.
- Tempo di fermo: dalle 15:00 alle 19:00, quattro ore. È il lato RTO.
Se l'azienda si era data un RTO di otto ore, sul tempo è dentro. Se il suo RPO era di un'ora, ha mancato l'obiettivo di dodici ore, e nessun ripristino più veloce avrebbe cambiato le cose: i dati dopo le 2:00 non esistevano in nessuna copia.
I due valori sono indipendenti anche nelle scelte. Un sistema di ordini online può tollerare qualche ora di fermo ma quasi nessuna perdita di dati, perché ogni ordine perso è un cliente da richiamare. Un archivio documentale può restare fermo per giorni, e una copia del giorno prima basta.
La differenza è scritta anche nelle norme. Il Regolamento delegato (UE) 2024/1774, che attua il DORA sulla gestione dei rischi ICT, all'articolo 24, paragrafo 4, chiede alle sedi di negoziazione due cose separate: che la negoziazione possa riprendere entro circa due ore dall'evento, e che la quantità massima di dati persa sia prossima allo zero. Sono un RTO e un RPO, fissati uno accanto all'altro.
Cosa determina l'RPO e cosa determina l'RTO
L'RPO dipende da quando è stata fatta l'ultima copia buona
- Frequenza dei backup e degli snapshot. Con un backup al giorno, nel caso peggiore si perde quasi un giorno di dati. La NIST SP 800-34 raccomanda che le politiche fissino frequenza minima e ambito dei backup in base alla criticità dei dati e a quanto spesso entrano informazioni nuove.
- Replica. Copiare i dati in continuo su un secondo sistema avvicina l'RPO a zero. Ma la replica copia tutto, anche una cancellazione o una cifratura: senza copie storiche, il dato replicato può essere già compromesso.
- Integrità della copia. L'RPO reale si misura dall'ultima copia utilizzabile, non dall'ultima eseguita.
L'RTO dipende da tutto ciò che serve per ripartire
- Accorgersi e decidere. Il tempo tra il guasto e la decisione di attivare il piano conta nell'RTO, anche se spesso non viene misurato.
- Ripristinare. Quanti dati, dove stanno le copie, con che banda si recuperano, se c'è un'infrastruttura pronta su cui riportarli.
- Ricostruire le dipendenze. Un'applicazione non riparte prima dell'identità, della rete e dei database da cui dipende: il suo RTO non può essere più corto di quello delle sue dipendenze.
- Verificare i dati. Prima di riaprire al lavoro, bisogna controllare che i dati ripristinati siano coerenti. Il DORA, all'articolo 12, paragrafo 7, lo chiede in modo esplicito alle entità finanziarie, anche con verifiche multiple e controlli incrociati.
Il costo cresce quando i valori scendono
La NIST SP 800-34 lo rappresenta come un bilanciamento: più dura il fermo, più costa all'azienda; più l'RTO è corto, più costa la capacità di ripristino. Ripartire subito richiede sistemi senza fermo e siti alternativi, molto più costosi; un sistema a basso impatto con un RTO lungo può reggersi su un semplice backup su nastro. Il punto di equilibrio è diverso per ogni azienda e per ogni sistema: per questo RPO e RTO si fissano sistema per sistema, non uno solo per tutta l'azienda.
Come si fissano RPO e RTO, in pratica
- Partire dai processi, non dai server. La BIA dice quali attività sono critiche e qual è il loro tempo massimo di interruzione tollerabile. Da lì si scende ai sistemi che le sostengono.
- Chiedere ai responsabili di processo le due cose separatamente. Quanto potete restare fermi? Se i dati tornano a ieri sera, cosa si perde e quanto costa ricostruirlo? Sono due domande diverse e danno due risposte diverse.
- Tradurre i valori in scelte tecniche. Frequenza dei backup, snapshot, replica per l'RPO; infrastruttura di riserva, procedure di ripristino, ordine di ripartenza per l'RTO.
- Misurare i tempi reali. Un RTO di quattro ore su un sistema mai ripristinato da backup è un'ipotesi. Il test di ripristino dice quanto serve davvero, e il confronto con l'obiettivo dice dove intervenire.
- Far approvare dalla direzione. Quanto fermo e quanta perdita accettare sono decisioni di business, e i valori più bassi costano di più. Le misure ACN per la NIS2 chiedono che i piani di continuità e di ripristino siano approvati dagli organi di amministrazione e direttivi.
Dove si sbaglia più spesso
- Contare sul backup raggiungibile. Con un ransomware l'ultimo backup può non essere utilizzabile. CISA, nella #StopRansomware Guide, raccomanda backup offline e cifrati dei dati critici, perché molte varianti cercano i backup accessibili per cancellarli o cifrarli. Se la copia buona più recente è di una settimana fa, l'RPO reale è una settimana. Come si imposta una copia che resti fuori portata è spiegato nell'articolo sul backup cloud per aziende.
- Scambiare la replica per un backup. La replica abbassa l'RPO contro un guasto, non contro un errore o un attacco che si propaga alla copia.
- Un RTO mai provato. I tempi di ripristino si allungano con i volumi di dati, e chi non li misura lo scopre durante il fermo.
- Dimenticare chi decide. Le ore spese a capire chi può dichiarare l'emergenza entrano nel fermo. Ruoli e attivazione stanno nel piano di gestione della crisi, descritto nell'articolo sul crisis management aziendale.
Cosa chiedono DORA, NIS2 e ISO 22301
DORA
Il Regolamento (UE) 2022/2554 usa i due concetti in modo esplicito. All'articolo 12, paragrafo 6, stabilisce: "Nel determinare gli obiettivi in materia di punti di ripristino e tempi di ripristino di ciascuna funzione, le entità finanziarie tengono conto del fatto che si tratti di una funzione essenziale o importante e del potenziale impatto complessivo sull’efficienza del mercato." Aggiunge che gli obiettivi di tempo devono garantire i livelli di servizio concordati anche in scenari estremi.
Lo stesso articolo, al paragrafo 1, chiede politiche di backup con una frequenza minima stabilita in base alla criticità delle informazioni o alla riservatezza dei dati, e al paragrafo 2 test periodici delle procedure di backup e di ripristino. Il Regolamento delegato (UE) 2024/1774 porta RPO e RTO fino al livello del singolo asset: l'articolo 4, paragrafo 2, lettera b), punto vi), chiede di registrare per ogni risorsa ICT i requisiti di continuità, compresi gli obiettivi di tempo di ripristino e di punto di ripristino. Restano fuori dagli articoli da 5 a 15 del DORA le entità del quadro semplificato dell'articolo 16. Il contesto è nell'articolo su gestione del rischio ICT e registro dei fornitori.
NIS2
Il D.Lgs. 138/2024 elenca tra le misure minime, all'articolo 24, comma 2, lettera c), 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 (allegati 1 e 2 della determinazione 379907/2025) non usano le sigle RPO e RTO, ma la misura ID.IM-04 chiede per almeno i sistemi informativi e di rete rilevanti un piano di ripristino in caso di disastro che contenga "le procedure di ripristino per operazioni specifiche, compresi gli obiettivi di ripristino", da riesaminare almeno ogni due anni e dopo incidenti significativi. La misura PR.DS-11 chiede che i backup siano fatti in accordo alle esigenze individuate in quei piani, con copie offline per i sistemi rilevanti; per i soggetti essenziali anche la verifica periodica dei backup con test di ripristino. Il quadro completo è nella guida completa alla NIS2.
ISO 22301
Nella ISO 22301:2019, aggiornata dall'emendamento 1 del 2024, la BIA è la clausola 8.2.2 e la scelta delle strategie di continuità la clausola 8.3. Nella pratica RPO e RTO stanno nel passaggio tra le due: la BIA dice quanto si può perdere e quanto si può restare fermi, le strategie decidono con quali mezzi rispettarlo.
Da dove partire
Se oggi RPO e RTO sono un numero nel contratto con il fornitore di backup, il primo passo è ricavarli dai processi e misurarli con un ripristino vero. Per farlo dentro un sistema di continuità verificabile da un ente terzo, il percorso di certificazione ISO 22301 parte da lì: attività critiche, obiettivi di ripristino approvati dalla direzione, strategie coerenti e test.