Il backup dei SaaS non esiste finché non lo fai tu: guida pratica per PMI

“È nel cloud, quindi è al sicuro” è una frase comoda, ma fuorviante. La maggior parte dei servizi SaaS non offre un backup completo: offre retention limitate, cestini e versioni. Funzionano per i piccoli errori, non per i disastri veri. Quando un utente cancella centinaia di record, o un’integrazione sbaglia campo e sovrascrive tutto, ti accorgi che “ripristino” spesso significa scaricare CSV, aprire ticket e affidarti al best effort del fornitore. In un attacco ransomware che colpisce anche gli account cloud, la situazione tende a peggiorare ancora.

Per una PMI il tema non è filosofico: è operativo e contrattuale. Chi custodisce le tue copie, con quali garanzie legali, in che tempi puoi ripartire. La buona notizia è che esistono soluzioni semplici e ragionevoli, senza dover cambiare tutti gli strumenti né firmare impegni capestro.

1. Perché “è nel cloud” non è un piano di backup

Il modello di responsabilità condivisa vale anche nel SaaS. Il fornitore si occupa dell’infrastruttura; i tuoi dati e le tue configurazioni restano, di norma, una tua responsabilità — ma il riparto preciso va sempre letto nel contratto e nei termini di servizio. Se un amministratore concede un permesso sbagliato, se un’app con token API fa un import errato, se qualcuno elimina per sbaglio una cartella critica, difficilmente un failover geografico aiuta: il dato sbagliato viene sincronizzato ovunque, e in fretta.

Le funzionalità di base dei SaaS — cestino, versioning, retention temporanee, legal hold — di solito non equivalgono a un backup. Il cestino scade, il versioning non sempre copre metadati e permessi, il legal hold serve alla conservazione a fini legali e di discovery, non al ripristino operativo. Se per ripristinare un tenant servono export manuali e ticket, difficilmente hai un RTO affidabile: hai più probabilmente una promessa generica.

Il lock-in entra di soppiatto: formati proprietari, API con limiti di throughput, costi di egress o tetti mensili sugli export possono rendere difficile estrarre i dati quando servono. È un problema tecnico e contrattuale insieme, lo stesso che rende fragile un piano d’uscita dal cloud scritto troppo tardi. Se non lo anticipi, rischi di pagarlo nel giorno peggiore.

2. Cosa chiedono davvero le norme: disponibilità e ripristino

Il GDPR non parla di brand o architetture, ma di risultati. L’art. 32 richiede misure tecniche e organizzative adeguate, tra cui la capacità di assicurare la disponibilità e la resilienza dei sistemi e dei servizi di trattamento, e la capacità di ripristinare tempestivamente la disponibilità e l’accesso ai dati in caso di incidente. La traduzione pratica è ragionevolmente lineare: dovresti poter ripristinare i dati in tempi compatibili con il tuo business, senza dipendere da interventi discrezionali del fornitore.

Lo stesso GDPR, con il principio di integrità e riservatezza (art. 5, par. 1, lett. f), richiama la protezione da perdita o danno accidentale. Attenzione invece alla portabilità dei dati (art. 20): viene spesso evocata a sproposito. Quel diritto è dell’interessato, riguarda formati strutturati e l’esercizio dei diritti; non è pensato come meccanismo di backup aziendale per ripristinare un tenant.

Se operi in filiere sensibili o fornisci servizi a clienti più grandi, la NIS2 può toccarti per osmosi: introduce misure di gestione del rischio e continuità operativa lungo la supply chain, ma se e come ti riguardi dipende da settore, soglie e ruolo nella filiera, e va verificato sul caso. Senza citare commi, il succo è questo: è probabile che il cliente ti chieda evidenze che sai ripartire e ripristinare i dati. Per inquadrare cosa cambia davvero per chi non ha un CISO né budget illimitato, è utile leggere cosa significa la NIS2 per le PMI italiane. Meglio prepararsi ora, con soluzioni semplici e verificabili.

3. Architettura minima: 3-2-1 per i SaaS, con storage UE e chiavi tue

Un piano pratico parte da un principio conservatore: la regola 3-2-1. Tre copie dei dati, su due media diversi, una offsite. Nel mondo SaaS significa avere, oltre ai dati “vivi” nel servizio:

• una copia indipendente in uno storage a oggetti S3-compatibile in UE, con versioning, immutabilità (Object Lock/WORM) e crittografia lato client con chiavi gestite da te;
• una seconda copia offline o isolata logicamente — ad esempio snapshot immutabili replicati su un secondo provider europeo, oppure on-prem su NAS con snapshot e replica asimmetrica.

