Come redigere un piano di ripristino ICT

Un’interruzione dei sistemi ICT non diventa una crisi soltanto quando si verifica un attacco ransomware o si guasta un data center. Diventa una crisi quando l’organizzazione non sa, con precisione, quali servizi ripristinare per primi, chi deve autorizzare le decisioni e in quanto tempo tornare a operare. Capire come redigere un piano di ripristino ICT significa quindi progettare una capacità esecutiva verificabile, non produrre un documento da archiviare.

Un piano efficace collega architetture tecnologiche, priorità di business, requisiti normativi, fornitori e persone. Deve funzionare sotto pressione, con informazioni incomplete e risorse potenzialmente indisponibili. Per questo richiede una governance chiara, dati aggiornati e test realistici.

Il perimetro del piano di ripristino ICT

Il piano di ripristino ICT, spesso ricondotto al Disaster Recovery Plan, definisce le modalità con cui l’azienda ripristina infrastrutture, applicazioni, dati, connettività e servizi tecnologici dopo un evento disruptive. Non coincide con il piano di business continuity, che ha un perimetro più ampio e si concentra sulla continuità dei processi aziendali. I due strumenti devono però essere coerenti: il ripristino tecnico deve sostenere le priorità operative stabilite dal business.

Il punto di partenza non è l’elenco dei server. È la comprensione delle conseguenze dell’indisponibilità. Un portale clienti, un sistema di gestione della produzione, una piattaforma di pagamento o un servizio di identity management possono avere livelli di criticità molto diversi, anche se risiedono nella medesima infrastruttura.

Una valutazione preliminare dovrebbe chiarire quali processi dipendono da ogni servizio, quali obblighi contrattuali o regolamentari sono coinvolti, quali dipendenze esistono tra applicazioni e quale degrado operativo sia tollerabile. In contesti industriali, occorre includere anche le interconnessioni tra IT e OT, gli impatti sulla sicurezza degli impianti e la disponibilità di fornitori specializzati.

Come redigere un piano di ripristino ICT: partire da BIA e risk assessment

Un piano non può essere progettato correttamente senza Business Impact Analysis e valutazione del rischio. La BIA individua le attività prioritarie, gli impatti derivanti dalla loro interruzione e le finestre temporali entro cui il servizio deve essere recuperato. Il risk assessment valuta invece gli scenari che possono compromettere tali servizi: guasti hardware, errori di configurazione, indisponibilità di un cloud provider, attacchi cyber, perdita di connettività, eventi fisici sul sito o compromissione della supply chain tecnologica.

Da questo lavoro derivano due parametri essenziali. Il Recovery Time Objective, o RTO, stabilisce il tempo massimo accettabile di indisponibilità. Il Recovery Point Objective, o RPO, indica invece la massima perdita di dati tollerabile, espressa come intervallo temporale. Un RTO di quattro ore e un RPO di quindici minuti implicano requisiti architetturali, contrattuali e operativi ben diversi da quelli di un servizio recuperabile entro due giorni con perdita dati fino a ventiquattro ore.

RTO e RPO non devono essere dichiarazioni aspirazionali. Devono essere validati con le funzioni di business, tradotti in soluzioni tecniche sostenibili e verificati con test. Un obiettivo non supportato da backup, replica, capacità elaborativa, connettività e competenze disponibili è soltanto un’esposizione al rischio non dichiarata.

Definire servizi, dipendenze e strategie di recovery

L’inventario tecnico è utile solo se descrive le dipendenze. Per ogni servizio critico, il piano dovrebbe identificare applicazioni, database, componenti middleware, directory, certificati, reti, storage, sistemi di monitoraggio, interfacce API, account privilegiati e fornitori esterni. La sequenza di ripristino deve rispettare questa catena: recuperare un’applicazione prima dei servizi di autenticazione o delle basi dati necessarie produrrebbe un ripristino apparente, non un servizio effettivamente utilizzabile.

La strategia può basarsi su backup tradizionali, replica sincrona o asincrona, infrastrutture ridondate, ambienti cloud, siti alternativi o soluzioni ibride. Non esiste una scelta universalmente corretta. La replica riduce potenzialmente il tempo di recovery, ma può propagare errori logici, cancellazioni o dati cifrati da malware. Il backup immutabile offre una protezione significativa contro molte forme di compromissione, ma richiede tempi di ripristino e capacità operative compatibili con gli RTO definiti.

Per servizi cloud o Software as a Service, la responsabilità del provider non elimina quella dell’azienda. Occorre verificare il modello di responsabilità condivisa, le condizioni di recupero dei dati, le modalità di esportazione, le dipendenze da identità federate e l’eventuale concentrazione del rischio su un singolo soggetto.

La struttura operativa del documento

