Disaster recovery per PMI: la prova di ripartenza conta più del documento

Il disaster recovery non è un fascicolo da mostrare all’audit. È la differenza tra un lunedì storto e una settimana in cui non si fattura, non si spedisce, non si risponde ai clienti e si scopre che l’unica persona con le password è in ferie.

Per molte PMI italiane il tema resta sospeso tra due errori opposti. Da un lato il fatalismo: «se succede, ci arrangiamo». Dall’altro la copia povera dei modelli enterprise: piani lunghi, diagrammi solenni, acronimi, nessuna prova vera. Entrambi gli approcci falliscono nello stesso punto: quando serve ripartire, non quando serve raccontare che si potrebbe.

La tesi è semplice: una PMI non ha bisogno di un disaster recovery da multinazionale. Ha bisogno di una prova di ripartenza credibile, ripetibile e misurata. Piccola, concreta, fatta sui sistemi che tengono in piedi il fatturato. Il resto viene dopo.

1. Il disaster recovery non parte dai server, parte dal fatturato

Il modo sbagliato di iniziare è chiedere: «quali server dobbiamo replicare?». È una domanda tecnica legittima, ma arriva troppo presto. La domanda utile per una PMI è un’altra: «quali attività devono ripartire per non fermare l’azienda?». Da lì si capisce quali sistemi contano davvero.

In una manifattura può essere l’ERP con ordini, magazzino e documenti di trasporto. In un’azienda commerciale il CRM con le offerte aperte, la posta, il gestionale e il portale e-commerce. In uno studio tecnico il file server con i progetti, il sistema di ticketing e l’accesso alle licenze. Ogni settore ha la sua gerarchia, ma quasi tutti scoprono la stessa cosa: non serve ripristinare tutto subito. Serve ripristinare bene il minimo indispensabile.

Qui entrano due sigle che non vanno trasformate in religione. RTO è il tempo massimo che può passare prima che un sistema torni utilizzabile. RPO è la quantità di dati che l’azienda può permettersi di perdere, misurata nel tempo: un’ora, quattro ore, un giorno. Se l’ERP ha un backup giornaliero e cade alle 17, l’RPO reale può essere quasi una giornata di lavoro. Non è una colpa, è una misura. Ma va conosciuta prima dell’incidente, non scoperta dopo.

La PMI ha un vantaggio che spesso sottovaluta: decide in fretta. Non deve scrivere un programma triennale per migliorare. Può prendere cinque processi, assegnare le priorità, chiamare il system integrator di fiducia e fare una prova entro un mese. L’agilità diventa difesa, se serve a misurare e non solo a improvvisare.

2. La norma non chiede teatro: chiede disponibilità, ripristino e test

Il punto normativo va detto senza enfasi. Il GDPR non parla solo di privacy come consenso e informative. L’art. 32 del Regolamento (UE) 2016/679 include, tra le misure di sicurezza, la capacità di assicurare disponibilità e resilienza dei sistemi, la capacità di ripristinare tempestivamente la disponibilità e l’accesso ai dati personali dopo un incidente fisico o tecnico, e una procedura per testare e valutare regolarmente l’efficacia delle misure.

Tre parole contano: disponibilità, ripristinare, testare. Non sono parole da avvocato, sono parole operative. Se un gestionale contiene dati di clienti, dipendenti, fornitori o pazienti, non basta dire che «il cloud è sicuro». Bisogna sapere come si torna operativi quando qualcosa smette di funzionare.

La NIS2 alza ulteriormente l’asticella per i soggetti che rientrano nel suo perimetro e, indirettamente, per molti fornitori della loro filiera. La Direttiva (UE) 2022/2555 include tra le misure di gestione del rischio la continuità operativa — gestione dei backup, disaster recovery e gestione delle crisi — e la sicurezza della supply chain. In Italia il recepimento è avvenuto con il D.Lgs. 138/2024.

Questo non significa che ogni PMI debba trasformarsi in una banca. Significa qualcosa di più concreto: clienti più strutturati, capofiliera e partner regolati inizieranno a chiedere evidenze. Non più solo «avete un backup?», ma «quando avete provato il ripristino?», «con quali tempi?», «su quali sistemi?», «chi vi supporta se il fornitore principale non risponde?». Chi ha una risposta credibile non è più burocratico: è più affidabile commercialmente.

3. Cosa deve ripartire per primo: la versione minima dell’azienda

In caso di incidente serve definire la versione minima dell’azienda che può continuare a lavorare. Non quella comoda: quella sufficiente a prendere ordini, consegnare, fatturare, pagare gli stipendi, comunicare con clienti e fornitori.

