Il disaster recovery plan è il documento che trasforma le buone intenzioni in procedure eseguibili. Senza di esso, anche un’infrastruttura di backup ben progettata rischia di rivelarsi inutilizzabile nel momento del bisogno, perché nessuno sa esattamente cosa fare, in che ordine e con quali credenziali. Vediamo come si scrive, quali sezioni non possono mancare e come si presenta concretamente.

Che cos’è un disaster recovery plan?

Un disaster recovery plan è il documento operativo che descrive come ripristinare i sistemi informatici di un’azienda dopo un evento critico. Definisce le priorità di intervento, le procedure tecniche, le responsabilità delle persone coinvolte e i tempi previsti per ogni fase del ripristino.

La sua funzione è eliminare l’improvvisazione. Durante un’emergenza il personale opera sotto pressione, spesso in orari anomali e con informazioni incomplete: un piano scritto in condizioni di calma sostituisce le decisioni estemporanee con una sequenza già ragionata e approvata.

Un buon piano è eseguibile da un tecnico competente che non lo ha redatto. È il criterio di qualità più utile: se la procedura funziona solo perché chi l’ha scritta ricorda i dettagli mancanti, il documento non è completo.

Quali informazioni deve contenere un disaster recovery plan?

Un piano completo si articola in sei blocchi informativi: inventario dei sistemi, classificazione delle priorità, obiettivi di ripristino, procedure tecniche, catena delle responsabilità e criteri di chiusura dell’emergenza. Ogni blocco risponde a una domanda precisa che si porrà chi opera durante il fermo.

• Inventario dei sistemi critici: server, applicativi, database, servizi cloud, apparati di rete, con le rispettive dipendenze reciproche.
• Priorità di ripristino: l’ordine in cui i sistemi devono tornare operativi, perché ripristinare tutto contemporaneamente non è possibile.
• RTO e RPO per sistema: tempo massimo di fermo e massima perdita di dati accettabile per ciascun servizio.
• Procedure tecniche: i passaggi concreti di ripristino, con percorsi dei backup, modalità di accesso e sequenza delle operazioni.
• Ruoli e contatti: chi dichiara l’emergenza, chi esegue, chi comunica verso l’esterno, con recapiti alternativi e sostituti.
• Criteri di rientro: le verifiche da superare per dichiarare concluso l’incidente e tornare all’esercizio ordinario.

Un allegato spesso dimenticato è l’elenco delle licenze software e delle credenziali amministrative, conservato in forma protetta ma accessibile anche quando i sistemi aziendali sono fermi. Un piano custodito esclusivamente sul server da ripristinare è un errore ricorrente.

Come si costruisce un piano passo per passo?

La costruzione segue cinque fasi in sequenza: analisi di impatto, definizione degli obiettivi, progettazione della soluzione tecnica, stesura delle procedure e collaudo. Saltare la prima fase è l’errore più frequente e porta a piani sovradimensionati su sistemi marginali e insufficienti su quelli vitali.

L’analisi di impatto stabilisce quali processi aziendali dipendono da quali sistemi e quanto costa ogni ora di indisponibilità. È un lavoro che coinvolge la direzione e i responsabili di funzione, non solo il reparto tecnico: sono loro a sapere che l’ordine di priorità reale mette il gestionale della produzione davanti alla posta elettronica.

Dalla mappatura discende la definizione di RTO e RPO per ciascun sistema, che a sua volta determina la soluzione tecnica: repliche continue per i sistemi con RPO di minuti, backup giornalieri per gli archivi con tolleranze più ampie. Solo a questo punto si passa alla stesura delle procedure e infine al collaudo, che verifica sul campo le ipotesi fatte a tavolino.

Come si presenta un disaster recovery plan: esempio di struttura

Un piano per una PMI si sviluppa in genere su venti o trenta pagine, organizzate in sezioni numerate per facilitare la consultazione rapida durante l’emergenza. La struttura seguente rappresenta uno schema applicabile alla maggior parte delle realtà produttive e di servizi.

1. Scopo e ambito: quali sedi e quali sistemi copre il piano, chi lo approva e da quando è in vigore.
2. Scenari previsti: guasto hardware, attacco ransomware, indisponibilità della sede, perdita della connettività.
3. Inventario e dipendenze: tabella dei sistemi con criticità, RTO, RPO e collegamenti reciproci.
4. Ruoli e recapiti: responsabile dell’attivazione, referenti tecnici interni ed esterni, sostituti.
5. Procedure operative: una scheda per scenario, con i passaggi numerati e i tempi attesi per ciascuno.
6. Comunicazione: modalità e tempi per informare dipendenti, clienti, fornitori e, se ricorre l’obbligo, il Garante privacy.
7. Registro dei test: data, tipo di prova, esito, anomalie riscontrate e correzioni apportate.
8. Allegati: schemi di rete, elenco licenze, contratti di assistenza, procedura di accesso alle credenziali di emergenza.

Le procedure operative sono il cuore del documento e vanno scritte in forma imperativa e verificabile, indicando comandi, percorsi e punti di controllo. Una formulazione come “ripristinare il server dal backup” non è una procedura; “avviare la console di gestione all’indirizzo indicato in allegato B, selezionare il punto di ripristino più recente antecedente all’orario dell’incidente, verificare l’integrità prima del riavvio” lo è.

Ogni quanto va aggiornato e testato il piano?

Il piano va rivisto almeno una volta l’anno e ogni volta che l’infrastruttura cambia in modo significativo. I test di ripristino andrebbero eseguiti con cadenza trimestrale sui sistemi critici e con una simulazione estesa annuale che coinvolga anche le persone e non solo la tecnologia.

Gli eventi che impongono un aggiornamento immediato sono la migrazione di un sistema, l’introduzione di un nuovo gestionale, il cambio di fornitore di connettività o di cloud, e le variazioni nell’organico che modificano la catena delle responsabilità. Un piano che indica come referente una persona uscita dall’azienda l’anno precedente è già inservibile.

Il registro dei test è la parte del documento che le certificazioni e gli audit dei clienti esaminano per prima, perché dimostra che il piano è vivo. Annotare anche i test falliti, con le correzioni conseguenti, è un segnale di maturità del processo, non una debolezza.

Chi deve scrivere il disaster recovery plan in una PMI?

La redazione richiede una collaborazione tra la direzione aziendale, che stabilisce le priorità di business e approva i livelli di servizio, e un partner tecnico, che traduce quelle priorità in architettura e procedure. Nelle PMI prive di un reparto IT interno strutturato la stesura viene affidata al fornitore che gestisce l’infrastruttura.

Il coinvolgimento della direzione non è una formalità: definire un RTO di quattro ore anziché di ventiquattro cambia sensibilmente il costo della soluzione, ed è una decisione di business prima che tecnica. Il ruolo del partner è presentare le alternative con i rispettivi costi, non decidere al posto dell’azienda.

HkStyle redige piani di ripristino per aziende in Lombardia ed Emilia-Romagna, integrandoli con l’infrastruttura di backup e replica esistente e curandone il collaudo periodico. Il quadro completo del tema è disponibile nella guida su che cos’è il disaster recovery e come funziona.

Se la tua azienda non dispone di un piano scritto, o se l’ultimo aggiornamento risale a più di un anno fa, il primo passo è un’analisi dei sistemi critici e dei tempi di ripristino attuali. Scrivi a HkStyle per una valutazione dell’infrastruttura e la stesura di un piano su misura.