La maggior parte delle organizzazioni presenti sul mercato possiedono un piano di Disaster Recovery, ma non tutte hanno costruito una capacità concreta di ripristino.
Qui si misura la distanza tra compliance documentale e resilienza operativa.
Il Disaster Recovery (DR) non coincide con un documento tecnico ma con la capacità effettiva di riportare in funzione servizi, sistemi e processi entro tempi compatibili con la sopravvivenza dell’organizzazione.
Questo terzo capitolo di un’eptalogia, dedicata alla sequenza degli adempimenti per costruire la resilienza richiesta dalla NIS 2, con focus sul legame tra fornitori, piano di Business Continuity e DR – esplora il significato strategico del ripristino, il ruolo delle dipendenze tecnologiche e il motivo per cui il DR rappresenta oggi uno dei principali punti di verità della sicurezza organizzativa.
Disaster recovery in un’organizzazione: il momento in cui la resilienza si rivela
Ogni organizzazione attraversa un istante preciso in cui scopre se la propria resilienza è reale oppure solo dichiarata.
È l’istante in cui qualcosa si ferma a causa di un ransomware, un errore umano, un guasto infrastrutturale, un blackout, una compromissione del cloud provider, una perdita di connettività, un attacco alla supply chain, un malfunzionamento critico.
Finché tutto funziona, la stabilità sembra naturale perchè i processi scorrono, i servizi rispondono, le persone lavorano senza interruzioni.
Ma la normalità non è il naturale riferimento della resilienza che si misura nella capacità di riportare l’operatività proprio quando la normalità si interrompe.
È in quel momento che il Disaster Recovery mostra il suo significato più autentico.
I primi due capitoli dell’eptalogia
Il grande equivoco: confondere il backup con il ripristino
Per anni il Disaster recovery è stato trattato come un tema tecnico affidato esclusivamente alla funzione IT.
Il DR è anzitutto una misura organizzativa che richiede una visione di insieme di un numero molto elevato di variabili.
Alcuni lo hanno confuso con il semplice possesso di backup, ma avere copie dei dati non significa essere in grado di ripartire e anche avere un’infrastruttura ridondata non significa saper governare una crisi.
Il ripristino è un esercizio complesso che – per ogni scenario immaginato, che si attiva in base a specifiche situazioni di crisi definite nel piano di continuità operativa – coinvolge: tempi, priorità, dipendenze, decisioni, coordinamento, disponibilità delle persone, funzionamento delle infrastrutture, continuità delle comunicazioni.
Quando si verifica un incidente di sicurezza significativo, emergono immediatamente le fragilità nascoste: backup corrotti, ripristini mai testati, tempi incompatibili con l’operatività, dipendenze ignorate, fornitori indisponibili, procedure obsolete, competenze mancanti.
In quel momento si comprende cos’è la resilienza.
RTO e RPO: le decisioni che definiscono la sopravvivenza
Due concetti guidano ogni ragionamento serio sul Disaster Recovery: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Spesso vengono trattati come parametri tecnici ma in realtà rappresentano scelte strategiche profonde.
L’RTO chiede quanto tempo un servizio può restare fermo prima che il danno diventi incompatibile con la sopravvivenza operativa. Invece, l’RPO chiede quanta perdita di dati l’organizzazione può realmente tollerare.
A queste domande non può rispondere la funzione IT deve rispondere il vertice organizzativo perché definire RTO e RPO comporta decidere cosa è davvero critico, quali perdite sono accettabili, quali investimenti sono necessari, quali rischi e penalità si è disposti a sostenere, cosa è stato contrattualizzato con i clienti.
Alcune organizzazioni scelgono valori teorici, numeri desiderati, non numeri reali, ma il Disaster Recovery non lavora sui desideri, lavora sulla realtà.
Dichiarare un RTO di quattro ore quando l’infrastruttura richiede due giorni di recovery o non avendo coinvolto i fornitori critici crea autoinganno non resilienza vera.
Ecco il motivo per cui il DR è uno dei principali esercizi di verità organizzativa.
Le dipendenze tecnologiche: il punto cieco del ripristino
Nessun Disaster Recovery può essere progettato ignorando le dipendenze esterne. Ma è qui che il lavoro sui fornitori critici diventa fondamentale.
Oggi in ecosistemi davvero molto complessi si può affermare che quasi nessuna organizzazione controlla completamente la propria architettura tecnologica.
Cloud provider, connettività, servizi SaaS, autenticazione federata, DNS, piattaforme collaborative, data center, servizi di cybersecurity gestita. Ogni elemento può influenzare radicalmente la capacità di recovery.
Il ripristino non dipende più solo dalle capacità interne ma anche dai tempi dei fornitori, dai vincoli contrattuali, dalla disponibilità dei servizi esterni, dalla priorità assegnata dal provider, dalla resilienza della supply chain.
Una parte essenziale della capacità di ripristino è ormai esternalizzata ed è qui che la resilienza contemporanea trova uno dei suoi punti più delicati.
La fine del perimetro e la nascita della resilienza distribuita
Per anni la sicurezza è stata costruita intorno all’idea di perimetro: proteggere ciò che era interno, difendere l’infrastruttura aziendale, controllare reti e sistemi locali.
Oggi questa visione non funziona più. Le organizzazioni operano attraverso ecosistemi distribuiti, integrati, fluidi.
Quindi, il Disaster recovery deve cambiare prospettiva. Non basta più progettare il ripristino dei sistemi interni, occorre chiedersi da quali soggetti esterni dipende la capacità di recovery.
È un cambio di paradigma che sposta il tema dalla tecnologia alla governance delle dipendenze.
La resilienza non coincide più con il controllo assoluto, ma con la capacità di governare sistemi complessi e interdipendenti.
Il ripristino come esercizio di priorità e di governo
Durante un incidente di sicurezza significativo non tutto può ripartire contemporaneamente. È nel momento della crisi che emergono le vere priorità operative e la Business Impact Analysis (BIA) ci insegna ad identificare cosa deve essere protetto e con quale priorità.
Alcuni servizi devono tornare disponibili subito, altri possono attendere, altri ancora possono operare in modalità degradata.
Queste scelte non sono tecniche: sono strategiche perché descrivono ciò che l’organizzazione considera essenziale per la propria sopravvivenza.
Purtroppo, è proprio durante il ripristino che alcune organizzazioni scoprono di non avere mai definito davvero le proprie priorità.
Così, tutto sembra importante finché non arriva una crisi.
Poi diventa necessario scegliere e in quel momento emerge la differenza tra chi ha costruito consapevolezza e chi ha prodotto solo documenti.
Quindi, si deve tenere ben presente che il vero Disaster Recovery non è l’esecuzione di procedure tecniche, ma la capacità di coordinare decisioni, persone, fornitori, tecnologie, comunicazioni, risorse.
In sintesi, il Disaster recovery è governo della crisi.
Cosa richiede la resilienza autentica
Il Disaster Recovery è uno dei principali punti di verità della resilienza organizzativa.
Costringe l’organizzazione a confrontarsi con la propria capacità reale di ripristino, non con quella dichiarata o sperata.
La resilienza autentica richiede conoscenza delle dipendenze, realismo operativo, test continui, priorità chiare, coordinamento, capacità decisionale e richiede soprattutto la consapevolezza che nessun piano sostituisce la preparazione reale.
Il DR non protegge perché esiste, ma protegge solo se può essere eseguito quando tutto si ferma.
Nel prossimo capitolo, esploreremo il Business Continuity Plan (BCP) e comprenderemo perché rappresenta il livello più alto della resilienza organizzativa: il punto in cui non si parla più solo di sistemi, bensì della capacità stessa dell’organizzazione di continuare a esistere durante una crisi.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Giuseppe Alverone e Monica Perego
Source link
