Guida gestione backup in cloud per la conformità ISO
Per dimostrare conformità a ISO 27001, ISO 27017 e ISO 27018 serve una backup policy‑driven: scoping documentato, RPO e RTO definiti, backup indipendenti dal sistema di origine, cifratura, immutabilità e soprattutto prove di restore verificate. Non basta che i backup esistano: l’auditor verifica che siano ripristinabili, e lo fa cercando registri di test, non dichiarazioni d’intenti.
Il controllo di riferimento è ISO 27001 A.8.13, che richiede backup mantenuti e testati secondo una policy concordata. A questo si aggiunge ISO 27017, con la clausola tecnica 12.3 dedicata proprio ai servizi cloud, e ISO 27018 quando i backup contengono dati personali. Le evidenze minime da preparare per l’audit sono:
- Backup policy formalizzata, con scope, retention e ruoli assegnati.
- Job log dei backup, completi di esiti e anomalie.
- Report dei test di restore, con date, durata e risultato.
- Configurazioni di cifratura, gestione chiavi e immutabilità.
- Contratti o allegati tecnici del fornitore cloud (CSP) che specificano backup, retention e diritti di audit.
Un consiglio: non aspettare l’audit per raccogliere queste prove. Costruisci fin da subito un archivio strutturato dove ogni test di restore genera automaticamente un record: è la differenza tra un’evidenza credibile e una ricostruita a memoria la sera prima della verifica.
Punti chiave
La conformità dei backup cloud a ISO 27001, ISO 27017 e ISO 27018 dipende da policy documentate, controlli tecnici verificabili e test di restore ripetuti nel tempo.
| Punto | Dettagli |
|---|---|
| Policy come base | Scrivere una backup policy con scope, RPO/RTO, retention e ruoli chiaramente assegnati. |
| Test di restore regolari | Programmare test regolari sui sistemi critici e documentare ogni esito. |
| Clausole con il CSP | Richiedere al fornitore cloud specifiche su scope, retention, localizzazione e diritti di audit. |
| Evidenze organizzate | Archiviare policy, job log, report di test e contratti per controllo ISO, non per sistema. |
| Supporto specializzato | Security Hub assiste nella gap analysis, nella documentazione e nella preparazione dei test di restore per la certificazione. |
Indice
- Mappatura pratica dei controlli ISO rilevanti per i backup cloud
- Policy e governance per i backup cloud dentro l’ISMS
- Come valutare il rischio dei backup cloud e fissare i criteri di accettazione
- Gestione dei fornitori cloud: quali clausole contrattuali richiedere
- Quali controlli tecnici documentare per cifratura, chiavi e integrità
- Come organizzare i test di restore e la verifica di integrità
- Cosa mostrare all’auditor: l’inventario delle evidenze
- Ruoli, separazione dei compiti e formazione per chi gestisce i backup
- Quali non conformità trovano più spesso gli auditor nei backup cloud
- Checklist operativa per implementare la conformità
- Osservazioni pratiche di Security Hub su implementazione e priorità per le PMI
- Come Security Hub può supportare l’implementazione e la certificazione
- Fonti
Mappatura pratica dei controlli ISO rilevanti per i backup cloud
I tre standard non si sovrappongono per caso: ISO 27001 stabilisce l’obbligo generale, ISO 27017 lo declina per il cloud e ISO 27018 aggiunge tutele quando sono coinvolti dati personali. Capire dove finisce l’uno e inizia l’altro evita sia i buchi di conformità sia la duplicazione inutile di documentazione.
| Controllo | Requisito principale | Artefatto di prova atteso |
|---|---|---|
| ISO 27001 A.8.13 | Backup mantenuti e testati secondo policy | Policy firmata, job log, report di test restore |
| ISO 27017 CLD 12.3.1 | Il provider cloud deve specificare scope, schedule, metodi e retention dei backup | Documento tecnico o allegato contrattuale del CSP |
| ISO 27017 (responsabilità condivisa) | Asset e responsabilità di backup inventariati e assegnati | Matrice di responsabilità cliente/CSP |
| ISO 27018 (quando applicabile) | Tutele aggiuntive per backup contenenti dati personali | Registro trattamenti, clausole su localizzazione e cancellazione |
La sovrapposizione più frequente riguarda proprio A.8.13 e il controllo 12.3.1 di ISO 27017: il primo chiede alla tua organizzazione di testare i backup, il secondo obbliga il fornitore a darti le informazioni tecniche necessarie per farlo. Senza quelle specifiche, il test di restore diventa un esercizio alla cieca.
ISO 27018 entra in gioco solo quando il backup include dati personali, tipico per ambienti SaaS con dati di clienti o dipendenti. In quel caso servono clausole aggiuntive su localizzazione geografica, tempi di cancellazione e limiti al trattamento da parte di subprocessor. Puoi approfondire le differenze pratiche tra i due standard nella guida sulla differenza tra ISO 27017 e 27018.
Policy e governance per i backup cloud dentro l’ISMS
La backup policy è il documento che l’auditor legge per primo, e spesso l’unico che legge davvero con attenzione. Deve rispondere a domande precise, non contenere principi generici copiati da un modello online.
Gli elementi obbligatori includono:
- Scopo e ambito di applicazione, con elenco esplicito di ambienti SaaS, IaaS e PaaS coperti.
- RPO e RTO definiti per ciascuna categoria di dati critici.
- Ruoli e responsabilità, incluso chi approva le eccezioni.
- Periodi di retention differenziati per tipo di dato e obbligo normativo.
- Procedure di cancellazione sicura al termine della retention.
La revisione 2022 di ISO 27001 ha reso esplicito che i servizi cloud fanno parte dello scope dell’ISMS, e che le piattaforme SaaS non possono restare fuori dalla policy solo perché “gestite dal fornitore”. Le organizzazioni devono dimostrare che i backup SaaS, IaaS e PaaS sono indipendenti e testati, non semplicemente presenti.
Un esempio concreto: se usi un CRM SaaS, la policy deve specificare se il backup è quello nativo del fornitore o un’esportazione periodica gestita internamente, e chi verifica che quell’esportazione funzioni. La guida passo passo per estendere l’ISMS al cloud approfondisce come strutturare questa parte della policy.
Un consiglio: evita policy che dicono “i backup vengono eseguiti regolarmente”. Un auditor competente chiede: quanto regolarmente, testati quando, da chi approvati. Scrivi numeri, non aggettivi.
Come valutare il rischio dei backup cloud e fissare i criteri di accettazione
La valutazione del rischio sui backup cloud deve partire dalle minacce reali, non da un elenco teorico. Le più frequenti riguardano perdita di integrità dei dati, cancellazione accidentale da parte di un operatore, attacchi ransomware che cifrano anche le copie di backup, indisponibilità regionale del provider ed esposizione di dati personali durante il ripristino.
Per ogni minaccia va definita una metrica operativa:
- RPO (Recovery Point Objective): quanta perdita di dati è accettabile in caso di incidente.
- RTO (Recovery Time Objective): quanto tempo può passare prima del ripristino completo.
- Soglie di rischio accettabile, documentate nel risk register con relativa giustificazione.
- Criteri di riesame periodico, legati a cambi di fornitore o architettura.
Il collegamento tra questi esiti e la selezione dei controlli è diretto: se il risk assessment indica che il ransomware è una minaccia rilevante, la mitigazione naturale è l’immutabilità dei backup, non solo la cifratura. Se il rischio riguarda l’indisponibilità regionale, serve una replica geografica indipendente dal data center primario del CSP.
Un consiglio: fissa RPO e RTO prima di parlare con il fornitore cloud, non dopo. Se lasci che sia il contratto standard del CSP a definire questi valori, probabilmente non rifletteranno il rischio reale della tua organizzazione.
Gestione dei fornitori cloud: quali clausole contrattuali richiedere
Il rapporto con il fornitore cloud (CSP) è il punto dove la maggior parte delle organizzazioni perde punti in audit. Non basta un contratto generico di servizio: servono clausole specifiche sui backup, altrimenti la responsabilità condivisa diventa un’area grigia che nessuno controlla davvero.
Le clausole minime da richiedere riguardano scope e schedule dei backup, localizzazione geografica delle copie, procedure di restore documentate, un piano di test periodico, diritti di audit su subprocessor e dettagli su cifratura e gestione delle chiavi. Il testo tecnico di ISO 27017 elenca proprio questi elementi come informazioni che il provider dovrebbe fornire al cliente per evitare ambiguità sulla responsabilità.
| Richiesta contrattuale | Documento o prova da ottenere |
|---|---|
| Scope e frequenza dei backup | Specifica tecnica del servizio (SLA o allegato) |
| Localizzazione delle copie | Dichiarazione data residency del CSP |
| Procedura e test di restore | Report periodico di restore test condiviso dal fornitore |
| Diritti di audit e subprocessor | Elenco subprocessor e clausola di audit nel contratto |
| Cifratura e gestione chiavi | Attestazione tecnica o certificazione (es. SOC 2, ISO 27017) |
Chiedi report periodici, non solo dichiarazioni al momento della firma. Un fornitore serio fornisce aggiornamenti regolari su test di restore ed eventuali incidenti, e questo materiale diventa parte della tua evidenza di audit senza sforzo aggiuntivo.
Quali controlli tecnici documentare per cifratura, chiavi e integrità
A livello tecnico, l’auditor non valuta la configurazione riga per riga, ma vuole vedere che i requisiti sono soddisfatti e documentati in modo coerente. Tre aree contano più delle altre.
Cifratura a riposo e in transito: bisogna dimostrare quali algoritmi sono in uso, che i dati in transito verso lo storage di backup siano protetti e che la cifratura a riposo copra sia le copie primarie sia quelle secondarie.
Key management: chi detiene le chiavi di cifratura è una domanda che l’auditor pone quasi sempre. Serve una policy di rotazione delle chiavi, separazione tra chi gestisce l’infrastruttura e chi controlla il KMS (Key Management System), ed evidenze esportabili come log di rotazione o report del sistema di gestione chiavi.
Integrità e versioning: gli snapshot immutabili e le funzionalità di object lock impediscono la cancellazione o modifica dei backup durante il periodo di retention, una difesa diretta contro il ransomware. Vanno accompagnati da logging delle modifiche e, dove possibile, firme digitali che attestino l’integrità del backup nel tempo.
Un consiglio: se il tuo fornitore cloud offre object lock o funzionalità equivalenti di immutabilità, attivale prima di scriverle nella policy. Una policy che promette immutabilità non ancora configurata è la non conformità più facile da individuare per un auditor.
Come organizzare i test di restore e la verifica di integrità
Un backup non testato è, ai fini della conformità, equivalente a un backup che non esiste. Questo è il punto su cui gli auditor insistono di più, perché la prova reale di resilienza è il test di restore documentato, non la semplice esecuzione dello job di backup.
Il piano di test dovrebbe includere una cadenza regolare, un ambiente isolato dove eseguire il ripristino senza toccare la produzione e uno scope che copra sia dati critici sia sistemi secondari a rotazione.
| Elemento del test | Cosa documentare |
|---|---|
| Cadenza | Trimestrale per sistemi critici, semestrale per sistemi secondari |
| Ambiente | Isolato dalla produzione, con accesso controllato |
| Verifica integrità | Checksum o hash comparato al punto di backup originale |
| Esito | Successo, errore, tempo impiegato, azioni correttive |
La gestione di retention e cancellazione richiede la stessa attenzione documentale: ogni ciclo di cancellazione dovrebbe generare un log che attesta cosa è stato eliminato, quando e secondo quale regola di retention. La guida con esempi di misure preventive ISO 27017 mostra alcune configurazioni pratiche applicabili a questa fase.
Cosa mostrare all’auditor: l’inventario delle evidenze
L’auditor lavora per campionamento: sceglie alcuni sistemi critici e chiede di vedere l’intera catena di prova, dalla policy al log del test più recente. Se l’inventario di evidenze è disorganizzato, anche un programma di backup tecnicamente solido rischia una non conformità procedurale.
Gli artefatti da tenere pronti sono:
- La backup policy approvata e la sua data di ultima revisione.
- I job log dei sistemi critici, con storicità di almeno un ciclo di audit.
- Le configurazioni KMS e le evidenze di rotazione chiavi.
- I report dei test di restore, con esiti e azioni correttive.
- I contratti CSP con gli allegati tecnici su backup e retention.
- I report di immutabilità o object lock, quando applicabili.
Un consiglio: automatizza l’esportazione dei job log e dei report di test in un archivio centralizzato con timestamp. Un registro firmato e generato automaticamente vale più, agli occhi di un auditor, di uno screenshot raccolto manualmente il giorno prima della verifica.
Aggiorna questo inventario con la stessa cadenza dei test di restore: se testi trimestralmente, l’archivio di evidenze va rivisto trimestralmente, non solo nei mesi che precedono l’audit di certificazione.
Ruoli, separazione dei compiti e formazione per chi gestisce i backup
La documentazione dei ruoli è spesso trascurata, ma è uno dei primi elementi che un auditor verifica quando valuta la maturità del sistema di gestione. Servono almeno cinque figure chiaramente distinte: il proprietario della policy, il proprietario del piano di ripristino, l’operatore che esegue i backup quotidiani, il responsabile che verifica le evidenze per l’audit e chi approva le eccezioni alla retention.
La separazione dei compiti (segregation of duties) è un principio semplice da enunciare e complesso da applicare: chi ha i permessi per cancellare o modificare la retention non dovrebbe essere la stessa persona che esegue i test di restore, altrimenti un errore o un abuso passerebbero inosservati.
Il piano di formazione dovrebbe coprire almeno la procedura di restore, la lettura dei job log e le regole di escalation in caso di errore. Ogni sessione formativa va registrata, con data, partecipanti e contenuti: questi registri sono prove dirette che l’auditor può chiedere per verificare la competenza operativa del personale coinvolto.
Quali non conformità trovano più spesso gli auditor nei backup cloud
Le non conformità più comuni non riguardano la tecnologia, ma la disciplina documentale. Restore mai testati restano l’errore più frequente: i backup vengono eseguiti regolarmente, ma nessuno verifica mai che il ripristino funzioni davvero.
Un secondo problema ricorrente è avere backup collegati allo stesso failure domain del sistema primario, per esempio nella stessa regione cloud o sullo stesso account, il che vanifica la protezione in caso di incidente su larga scala. Segue l’assenza di una policy specifica per gli ambienti SaaS, spesso esclusi perché “gestiti dal fornitore”, e la retention non documentata, con periodi di conservazione scelti in modo arbitrario e mai formalizzati.
I segnali di allarme da monitorare includono job log con errori ricorrenti mai risolti, contratti CSP privi di clausole sui backup e assenza di un responsabile identificabile per il ripristino.
Un consiglio: quando trovi una non conformità, documenta subito l’azione correttiva con data e responsabile. Un’organizzazione che mostra un ciclo di miglioramento continuo, anche con errori passati, viene valutata meglio di una che dichiara zero problemi senza prove a supporto.
Checklist operativa per implementare la conformità
Una sequenza chiara aiuta a non saltare passaggi critici durante l’implementazione. Il percorso tipico parte dalla policy, passa per l’implementazione tecnica, arriva ai test e si chiude con l’organizzazione delle evidenze.
- Redigere e approvare la backup policy con scope, RPO/RTO e retention.
- Mappare i controlli ISO 27001, ISO 27017 e, se pertinente, ISO 27018.
- Configurare cifratura, gestione chiavi e immutabilità sui sistemi critici.
- Ottenere dal CSP le specifiche tecniche su backup e retention.
- Eseguire il primo ciclo di test di restore e documentare l’esito.
- Archiviare tutte le evidenze in un formato accessibile per l’audit.
I modelli da popolare includono il template della backup policy, il modulo per registrare i test di restore, il registro dei job log e il modulo di valutazione dei fornitori cloud. La checklist per la certificazione ISO 27017 offre una struttura pronta per questi documenti, utile come punto di partenza piuttosto che come modello da copiare senza adattamento.
Un consiglio: organizza le evidenze per controllo ISO, non per sistema tecnico. In audit, chi cerca la prova per A.8.13 vuole trovarla in una cartella dedicata, non spulciare tra decine di configurazioni server per sistema.
Osservazioni pratiche di Security Hub su implementazione e priorità per le PMI
Le PMI che affrontano per la prima volta l’integrazione dei backup cloud nell’ISMS tendono a commettere lo stesso errore: cercano di replicare un programma da grande azienda, con dashboard sofisticate e cicli di test settimanali, prima ancora di avere una policy scritta bene. Il risultato è quasi sempre una struttura sovradimensionata rispetto alle risorse disponibili, che si sgretola al primo turnover di personale.
La priorità pragmatica per una PMI dovrebbe essere una policy minima ma completa, l’automazione dell’evidenza fin dal primo giorno e test di restore trimestrali su almeno i sistemi critici. Non serve investire subito in KMS esterni o soluzioni di immutabilità enterprise: quelle scelte hanno senso quando il volume di dati critici o il rischio normativo lo giustificano, non prima.
L’errore più ricorrente osservato riguarda proprio la sequenza inversa: aziende che acquistano strumenti avanzati di cifratura e gestione chiavi ma non hanno mai eseguito un test di restore documentato. In un audit, un test di restore ben tenuto vale più di una configurazione tecnica sofisticata mai verificata sul campo.
Come Security Hub può supportare l’implementazione e la certificazione
Molte organizzazioni arrivano a questo punto con la teoria chiara ma senza il tempo interno per tradurla in policy, evidenze e test verificabili. Security Hub affianca i responsabili della sicurezza e i team IT nella preparazione concreta della certificazione, con un vantaggio preciso rispetto al farlo internamente da zero: deliverable già strutturati e verificati, che riducono drasticamente il tempo necessario per arrivare pronti all’audit.
I servizi includono gap analysis rispetto a ISO 27001, ISO 27017 e ISO 27018, redazione della backup policy e della documentazione di supporto, automazione della raccolta delle evidenze e supporto diretto nella pianificazione dei test di restore. L’obiettivo è arrivare all’audit con un archivio di prove già organizzato, non da ricostruire sotto pressione.
Se la tua organizzazione deve integrare i backup cloud nell’ISMS in vista della certificazione, la pagina sui passaggi per ISO 27001 descrive il percorso di preparazione, mentre la sezione dedicata alla certificazione ISO 27001 permette di richiedere una consulenza diretta per valutare lo stato attuale della tua documentazione.
Fonti
Per chi vuole verificare direttamente i requisiti normativi citati, il testo ufficiale di ISO 27017 resta il riferimento primario per i controlli specifici del cloud, mentre l’analisi della ISO 27001:2022 sui requisiti cloud chiarisce come i servizi SaaS, IaaS e PaaS rientrino nello scope dell’ISMS.
Sul fronte tecnico, l’approfondimento su ISO 27001 A.8.13 spiega nel dettaglio le evidenze attese per policy e test di restore. Per la parte legata ai dati personali nei backup, la guida su come mantenere compliance ISO 27018 offre un percorso operativo specifico.
Chi cerca modelli e checklist pronti all’uso può partire dalla checklist per la certificazione ISO 27017 o dalla panoramica generale su ISO 27000 per responsabili IT, utile per collocare i controlli sui backup all’interno del framework più ampio.
- ISO/IEC 27017 (testo tecnico) — backup e responsabilità nel cloud
- ISO 27001:2022 Cloud Security Requirements Explained
Raccomandati
