Uscita dai servizi cloud: restituzione, cancellazione e portabilità dei dati

Uscita pianificata invece che affrettata

Chi abbandona un servizio cloud non si libera dai propri obblighi: secondo le linee guida dell’IFPDP sull’elaborazione dei dati nel cloud, il fornitore agisce generalmente come incaricato del trattamento ai sensi dell’art. 9 LPD, mentre il cliente rimane il responsabile. Egli deve garantire che le elaborazioni effettuate per suo conto siano conformi alla protezione dei dati e che i diritti delle persone interessate non vengano compromessi dall’esternalizzazione. L’uscita è quindi un progetto a sé stante con una propria pianificazione temporale, non una disdetta da gestire in un secondo momento.

Da questa ripartizione dei ruoli deriva ciò che deve essere recuperato: non solo i dati caricati autonomamente, ma tutto quanto è stato elaborato per conto terzi, inclusi i dati presso i sub-incaricati. L’IFPDP cita come tipici utilizzi del cloud la collaborazione online come Office 365, gli strumenti di gestione online per indirizzi e-mail nelle newsletter o nell’assistenza clienti, i sistemi CRM online, il caricamento di video su piattaforme di streaming e l’archiviazione di file su server accessibili via Internet.

Pianificate a ritroso a partire dalle scadenze contrattuali: i termini di preavviso e la fine del contratto determinano quanto tempo resta per l’esportazione, la verifica e le consegne successive. Per ogni fase del periodo di transizione va stabilito chi è responsabile: il reparto specialistico per la completezza tecnica, l’IT per l’esportazione e l’importazione, la consulenza sulla protezione dei dati per la valutazione, la direzione aziendale per la firma del contratto.

Va inoltre definito entro quando devono pervenire le singole promesse del fornitore. Senza questo ordine, gli accessi durante la fase di transizione avvengono senza che nessuno verifichi i dati in entrata.

Le basi giuridiche rilevanti sono la LPD del 25 settembre 2020 (RS 235.1) e, ove applicabile, il RGPD. L’art. 9 LPD regola l’elaborazione per conto terzi; le persone interessate hanno diritto, secondo il diritto applicabile, all’informazione, alla cancellazione e alla limitazione del trattamento. Questi diritti devono essere soddisfatti fino alla confermata cancellazione.

Basi giuridiche e livello decisionale nella protezione dei dati svizzera

Sapere quali dati si trovano effettivamente nel cloud

Create un inventario per ogni servizio, distinguendo per categorie di dati e gruppi di persone interessate. Come orientamento possono servire le categorie presenti nelle informative sulla privacy: dati anagrafici e di contatto, dati dei contenuti, dati contrattuali, dati di utilizzo, dati meta, di comunicazione e procedurali nonché dati di registro. Tipicamente sono coinvolti utenti, dipendenti, clienti, partner di comunicazione nonché partner commerciali e contrattuali. Chi non compila queste due dimensioni non saprà alla fine se la restituzione è completa.

Per ogni categoria, registrate la sede di archiviazione e tutti i soggetti coinvolti: sistema primario, indici di analisi e ricerca, allegati nei dati di supporto e ticket, ambienti di test e demo nonché copie di backup. L’IFPDP indica come punti centrali di ogni utilizzo del cloud il ricorso a incaricati e sub-incaricati, la sicurezza dell’elaborazione dei dati e la trasmissione di dati personali verso paesi terzi: questi tre punti devono far parte del censimento. Annotate quale sub-incaricato opera per quale categoria; la sua cancellazione non avviene automaticamente con quella presso il fornitore principale.

Integrate per ogni servizio la possibilità di esportazione: esiste un’esportazione completa e leggibile da macchina o solo visualizzazioni a schermo e stampe singole? Quali campi, allegati e metadati contiene e con quale frequenza può essere generata? Il risultato è una tabella con servizio, categoria di dati, gruppo di interessati, sede di archiviazione, sub-incaricato coinvolto, formato di esportazione e responsabilità. Senza questa panoramica, ogni richiesta di restituzione rimane incompleta, poiché non è possibile un confronto tra quanto dovuto e quanto effettivamente presente.