Per molte PMI questa mappa minima contiene pochi blocchi:

• identità e accessi: account amministrativi, MFA, directory, password manager, VPN o accesso remoto;
• comunicazioni: posta, calendario, centralino VoIP o strumenti alternativi già pronti;
• dati operativi: ERP, gestionale, database, file critici, documenti fiscali e contrattuali;
• canali di vendita e assistenza: sito, e-commerce, CRM, ticketing, PEC dove rilevante;
• infrastruttura di supporto: DNS, dominio, backup, storage di ripristino, documentazione tecnica;
• persone chiave: chi decide, chi ha le credenziali, chi parla con clienti e fornitori.

Questa lista non va incollata in un manuale e dimenticata. Va ridotta, adattata, ordinata. Il sistema paghe magari non serve nella prima ora, ma diventa critico a fine mese. Il file server con gli archivi storici può aspettare, la cartella con i disegni in produzione no. Il sito vetrina può restare giù qualche ora, l’e-commerce durante il picco stagionale no.

La priorità va decisa con chi conosce il business, non solo con l’IT. Il responsabile amministrativo sa cosa blocca la fatturazione. Il responsabile di produzione sa cosa ferma le spedizioni. Il commerciale sa quali clienti chiameranno dopo trenta minuti. Il system integrator porta il metodo e traduce le priorità in architettura, ma la decisione resta aziendale.

4. Architetture realistiche: non serve l’active-active da brochure

Il mercato vende spesso l’idea che la vera continuità operativa sia avere tutto duplicato, sempre acceso, su più region geografiche. È una soluzione legittima per chi ha volumi, margini e requisiti coerenti. Per molte PMI è un modo costoso per non fare la cosa più importante: provare davvero il ripristino.

Ci sono tre modelli più realistici. Il primo è il backup immutabile con restore provato in un ambiente separato. È adatto quando l’azienda può tollerare alcune ore di fermo e vuole difendersi soprattutto da ransomware, errore umano e guasto del fornitore. L’elemento decisivo non è solo l’immutabilità, ma la possibilità di avviare una copia pulita dei sistemi in una rete isolata.

Il secondo modello è il warm standby: una parte dell’infrastruttura è già predisposta su un secondo ambiente — magari presso un provider italiano o europeo diverso dal principale — con dati replicati a intervalli definiti. Costa più del solo backup, ma riduce i tempi di ripartenza. È spesso sensato per ERP, database, servizi B2B e portali che generano fatturato diretto.

Il terzo modello è ibrido: pochi sistemi critici in warm standby, il resto in restore da backup. È spesso il compromesso migliore. Evita il teatro del multi-cloud totale, ma non lascia l’azienda appesa a un unico punto di guasto.

Qui la sovranità tecnologica diventa pratica. Non è la bandierina sul sito del provider. È poter chiamare qualcuno che conosce l’ambiente, sapere dove sono i dati, avere contratti leggibili, poter esportare macchine e backup, non dipendere da un’unica console proprietaria per ogni operazione. Un provider vicino e un system integrator italiano competente non garantiscono miracoli, ma riducono il tempo perso in escalation anonime quando il problema è reale.

Il cloud indipendente non è necessariamente più «piccolo». È più governabile. E per una PMI governabile significa scelte tecniche spiegabili, costi di ripristino stimabili e un’uscita che non richiede di riscrivere l’intera infrastruttura.

5. La prova di ripartenza: quattro ore valgono più di quaranta pagine

Il test non deve iniziare con scenari cinematografici. Niente simulazioni da film, niente war room teatrali. Si sceglie un sistema critico, si crea un ambiente isolato, si ripristinano dati e applicazione, si verifica che un utente riesca a fare un’operazione reale: aprire un ordine, emettere un documento, consultare una pratica, scaricare un allegato, inviare una comunicazione.

La prova deve misurare tempi e attriti. Quanto tempo serve per trovare le credenziali? Chi autorizza l’avvio del ripristino? Il backup è leggibile? La versione del database è compatibile? Le licenze software permettono l’esecuzione in un ambiente alternativo? Il DNS può essere modificato rapidamente? L’MFA funziona se il telefono dell’amministratore non è disponibile? Sono dettagli piccoli solo finché non bloccano tutto.

Una buona prova produce un verbale breve, non un romanzo. Deve dire quali sistemi sono stati provati, da quale backup, con quale tempo di ripristino, con quale perdita dati stimata, quali problemi sono emersi e quali azioni correttive sono state assegnate. Se il risultato è brutto, è comunque utile. Il peggior test è quello mai fatto.

