Uno degli errori più frequenti nella gestione della continuità operativa è confondere il backup con la capacità reale di ripristino.

Avere copie dei dati è indispensabile, ma non significa automaticamente essere in grado di ripartire nei tempi necessari, con la sequenza corretta e con un livello di perdita dati accettabile per il business.

Oltre il backup

La NIS2 impone alle organizzazioni un cambio di prospettiva. Non basta chiedersi se esistono backup, repliche o procedure tecniche. Occorre comprendere quali attività aziendali devono essere garantite, quali servizi IT le supportano, quali asset sono coinvolti, quali fornitori devono intervenire e quale impatto avrebbe una loro indisponibilità.

La continuità operativa e il disaster recovery devono quindi essere costruiti a partire dal business, non solo dall’infrastruttura.

Continuità operativa e disaster recovery non sono la stessa cosa

Continuità operativa e disaster recovery sono strettamente collegati, ma non coincidono. La continuità operativa riguarda la capacità dell’organizzazione di mantenere o ripristinare le proprie attività essenziali entro livelli accettabili, anche in presenza di eventi avversi. Include processi, persone, sedi, fornitori, comunicazioni, modalità alternative di lavoro e decisioni organizzative.

Il disaster recovery riguarda, invece, il ripristino dei sistemi informativi, delle infrastrutture, delle applicazioni, dei dati e dei servizi IT necessari a sostenere quelle attività. Il disaster recovery è, quindi, una componente della continuità operativa, ma non la esaurisce.

Un’organizzazione può avere un buon piano tecnico di ripristino, ma non sapere quali processi debbano ripartire prima. Oppure può avere procedure di continuità formalmente corrette, ma non disporre di backup verificati, tempi di ripristino realistici o fornitori in grado di intervenire nei tempi necessari.

La resilienza nasce dall’allineamento tra questi due livelli.

Il punto di partenza: la Business Impact Analysis

Per definire una continuità operativa coerente serve prima comprendere gli impatti. È qui che entra in gioco la Business Impact Analysis.

La BIA consente di valutare quali conseguenze avrebbe l’interruzione di una determinata attività: impatto operativo, economico, contrattuale, regolatorio, reputazionale, sulla sicurezza, sulla qualità o sulla capacità di erogare servizi.

Senza questa analisi, RTO e RPO rischiano di essere numeri arbitrari. Spesso vengono assegnati per consuetudine, per disponibilità tecnologica o per semplice prudenza. Ma un obiettivo di ripristino non dovrebbe essere deciso perché sembra ragionevole. Dovrebbe derivare dall’impatto reale che il fermo produce sull’organizzazione.

Un’attività amministrativa può tollerare un’interruzione più lunga rispetto a un’attività produttiva essenziale. Un sistema documentale può accettare una perdita dati limitata, mentre un sistema di tracciabilità, qualità, fatturazione o gestione ordini può avere requisiti molto più stringenti. In alcuni casi, l’integrità del dato può essere più importante della disponibilità immediata.

RTO e RPO: indicatori da collegare al rischio

Il Recovery Time Objective indica il tempo massimo entro cui un servizio, un sistema o un’attività deve essere ripristinato dopo un’interruzione. Il Recovery Point Objective indica, invece, la quantità massima di dati che l’organizzazione può permettersi di perdere, misurata nel tempo.

Sono due concetti semplici nella definizione, ma spesso complessi nella gestione reale. Un RTO molto basso richiede architetture, processi e competenze adeguate. Un RPO molto stringente richiede backup frequenti, replica, sincronizzazione o soluzioni tecnologiche più avanzate. Entrambi hanno un costo, e quel costo deve essere giustificato dall’impatto dell’attività supportata.

RTO e RPO non sono valori desiderati, ma obiettivi che devono essere sostenibili tecnicamente, organizzativamente ed economicamente. Per questo non ha senso assegnarli in modo uniforme a tutti i sistemi.

Un’applicazione marginale e un sistema che abilita produzione, logistica, fatturazione o sicurezza non possono avere necessariamente gli stessi obiettivi.

Costruire l’ordine di ripristino

Durante un incidente grave, non tutto può essere ripristinato contemporaneamente. È necessario stabilire un ordine di priorità. Ma questo ordine non dovrebbe essere deciso durante l’emergenza, sotto pressione, con informazioni incomplete e responsabilità non chiare. Dovrebbe essere definito prima, sulla base delle attività aziendali, dei servizi IT, degli asset coinvolti e delle dipendenze tecniche.

Il percorso corretto è logico: si parte dalle attività critiche, si identificano i servizi IT che le supportano, si individuano gli asset che erogano quei servizi e si definisce la sequenza di ripristino. Questa sequenza deve considerare anche le dipendenze.

Un’applicazione potrebbe non poter ripartire senza database, storage, autenticazione, connettività, DNS, firewall, hypervisor o sistemi di backup. Un servizio cloud potrebbe richiedere credenziali, console amministrative, connettività o supporto del fornitore.

Ignorare queste relazioni significa costruire un piano teorico.

Fornitori e test di ripristino

Molte capacità di ripristino dipendono da fornitori esterni. Fornitori di infrastruttura, gestionali, cloud, backup, sicurezza, connettività, sistemi industriali o assistenza tecnica possono essere determinanti durante un’interruzione. Se un fornitore gestisce un asset critico o detiene competenze necessarie al ripristino, deve essere incluso nella valutazione di continuità.

Non basta sapere che esiste un contratto. Occorre capire quali tempi di intervento sono previsti, quali escalation sono disponibili, quali responsabilità sono definite, quali accessi sono necessari, quali dipendenze esistono e quali alternative sono possibili.

Un altro aspetto centrale è la verifica. Molte organizzazioni dichiarano di avere backup, ma non testano con regolarità la capacità di ripristino. Il test dovrebbe produrre evidenze, non solo conferme verbali: cosa è stato recuperato, in quanto tempo, con quale perdita dati, con quali problemi e con quali azioni correttive. Un piano non testato resta un’ipotesi. Un ripristino verificato diventa capacità operativa.

Conclusione

La NIS2 richiede alle organizzazioni di superare una visione puramente tecnica della resilienza. La continuità operativa non è un documento da conservare e il disaster recovery non è sinonimo di backup. Sono strumenti di governo che devono collegare attività aziendali, servizi IT, asset, fornitori, RTO, RPO, priorità di ripristino e capacità effettiva di risposta.

Il ripristino non dovrebbe essere improvvisato durante la crisi. Deve essere progettato prima, verificato nel tempo e aggiornato quando cambiano processi, tecnologie, fornitori o impatti.

La vera domanda, quindi, non è se l’organizzazione abbia i backup. La domanda corretta è se sappia cosa deve ripartire prima, entro quanto tempo, con quale perdita dati accettabile e con quali risorse interne ed esterne.

Quando la continuità operativa viene messa alla prova da un evento reale, il tema si sposta sulla gestione degli incidenti: ruoli, escalation, comunicazioni, decisioni e impatti economici.