Un piano di business continuity resta affidabile quando ogni modifica operativa genera una revisione precisa e, se necessario, un nuovo test. Il criterio pratico è semplice: registrare cosa è cambiato, assegnare un responsabile, aggiornare i documenti coinvolti e conservare la prova del collaudo.
Il punto da cui partire è il minuto in cui il ripristino supera l’RTO, cioè il tempo massimo previsto per rimettere in servizio un’attività. A quel punto il test è già fallito. Per capire perché, bisogna risalire lungo la sequenza e cercare le modifiche rimaste fuori dal piano.
Perché un piano aggiornato sulla carta può fallire durante il test
Il superamento dell’RTO raramente dipende da una sola azione. Più spesso si accumulano piccoli ritardi: una chiamata al referente sbagliato, un accesso negato, un fornitore che non gestisce più il servizio o un sistema ripristinato prima di quello da cui dipende.
La ricostruzione parte dall’ultimo passaggio non riuscito e procede all’indietro. Se il servizio non è ripartito, si controlla il runbook, cioè la procedura operativa di ripristino. Se il runbook è stato eseguito correttamente, si verificano le dipendenze. Se una dipendenza mancava, si controlla quando è cambiata e perché la modifica non ha prodotto una revisione.
I segnali trascurati sono spesso ordinari:
- il responsabile indicato nel piano ha cambiato funzione o sede;
- il contratto con un fornitore è stato sostituito, ma il recapito di emergenza è rimasto quello vecchio;
- le credenziali conservate per il ripristino sono scadute o non hanno più i permessi necessari;
- un’applicazione usa un nuovo servizio esterno non riportato nella mappa delle dipendenze;
- la sequenza tecnica è ancora eseguibile, ma non segue più l’ordine richiesto dalle attività aziendali;
- il personale reperibile conosce il documento, ma non ha mai svolto direttamente la procedura.
Questi scostamenti costituiscono il decadimento silenzioso del piano. Il documento può avere una data recente e risultare comunque inutilizzabile. Una revisione formale, infatti, non prova che numeri di telefono, accessi, responsabilità e tempi siano ancora validi.
Che cosa comprende davvero la business continuity
La continuità operativa è la capacità organizzata di mantenere o ripristinare attività prioritarie durante un’interruzione. Comprende persone, sedi, impianti, sistemi informatici, dati, fornitori, comunicazioni e decisioni. Il piano di continuità operativa, spesso indicato come BCP, traduce questa capacità in ruoli, priorità e procedure verificabili.
ISO 22301:2024 è il riferimento internazionale per il sistema di gestione della continuità operativa. Il punto utile per chi gestisce il piano è l’impostazione sistemica: analisi, responsabilità, preparazione, esercitazioni, valutazione e miglioramento devono funzionare insieme. Un documento isolato, aggiornato solo prima di una verifica, non sostituisce questo ciclo.
Il disaster recovery riguarda invece il recupero di sistemi, infrastrutture e dati dopo un’interruzione. Le Linee guida per il Disaster Recovery di AgID lo collocano nel perimetro più ampio della continuità operativa. Anche il dominio Business Continuity and Disaster Recovery dell’Agenzia per la Cybersicurezza Nazionale mantiene distinti ma collegati i due ambiti.
La distinzione ha un effetto pratico. Un server può essere ripristinato correttamente mentre l’attività resta ferma perché manca un operatore autorizzato, una connessione, una materia prima, un servizio logistico o una decisione dell’ufficio acquisti. Il recupero informatico è quindi una parte del piano, non il piano intero.
I quattro documenti da verificare dopo un ripristino in ritardo
Organigramma dei ruoli e delle sostituzioni
L’organigramma operativo deve indicare chi dichiara l’interruzione, chi coordina la risposta, chi autorizza le spese urgenti, chi contatta clienti e fornitori e chi decide il ritorno alla normalità. Per ogni ruolo serve anche un sostituto effettivamente raggiungibile.
Il nome da solo non basta. Occorre verificare funzione, recapiti, deleghe e disponibilità degli strumenti necessari. Se una persona può autorizzare un acquisto urgente ma non accede al sistema da remoto, quella responsabilità esiste solo sulla carta.
Elenco delle dipendenze operative
La mappa delle dipendenze collega ogni attività prioritaria alle risorse indispensabili. Deve comprendere sistemi informatici, dati, personale, locali, energia, connettività, macchinari, materiali e servizi esterni.
La domanda utile non è soltanto quale sistema serve, ma che cosa deve essere già disponibile prima di avviarlo. Un applicativo può dipendere dall’identità digitale degli utenti, da un archivio, da una rete, da un servizio del fornitore e da una persona abilitata a eseguire il controllo finale.
ICT Security Magazine richiama la mappatura dei fornitori critici tra gli elementi da verificare. Per ciascuno vanno controllati il servizio fornito, il contatto di emergenza, le condizioni operative previste e le eventuali dipendenze da ulteriori soggetti.
Runbook di ripristino
Il runbook è la sequenza eseguibile delle operazioni. Deve dire chi fa cosa, con quali accessi, in quale ordine, quali controlli confermano il risultato e quando si deve interrompere o cambiare percorso.
Una frase come ripristinare il gestionale è troppo generica. La procedura deve distinguere l’avvio tecnico dalla verifica operativa. Un sistema acceso ma privo di dati aggiornati, integrazioni o autorizzazioni non è ancora un servizio ripristinato.
Registro delle modifiche
Il registro delle modifiche collega il lavoro quotidiano al piano di continuità. Ogni variazione rilevante deve riportare almeno l’evento, la data, i servizi interessati, il responsabile della valutazione, i documenti aggiornati, il test richiesto e l’evidenza conservata.
Qui si trova spesso la causa del ritardo. Il cambio di fornitore è stato gestito negli acquisti, la nuova applicazione nell’area tecnica e il trasferimento del referente nelle risorse umane. Nessuno dei tre eventi è arrivato a chi mantiene il piano.
Come verificare RTO, RPO e sequenza di ripristino
RTO e RPO rendono misurabili le aspettative. L’RTO, Recovery Time Objective, è il tempo massimo previsto per ripristinare un servizio. L’RPO, Recovery Point Objective, rappresenta la perdita di dati tollerabile espressa nel tempo.
Se l’RPO prevede il recupero dei dati fino a un determinato momento precedente all’interruzione, il test deve dimostrare che quel punto di recupero è realmente disponibile. Controllare soltanto che esista una copia non prova che sia leggibile, completa e coerente con le applicazioni collegate.
RTO e RPO devono derivare dalle necessità operative. Un ufficio può accettare una sospensione più lunga di una linea produttiva, mentre un archivio può tollerare tempi di recupero diversi da un sistema che registra ordini o movimenti. Usare lo stesso obiettivo per tutti i servizi semplifica il documento, ma rende poco attendibile la prova.
I test possono avere profondità diverse:
- walkthrough: i responsabili percorrono la procedura passo per passo e verificano ruoli, recapiti, decisioni e dipendenze;
- prova tecnica mirata: si collauda una parte specifica, come il recupero dei dati, l’accesso alternativo o l’attivazione di un servizio;
- simulazione realistica: persone e reparti eseguono la risposta in condizioni vicine a quelle operative, misurando tempi e risultati;
- verifica completa: si prova l’intera catena fino alla ripresa dell’attività, non soltanto l’avvio dell’infrastruttura.
L’approfondimento di ICT Security Magazine richiama walkthrough, simulazioni realistiche e verifica degli RTO. La scelta del test dipende dalla modifica. Un nuovo numero di reperibilità può richiedere una prova di contatto. Una diversa architettura dei sistemi richiede invece un collaudo tecnico e una nuova verifica della sequenza.
L’evidenza deve permettere di ricostruire il risultato. Sono utili il verbale della prova, gli orari di inizio e fine, gli esiti dei controlli, gli errori incontrati, le decisioni prese e le azioni correttive assegnate. La sola firma sul documento non dimostra il rispetto di RTO e RPO.
Quali modifiche devono far scattare revisione e nuovo test
Una revisione periodica resta utile, ma non intercetta subito ciò che cambia tra due scadenze. Per questo serve un meccanismo basato sugli eventi. Le funzioni aziendali che introducono modifiche devono sapere quali casi segnalare al responsabile della continuità.
La matrice seguente traduce gli eventi più comuni in azioni. Le responsabilità indicate sono funzioni operative, da adattare all’organizzazione reale.
| Evento modificato | Responsabile della segnalazione | Documento ed evidenza | Test da ripetere |
|---|---|---|---|
| Trasferimento o uscita di un referente | Risorse umane e responsabile di funzione | Organigramma, contatti e deleghe; esito della prova di reperibilità | Chiamata a cascata e verifica delle autorizzazioni |
| Sostituzione di un fornitore critico | Ufficio acquisti e responsabile del servizio | Mappa delle dipendenze e procedura di attivazione; verbale del contatto | Attivazione del canale di emergenza e prova del servizio previsto |
| Modifica di applicazioni o infrastrutture | Responsabile tecnico | Runbook, architettura e dipendenze; registrazione del collaudo | Ripristino tecnico e verifica dell’ordine di avvio |
| Modifica delle credenziali o dei permessi | Gestore degli accessi e proprietario del servizio | Procedura di accesso; esito della verifica delle autorizzazioni | Accesso controllato con i profili previsti per l’emergenza |
| Cambio di sede, reparto o impianto | Responsabile operativo e servizi generali | Piano, risorse alternative e contatti; verbale della simulazione | Trasferimento dell’attività o attivazione della soluzione alternativa |
| Variazione di RTO o RPO | Proprietario del processo e direzione | Analisi delle priorità e runbook; tempi e punti di recupero misurati | Prova completa del servizio interessato |
Il registro deve essere collegato ai processi che generano le modifiche: acquisti, gestione del personale, manutenzione, gestione degli accessi e cambiamenti tecnici. Se la segnalazione dipende dalla memoria del singolo referente, prima o poi un evento resterà fuori.
Come valutare strategie e costi della continuità operativa
Le strategie possibili comprendono risorse alternative, procedure manuali temporanee, ridondanza tecnica, scorte, accordi con fornitori e trasferimento di attività. La scelta deve rispettare le priorità e i tempi fissati. Una soluzione che richiede più tempo dell’RTO non è adeguata, anche se costa meno.
Il costo non coincide con l’acquisto di tecnologia. Comprende l’analisi delle attività, il tempo delle persone, la manutenzione dei documenti, la formazione, i test, le risorse alternative e la gestione delle azioni correttive. Comprende anche il lavoro necessario per controllare fornitori e dipendenze esterne.
Per evitare spese senza effetto, conviene partire dai servizi prioritari e dai loro obiettivi. Ogni voce di costo deve rispondere a una domanda concreta: riduce il tempo di ripristino, limita la perdita di dati, elimina una dipendenza singola oppure rende eseguibile una procedura?
Il costo nascosto più comune è mantenere soluzioni mai collaudate. Una risorsa alternativa inutilizzabile durante l’interruzione ha già generato costi di acquisto e gestione, ma non offre la capacità prevista. Le prove servono anche a verificare questo scarto.
La manutenzione può essere gestita internamente quando ruoli e competenze sono chiari. Il supporto esterno può servire per analisi specialistiche o prove tecniche, ma la proprietà del piano resta all’organizzazione. Un consulente non può decidere al posto dei responsabili quali attività debbano ripartire prima.
Domande e risposte
Ogni quanto va aggiornato un piano di business continuity?
Il piano va riesaminato con una cadenza definita dall’organizzazione e ogni volta che cambia un elemento rilevante. Nuovi fornitori, trasferimenti di personale, modifiche tecniche, credenziali, sedi e obiettivi di ripristino devono attivare una valutazione immediata. Attendere la revisione programmata lascia aperto un periodo nel quale procedure e realtà operativa possono divergere.
Come si prepara un piano di continuità operativa?
Si parte dalle attività prioritarie e dagli effetti della loro interruzione. Poi si definiscono RTO, RPO, dipendenze, ruoli, strategie e procedure di ripristino. Il piano deve indicare anche sostituti, contatti e criteri per il ritorno alla normalità. L’ultima fase è il test, seguito dalla correzione degli scostamenti rilevati.
Quanto costa mantenere aggiornato il piano?
Il costo dipende da complessità, numero di sedi, tecnologie, fornitori e profondità dei test. Le voci principali sono tempo del personale, gestione documentale, formazione, simulazioni e risorse alternative. Per stimarlo serve un perimetro preciso: servizi prioritari, obiettivi di ripristino e prove necessarie. Un prezzo unico per tutta l’azienda tende a nascondere differenze operative rilevanti.
Qual è la differenza tra continuità operativa e disaster recovery?
La continuità operativa riguarda il mantenimento o il recupero delle attività aziendali nel loro insieme. Il disaster recovery si concentra sul ripristino di sistemi, infrastrutture e dati. Un recupero informatico riuscito non garantisce da solo la ripresa del lavoro: possono ancora mancare persone, autorizzazioni, locali, materiali o servizi esterni.
Una piccola impresa può gestire il piano senza consulenti?
Sì, se conosce bene i propri processi e assegna responsabilità chiare. Può iniziare da poche attività prioritarie, mappare persone e fornitori indispensabili, scrivere procedure semplici e provarle. Il supporto specialistico diventa utile quando servono competenze tecniche non disponibili internamente. Decisioni, priorità e accettazione dei rischi devono comunque restare in azienda.
Il primo intervento pratico è aprire il registro delle modifiche e confrontarlo con organigramma, dipendenze e runbook. Ogni differenza deve produrre un responsabile, una scadenza, un test proporzionato e un’evidenza conservata.
Da leggere anche: Tecnologia BIM: costi iniziali e nascosti per un piccolo studio tecnico
Da leggere anche: Business model canvas: quando rivederlo e quali segnali controllare