Un piano realmente utilizzabile deve essere leggibile da chi dovrà eseguirlo, anche fuori orario e in condizioni di pressione. Le procedure devono distinguere le attività decisionali da quelle tecniche e indicare con chiarezza precondizioni, responsabilità, evidenze da raccogliere e criteri di chiusura.

In particolare, il documento dovrebbe contenere almeno quattro blocchi operativi:

• criteri di attivazione, livelli di escalation, autorità che dichiarano l’evento e collegamento con la gestione della crisi;
• ruoli, reperibilità, deleghe e contatti dei team interni, dei fornitori, dei cloud provider e dei partner di telecomunicazione;
• runbook tecnici dettagliati per il ripristino, la validazione funzionale, la gestione delle credenziali di emergenza e il ritorno alla normale operatività;
• modelli di comunicazione, registro delle decisioni, evidenze di test e processo di aggiornamento controllato.

Le istruzioni tecniche devono evitare formule vaghe come “ripristinare il database” o “attivare il sito secondario”. Devono indicare versione, ambiente, strumenti, credenziali custodite con modalità sicure, dipendenze, verifiche da eseguire e soggetti che accettano il servizio ripristinato. Dove possibile, è opportuno integrare automazione e orchestrazione, senza trasformare l’automazione in un punto singolo di fallimento.

Un aspetto spesso trascurato riguarda il ritorno all’ambiente primario. Il failback comporta sincronizzazione dei dati, gestione delle modifiche intervenute durante l’emergenza, validazioni e finestre operative. Se non è pianificato, il recovery rischia di prolungare l’esposizione invece di ridurla.

Integrare la risposta cyber nel recovery

Dopo un incidente cyber, il ripristino non può limitarsi a riaccendere i sistemi. Prima di recuperare un ambiente, occorre accertare che la causa dell’incidente sia stata contenuta, che le credenziali compromesse siano state gestite e che le immagini o i backup selezionati siano affidabili. Il recovery accelerato di un sistema ancora compromesso può vanificare l’intervento e amplificare l’impatto.

Il piano deve quindi prevedere punti di controllo tra incident response e disaster recovery: isolamento, analisi forense quando necessaria, decisione sulla pulizia o ricostruzione dell’ambiente, gestione delle chiavi, rotazione delle credenziali privilegiate e monitoraggio rafforzato dopo il ripristino. In organizzazioni regolamentate, la conservazione delle evidenze e la tracciabilità delle decisioni assumono inoltre rilievo legale, contrattuale e assicurativo.

Riferimenti quali ISO 22301 e ISO 27031 possono fornire una struttura metodologica utile, ma la conformità formale non sostituisce l’efficacia operativa. Il test dimostra se un piano funziona; il documento, da solo, dimostra soltanto che è stato scritto.

Testare il piano e misurarne l’efficacia

Il testing deve essere pianificato in base alla criticità dei servizi e ai cambiamenti dell’ecosistema tecnologico. Una verifica annuale generica può essere insufficiente per applicazioni soggette a rilasci frequenti, per infrastrutture cloud dinamiche o per ambienti industriali con forti vincoli di disponibilità.

Le esercitazioni possono partire dalla revisione documentale e dai tabletop exercise, per poi evolvere verso test tecnici parziali, recovery di singoli componenti e simulazioni end-to-end. I test completi sono più onerosi e possono comportare rischi operativi, ma sono anche quelli che rivelano dipendenze nascoste, tempi reali, limiti contrattuali dei fornitori e carenze di competenza.

Ogni esercitazione dovrebbe produrre evidenze misurabili: RTO e RPO effettivi, attività non eseguite, deviazioni dalla procedura, problemi di accesso, capacità insufficienti e azioni correttive con responsabile e scadenza. Il valore del test non risiede nell’esito positivo dichiarato, ma nella capacità di trasformare le anomalie emerse in miglioramenti verificabili.

Governare il ciclo di vita del piano

Un piano di ripristino ICT invecchia rapidamente quando cambiano applicazioni, contratti, configurazioni, persone o sedi. Per mantenerlo affidabile, è necessario assegnare un owner, definire una frequenza di revisione e integrare il suo aggiornamento nei processi di change management, onboarding dei fornitori e gestione degli asset.

La maturità non dipende dalla quantità di pagine prodotte, ma dall’allineamento tra requisiti di business, architetture reali, capacità del personale e risultati dei test. Un piano essenziale, aggiornato e provato può essere più efficace di una documentazione estesa che nessuno riesce a usare durante un’emergenza.

La domanda da porre al management non è se il piano esista, ma se l’organizzazione saprebbe ripristinare i servizi prioritari entro gli obiettivi dichiarati, con le persone e le risorse concretamente disponibili. È da questa verifica che il piano di ripristino ICT diventa una componente credibile della resilienza aziendale.

This post is also available in: