Fare una copia dei dati e riuscire a ripartire sono due cose diverse. Se il gestionale si blocca, non basta sapere che il backup è andato a buon fine: bisogna poter recuperare dati e configurazioni necessari e rimettere in funzione il servizio nell’ordine e nei tempi necessari all’azienda.
In un percorso coerente con la ISO/IEC 27001:2022, backup e continuità non sono una checklist tecnica isolata. Sono decisioni organizzative su che cosa proteggere, per quanto tempo conservarlo, in quale ordine ripristinarlo e con quali evidenze verificare che il metodo funzioni. Una procedura formale è utile, ma non può sostituire configurazioni reali, responsabilità chiare e prove ripetibili.
Identificare le attività essenziali
La domanda iniziale non è “quante copie abbiamo?”, ma “quale attività si ferma se questo sistema o dato non è disponibile?”. Un gestionale, una casella condivisa, un file di produzione, una piattaforma di assistenza o un servizio erogato da un fornitore possono avere impatti molto diversi.
Per ogni servizio essenziale conviene rendere espliciti almeno quattro elementi: il responsabile aziendale, i dati o le configurazioni necessari, la conseguenza dell’indisponibilità e una priorità di ripartenza condivisa. La priorità non coincide automaticamente con il valore tecnologico del sistema. Un’applicazione poco visibile può essere indispensabile per spedire, fatturare, produrre o gestire richieste urgenti.
Questo passaggio evita due errori frequenti: proteggere tutto con lo stesso livello di attenzione oppure lasciare che l’ordine di ripristino venga deciso solo nel momento dell’emergenza. La direzione non deve scegliere il dettaglio tecnico della copia; deve rendere esplicite le priorità di servizio e assegnare chi può confermarle quando cambiano processi, fornitori o strumenti.
Configurazioni: ciò che la procedura non dimostra
Una policy può indicare che vengono effettuati backup giornalieri. Per capire se l’affermazione corrisponde alla pratica servono però evidenze operative: quali origini sono incluse, dove viene conservata la copia, con quale frequenza, quali esiti sono controllati e che cosa accade quando un job fallisce.
Non occorre trasformare il vertice aziendale in amministratore di sistema. Chi governa il processo deve però poter chiedere informazioni comprensibili: quali servizi rientrano nel perimetro, quali esclusioni sono state accettate, chi riceve gli alert e quando un’anomalia richiede escalation.
Una verifica utile collega una configurazione a un servizio reale. Per esempio: il sistema indicato come prioritario è davvero incluso nelle copie? I database, le chiavi, le configurazioni applicative e le informazioni necessarie per riavviare il servizio sono trattati in modo coerente? La risposta può essere tecnica, ma la domanda è di continuità: “possiamo ricostruire il servizio, non soltanto recuperare un file?”.
Retention: decidere quanto tempo serve davvero
Retention significa stabilire per quanto tempo le copie restano disponibili e con quale logica possono essere recuperate. Non è un numero da scegliere perché “si è sempre fatto così”. Dipende dal tipo di dato, dalla velocità con cui si scoprono errori o alterazioni, dagli obblighi applicabili, dai cicli aziendali e dalla possibilità concreta di conservare le copie in sicurezza.
Una retention troppo breve può rendere impossibile recuperare una versione precedente quando il problema emerge tardi. Una retention molto lunga, invece, non è automaticamente una garanzia: richiede costi, controlli, protezione degli accessi e chiarezza su ciò che viene conservato.
Il confronto utile mette a fianco scenari concreti. Se un errore viene individuato dopo alcune settimane, esiste una copia utile? Se un fornitore gestisce parte dell’infrastruttura, quali tempi e condizioni valgono per il recupero? Se un dipendente lascia l’azienda, le informazioni necessarie restano disponibili nel processo corretto? Le decisioni possono cambiare nel tempo, ma devono essere tracciabili e riesaminate quando cambiano attività o rischi.
Verificare il ripristino, non solo il completamento del job
Quando il software di backup segnala che il job si è concluso senza errori, conferma soltanto che la copia è stata creata. Non conferma che l’azienda riesca a usarla per recuperare dati e configurazioni e riattivare il servizio. La verifica di ripristino serve proprio a far emergere dipendenze non previste, credenziali mancanti, tempi incompatibili con l’operatività o istruzioni che nessuno riesce ad applicare.
La prova deve essere proporzionata: non tutte le applicazioni richiedono la stessa simulazione. Per i servizi più importanti, però, è utile definire uno scenario, chi coinvolgere, quale risultato osservare e quale evidenza conservare. Può essere il recupero controllato di un file, il ripristino di un database in ambiente separato o la verifica della sequenza necessaria per riattivare un servizio.
Dopo il test, il punto non è scrivere che “il backup funziona”. Serve registrare ciò che è stato verificato, i tempi osservati, le difficoltà emerse, le azioni assegnate e la data del riesame. Se una prova fallisce, non è un dato da nascondere: è un’informazione per rivedere priorità, configurazione o responsabilità prima che l’incidente renda il problema più costoso.
Ruoli chiari tra IT, direzione e fornitori
La continuità richiede un confine chiaro tra chi configura e controlla le soluzioni, chi possiede il servizio aziendale e chi prende decisioni su priorità, risorse o rischio residuo. Senza questo confine, gli alert restano nell’IT, le aspettative restano implicite e le deroghe diventano difficili da ricostruire.
Quando interviene un fornitore, il metodo deve includere anche lui: responsabilità operative, canali di escalation, informazioni disponibili, tempi concordati e modalità per ottenere evidenze. Non è sufficiente sapere che il fornitore “fa i backup”; l’azienda deve comprendere quale parte del proprio servizio dipende da quella attività e come verificare che il rapporto sia governato.
Un riesame breve e periodico può concentrarsi su poche domande: sono cambiate le priorità? Ci sono servizi nuovi o esclusioni non più accettabili? Gli ultimi test hanno prodotto azioni aperte? Qualcuno è responsabile della loro chiusura? In questo modo i backup vengono riesaminati con regolarità, invece di essere considerati solo quando un servizio è già fermo.
Una traccia essenziale per rendere il metodo verificabile
Per iniziare non serve creare un registro complesso. È sufficiente costruire una tabella aggiornata che colleghi servizio, responsabile, priorità, origine del backup, retention, ultima verifica di ripristino, esito e azione successiva. IT, direzione e fornitori possono così verificare gli stessi dati senza confondere configurazioni tecniche e decisioni aziendali.
Il valore non sta nell’avere più tabelle. La tabella deve mostrare per ogni servizio: chi lo gestisce, come viene eseguita la copia, per quanto tempo resta disponibile, quando è stato provato il ripristino e chi chiude un’eventuale anomalia.
Conclusione. Backup e continuità sono affidabili quando le copie includono i sistemi necessari, restano disponibili per il tempo stabilito e vengono provate secondo l’ordine di ripristino deciso dall’azienda. Una procedura può dare un orientamento; la verifica arriva quando l’azienda sa quale servizio deve riattivare, quali dati e configurazioni servono, in quale priorità e con quale prova di ripristino. In questo modo direzione e IT possono decidere su fatti verificati, non su un semplice esito positivo del software di backup.