Quando un’azienda sposta archivi, applicazioni o dati dei clienti nel cloud, la domanda decisiva non riguarda solo la sicurezza, ma anche il luogo in cui quei dati vengono conservati e trattati. La domanda è semplice ma tutt’altro che banale: usando il cloud computing sappiamo dove risiedono i dati? La risposta dipende dal servizio scelto, dalla configurazione e dagli impegni contrattuali del provider.
La posizione dei dati dipende da configurazione e contratto
- Il cloud non è un luogo unico: dati, backup, metadati e log possono trovarsi in aree differenti.
- La regione geografica va scelta e verificata servizio per servizio.
- La residenza dei dati non coincide con il GDPR: anche un accesso remoto dall’estero può rilevare come trasferimento.
- Backup e disaster recovery possono spostare copie fuori dall’Italia o dall’Unione europea.
- Contratto, DPA e documentazione tecnica sono indispensabili per dimostrare dove vengono trattati i dati.
Il cloud non ha un unico luogo fisico
Quando parliamo di “dati nel cloud”, immaginiamo spesso un archivio collocato in un punto preciso. In realtà il cloud è una rete di infrastrutture distribuite. Un file può essere conservato in una regione cloud, replicato in una seconda area per garantire continuità operativa e accompagnato da metadati e log gestiti da servizi diversi.
La regione indica un’area geografica composta da uno o più data center. Le availability zone, invece, sono strutture separate all’interno della stessa regione, progettate per ridurre il rischio di fermo. La scelta di una regione italiana può quindi limitare la posizione principale dei dati, ma non garantisce automaticamente che ogni componente della piattaforma resti in Italia.
Dati principali, backup e metadati
Io distinguo sempre almeno quattro categorie prima di valutare un servizio cloud. La prima è il dato principale, per esempio il database dei clienti. Poi ci sono backup, copie di emergenza e snapshot, cioè immagini temporanee usate per ripristinare un sistema.
A queste si aggiungono i metadati, come nome dell’account, informazioni di fatturazione, identificativi delle risorse e dati sull’utilizzo del servizio. Infine troviamo i log, che registrano accessi, errori e attività amministrative. Questi elementi possono seguire regole di localizzazione diverse rispetto al contenuto principale.
| Elemento | Cosa verificare | Perché conta |
|---|---|---|
| Dati archiviati | Regione di storage e modalità di replica | Determina dove si trova il contenuto principale |
| Backup e snapshot | Area di conservazione e durata | Una copia può finire in una geografia diversa |
| Metadati | Paese e servizio che li gestisce | Possono contenere informazioni personali o aziendali |
| Log e monitoraggio | Regione del servizio e accessi del supporto | Documentano attività e possibili trasferimenti |
Un errore frequente consiste nel leggere “data center in Italia” e considerare chiusa la verifica. La mia esperienza è diversa: la localizzazione va controllata sull’intera catena tecnica, non soltanto sulla pagina commerciale del provider.
Residenza dei dati e GDPR sono due domande diverse
La residenza dei dati risponde a una domanda geografica: dove vengono conservati o elaborati? Il GDPR risponde invece a una domanda giuridica: con quali garanzie vengono trattati i dati personali? Le due questioni sono collegate, ma non coincidono.
Il GDPR non impone in generale che i dati personali di cittadini italiani rimangano in Italia. All’interno dello Spazio economico europeo il trasferimento è normalmente possibile, purché siano rispettati gli altri obblighi sulla protezione dei dati. La situazione diventa più delicata quando dati o accessi coinvolgono Paesi fuori dallo Spazio economico europeo.
Il ruolo del titolare e del responsabile
L’azienda che decide finalità e modalità del trattamento è normalmente il titolare del trattamento. Il cloud provider agisce spesso come responsabile, perché tratta i dati per conto dell’azienda e secondo le sue istruzioni.
Il rapporto deve essere regolato da un Data Processing Agreement, o DPA. Questo documento dovrebbe chiarire subfornitori, aree geografiche, misure di sicurezza, gestione degli incidenti, cancellazione dei dati e procedure per eventuali trasferimenti internazionali.
Non basta sapere che il provider ha sede in Europa. Una società europea può utilizzare subprocessor, cioè fornitori tecnici incaricati di svolgere specifiche attività, in altri Paesi. Per questo controllo sempre l’elenco dei subfornitori e le relative localizzazioni.
Accesso remoto e trasferimenti internazionali
Un dato può rimanere fisicamente in Italia e tuttavia essere consultato da personale tecnico situato negli Stati Uniti o in un altro Paese. In determinati casi anche questo accesso può rientrare nella disciplina dei trasferimenti internazionali, soprattutto se il contenuto è leggibile.
La Commissione europea prevede strumenti come decisioni di adeguatezza e clausole contrattuali standard. L’EDPB, il Comitato europeo per la protezione dei dati, richiama inoltre l’attenzione sulle misure supplementari, tra cui cifratura, controllo degli accessi e valutazione delle leggi del Paese destinatario.
La cifratura aiuta molto, ma non risolve ogni problema. Se il provider deve possedere o gestire le chiavi per leggere i dati, il livello di protezione è diverso rispetto a una soluzione con chiavi sotto il controllo del cliente.
Come verificare davvero dove risiedono i dati
Per ottenere una risposta affidabile non servono supposizioni, ma una verifica ordinata. Io partirei da un inventario semplice, perché spesso il problema non è il provider principale, bensì un servizio secondario attivato senza esaminarne la geografia.
- Classifica i dati in personali, sensibili, aziendali riservati e non personali.
- Mappa i servizi utilizzati, distinguendo database, storage, posta, analisi, backup, sicurezza e supporto.
- Individua la regione effettiva di ogni servizio e controlla se esistono repliche automatiche.
- Leggi DPA e condizioni contrattuali, verificando subprocessor, trasferimenti e accessi del personale.
- Configura i limiti geografici disponibili, come policy che impediscono la creazione di risorse fuori da determinate aree.
- Conserva le prove con configurazioni, report, registri degli accessi e documentazione aggiornata.
La parte più sottovalutata è la configurazione. Una regione selezionata nel database non impedisce necessariamente a un sistema di analisi, a un servizio di logging o a un backup gestito separatamente di usare un’altra area. La verifica deve essere servizio per servizio, anche quando tutti appartengono allo stesso fornitore.
Leggi anche: Categorie particolari di dati personali - guida pratica al GDPR
Le domande da fare al provider
- I dati vengono conservati in Italia, nell’Unione europea o in una macro-area più ampia?
- Dove vengono archiviati backup, snapshot e copie per il disaster recovery?
- I metadati e i log seguono la stessa regola del contenuto principale?
- Quali subprocessor possono accedere ai dati?
- Il supporto tecnico può accedere ai dati in chiaro?
- Quali garanzie si applicano se avviene un trasferimento fuori dallo Spazio economico europeo?
- È possibile scegliere chi gestisce le chiavi di cifratura?
Se il provider risponde soltanto con formule generiche come “i dati sono protetti” o “l’infrastruttura è globale”, per me è un segnale di documentazione insufficiente. Sicurezza e localizzazione sono aspetti distinti: un sistema può essere molto sicuro e allo stesso tempo non rispettare il requisito geografico richiesto dall’azienda.
Italia, Europa o più regioni quale scelta ha senso
La scelta della geografia non è solo legale. Incide su latenza, disponibilità, costi, continuità operativa e libertà di progettazione. Cercare sempre la regione più vicina può sembrare prudente, ma una singola area non offre automaticamente la migliore resilienza.
| Modello | Vantaggio principale | Limite da considerare | Adatto a |
|---|---|---|---|
| Una regione italiana | Maggiore semplicità nella gestione della residenza | Rischio di dipendere da una sola area geografica | Dati ordinari e applicazioni con requisiti nazionali |
| Più regioni nell’UE | Buon equilibrio tra resilienza e controllo normativo | Possibili costi e complessità aggiuntive | Servizi critici e aziende con piano di continuità |
| Multi-region globale | Disponibilità elevata e bassa latenza internazionale | Maggiore difficoltà nel controllare trasferimenti e repliche | Applicazioni realmente globali |
| Cloud qualificato o sovrano | Controllo più stretto su gestione e giurisdizione | Offerta e flessibilità potenzialmente più limitate | Pubblica amministrazione e settori regolamentati |
Alcuni grandi provider rendono disponibili regioni italiane, come l’area di Milano, ma la presenza di una regione non significa che ogni servizio del catalogo abbia la stessa disponibilità. Per questo verifico sempre il singolo prodotto cloud, non soltanto l’elenco generale dei data center.
Per molte piccole e medie imprese italiane, una configurazione distribuita in due regioni dell’Unione europea può essere un compromesso ragionevole. Se invece un contratto impone che i dati restino in Italia, il disaster recovery dovrà essere progettato entro quel perimetro, accettando eventualmente costi più alti o una resilienza diversa.
Gli errori che fanno perdere il controllo
Il primo errore è confondere la sede legale del provider con il luogo del trattamento. Una società italiana può usare infrastrutture internazionali, mentre un provider statunitense può offrire regioni fisiche in Europa. La giurisdizione societaria e la posizione dei server non sono la stessa cosa.
Il secondo errore consiste nell’attivare backup automatici senza controllarne la destinazione. Una policy di continuità può replicare i dati in un’altra regione per proteggerli da guasti, ma quella stessa replica può creare un problema di conformità o di contratto.
Un altro punto critico riguarda i servizi SaaS, come piattaforme di collaborazione, CRM e strumenti di analisi. In questi casi l’utente spesso non sceglie direttamente l’architettura. Occorre quindi controllare data location card, DPA, subprocessor e opzioni di residenza prima di caricare informazioni personali o riservate.
Infine, molte aziende documentano la configurazione una sola volta e poi la dimenticano. Nuove funzioni, aggiornamenti del provider o modifiche al piano tariffario possono cambiare regioni disponibili, servizi collegati e modalità di supporto. Una revisione almeno annuale è una misura semplice e realistica.
La verifica finale prima di affidare dati al cloud
Prima di approvare un nuovo servizio, io cerco una risposta scritta a tre domande. Dove sono i dati principali? Dove finiscono copie, log e metadati? Quali soggetti, da quali Paesi, possono accedervi?
Se le risposte sono precise, coerenti tra documentazione tecnica e contratto, e sostenute da configurazioni verificabili, il cloud può offrire un controllo migliore di molte infrastrutture locali. Se invece la localizzazione resta vaga, è prudente ridurre i dati condivisi, cifrarli con chiavi proprie o scegliere un servizio con impegni geografici più chiari.
Il punto non è ottenere una promessa generica di “cloud europeo”, ma costruire un perimetro misurabile. Solo così sappiamo davvero dove risiedono i dati, chi li può trattare e quali garanzie restano valide quando l’architettura diventa distribuita.
