BCP e DRP: il piano che tiene in piedi l'azienda, non solo i server

BCP e DRP non sono la stessa cosa

I due termini vengono usati quasi come sinonimi, ma coprono ambiti diversi. Il piano di continuità operativa (Business Continuity Plan, BCP) riguarda l'intera azienda: persone, sedi, fornitori, comunicazione, non solo i sistemi informatici. Il piano di disaster recovery (Disaster Recovery Plan, DRP) è la parte tecnica che riguarda specificamente il ripristino dei sistemi IT, con gli RTO e RPO definiti per ciascuno.

Un DRP tecnicamente perfetto non serve a molto se nessuno sa chi deve decidere cosa, o se le persone non hanno un posto da cui lavorare mentre i sistemi vengono ripristinati. Servono entrambi, e il secondo è contenuto nel primo.

A confronto

Cosa contiene un piano che funziona davvero

• Un'analisi di impatto (BIA): quali processi sono critici, e cosa succede se si fermano, per un'ora, per un giorno, per una settimana. È la base da cui partono anche RTO e RPO.
• Ruoli e responsabilità chiari: chi decide di attivare il piano, chi coordina, chi comunica, con nomi e non solo funzioni astratte.
• Un piano di comunicazione, interno (le persone sanno cosa fare e dove) ed esterno (clienti, fornitori, eventuali autorità), che funzioni anche se i canali abituali, come la posta aziendale, non sono disponibili.
• Modalità di lavoro alternative: dove e come si lavora se la sede abituale non è raggiungibile o disponibile.
• La continuità dei fornitori critici: cosa succede se è un fornitore, non un tuo sistema, a fermarsi.
• Il piano tecnico di ripristino (DRP), con RTO e RPO definiti per ogni sistema in base alla sua criticità.

Gli errori più comuni

• Scritto una volta, mai aggiornato. Nuovi sistemi, nuove sedi, nuovi fornitori cambiano il piano: senza revisione periodica, il documento descrive un'azienda che non esiste più.
• Un piano che vive solo nell'IT. Se i responsabili di processo e la direzione non lo conoscono, nel momento critico nessuno sa a chi spetta decidere cosa.
• Nessuna prova reale, solo carta. Un piano non testato è un'ipotesi, non una garanzia: lo stesso principio spiegato nella guida su RTO e RPO a proposito delle prove di ripristino.
• Dipendenza da una sola persona. Se solo una persona sa dove sono le password o come si attiva davvero il piano, la sua assenza nel momento sbagliato diventa il problema più grande.

Come si testa, con un ritmo sostenibile

1. Esercitazione a tavolino: si discute uno scenario a voce, senza toccare i sistemi, per verificare che ruoli e decisioni siano chiari. Il modo più semplice ed economico per iniziare.
2. Test parziale: si prova il ripristino di un singolo sistema o processo, in un ambiente separato dalla produzione.
3. Prova completa, quando la criticità lo giustifica: un'interruzione simulata più estesa, con orari e tempi reali misurati.
4. Revisione dopo ogni incidente reale, anche minore: cosa ha funzionato, cosa no, cosa aggiornare nel piano.

Nella storia Il venerdì sera in cui i file cambiarono nome il tempo di ripristino era già noto perché era stato misurato in una prova reale poche settimane prima: è la differenza tra un piano provato e un piano soltanto scritto.

Checklist rapida

• esiste un piano di continuità scritto, non solo una prassi informale conosciuta da poche persone;
• i responsabili di processo e la direzione conoscono il piano, non solo l'IT;
• il piano include un modo di comunicare che funziona anche senza i canali abituali;
• so cosa fare se è un fornitore critico, e non un mio sistema, a fermarsi;
• il piano è stato testato negli ultimi dodici mesi, almeno con un'esercitazione a tavolino;
• il piano viene aggiornato quando cambiano sistemi, sedi o fornitori importanti.

In sintesi