Registrate per ogni servizio il formato di esportazione: CSV, JSON e XML sono formati aperti e leggibili da macchina; Parquet è un formato di file aperto orientato alle colonne per grandi volumi di dati. Esigete il riempimento completo dei campi e i metadati, non solo visualizzazioni in PDF. Il formato va inserito nella tabella accanto alla possibilità di esportazione e alla responsabilità.

Regolare restituzione e cancellazione prima della disdetta

Fissate per iscritto e prima della disdetta le modalità di restituzione e cancellazione; una promessa fatta dopo la disdetta è più difficile da far valere. Da regolamentare sono: il formato della consegna (leggibile da macchina e completo, inclusi metadati, allegati e collegamenti), l’ambito preciso (categorie di dati, periodo temporale, sub-incaricati), il termine per la consegna, i diritti di accesso durante la fase di transizione nonché i costi della restituzione. L’IFPDP richiede all’utente del cloud di accertarsi e di tutelarsi contrattualmente del rispetto dei requisiti per un’elaborazione per conto terzi ai sensi dell’art. 9 LPD; la clausola di restituzione e cancellazione ne fa parte.

La cancellazione deve includere quattro indicazioni: entro quando si procede alla cancellazione dopo il completamento della restituzione; quali dati sono interessati (dati di produzione, copie di backup, dati di registro, copie intermedie e di test); entro quando deve pervenire una conferma scritta; e il fatto che i sub-incaricati siano espressamente inclusi. Stabilite anche chi, dal lato del cliente, verifica la restituzione, secondo quali criteri e entro quale termine vengono segnalati i difetti, nonché i nomi delle persone di contatto di entrambe le parti per le consegne successive.

Chiarite prima della conclusione se l’utilizzo era o è ancora collegato a una comunicazione di dati all’estero. L’IFPDP sottolinea che prima della comunicazione all’estero va verificato se essa soddisfi i requisiti legali. Questa verifica vale fino alla cancellazione definitiva, non solo per l’esercizio: finché i dati si trovano presso il fornitore o i suoi sub-incaricati, la comunicazione prosegue.

Restituzione dei dati: cosa arriva effettivamente

Verificate i dati consegnati in tre passaggi. Primo, completezza: il numero di record e di file e il periodo coperto corrispondono al censimento? Sono incluse tutte le categorie di dati e i gruppi di persone interessate? Secondo, leggibilità: il formato può essere aperto senza software aggiuntivo? La codifica dei caratteri, i formati di data e numero e i fusi orari sono coerenti? Terzo, assegnazione: metadati, allegati e collegamenti sono conservati in modo che ogni record possa essere attribuito alla corretta persona interessata?

Fornite la prova tramite campionamenti e un test di importazione: inserite record selezionati nel sistema di destinazione e confrontateli lì con l’originale. Un tale test rivela perdite di campi, relazioni mancanti e allegati non trasferiti in modo più affidabile rispetto a un controllo visivo del file di esportazione. Documentate per ogni categoria di dati cosa è stato acquisito e cosa manca.

In caso di restituzione incompleta o tardiva: segnalate i difetti per iscritto facendo riferimento al termine concordato e all’ambito pattuito, esigete una consegna successiva con una nuova scadenza e terminate la fase di transizione solo dopo aver verificato la consegna supplementare. Se la restituzione si ritarda, le richieste delle persone interessate devono comunque poter essere evase. Secondo il diritto applicabile in materia di protezione dei dati – in Svizzera la LPD del 25 settembre 2020 (RS 235.1), integrata ove applicabile dal RGPD – gli interessati hanno diritti come l’informazione, la cancellazione e la limitazione del trattamento; finché tali richieste possono pervenire, è necessario l’accesso ai dati non ancora restituiti.

Verificate il formato: CSV, JSON, XML e Parquet sono formati aperti. I file Parquet contengono uno schema esplicito e metadati sui tipi di dati; ciò consente di verificare automaticamente i tipi di campo e la completezza.

Formati aperti vs proprietari per l’esportazione dei dati

Cancellazione che raggiunge anche le copie di backup