La frequenza dipende dal rischio, ma una PMI può partire con una prova semestrale sui sistemi critici e una verifica più leggera dopo ogni cambio importante: migrazione ERP, cambio provider, rinnovo del firewall, nuovo sistema di identità, introduzione di un servizio AI collegato ai dati aziendali. Ogni modifica che aumenta la dipendenza tecnica dovrebbe aggiornare anche il piano di ripartenza.

Qui l’AI merita un inciso concreto. Molte aziende stanno introducendo chatbot interni, motori RAG, automazioni sui documenti e strumenti di supporto clienti. Se questi sistemi diventano parte del lavoro quotidiano, entrano nel perimetro della continuità. Non perché siano «intelligenti», ma perché diventano dipendenze operative: indicizzano documenti, suggeriscono risposte, muovono pratiche, interrogano database. Il disaster recovery deve sapere dove sono embedding, prompt, log, configurazioni e permessi. Altrimenti l’AI riparte vuota, o peggio riparte con dati incoerenti.

6. Contratti: il disaster recovery muore nelle clausole vaghe

Molti piani di continuità saltano non per limiti tecnici, ma per contratti scritti male. La clausola «backup incluso» non basta. Incluso come? Con quale retention? Ripristinabile dal cliente o solo dal fornitore? Su ticket best effort o entro un tempo contrattuale? Con quale granularità? A quale costo? In quale Paese sono conservate le copie? Chi può cancellarle?

Per i fornitori che trattano dati personali come responsabili del trattamento, l’art. 28 del GDPR richiede un contratto o altro atto giuridico che disciplini il trattamento. Dentro quel rapporto, le misure tecniche e organizzative non sono arredamento. Se un SaaS contiene dati essenziali e non offre un’esportazione utilizzabile, log sufficienti e tempi chiari di ripristino, il rischio resta in capo all’azienda che lo usa. Anche quando il pannello del servizio è bello.

Le clausole utili non devono essere aggressive, devono essere precise. Tempi di presa in carico e di escalation. Descrizione di backup, retention e ripristino. Obbligo di comunicare gli incidenti che impattano disponibilità e integrità. Possibilità di esportare i dati in un formato documentato. Evidenze periodiche dei test del fornitore, almeno per i servizi critici. Indicazione dei subfornitori rilevanti e dei Paesi coinvolti quando il tema tocca dati e continuità.

Il punto non è litigare con ogni vendor. È distinguere tra servizio commodity e servizio critico. Per un tool marginale si accetta più rischio. Per ERP, identità, documentale, posta, produzione, backup e AI collegata ai dati interni, la vaghezza costa troppo. Il rinnovo contrattuale è spesso il momento migliore per correggere: non blocca il business e sposta il rapporto da fiducia generica a responsabilità misurabile.

7. Un piano da trenta giorni, senza finta maturità

Una PMI può iniziare senza comitati, senza consulenze infinite e senza comprare subito nuova infrastruttura. Il primo passo è scegliere tre processi che tengono in piedi il fatturato. Il secondo è associare a ciascuno i sistemi tecnici minimi. Il terzo è dichiarare un RTO e un RPO provvisori, anche imperfetti. Il quarto è fare una prova su un solo sistema critico. Il quinto è correggere ciò che emerge.

In trenta giorni si arriva a un risultato più serio di molte policy aziendali: una mappa dei sistemi critici, un contatto operativo per ogni fornitore, una procedura di accesso alle credenziali di emergenza, una prova di restore documentata, un elenco di interventi prioritari con costi stimati. Non è la fine del percorso. È l’inizio del controllo.

La spesa va tenuta proporzionata. Prima si eliminano i punti di rottura evidenti: backup nello stesso tenant che potrebbe essere compromesso, un solo account amministratore, MFA non attivo sugli accessi critici, documentazione salvata solo sul file server da ripristinare, dominio gestito da una casella personale, nessun export dei dati SaaS. Sono difetti comuni e correggibili. Non servono slogan, serve ordine.

Il vantaggio competitivo è sottile ma reale. Quando un cliente chiede garanzie sulla continuità, l’azienda che risponde con una prova recente appare diversa. Quando un ransomware colpisce un concorrente, chi riparte in tempi accettabili mantiene clienti e reputazione. Quando un fornitore cloud cambia le condizioni o ha un disservizio, chi ha già provato l’uscita ragiona con lucidità.

Il disaster recovery per PMI non deve imitare l’enterprise. Deve essere più onesto. Pochi sistemi, priorità chiare, contratti leggibili, provider raggiungibili, test periodici. La domanda da mettere in agenda non è «abbiamo un piano?». È: «se domani mattina l’ambiente principale non c’è, entro quanto ripartiamo davvero?». Finché non c’è una prova, la risposta è solo una speranza.