Come funziona la residenza dei dati?
La residenza dei dati dipende dalle scelte di infrastruttura: in quale regione cloud fai il deployment, dove il tuo provider di database fa girare i suoi cluster, dove finiscono backup e repliche di lettura. È facile perderne traccia: un SaaS multi-tenant può replicare i record dei clienti su più regioni, e ogni sub-responsabile nella catena aggiunge un altro luogo possibile. Se non sai dire in quali paesi passano i tuoi dati, non conosci la tua residenza.
Il GDPR impone di conservare i dati nell’UE?
No. Il GDPR non impone che i dati personali restino nell’UE. Il capo V (articoli 44–50) regola i trasferimenti verso paesi terzi e prevede strade lecite: decisioni di adeguatezza, clausole contrattuali standard, norme vincolanti d’impresa. Al contrario, un server nell’UE non basta da solo a essere conformi: un provider la cui capogruppo risponde a leggi straniere sulla divulgazione dei dati può complicare il quadro anche con la residenza nell’UE. La residenza è una variabile nella valutazione GDPR, non il verdetto.
Come cambia la residenza dei dati con il self-hosting?
La trasforma da trattativa con un vendor a decisione di deployment. Quando gestisci tu la piattaforma, scegli il paese, il provider e dove vanno i backup: la residenza dei dati diventa una riga nella configurazione della tua infrastruttura. Quel controllo è una parte importante delle ragioni a favore del self-hosting nel quadro del GDPR e, più in generale, per possedere i dati dei tuoi clienti.
Perché la residenza dei dati conta per un piccolo team?
Perché gli acquirenti lo chiedono. Questionari di sicurezza, uffici acquisti enterprise e mercati attenti alla privacy vogliono tutti una risposta di una riga a “dove sono conservati i nostri dati?”. Un piccolo team che risponde con una regione precisa, invece di inoltrare un elenco di sub-responsabili, chiude quelle conversazioni più in fretta. Scegliere la residenza presto costa poco; migrare più avanti un database di produzione da una giurisdizione all’altra no.