Questo articolo è una guida metodologica al piano di disaster recovery. Se stai valutando un servizio gestito con RTO e RPO concordati, la pagina di riferimento è Disaster Recovery per aziende.
Un piano di disaster recovery è il documento che stabilisce cosa fare, chi lo fa e in quanto tempo, quando un guasto, un attacco o un evento imprevisto mette fuori uso i sistemi IT della tua azienda. Non è un dettaglio tecnico da lasciare al reparto IT: è una delle poche cose che, nel momento peggiore, fa la differenza tra un'interruzione di poche ore e una crisi che dura settimane.
Nel 2026 questo tema è diventato ancora più urgente per due motivi concreti. Il primo è normativo: la direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, impone piani di continuità misurabili, testati e documentati a decine di migliaia di aziende medie e grandi in 18 settori essenziali (a partire da 50 dipendenti e 10 milioni di fatturato), oltre alla pubblica amministrazione e a tutta la catena di fornitura collegata. Se la tua azienda rientra in questo perimetro, o lavora con chi ci rientra, trovi il quadro completo nella nostra guida alla NIS2 per le PMI.
Il secondo motivo è più diretto: il ransomware. Secondo il Rapporto Clusit, nel 2025 in Italia sono stati registrati 507 incidenti gravi di questo tipo, quasi il 10% del totale mondiale, in crescita del 42% rispetto all'anno precedente. Un piano di disaster recovery scritto pensando solo a guasti hardware o eventi naturali, nel 2026, è già in ritardo di qualche anno.
Cosa deve contenere un piano che funziona davvero
Prima dei consigli pratici, vale la pena chiarire cosa rende un piano di disaster recovery davvero utilizzabile, e non solo un documento che nessuno ha mai riletto dopo averlo scritto.
Ogni piano si costruisce intorno a due numeri: l'RTO (Recovery Time Objective), il tempo massimo che l'azienda può permettersi di restare ferma, e l'RPO (Recovery Point Objective), la quantità massima di dati che accetta di perdere. Non sono valori standard: cambiano da sistema a sistema, in base a quanto costa davvero, in euro e in reputazione, che quel sistema resti fermo. Li abbiamo spiegati più nel dettaglio, con qualche esempio in più, nella nostra guida al disaster recovery, e in come cambiano quando si sceglie una soluzione gestita nella pagina dedicata al Disaster Recovery as a Service.
Oltre a RTO e RPO, un piano solido definisce chi fa cosa (chi dichiara l'emergenza, chi coordina il ripristino, chi comunica con clienti e fornitori), dove sono conservate le copie dei dati critici, e come vengono replicati i sistemi che servono a farli funzionare, non solo i file al loro interno.
5 consigli pratici per costruire un piano che funziona davvero
1. Testalo, non limitarti a scriverlo
Un piano di disaster recovery mai testato è, nella pratica, solo un'ipotesi. Va simulato almeno una o due volte l'anno, e ogni volta che cambia in modo significativo l'infrastruttura che deve proteggere: un nuovo server, un nuovo gestionale, un trasferimento di sede. Il test serve a scoprire cosa non funziona quando le conseguenze di un errore sono ancora zero, non quando l'azienda è già ferma davvero.
2. Costruiscilo sulla tua azienda, non su un modello generico
Un piano copiato da un template trovato online, senza adattarlo ai tuoi sistemi, ai tuoi fornitori e ai tuoi vincoli normativi, si rivela quasi sempre incompleto proprio nel momento in cui serve. Deve rispecchiare come lavora davvero la tua azienda: quali applicazioni usa ogni giorno, quali dati sono realmente critici, quali obblighi contrattuali o normativi, NIS2 compresa, è tenuta a rispettare.
3. Dai priorità: non tutti i dati valgono lo stesso
Uno degli errori più comuni è trattare tutti i dati e i sistemi allo stesso modo. Un database ordini è quasi sempre più critico di un archivio di documenti consultati una volta al mese: metterli sullo stesso piano nel piano di ripristino significa sprecare tempo e risorse dove contano meno, e lasciarne poche dove servirebbero davvero.
4. Definisci RTO e RPO prima di scegliere la tecnologia
È un errore frequente: si sceglie prima la soluzione tecnica, e solo dopo ci si chiede se rispetta davvero i tempi di cui l'azienda ha bisogno. Andrebbe fatto al contrario. Stabilisci quanto puoi permetterti di restare fermo e quanti dati puoi permetterti di perdere, per ogni sistema critico, e solo a quel punto valuta le soluzioni in grado di garantirli.
5. Coinvolgi tutta l'azienda, non solo l'IT
Un guasto o un attacco non colpisce mai un solo reparto. Il piano deve coinvolgere chi si occupa della comunicazione verso i clienti, chi gestisce i rapporti con i fornitori, chi ha responsabilità legali in caso di violazione dei dati. Se il piano vive solo nella testa di una persona in IT, quella persona diventa un singolo punto di fallimento, esattamente il tipo di rischio che il piano dovrebbe eliminare.
Disaster recovery e business continuity, in breve
Vale la pena chiarirlo, perché i due termini vengono usati come sinonimi più spesso di quanto dovrebbero. Il disaster recovery si occupa di ripristinare i sistemi informativi dopo un evento che li ha colpiti direttamente. La business continuity è più ampia: riguarda tutto ciò che serve all'azienda per continuare a operare, anche di fronte a cause che non hanno nulla a che fare con l'IT. Il disaster recovery è, in pratica, la parte tecnologica di un piano di continuità più grande. Se vuoi capire meglio dove finisce l'uno e comincia l'altro, con qualche esempio in più, ne parliamo nella nostra guida al disaster recovery.
Non deve essere un lavoro che fai da solo
Scrivere un piano di disaster recovery richiede tempo, competenze e uno sguardo esterno che spesso manca a chi vive l'infrastruttura ogni giorno. Affidarne la costruzione e la gestione a chi lo fa di mestiere può far risparmiare mesi di lavoro, e più di un errore fatto scoprire nel momento sbagliato.
Con Nexsys puoi affidarti a una soluzione DRaaS basata su Druva, con RTO e RPO definiti insieme a te fin dall'inizio del progetto, non scoperti a piano già scritto e testato male.