Un concetto di cancellazione elenca ogni luogo in cui si trovano i dati del servizio e assegna a ogni luogo un termine di cancellazione e un ente responsabile: database di produzione, indici di ricerca e analisi, allegati nei dati di supporto e ticket, copie intermedie e di test, file di esportazione lato cliente nonché copie di backup. È decisivo che i sub-incaricati siano elencati singolarmente; la loro cancellazione non segue automaticamente quella presso il fornitore principale.

Le copie di backup e i dati di registro richiedono un’analisi separata. Per le copie di backup, il termine di cancellazione può differire da quello dei dati di produzione, poiché le copie vengono sovrascritte solo con il successivo ciclo di backup; va quindi stabilito entro quando i dati sono effettivamente eliminati, e non solo da quando non sono più utilizzati attivamente. I dati di registro vanno trattati separatamente: possono rimanere conservati più a lungo per motivi di tracciabilità o a causa di propri obblighi di conservazione; ciò deve essere espresso esplicitamente nel concetto di cancellazione.

Esigete una conferma scritta di cancellazione con data, categorie di dati registrate e sub-incaricati coinvolti. Finché manca, la responsabilità resta al cliente: egli risponde come responsabile della conformità alla protezione dei dati dell’elaborazione – anche per le elaborazioni effettuate per conto terzi. Nel concetto, stabilite inoltre come gestire i dati che emergono durante la fase di transizione, ad esempio le segnalazioni di supporto relative ai dati esportati.

Portabilità: portare con sé i dati invece di copiarli soltanto

Chiarite prima dell’esportazione in quale formato i dati possono essere riutilizzati nel sistema di destinazione. Esigete formati aperti e leggibili da macchina e il riempimento completo dei campi; chiarite la gestione delle relazioni e degli ID oggetto, degli allegati e dei file binari, nonché della codifica dei caratteri, del formato di data e del fuso orario. Una panoramica in PDF è un’informazione, ma non uno strumento di lavoro per il riutilizzo.

Testate la portabilità con un’importazione nel sistema di destinazione prima di confermare la disdetta: create una mappatura dei campi, confrontate i campi obbligatori del sistema di destinazione, documentate i campi non trasferibili e i valori standard. Il test mostra anche se il volume di dati può essere effettivamente trasferito nel tempo previsto – per grandi volumi, questo determina il calendario.

Distinguete la portabilità del servizio dal diritto delle persone interessate ai propri dati. Secondo il diritto applicabile, gli interessati hanno diritto all’informazione, alla cancellazione e alla limitazione del trattamento; l’informativa sulla privacy di un servizio ne dà conto. Il responsabile deve poter soddisfare questi diritti anche dopo l’uscita. L’esportazione tecnica del fornitore non copre questo aspetto: essa comprende generalmente l’intero patrimonio dati, mentre una richiesta riguarda solo i dati di una persona interessata – per questo serve, dopo l’uscita, un archivio proprio ricercabile nel sistema di destinazione.

La portabilità cloud significa spostare applicazioni, dati e carichi di lavoro senza un ampio nuovo sviluppo e senza perdita di dati da un ambiente cloud a un altro. Ciò include formati di dati aperti come JSON, XML e CSV nonché API aperte.

Controllate le interfacce: API aperte come REST o GraphQL invece di endpoint proprietari; autenticazione tramite standard come OAuth, SAML o OpenID. Le applicazioni containerizzate con Docker o Kubernetes facilitano lo spostamento.

Per grandi volumi di dati è adatto il formato aperto orientato alle colonne Parquet, che porta con sé schema e metadati. Chiarite prima dell’esportazione se il sistema di destinazione può elaborare CSV, JSON, XML o Parquet.

Cifratura e chiavi sotto il proprio controllo

La Conferenza svizzera delle responsabili e dei responsabili della protezione dei dati (Privatim) stabilisce nella sua risoluzione sull’esternalizzazione dell’elaborazione dei dati nel cloud: per gli organismi pubblici l’utilizzo di soluzioni SaaS di fornitori internazionali è ammesso solo se i dati personali particolarmente sensibili vengono cifrati dall’organismo stesso. Lo stesso vale per i dati personali soggetti a un obbligo legale di segretezza. Il fornitore cloud non deve avere accesso alla chiave.

La risoluzione è stata adottata il 18 novembre 2025 e pubblicata il 24 novembre 2025.

