Quando un server si blocca, un ransomware cifra i dati o un guasto elettrico manda in fumo il NAS in produzione, la domanda che conta davvero non è “abbiamo il backup?” ma “in quanto tempo torniamo operativi e quanti dati abbiamo perso per sempre?”. Sono le due metriche che ogni imprenditore dovrebbe conoscere quanto il fatturato: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Nella nostra esperienza con aziende manifatturiere, automotive, food & beverage e studi professionali della Val di Sangro, la maggior parte delle PMI ha un backup, ma pochissime sanno rispondere con un numero preciso a queste due domande. Ed è proprio quel numero, o la sua assenza, a determinare se un incidente informatico diventa un disagio di poche ore o una crisi aziendale che dura settimane.
Cosa sono davvero RTO e RPO
Il RTO è il tempo massimo che l’azienda può permettersi di restare ferma prima che il danno diventi insostenibile: produzione bloccata, ordini non evasi, linee di assemblaggio ferme, clienti automotive che applicano penali per ritardo consegna. Se il tuo gestionale di produzione si blocca e il RTO concordato è di 4 ore, significa che entro 4 ore devi avere ambiente e dati di nuovo operativi, non “in fase di ripristino”.
Il RPO invece misura la perdita di dati accettabile, espressa in tempo: se il backup gira ogni notte alle 2:00 e il sistema si blocca alle 17:00 del giorno dopo, il RPO reale è di quasi 40 ore di lavoro perso — ordini, bolle, distinte base, email commerciali. Per uno studio professionale che gestisce pratiche fiscali o contrattuali, questo può significare dover ricostruire a mano giornate intere di lavoro con i clienti.
Molte PMI confondono “abbiamo il backup” con “abbiamo un RPO basso”: non è la stessa cosa. Un backup settimanale garantisce continuità teorica ma un RPO di 7 giorni, del tutto inaccettabile per un’azienda che fattura quotidianamente.
Il costo reale di un fermo produttivo
Nel settore manifatturiero e automotive un’ora di fermo linea può costare da alcune centinaia a diverse migliaia di euro, tra mancata produzione, personale retribuito ma inattivo e penali contrattuali verso committenti che lavorano in just-in-time. Abbiamo seguito casi in Val di Sangro dove un guasto al server di gestione ordini ha bloccato la programmazione delle macchine CNC per un’intera giornata lavorativa, con ricadute dirette sulle consegne concordate con OEM del settore automotive.
Nel food & beverage il rischio si somma a quello della tracciabilità: se il sistema che gestisce lotti, scadenze e HACCP resta fermo o perde dati, non è solo un problema informatico ma di conformità alimentare, con possibili ricadute su ispezioni e certificazioni.
Per uno studio professionale, invece, il danno è spesso reputazionale: un cliente che scopre che la sua pratica fiscale o il suo contratto sono andati persi per un guasto non coperto da backup verificato, difficilmente torna a fidarsi.
Come calcolare RTO e RPO reali per la tua azienda
Non esiste un valore standard: dipende da quanto la tua attività dipende dai sistemi informatici in ogni singola ora della giornata. Il primo passo è mappare i processi critici: gestionale ERP, sistema di produzione, posta elettronica, server file condivisi, software di contabilità. Per ciascuno va chiesto: “se questo sistema si ferma, dopo quante ore iniziamo a perdere soldi o clienti?” e “quanti dati recenti non possiamo permetterci di perdere?”.
Un’azienda di packaging con turni su due linee produttive avrà probabilmente un RTO di 1-2 ore sul sistema di gestione ordini, ma potrà tollerare un RTO di 24 ore sul server di archiviazione documentale storico. Distinguere i sistemi per criticità evita di investire tutto il budget IT in modo indiscriminato, concentrando le risorse dove il rischio economico è maggiore.
Allineare la strategia di backup a questi obiettivi
Una volta definiti RTO e RPO, la strategia tecnica ne consegue direttamente. Se il RPO richiesto è di 1 ora, un backup notturno non basta: servono repliche più frequenti, snapshot orari o sistemi di backup continuo per i dati più critici. Se il RTO richiesto è di poche ore, non basta avere i dati salvati: serve un ambiente di ripristino pronto, che sia un server di scorta, una virtual machine pre-configurata o uno spazio cloud dedicato al disaster recovery.
La regola 3-2-1 (tre copie dei dati, su due supporti diversi, con una copia fuori sede) resta il punto di partenza, ma va integrata con l’immutabilità dei backup: copie che non possono essere modificate o cifrate nemmeno da un attacco ransomware con privilegi amministrativi. Molte aziende scoprono solo dopo un attacco che anche il loro backup era raggiungibile e quindi cifrato insieme ai dati originali.
Il test di ripristino: l’errore più comune
Avere il backup non significa avere la certezza di poterlo ripristinare. Nella nostra esperienza sul territorio, oltre la metà delle PMI non ha mai testato concretamente un ripristino completo, limitandosi a verificare che il job di backup sia “andato a buon fine” da un pannello di controllo. Il problema emerge nel momento peggiore: durante un’emergenza reale, quando si scopre che il backup è corrotto, incompleto o troppo lento da ripristinare rispetto al RTO promesso.
Un test di ripristino periodico, anche solo trimestrale su un ambiente isolato, permette di verificare tempi reali di recovery, integrità dei dati e correttezza delle procedure documentate. È l’unico modo per sapere se il RTO dichiarato sulla carta corrisponde al RTO reale misurato sul campo.
Conformità, assicurazioni cyber e responsabilità aziendale
RTO e RPO documentati non sono solo buon senso tecnico: sono sempre più richiesti da polizze assicurative cyber, da clienti committenti che effettuano audit fornitori (tipico nell’automotive) e dal quadro normativo che, con la direttiva NIS2, impone alle aziende di dimostrare capacità di continuità operativa. Non avere questi parametri definiti espone l’azienda a due rischi concreti: il rifiuto di indennizzo assicurativo in caso di sinistro informatico, e la perdita di commesse verso clienti che richiedono garanzie documentate di business continuity.
Per uno studio professionale, definire RTO e RPO significa anche tutelare la responsabilità verso i clienti in caso di controversie legate alla perdita di documentazione fiscale o contrattuale.
- Mappa i sistemi critici e assegna a ciascuno un RTO e un RPO realistico basato sull’impatto economico
- Verifica la frequenza reale dei backup rispetto al RPO richiesto, non solo la loro esistenza
- Implementa copie immutabili e offsite, non raggiungibili da un attacco ransomware sulla rete principale
- Pianifica test di ripristino trimestrali su ambiente isolato, misurando i tempi effettivi
- Documenta procedure di disaster recovery accessibili anche se i sistemi principali sono fuori uso
- Rivedi RTO e RPO almeno una volta l’anno o dopo ogni cambiamento significativo dei processi
- Verifica che la polizza cyber richieda e riconosca i tuoi valori di RTO/RPO documentati
Definire RTO e RPO non è un esercizio teorico da consulente, ma la base concreta su cui costruire la continuità operativa della tua azienda: senza questi numeri, ogni piano di backup rischia di essere solo un’illusione di sicurezza. Se vuoi calcolare i valori reali per la tua PMI e verificare se la tua attuale strategia di backup li rispetta davvero, contatta pRcant.NET di Atessa al numero 0872 889205, anche su WhatsApp: analizziamo insieme i tuoi processi critici e costruiamo un piano di continuità operativa su misura per la tua azienda in Val di Sangro e in tutto l’Abruzzo.