Quando un servizio digitale si interrompe, i processi non subiscono tutti le stesse conseguenze e non possono attendere lo stesso tempo prima di essere ripristinati. Anche perdere alcuni minuti di informazioni è diverso dal perdere un’intera giornata di attività. Per questo, definire gli obiettivi di ripristino significa collegare le esigenze aziendali alle capacità tecniche, invece di assegnare un valore uniforme a tutte le applicazioni.
Due misure aiutano a esprimere queste esigenze: l’RTO, che stabilisce per quanto tempo un processo può rimanere interrotto prima che l’impatto diventi inaccettabile, e l’RPO, che definisce quanta perdita di dati, espressa in termini di tempo, è possibile tollerare. Sono obiettivi concordati, non garanzie automatiche. Per essere utili, devono essere comprensibili, realistici e verificabili.
RTO e RPO rispondono a domande diverse
L’RTO, o obiettivo di tempo di ripristino, risponde alla domanda: per quanto tempo possiamo fare a meno di questo processo? Si misura dall’interruzione fino al momento in cui il processo torna a un livello operativo concordato. Non basta che un server si avvii: il servizio deve poter svolgere le funzioni che giustificano il ripristino.
L’RPO, o obiettivo del punto di ripristino, risponde invece alla domanda: fino a quale momento devono essere aggiornati i dati ripristinati? Se l’RPO concordato è di un’ora, l’azienda accetta, al massimo, di recuperare dati il cui stato risale a un’ora prima dell’incidente. L’RPO non indica quanto tempo occorre per ripristinarli: questo rientra nell’RTO.
Le due misure sono complementari, ma non intercambiabili. Un sistema può ripristinare rapidamente una copia con dati troppo datati oppure conservare dati recenti e impiegare troppo tempo per riprendere l’attività. La decisione deve considerare entrambe le situazioni e precisare che cosa significa «ripristinato»: quali utenti, transazioni o funzioni devono essere disponibili.
Definire gli obiettivi per processo, non per applicazione
Un’applicazione può supportare diversi processi con impatti differenti. Viceversa, un processo dipende spesso da varie applicazioni, dati, fornitori e attività operative. Perciò, partire dall’elenco dei sistemi e assegnare loro una priorità tecnica può nascondere ciò che l’azienda deve davvero proteggere.
È preferibile iniziare individuando processi specifici, come accettare ordini, registrare pagamenti o gestire le richieste. Per ciascuno, il responsabile aziendale dovrebbe descrivere le conseguenze di un’interruzione e della perdita di dati. Il team tecnologico può poi mappare le applicazioni e le dipendenze necessarie a mantenerlo operativo. Se una stessa piattaforma supporta processi con obiettivi diversi, occorre verificare se sia possibile ripristinarli separatamente oppure se condividano un vincolo da rendere esplicito.
Questo approccio aiuta anche a individuare dipendenze trascurate: identità e accessi, comunicazioni, integrazioni, database, informazioni di configurazione, personale con competenze specifiche e fornitori esterni. Ripristinare l’applicazione principale non riattiva il processo se una dipendenza critica è ancora indisponibile.
Stimare l’impatto nel tempo
L’impatto non si manifesta sempre all’improvviso. Un’interruzione breve può avere conseguenze gestibili, ma, superata una certa soglia, può causare arretrati, il mancato rispetto degli impegni o una riduzione della capacità operativa. L’analisi deve descrivere come cambia il danno con il passare del tempo, non limitarsi a definire un sistema «critico».
Per svolgere questa valutazione in modo pratico, il team può chiedersi:
- Che cosa si ferma: operazioni, canali o decisioni che dipendono dal processo.
- Chi ne subisce le conseguenze: clienti, dipendenti, partner o altri team.
- Che cosa si accumula: ordini in sospeso, richieste inevase o informazioni che non vengono registrate.
- Quando l’impatto diventa inaccettabile: il momento in cui supera la soglia tollerata dall’azienda.
- Quali dati potrebbero andare persi: la loro importanza, la frequenza di aggiornamento e la possibilità di ricostruirli.
Le stime devono considerare condizioni rilevanti, come i periodi di maggiore attività o le chiusure operative. Se i dati disponibili non sono sufficienti, è meglio documentare l’incertezza e concordare un’ipotesi da rivedere, invece di presentare una cifra apparentemente precisa ma priva di fondamento.
Concordare obiettivi realizzabili
Il responsabile aziendale propone quale perdita di dati e quale ritardo siano tollerabili; il team tecnologico valuta le risorse e le procedure necessarie per rispettare tali limiti. Il team operativo spiega come viene rilevato l’incidente, chi decide di attivare il ripristino e quali attività devono essere eseguite. La decisione finale richiede il confronto fra queste funzioni: fissare un RTO ambizioso senza risorse né capacità comprovate non riduce il rischio.
Un accordo utile specifica almeno il processo, l’RTO, l’RPO, l’ambito del ripristino, le dipendenze, i responsabili e le evidenze che dimostreranno il raggiungimento degli obiettivi. Deve inoltre indicare le ipotesi di riferimento: per esempio, quali funzioni vengono ripristinate per prime o quali procedure manuali possono sostenere temporaneamente l’attività. Un’alternativa manuale può ridurre l’impatto, ma richiede responsabili, istruzioni e limiti chiari; non va considerata disponibile per scontata.
Il confronto tra esigenze e capacità attuali può far emergere delle lacune. La soluzione non consiste sempre nell’acquistare tecnologia: può essere necessario semplificare le dipendenze, migliorare le procedure, rafforzare la registrazione dei dati, dare priorità a una funzione essenziale oppure accettare formalmente un diverso livello di rischio. La scelta dipende dall’impatto e dalle reali opzioni operative.
Verificare dipendenze, architettura e operatività
L’obiettivo concordato va confrontato con l’intero percorso di ripristino. Per l’RTO bisogna considerare il rilevamento, il processo decisionale, l’accesso a persone e sistemi, il ripristino, la verifica e la ripresa del processo. Se una fase non è inclusa nel piano, il tempo previsto potrebbe non essere realistico.
Per l’RPO occorre controllare come vengono generati e conservati i dati recuperabili, con quale frequenza vengono aggiornati e quali informazioni non rientrano in quel meccanismo. Un backup è una componente della strategia, non la prova che il ripristino sarà possibile entro gli obiettivi. Bisogna verificare che i dati siano utilizzabili e che la procedura non dipenda da ipotesi mai convalidate.
È inoltre importante individuare le dipendenze condivise. Se più processi richiedono la stessa soluzione di identità, la stessa rete o lo stesso fornitore, il loro ripristino simultaneo può mettere in concorrenza le risorse o richiedere un ordine specifico. Documentare queste relazioni permette di definire le priorità di ripristino e capire quali obiettivi siano raggiungibili nelle diverse condizioni.
Testare, rivedere e correggere gli obiettivi
I test trasformano gli obiettivi in evidenze. Un’esercitazione può seguire la procedura dall’inizio alla fine, misurare il tempo necessario per ripristinare le funzioni concordate e verificare lo stato dei dati recuperati. Non basta accertarsi che esista un backup o che un’istanza si avvii: il responsabile del processo deve confermare che il risultato consenta di lavorare.
Le esercitazioni possono iniziare con una revisione delle procedure e passare a scenari tecnici più completi, in base al rischio e alle capacità del team. Per ogni test è utile registrare:
- Il processo, lo scenario e le dipendenze sottoposti a verifica.
- Quando è iniziata l’interruzione e quando sono state ripristinate le funzioni concordate.
- Il punto temporale dei dati recuperati e l’eventuale perdita osservata.
- Le fasi non riuscite, le ipotesi non rispettate e chi correggerà ciascuna lacuna.
Se il risultato supera l’RTO o l’RPO, bisogna decidere se migliorare le capacità, modificare il processo o rivedere l’obiettivo insieme all’azienda. Ripetere un test senza risolvere i problemi emersi non aumenta l’affidabilità. Gli obiettivi vanno rivisti anche quando cambiano il processo, l’architettura, il volume delle attività o le dipendenze.
Errori frequenti e modello decisionale
Tra gli errori più comuni ci sono assegnare lo stesso obiettivo a tutti i sistemi, confondere RTO e RPO, presumere che un backup equivalga al ripristino e fissare traguardi senza coinvolgere l’azienda. È rischioso anche misurare soltanto la disponibilità tecnica, ignorare le attività di coordinamento o considerare riuscito un test senza convalidare i dati e le funzioni del processo.
Una scheda semplice aiuta a rendere tracciabili le decisioni. Può comprendere i seguenti campi:
- Processo e responsabile aziendale: quale attività viene protetta e chi accetta l’impatto.
- Impatto in base alla durata e alla perdita di dati: conseguenze e soglie tollerabili.
- RTO e RPO concordati: obiettivi e ambito del ripristino.
- Applicazioni e dipendenze: componenti, team e fornitori necessari.
- Procedura e alternativa manuale: passaggi, priorità, responsabili e limiti.
- Ultimo test ed evidenze: risultato osservato, lacune e azioni ancora da svolgere.
Definire RTO e RPO per processo non significa scegliere numeri ideali, ma concordare limiti che riflettano l’impatto, verificare se l’organizzazione sia in grado di rispettarli e intervenire sulle lacune. Una revisione periodica mantiene gli obiettivi allineati al servizio reale ed evita di confondere un’aspettativa documentata con una capacità dimostrata.