Non serve costruire un data center. Serve evitare la monocultura-cloud: se il tuo dato vive e viene salvato all’interno dello stesso perimetro tecnologico e legale del SaaS, rischi un punto singolo di fallimento, tecnico e giuridico insieme. Con uno storage a oggetti europeo separato riduci la dipendenza, mantieni il controllo delle chiavi e tieni la replica sotto la tua governance. Qui aiuta capire cosa significhi davvero cloud sovrano oltre lo slogan commerciale, perché non tutto ciò che è “in Europa” è necessariamente fuori dalla portata di leggi extra-UE.

La scelta dello strumento di backup conviene farla su tre criteri: copertura API del SaaS (email, file, chat, CRM, wiki, ticketing…), granularità di restore (per singolo oggetto ma anche per interi insiemi) e portabilità del repository (formati documentati, export completo possibile senza licenze aggiuntive). Gli strumenti open source sono spesso ottimi per file e VM; per i SaaS verticali spesso servono soluzioni dedicate, purché l’archivio resti tuo e verificabile.

Impostare l’immutabilità non è un dettaglio: è una barriera importante contro cancellazioni malevole o errori che si propagano. Versioning più Object Lock, con politiche di retention ragionevoli (ad esempio 30-60-90 giorni sulle aree operative, retention più lunga sui repository legali), aiutano a definire il terreno di gioco. Il principio di limitazione della conservazione del GDPR (art. 5, par. 1, lett. e) non è necessariamente in conflitto: può giustificare le retention in base alle esigenze operative e legali, purché documentate e applicate con policy chiare.

4. RPO e RTO realistici, e come testarli senza paralizzare nessuno

RPO e RTO non sono slogan: sono decisioni. Un contabile può tollerare di perdere le ultime 4 ore di email? Le vendite possono accettare un CRM indisponibile per mezza giornata? Una PMI tipica trova spesso un equilibrio attorno a RPO di 4–12 ore e RTO di 2–8 ore per i servizi principali, ma vanno scritti per sistema, non a sentimento. Il punto non è raggiungere lo “zero”, è avere numeri sostenibili con gli strumenti e il budget che hai.

La prova del nove è il restore test. Una volta a trimestre scegli un perimetro realistico — una mailbox, un set di file, un progetto del CRM, una pagina del wiki — e fai un ripristino in sandbox, misurando tempi e qualità del risultato. Annota dove si inceppa: limiti di API, mapping dei permessi, oggetti non coperti. Poi migliori lo strumento o ritocchi RPO/RTO. Senza test, i numeri rischiano di restare solo desideri.

C’è anche un tema umano: fare restore non dovrebbe richiedere l’eroe di turno. Procedure con passi numerati, screenshot e prerequisiti chiari abbassano la dipendenza dalle singole persone. Se ti affianca un partner esterno, definisci chi fa cosa in caso di incidente, su quali orari e con quali livelli di servizio. Il giorno dell’emergenza, l’ambiguità è spesso il vero collo di bottiglia.

5. Clausole contrattuali da fissare prima che servano

Gran parte del rischio sta nei contratti, non nei dischi. Se non puoi estrarre i dati in modo prevedibile, il tuo piano rischia di restare di carta. Queste clausole sono spesso negoziabili anche per una PMI, soprattutto al rinnovo — vanno però portate al tavolo con legale e acquisti, verificando di volta in volta cosa è davvero negoziabile nel tuo contratto:

• diritto al backup indipendente via API documentate, con throughput sufficiente e senza limiti arbitrari nei casi di ripristino;
• preavviso minimo (ad esempio 90 giorni) per deprecazioni di API o formati di export, con un periodo di coesistenza;
• formati di export documentati e completi, inclusi metadati e permessi, non solo contenuti;
• restore test in sandbox senza costi extra e senza impattare i limiti di produzione;
• trasparenza sull’ubicazione dei dati e dei backup, con opzione di confinamento in UE;
• esclusione o tetto ragionevole alle fee di egress quando l’export serve a backup o exit plan;
• log firmati o attestazioni periodiche che confermino il successo dei job di backup (utili in audit GDPR e nelle richieste dei clienti).

Molte di queste richieste si inseriscono bene al rinnovo, lo stesso momento adatto per introdurre un audit ai fornitori in ottica pre-NIS2 senza fermare il business. Le stesse righe valgono per il fornitore del software di backup: repository portabile, chiavi sotto il tuo controllo, dati restituibili senza penali. Il vendor lock-in nel backup rischia di diventare un doppio lock-in.

