C’è un equivoco che notiamo spesso in ambito trasferimenti dati: “Noi non trasferiamo dati fuori dall’Europa”. Poi apri la lista dei tool e trovi CRM, ticketing, newsletter, analytics, cloud drive, AI, backup, video call… e capisci che il tema non è se ci sono trasferimenti, ma se li stiamo governando.
Il DPO, qui, non entra per fare terrorismo. Entra perché questi trasferimenti, oggi, sono uno dei punti più controllati in audit e contratti enterprise: se non hai ordine, ti basta una domanda (“dove stanno i dati?”) per perdere mezza giornata.
Prima di tutto: cosa sono davvero i “trasferimenti dati”?
Non è solo “spedire un file negli USA”. È più sottile. In molti casi il trasferimento è già dentro il tuo flusso standard: usi un servizio cloud, il fornitore ha sub-processor, o l’accesso ai dati può avvenire da fuori EEA. Il risultato pratico è che la protezione GDPR deve “viaggiare con i dati”, non restare solo sulla carta.
Qui il DPO fa una cosa molto concreta: ti aiuta a mettere una definizione chiara, condivisa con IT e procurement, su cosa l’azienda considera “trasferimento” e quando scatta la valutazione.
Adeguatezza, SCC, eccezioni: la bussola semplice dei trasferimenti dati
La regola base è: trasferire fuori EEA si può, ma con condizioni (Capo V GDPR). In pratica:
- se c’è decisione di adeguatezza, il percorso è più lineare;
- se non c’è, spesso si va di SCC (Standard Contractual Clauses);
- le eccezioni (art. 49) non sono la scorciatoia “per fare prima”: vanno usate con prudenza.
La cosa interessante è che molte aziende hanno le SCC “firmate” ma non hanno fatto il passaggio che, dopo Schrems II, conta davvero: capire se le SCC bastano da sole o servono misure supplementari. Ed è qui che entra la TIA.
TIA: non un documento, ma una domanda onesta
La TIA (Transfer Impact Assessment), detta semplice, è questo: “Nel paese di destinazione, i dati hanno una protezione sostanzialmente equivalente a quella UE? E se no, cosa facciamo per colmare il gap?”
Non serve farla diventare un romanzo. Serve che sia credibile: che guardi tipo di dati, tipo di servizio, possibilità di accesso da parte di autorità, misure tecniche realistiche (non promesse), e che porti a una decisione. L’EDPB nelle sue raccomandazioni indica proprio un approccio “per step” e un set di misure supplementari possibili.
Il punto più delicato: le “misure supplementari” per i trasferimenti dati non sono tutte uguali
Qui spesso ci si perde. Perché “mettiamo la cifratura” sembra la risposta a tutto, ma la cifratura conta davvero solo se:
- è implementata bene,
- le chiavi sono gestite correttamente,
- e soprattutto il fornitore non ha accesso in chiaro quando non deve.
Le raccomandazioni EDPB parlano di misure tecniche, contrattuali e organizzative, ma nella vita reale il DPO tende a far emergere una verità: se il dato è molto sensibile, la misura che cambia tutto è la minimizzazione. Meno dati personali escono, meno ti serve “difenderli” in contesti complessi.
Il cloud è il motivo per cui questo tema non sparisce mai
La maggior parte dei trasferimenti non nasce da un “grande progetto internazionale”. Nasce da un tool scelto in fretta. E in quei casi succedono due cose:
- il contratto viene firmato senza fare domande su sub-processor e region;
- l’uso interno del tool diventa più largo del previsto (e quindi aumentano i rischi).
Il DPO in regia fa due mosse intelligenti:
- costruisce una scheda standard per ogni fornitore critico (dati, region, sub-processor, SCC, retention, incident response);
- crea un’abitudine: ogni nuovo tool passa da un check rapido prima di entrare in produzione.
È qui che “compliance” diventa gestione ordinata, non burocrazia.
SCC 2021/914: perché non basta “averle”
Le SCC aggiornate sono importanti perché danno un framework moderno (controller/processor, processor/processor, ecc.). Ma averle firmate non significa automaticamente essere a posto: il punto è dimostrare che hai valutato il contesto e messo misure coerenti (TIA + misure supplementari dove servono).
Se vuoi una frase semplice da tenere in mente: SCC = contratto, TIA = realtà. Servono entrambe.
Errori tipici nei trasferimenti dati(quelli che vedo più spesso)
Il primo è dire “non trasferiamo”, ma avere metà stack su cloud extra-UE senza una mappa.
Il secondo è trattare l’art. 49 come “jolly” invece che come eccezione.
Il terzo è fare TIA fotocopia: stessa valutazione per servizi diversi. In audit, questa cosa si vede subito.
Il quarto è ignorare i sub-processor: il fornitore principale magari è “ok”, ma la catena sotto è quella che cambia più spesso.
EDPB – Recommendations 01/2020 sulle misure supplementari ai trasferimenti dati.
I trasferimenti extra-UE non sono un problema “legale”. Sono un problema di governance: sapere dove vanno i dati, con chi, con quali garanzie, e poterlo dimostrare senza correre all’ultimo minuto.
Se vuoi mettere ordine su trasferimenti, SCC e TIA in modo pratico (senza carta inutile e senza scoperte spiacevoli in audit), contatta il DPO Alessandro Simonassi (P.I. Computers) → https://picomputers.it/contatti/
