Un backup esiste davvero solo quando qualcuno ha verificato che possa essere ripristinato nei tempi e nel modo necessari all'azienda. Per molte PMI, invece, il tema resta ambiguo: si pensa di essere protetti perché "i dati sono copiati da qualche parte", ma non sempre è chiaro quali sistemi siano inclusi, quanto tempo serva per ripartire, chi debba intervenire e che cosa accada se l'incidente coinvolge anche il fornitore cloud, il server locale o gli account amministrativi.
Il punto non è avere una copia in più, ma sapere se l'impresa può continuare a lavorare dopo un guasto, un errore umano, un ransomware, una cancellazione accidentale o una violazione dei dati personali. Questo articolo aiuta a distinguere backup, disaster recovery e continuità operativa, a porre le domande giuste prima di scegliere una soluzione e a capire quando serve una revisione tecnica più strutturata. Verifica fonti: 17 luglio 2026.
Backup, disaster recovery e continuità operativa non sono la stessa cosa
Il backup è la copia di dati, configurazioni o sistemi. Serve a recuperare informazioni perse, danneggiate o rese inaccessibili. Da solo, però, non dice quanto tempo servirà per tornare operativi, quali applicazioni verranno ripristinate per prime e quali persone dovranno approvare le decisioni durante l'emergenza.
Il disaster recovery riguarda invece il processo di ripristino dei sistemi e dei servizi dopo un evento critico. Include priorità, responsabilità, ambienti alternativi, tempi attesi, procedure di test e comunicazioni interne. La continuità operativa è ancora più ampia: considera come l'azienda continua a erogare attività essenziali anche quando alcuni strumenti non sono disponibili.
Per una PMI, questa distinzione è decisiva. Un gestionale può avere backup regolari, ma se nessuno ha definito come accedere ai dati durante il fermo, il problema operativo resta aperto. Allo stesso modo, un ambiente cloud può ridurre alcuni rischi infrastrutturali senza eliminare la necessità di controllare configurazioni, accessi, copie, contratti e tempi di ripristino.
Le domande da fare prima di fidarsi dei propri backup
La prima domanda è semplice: quali dati e sistemi sono davvero coperti? Molte aziende salvano documenti e database principali, ma dimenticano configurazioni, account, macchine virtuali, caselle email, archivi condivisi, applicazioni verticali o integrazioni tra strumenti. In caso di incidente, proprio questi elementi possono rallentare il ritorno alla normalità.
La seconda domanda riguarda la frequenza. Se il backup avviene una volta al giorno, l'azienda deve accettare la possibilità di perdere le modifiche successive all'ultima copia valida. Se il processo è più frequente, bisogna comunque verificare che le copie non siano corrotte, incomplete o accessibili dallo stesso account compromesso.
La terza domanda è: dove sono conservate le copie? ENISA raccomanda per le PMI backup regolari, possibilmente automatizzati, separati dall'ambiente di produzione, cifrati quando necessario e testati con ripristini periodici. Questa separazione è particolarmente importante nei casi di ransomware, perché un attacco può colpire anche le copie se sono sempre raggiungibili dalla stessa rete o dagli stessi privilegi.
Quanto tempo può restare ferma l'azienda
Ogni impresa dovrebbe chiarire quali attività non possono fermarsi e per quanto tempo. Non tutti i sistemi hanno la stessa priorità: posta, gestionale, CRM, file condivisi, sito, e-commerce, portali di collaborazione e strumenti contabili possono avere impatti diversi su clienti, fornitori, produzione e amministrazione.
Due domande aiutano a tradurre il tema in decisioni operative. La prima è: quanti dati possiamo perdere senza danni rilevanti? La seconda è: entro quanto tempo dobbiamo ripristinare un servizio per evitare conseguenze gravi? Anche senza usare formule tecniche, queste risposte guidano la scelta tra backup semplice, replica, infrastruttura ibrida, ambienti di emergenza o servizi gestiti.
Il NIST Cybersecurity Framework 2.0 tratta il recupero come una funzione specifica della gestione del rischio: dopo un incidente, asset e operazioni devono essere ripristinati in modo tempestivo per ridurne gli effetti. Questo significa che il ripristino non va improvvisato durante la crisi, ma preparato, documentato e aggiornato.
Il test di ripristino è il vero controllo di qualità
Un backup non testato è una promessa, non una prova. Il test di ripristino serve a verificare che le copie siano leggibili, che i dati siano coerenti, che le credenziali siano disponibili, che la procedura sia comprensibile e che i tempi siano compatibili con le esigenze aziendali.
Il test non deve per forza essere complesso fin dall'inizio. Una PMI può partire da verifiche mirate: recuperare una cartella, ripristinare un database in ambiente separato, riattivare una macchina virtuale, simulare l'indisponibilità di un file server o controllare il recupero di una casella email. L'importante è registrare cosa è stato provato, chi ha partecipato, quanto tempo è servito e quali problemi sono emersi.
Quando emergono errori, il test ha già prodotto valore. Una procedura che fallisce in un'esercitazione può essere corretta senza pressione. Una procedura che fallisce durante un attacco, invece, può bloccare decisioni commerciali, amministrative e legali proprio quando l'azienda ha meno margine.
Protezione dei dati e obblighi in caso di incidente
Backup e disaster recovery hanno anche un impatto sulla protezione dei dati personali. Il Garante Privacy include tra gli esempi di violazione l'impossibilità di accedere ai dati per attacchi esterni, virus o malware, oltre alla perdita o distruzione di dati personali per incidenti o eventi avversi.
Se l'incidente riguarda dati personali, il titolare del trattamento deve valutare se esistono rischi per i diritti e le libertà delle persone fisiche. Quando la notifica al Garante è dovuta, il GDPR richiede che avvenga senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui il titolare ne viene a conoscenza. Le violazioni devono comunque essere documentate, anche quando non vengono notificate.
Per questo la dimensione tecnica non può essere separata da quella organizzativa. Sapere quali dati sono coinvolti, quali sistemi sono stati colpiti, quali copie sono affidabili e chi gestisce la comunicazione aiuta a ridurre confusione e ritardi. Nei casi dubbi, la valutazione va affidata a figure competenti in sicurezza, privacy e gestione del rischio.
Quando rivedere architettura, fornitori e responsabilità
Un controllo sui backup diventa particolarmente utile quando l'azienda cresce, cambia gestionale, introduce cloud e soluzioni ibride, apre nuove sedi, abilita lavoro remoto, gestisce dati più sensibili o dipende da portali collaborativi. In questi momenti, l'infrastruttura reale spesso diventa più articolata della documentazione disponibile.
La revisione dovrebbe coprire almeno cinque aree: inventario dei sistemi critici, posizione dei dati, responsabilità dei fornitori, privilegi amministrativi e piano di ripristino. Nei contratti con provider IT e cloud è opportuno verificare cosa è incluso, quali tempi sono previsti, quali attività restano a carico dell'azienda e quali prove di ripristino possono essere eseguite.
Zanettistudios colloca i servizi IT in una logica integrata: infrastrutture ibride, cybersecurity, protezione dei dati, data management, portali di collaborazione e datacenter devono sostenere efficienza, sicurezza e decisioni aziendali. Per una PMI, questa integrazione è utile quando il problema non è scegliere un singolo strumento, ma costruire un assetto coerente tra tecnologia, processi e continuità operativa.
Come impostare un primo piano di verifica
Un primo piano può partire da una mappa essenziale. Elencare sistemi, dati, responsabili, fornitori, frequenza dei backup, luogo delle copie e ultimo test di ripristino consente di vedere rapidamente le lacune. Se alcune risposte mancano, è già un segnale di rischio operativo.
Il secondo passaggio è definire priorità. Non tutto va risolto nello stesso momento: prima si proteggono i servizi senza i quali l'azienda non può lavorare, poi si estende il controllo agli altri ambienti. Per ogni servizio critico conviene indicare una procedura minima: chi chiama chi, dove si trovano le credenziali, quale copia usare, come verificare il dato recuperato e come comunicare lo stato del ripristino.
Il terzo passaggio è pianificare test periodici. La frequenza dipende dal rischio, dalla complessità e dal ritmo di cambiamento dei sistemi. Ciò che conta è non trattare il backup come una configurazione statica: nuovi utenti, nuove applicazioni, modifiche cloud e aggiornamenti possono cambiare la capacità reale di ripartenza.
Il supporto di Zanettistudios
Per le PMI, backup e disaster recovery non sono solo temi tecnici: toccano continuità operativa, protezione dei dati, responsabilità interne, rapporto con i fornitori e qualità dell'infrastruttura IT. Zanettistudios può supportare l'analisi dell'assetto esistente, l'individuazione dei sistemi critici e la progettazione di soluzioni coerenti con cybersecurity, infrastrutture ibride, datacenter e gestione dei dati.
L'obiettivo non è aggiungere complessità, ma rendere più chiaro cosa succede quando qualcosa va storto: quali dati si recuperano, in quanto tempo, con quali responsabilità e con quali controlli. Una verifica preventiva può evitare che l'azienda scopra i limiti dei propri backup nel momento peggiore.
FAQ
Avere il backup in cloud significa essere al sicuro? No. Il cloud può aumentare disponibilità e flessibilità, ma bisogna verificare configurazioni, accessi, retention, copie separate, responsabilità contrattuali e test di ripristino.
Ogni quanto bisogna testare un backup? Dipende dal rischio e dalla criticità dei sistemi. Per i servizi essenziali è opportuno prevedere test periodici e ogni volta che cambiano infrastruttura, applicazioni o fornitori rilevanti.
Il disaster recovery serve anche alle piccole imprese? Sì, in forma proporzionata. Anche una piccola impresa può subire danni rilevanti se non riesce ad accedere a dati, posta, gestionale o documenti essenziali.
Un attacco ransomware è sempre un data breach? Non necessariamente in ogni caso, ma può diventarlo se riguarda dati personali e comporta accesso non autorizzato, perdita, distruzione, alterazione o indisponibilità con rischi per le persone. La valutazione deve essere fatta caso per caso.