Disaster recovery e business continuity vengono usati quasi come sinonimi, ma descrivono due livelli distinti di preparazione. Confonderli porta a errori concreti: aziende che hanno investito in repliche dei server e si scoprono incapaci di evadere un ordine perché nessuno ha previsto come lavorare durante il fermo, e aziende che hanno redatto procedure di emergenza senza la tecnologia per sostenerle. Vediamo dove passa il confine e come far lavorare insieme i due piani.

Qual è la differenza tra disaster recovery e business continuity?

La business continuity riguarda l’intera azienda e definisce come continuare a operare durante un’emergenza; il disaster recovery è la sua componente informatica e stabilisce come rimettere in funzione i sistemi IT. Il primo è un piano di sopravvivenza operativa, il secondo è un piano di ripristino tecnologico.

La distinzione si coglie con un esempio. Se un allagamento rende inagibile la sede, il disaster recovery risponde alla domanda “come torniamo ad avere gestionale e posta elettronica”; la business continuity risponde a “dove lavorano le persone, come riceviamo le merci, chi avvisa i clienti, con quali procedure manuali andiamo avanti nel frattempo”.

Il disaster recovery è quindi contenuto nella business continuity, non parallelo ad essa. Un piano di continuità senza la parte tecnologica è incompleto; un piano di ripristino IT senza il contesto organizzativo rischia di riportare online i sistemi giusti nell’ordine sbagliato rispetto alle reali necessità del business.

Che cos’è un piano di business continuity?

Un piano di business continuity è il documento che descrive come l’azienda mantiene attivi i processi essenziali durante un’interruzione, indipendentemente dalla causa. Copre persone, sedi, fornitori, procedure alternative e comunicazione, oltre alla tecnologia.

Le componenti tipiche comprendono l’individuazione dei processi critici e delle risorse minime per sostenerli, le modalità di lavoro alternative come sedi di ripiego o lavoro da remoto, gli accordi con fornitori sostitutivi, le procedure manuali da attivare quando i sistemi non sono disponibili e il piano di comunicazione verso dipendenti, clienti e autorità.

Rispetto al piano di ripristino IT, il piano di continuità ha un orizzonte più ampio e una componente organizzativa prevalente. Richiede il coinvolgimento diretto della direzione e dei responsabili di funzione, perché le decisioni che contiene riguardano il modo in cui l’azienda lavora, non solo l’infrastruttura.

Che cos’è la business impact analysis e perché viene prima?

La business impact analysis è l’analisi che misura le conseguenze dell’interruzione di ciascun processo aziendale nel tempo. È il presupposto di entrambi i piani, perché stabilisce quali attività vanno protette per prime e con quale livello di investimento.

L’analisi procede per processi, non per sistemi. Per ognuno si stimano il costo dell’interruzione per unità di tempo, il momento oltre il quale il danno diventa irreversibile, le dipendenze da persone, fornitori e tecnologie, e le eventuali conseguenze contrattuali o normative.

Il risultato è una graduatoria che spesso smentisce le convinzioni interne. Capita di scoprire che un applicativo considerato secondario blocca la spedizione delle merci, mentre un sistema percepito come vitale tollera un giorno di fermo senza conseguenze economiche rilevanti. Da questa graduatoria discendono gli RTO e gli RPO che guideranno la progettazione tecnica.

Come si integrano i due piani?

L’integrazione avviene attraverso gli obiettivi di ripristino: la business impact analysis stabilisce quanto ogni processo può restare fermo, quel limite diventa il tempo massimo entro cui i sistemi che lo sostengono devono tornare operativi, e il piano di disaster recovery viene progettato per rispettarlo.

Il collegamento va mantenuto anche nell’esecuzione. L’ordine di ripristino dei sistemi deve rispecchiare la graduatoria dei processi, non la comodità tecnica: se la priorità è evadere gli ordini in corso, il gestionale precede la posta elettronica anche quando quest’ultima sarebbe più rapida da riattivare.

Un secondo punto di raccordo è la comunicazione. Chi coordina l’emergenza sul piano organizzativo deve conoscere in tempo reale lo stato dei ripristini per decidere quando sospendere le procedure manuali. Prevedere un punto di contatto unico tra il referente tecnico e la direzione evita duplicazioni e informazioni contraddittorie.

I test, infine, andrebbero condotti congiuntamente almeno una volta l’anno. Una simulazione che coinvolge solo il reparto tecnico verifica la tecnologia ma non la capacità dell’organizzazione di reggere l’emergenza.

Quali standard e normative regolano la continuità operativa?

Il riferimento internazionale è la norma ISO 22301, che definisce i requisiti di un sistema di gestione della continuità operativa. Sul piano normativo europeo, la direttiva NIS2 ha esteso a una platea molto più ampia di imprese gli obblighi di gestione del rischio informatico, includendo esplicitamente la continuità operativa e la gestione dei backup.

Per le aziende inserite in filiere industriali l’impulso arriva spesso prima dai clienti che dal legislatore: i questionari di qualifica fornitore richiedono con crescente frequenza l’evidenza di un piano di continuità documentato e collaudato. Disporne diventa un requisito commerciale.

Si aggiunge il GDPR, che impone la capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali in caso di incidente, oltre agli obblighi di notifica entro settantadue ore. La conformità passa quindi anche dalla qualità delle procedure di ripristino.

Da dove deve partire una PMI?

L’approccio più efficace è partire dal disaster recovery ed estendere progressivamente. Ha confini tecnici definiti, risultati misurabili e tempi di realizzazione contenuti, e produce fin da subito la parte più costosa e complessa di qualsiasi piano di continuità.

La sequenza consigliata prevede una business impact analysis semplificata sui processi principali, la definizione degli obiettivi di ripristino, la realizzazione dell’infrastruttura di backup e replica, la stesura delle procedure tecniche e infine l’estensione agli aspetti organizzativi: sedi alternative, procedure manuali, comunicazione di emergenza.

HkStyle affianca le aziende in questo percorso, dalla mappatura dei sistemi critici alla progettazione dell’infrastruttura di ripristino, con certificazioni ISO 9001:2015 e ISO/IEC 27001:2022. Il quadro generale del tema è disponibile nella guida su che cos’è il disaster recovery e come funziona.

Se non hai ancora mappato quali processi si fermerebbero e per quanto, quello è il punto di partenza: senza quel dato ogni investimento in continuità è una scommessa. Parla con HkStyle per un’analisi dei processi critici e la definizione degli obiettivi di ripristino della tua azienda.