Piano di disaster recovery per PMI: come scriverlo passo per passo
Come scrivere un piano di disaster recovery per una PMI: analisi dei rischi, priorità, ruoli, procedure di ripristino e test. Una guida pratica e senza gergo.
Area GUI · · 4 min di lettura
Un guasto al server, un ransomware, un allagamento in sala macchine: quando succede, la domanda non è «se» ripartire ma «in quanto tempo e con quali dati». Molte PMI hanno i backup, ma non hanno scritto da nessuna parte chi fa cosa, in che ordine e con quali priorità. Un piano di disaster recovery serve esattamente a questo.
Cos'è un piano di disaster recovery
Il piano di disaster recovery (DR) è un documento operativo che descrive come ripristinare sistemi informatici e dati dopo un evento grave. Non è un manuale teorico: è una sequenza di passi che una persona deve poter seguire anche sotto stress, magari di notte o nel fine settimana.
Un buon piano risponde a quattro domande:
- quali sistemi sono critici e in che ordine vanno ripristinati;
- quanti dati l'azienda può permettersi di perdere e per quanto tempo può restare ferma;
- chi decide, chi esegue e chi comunica;
- dove si trovano backup, credenziali, contratti e contatti utili.
Il disaster recovery è una parte della più ampia continuità operativa: dove la prima riguarda l'intera organizzazione e il secondo i sistemi informatici e i dati.
Passo 1: censire sistemi e dipendenze
Non si può proteggere ciò che non si conosce. Il primo passo è un elenco aggiornato di server, applicazioni, servizi cloud, apparati di rete e postazioni critiche, con le relative dipendenze. Il gestionale, per esempio, può dipendere da un database, da un server di dominio, dalla rete e da una licenza online: se manca uno di questi elementi, non riparte.
Un inventario degli asset IT ben tenuto rende questo passaggio molto più rapido.
Passo 2: definire priorità, RPO e RTO
Per ogni sistema serve stabilire due valori:
- RPO (Recovery Point Objective): quanti dati, misurati in tempo, si possono perdere;
- RTO (Recovery Time Objective): entro quanto tempo il servizio deve tornare disponibile.
Questi valori non li decide l'IT da solo: vanno concordati con la direzione e con i responsabili di reparto, perché dipendono da quanto costa all'azienda ogni ora di fermo. Ne parliamo in dettaglio in RPO e RTO spiegati semplice.
Il risultato è una classifica: i sistemi di livello 1 (per esempio ERP e posta) ripartono per primi, quelli di livello 3 possono attendere qualche giorno.
Passo 3: scrivere le procedure di ripristino
Per ogni sistema critico va descritta la procedura concreta:
- dove si trova il backup più recente e come si verifica che sia integro;
- su quale infrastruttura si ripristina (server di riserva, ambiente virtuale, cloud);
- in che ordine si riattivano i servizi dipendenti;
- come si verifica che il sistema funzioni davvero prima di riaprirlo agli utenti.
Le istruzioni devono essere chiare anche per chi non ha configurato il sistema. Se una procedura esiste solo nella testa di un tecnico, il piano ha un punto debole.
Passo 4: ruoli, contatti e comunicazione
Durante un'emergenza la confusione fa perdere più tempo del guasto stesso. Il piano deve indicare:
- il responsabile che dichiara l'emergenza e attiva il piano;
- i referenti tecnici, interni ed esterni, con un sostituto per ciascuno;
- i contatti di fornitori, assistenza, provider di connettività;
- chi comunica con dipendenti, clienti e, se necessario, con le autorità.
Se l'incidente coinvolge dati personali, il Regolamento (UE) 2016/679 (GDPR) prevede, all'art. 33, la notifica al Garante entro 72 ore dalla conoscenza della violazione, salvo che sia improbabile un rischio per le persone. Per le aziende soggette a NIS2 valgono anche gli obblighi di notifica verso il CSIRT nazionale: è utile che il piano rimandi alla procedura di gestione degli incidenti.
Una copia del piano, con contatti e credenziali d'emergenza, va conservata anche fuori dai sistemi aziendali: se il server è cifrato da un ransomware, un documento salvato solo lì non serve a nessuno.
Passo 5: testare e aggiornare
Un piano mai provato è un'ipotesi. Almeno una volta l'anno, e a ogni cambiamento importante dell'infrastruttura, conviene simulare uno scenario e verificare tempi e risultati reali. Le prove possono essere semplici, come il ripristino di un singolo server, o più complete, come la ripartenza dell'intero ambiente su infrastruttura alternativa. Per approfondire, vedi come testare il ripristino dei backup.
Checklist rapida
- Elenco aggiornato di sistemi, dati e dipendenze
- RPO e RTO concordati con la direzione per ogni sistema critico
- Backup con almeno una copia isolata o non modificabile
- Procedure di ripristino scritte, passo per passo
- Ruoli, sostituti e contatti d'emergenza
- Copia del piano accessibile anche a sistemi spenti
- Test periodico con verbale dei risultati
- Revisione dopo ogni cambiamento rilevante
Come può aiutarti Area GUI
Area GUI affianca le PMI nella stesura del piano di disaster recovery, partendo dall'analisi dei sistemi critici fino ai test di ripristino periodici. Puoi approfondire il nostro servizio Data Availability Service oppure contattarci per una prima valutazione.