Nella pratica, questo requisito incontra limiti. Secondo la risoluzione, per la maggior parte dei servizi cloud non è possibile un utilizzo sensato con cifratura end-to-end. Per i servizi che possono essere utilizzati in modo sensato con una cifratura end-to-end continua, spesso non è possibile impedire al fornitore qualsiasi accesso alle chiavi degli utenti. Per i servizi internazionali come Amazon Web Services (AWS), Google o Microsoft 365, agli organismi pubblici rimane essenzialmente solo l’utilizzo come puro spazio di archiviazione online.

Per l’uscita ne consegue: chiarite prima della restituzione quali dati sono archiviati in forma cifrata, chi detiene le chiavi e in quale forma i dati vengono consegnati – cifrati con materiale chiave fornito o decifrati tramite un canale sicuro. Salvate e verificate le chiavi prima dell’ultimo accesso al servizio; senza chiavi, i dati recuperati non sono più utilizzabili. Stabilite inoltre chi in azienda ha accesso alle chiavi e cosa accade in caso di smarrimento o cambio della persona responsabile delle chiavi.

Perché una sede del server in Europa non basta

L’IFPDP sottolinea che, nell’utilizzo dei servizi cloud, prima di una comunicazione di dati all’estero va verificato se essa soddisfi i requisiti legali. Questa verifica fa parte tanto dell’uscita quanto dell’ingresso: riguarda tutti i dati che, fino alla confermata cancellazione, si trovano ancora presso il fornitore o i suoi sub-incaricati.

Una sede del server in Europa non basta a tal fine. Un contributo specialistico sulla sicurezza cloud in Svizzera riporta nel titolo l’affermazione «Cloud in Europa: nessuna protezione dall’accesso USA» e sottolinea che la sicurezza cloud in Svizzera significa più di una semplice sede europea del server. Per l’uscita ciò significa: ottenere per iscritto le indicazioni sulla comunicazione dei dati – sede e società madre del fornitore, sede dei sub-incaricati, luogo dell’elaborazione, base giuridica della comunicazione – e non dedurle dalla sede del server.

Per gli organismi pubblici l’asticella è più alta, perché la maggior parte dei loro dati è soggetta al segreto d’ufficio e quindi a un obbligo legale di segretezza. La risoluzione di Privatim stabilisce che gli organismi pubblici possono esternalizzare l’elaborazione a terzi, ma devono garantire che la protezione dei dati e la sicurezza dell’informazione siano preservate; per i dati personali particolarmente sensibili o soggetti a un obbligo legale di segretezza, essa richiede la cifratura da parte dell’organismo stesso. All’uscita va quindi documentato dove si trovano i dati fino alla cancellazione e quali possibilità di accesso di terzi esistono in questo periodo.

Vantaggi e rischi della sede del server in Europa

Documentare l’offboarding

Al termine dovrebbero essere disponibili i seguenti documenti: verbale di restituzione con data, categorie di dati consegnate, formati e supporti dati, nonché annotazione di verifica con campionamenti, test di importazione ed eventuali difetti con relative consegne successive.

Dovrebbero inoltre essere presenti una conferma scritta di cancellazione con data e ambito, la conferma che i sub-incaricati sono stati inclusi e la prova del salvataggio e della custodia delle chiavi di cifratura. Senza queste prove, in seguito non sarà possibile dimostrare né alle persone interessate né a un’autorità di vigilanza quando e quali dati sono stati recuperati e cancellati.

Adattate i registri interni: rimuovete o contrassegnate come conclusi il servizio e i sub-incaricati dal registro delle attività di trattamento o dal registro dei contratti, ridefinite i termini di conservazione e cancellazione per i dati recuperati e aggiornate i diritti di accesso nel sistema di destinazione. Eliminate account, chiavi API, token e utenti di servizio del servizio terminato; altrimenti rimangono attivi accessi che nessuno gestisce più.

Verificate infine la comunicazione esterna. Se il servizio è menzionato nell’informativa sulla privacy o in un elenco di fornitori e servizi utilizzati, la voce va adattata. Gli obblighi informativi e l’evasione delle richieste di informazione e cancellazione delle persone interessate continuano nel sistema di destinazione dopo l’uscita; stabilite chi ne è responsabile e come i dati recuperati possono essere ricercati.