6. Quanto costa e quanto tempo serve: un percorso in 60 giorni

Gli investimenti sono di solito modesti rispetto al costo di un fermo. Per una PMI tra 50 e 200 utenti, lo storage a oggetti europeo con immutabilità e replica pesa spesso nell’ordine di qualche centinaio di euro al mese; gli abbonamenti software di backup per i SaaS principali sono di solito di pochi euro a utente al mese — ma gli importi variano molto per fornitore, volumi e configurazione. Il progetto tende a ripagarsi se evita di perdere giornate di lavoro o di negoziare al buio con un fornitore durante un incidente.

Un percorso snello, senza velleità:

• settimane 1–2: inventario dei SaaS vitali (email e file, chat, CRM, ticketing, wiki), mappa dei dati personali e dei team critici, definizione di RPO/RTO per ciascun servizio;
• settimane 3–4: scelta dello strumento e dello storage, prova in laboratorio su un sottoinsieme reale, verifica della copertura API e della granularità di restore;
• settimane 5–6: messa in produzione per email e file (di solito i volumi principali), definizione delle policy di retention, onboarding graduale degli altri SaaS;
• settimana 7: primo restore test in sandbox con misurazione dei tempi e ritocchi di configurazione;
• settimana 8: formalizzazione delle procedure e inclusione nel registro dei trattamenti e nelle misure di sicurezza documentate.

Un system integrator italiano “a misura d’uomo” può spesso completare questo percorso senza travolgere l’operatività: poche riunioni mirate, prove su dati veri, nessuna rivoluzione. Il valore sta nei dettagli: mapping dei permessi, orari dei job per non saturare le API, notifiche su canali che qualcuno effettivamente legge.

7. Errori comuni (e facili da evitare)

Un errore frequente è confondere retention con backup. Tenere le email “per sempre” nel tenant non equivale ad avere una copia isolata e immutabile. Un secondo è concentrarsi solo sui file: chat, ticket, wiki e CRM contengono decisioni e prove di fatto. Un terzo è delegare tutto al fornitore SaaS senza leggere le clausole di responsabilità, che spesso escludono la perdita di dati dovuta a configurazioni o azioni dell’utente.

Un altro abbaglio è fissare RPO/RTO irrealistici. “Zero” suona bene in riunione, ma se poi il restore di 5 TB richiede 12 ore di API throttling, la realtà tende a vincere. Meglio numeri sostenibili e verificati che promesse che saltano al primo test. Infine, ignorare l’immutabilità: senza WORM o Object Lock, un ransomware con token amministrativo può arrivare a cancellare anche le copie.

C’è anche un risvolto positivo che spesso si sottovaluta. Un backup ben fatto può accelerare migrazioni ed exit plan: ripristinare un sottoinsieme in un ambiente di prova ti permette di valutare alternative senza chiedere favori al vendor. Lo stesso principio vale quando introduci l’AI: una enclave AI portabile che tiene i dati in casa può essere il complemento naturale di un backup indipendente. È un vantaggio competitivo sottile ma concreto: scegli in base ai tuoi test, non alle demo dei fornitori.

8. Documentare senza burocrazia

Non serve un malloppo. Bastano documenti vivi: una pagina che elenca i SaaS coperti, RPO/RTO, storage usato, chiavi e custodi, procedura di restore test e risultati trimestrali con screenshot e tempi. Allega le evidenze dei job riusciti e dei test. È in genere quello che clienti e auditor vogliono vedere: non parole, ma ripristini riusciti.

Collega il piano di backup al registro dei trattamenti e alle DPIA dove rilevante, annotando che il ripristino serve a limitare l’impatto su diritti e libertà degli interessati in caso di incidente. È coerente con lo spirito dell’art. 32 del GDPR: capacità di ripristino tempestivo, con misure adeguate al rischio.

9. Indipendenza, non ideologia

Fare backup dei SaaS non significa “uscire dal cloud”. Significa non delegare all’ottimismo la continuità operativa. Una PMI può di solito permettersi un piano serio, indipendente e in regola senza stravolgere gli strumenti che la fanno correre. La metrica che conta non è quanti loghi compaiono nelle slide, ma in quante ore puoi tornare a fatturare dopo un disastro.

Il giorno in cui servirà, la differenza tra un cestino e un backup immutabile difficilmente è un dettaglio tecnico: è spesso la linea che separa un imprevisto gestibile da una crisi d’impresa. Meglio tracciarla adesso, con scelte sobrie e contratti chiari, che disegnarla la notte di un sabato davanti a un form di supporto.