Il problema che quasi nessuno ha risolto davvero
Se il tuo SaaS è ospitato su AWS, usa Stripe per i pagamenti, manda email attraverso Mailchimp, traccia gli utenti con Mixpanel, o chiama le API di OpenAI, stai trasferendo dati personali di utenti europei verso gli Stati Uniti. Questo è un trasferimento di dati extra-UE soggetto al Capo V del GDPR — e richiede una base legale specifica.
Non è una questione teorica. Le sanzioni comminate dal Garante e dalle altre autorità europee per trasferimenti non conformi includono casi concreti: Meta ha ricevuto una multa da 1,2 miliardi di euro dall’autorità irlandese nel 2023 proprio per il trasferimento di dati verso gli USA senza una base legale adeguata. Il problema non riguarda solo i grandi player — riguarda qualsiasi organizzazione che usa strumenti americani per trattare dati di utenti europei.
Un po’ di storia: Schrems I e Schrems II
Per capire la situazione attuale è necessario conoscere cosa è successo negli ultimi dieci anni.
Il primo meccanismo pensato per legittimare i trasferimenti UE-USA era il Safe Harbor, un accordo del 2000 che permetteva alle aziende americane di auto-certificarsi come conformi agli standard europei di protezione dei dati. Nel 2015, la Corte di Giustizia dell’UE lo ha dichiarato invalido con la sentenza Schrems I (C-362/14): il meccanismo non garantiva una protezione sostanzialmente equivalente a quella europea, in particolare a causa dei programmi di sorveglianza delle autorità americane.
Il Safe Harbor fu sostituito dal Privacy Shield nel 2016. Anche questo meccanismo è stato dichiarato invalido dalla Corte di Giustizia nel luglio 2020 con la sentenza Schrems II (C-311/18): stesso problema di fondo — le leggi americane sulla sorveglianza (FISA Section 702, EO 12333) permettono alle autorità USA di accedere ai dati dei cittadini europei senza le garanzie richieste dal GDPR.
Tra il 2020 e il 2023, il trasferimento di dati verso gli USA era tecnicamente possibile solo attraverso le Standard Contractual Clauses — con un Transfer Impact Assessment obbligatorio per valutare se le garanzie fossero sufficienti. Un sistema complesso, che molte aziende ignoravano o gestivano in modo superficiale.
Il Data Privacy Framework: cosa è e come funziona
Il 10 luglio 2023 la Commissione Europea ha adottato la decisione di adeguatezza per il Data Privacy Framework (DPF) — il terzo tentativo di creare un meccanismo strutturato per i trasferimenti UE-USA.
Il DPF si basa su un impegno formale degli Stati Uniti a limitare l’accesso delle proprie autorità ai dati dei cittadini europei, con l’istituzione di un meccanismo di ricorso indipendente (il Data Protection Review Court). Le aziende americane che vogliono ricevere dati dall’UE sotto il DPF devono certificarsi presso il Dipartimento del Commercio USA, impegnandosi a rispettare i principi del Framework.
Come verificare se un fornitore è certificato DPF: il sito ufficiale del Dipartimento del Commercio (dataprivacyframework.gov) pubblica l’elenco aggiornato delle aziende certificate. La verifica è semplice: cerca il nome del fornitore, verifica che la certificazione sia attiva e che copra la tipologia di dati che stai trasferendo.
I principali fornitori utilizzati dai SaaS italiani certificati DPF includono: Amazon Web Services, Google LLC, Microsoft Corporation, Stripe, Salesforce, HubSpot, Twilio, Mailchimp (Intuit). Attenzione: OpenAI e Anthropic non risultano certificate nel DPF — il meccanismo di trasferimento per questi provider è basato su SCC.
Perché il DPF non è sufficiente da solo
Il DPF semplifica i trasferimenti verso le aziende certificate, ma presenta due limiti strutturali che ogni responsabile della protezione dei dati deve considerare.
Il rischio Schrems III. Il DPF è già sotto sfida legale. Max Schrems e NOYB hanno annunciato che impugneranno il meccanismo davanti alla Corte di Giustizia, ritenendo che non affronti adeguatamente i problemi strutturali della sorveglianza americana. Se la Corte dovesse dichiarare invalido anche il DPF — come ha fatto con i due meccanismi precedenti — le aziende che hanno basato tutti i loro trasferimenti esclusivamente sul DPF si troverebbero nuovamente senza copertura.
La copertura non è universale. Il DPF copre solo le aziende americane certificate. Se usi un fornitore non certificato, o se i dati vengono trasferiti in un paese diverso dagli USA, il DPF non si applica e serve un meccanismo alternativo.
La soluzione più robusta dal punto di vista della continuità operativa è usare il DPF come meccanismo principale dove disponibile, affiancato dalle Standard Contractual Clauses come base legale alternativa documentata. Il DPF è una decisione di adeguatezza autonoma e sufficiente: usare entrambi gli strumenti non è un requisito normativo, ma una scelta di risk management che garantisce copertura anche in caso di futura invalidazione del meccanismo.
Le Standard Contractual Clauses: lo strumento principale
Le Standard Contractual Clauses (SCC) sono clausole contrattuali tipo adottate dalla Commissione Europea che, una volta inserite nel contratto con il fornitore extra-UE, costituiscono una base legale per il trasferimento. Sono lo strumento più solido e più utilizzato nella pratica.
La Commissione ha aggiornato le SCC nel giugno 2021 (Decisione 2021/914), sostituendo le versioni precedenti. Le nuove SCC coprono quattro scenari di trasferimento distinti (moduli): titolare → titolare, titolare → responsabile, responsabile → responsabile, responsabile → titolare (sub-processing). La scelta del modulo corretto dipende dal ruolo che tu e il tuo fornitore avete nel trattamento dei dati.
Attenzione pratica: le SCC non si firmano automaticamente — devono essere incorporate nel contratto con il fornitore (tipicamente nel Data Processing Agreement). Molti fornitori le includono nelle proprie condizioni standard, ma spesso in versioni pre-compilate che meritano una verifica.
Nota aggiornamento: la Commissione Europea ha avviato un processo di revisione della Decisione 2021/914. Al momento non è stata adottata una nuova versione, ma chi firma DPA con fornitori critici nel 2025 dovrebbe monitorare l’iter: un aggiornamento delle SCC richiedrà una revisione dei contratti esistenti entro la finestra transitoria che la Commissione stabilirà.
Il Transfer Impact Assessment: quando serve e come si fa
Il Transfer Impact Assessment (TIA) è la valutazione che deve precedere ogni trasferimento verso paesi terzi, anche quando si usano le SCC. Lo ha resa obbligatoria la sentenza Schrems II, confermata dalle linee guida EDPB 05/2021.
Lo scopo del TIA è verificare che la protezione garantita dalle SCC sia sostanzialmente equivalente a quella del GDPR nel paese di destinazione — in particolare, che le leggi di quel paese non permettano alle sue autorità di accedere ai dati in modo incompatibile con gli standard europei.
Nella pratica, il TIA si struttura in tre parti:
- Prima parte — mappa del trasferimento: quali dati vengono trasferiti, verso quale paese, a quale fornitore, per quale finalità, con quale frequenza.
- Seconda parte — analisi dell’ordinamento del paese di destinazione: le leggi del paese di destinazione prevedono forme di sorveglianza o accesso governativo ai dati incompatibili con il GDPR? Per gli USA, la risposta è sì in astratto (FISA Section 702) — ma l’analisi deve considerare anche la probabilità concreta che queste norme si applichino al tipo di dati trasferiti e al profilo del titolare del trattamento.
- Terza parte — misure supplementari: se l’analisi evidenzia rischi, quali misure tecniche, contrattuali o organizzative vengono adottate per mitigarli? La cifratura end-to-end con gestione delle chiavi in UE è la misura supplementare tecnica più comune e più efficace.
I principali fornitori: situazione aggiornata a gennaio 2025
| Provider | DPF | Note operative |
|---|---|---|
| AWS | ✓ Sì | Regioni EU disponibili. SCC incluse nel DPA. Configurare esplicitamente le regioni EU. |
| Google Cloud | ✓ Sì | Data residency EU. SCC nel DPA. Google Workspace ha regime separato. |
| Stripe | ✓ Sì | DPA con SCC disponibile nelle impostazioni account. Dati pagamento transitano per infrastruttura USA. |
| HubSpot | ✓ Sì | DPA con SCC incluso nelle condizioni standard per clienti EU. |
| OpenAI | ✗ No | SCC tramite DPA per clienti API. Dati non usati per training per default. Verifica DPA firmato. |
| Anthropic | ✗ No | SCC disponibili per clienti API. Verificare stato aggiornato prima di procedere. |
| Mailchimp (Intuit) | ✓ Sì | DPA con SCC disponibile, da richiedere esplicitamente per piani a pagamento. |
| Mixpanel | ✓ Sì | DPA con SCC disponibile. Verificare configurazione data residency per i piani che lo supportano. |
Cosa fare adesso
Passo 1 — Inventario dei fornitori extra-UE. Elenca tutti i servizi terzi che il tuo prodotto usa e che potrebbero ricevere dati personali di utenti europei. Non solo i fornitori principali (cloud, pagamenti) ma anche quelli secondari: strumenti di monitoring, di analytics, di supporto clienti, di email marketing.
Passo 2 — Verifica delle certificazioni DPF. Per ogni fornitore USA, verifica su dataprivacyframework.gov che la certificazione sia attiva e copra il tipo di dati che stai trasferendo.
Passo 3 — Verifica e firma dei DPA. Controlla che ogni fornitore abbia un Data Processing Agreement firmato che include le SCC nel modulo corretto.
Passo 4 — Transfer Impact Assessment per i trasferimenti principali. Conduci un TIA documentato almeno per i trasferimenti verso fornitori che ricevono la maggior parte dei dati personali dei tuoi utenti.
Passo 5 — Aggiorna il registro dei trattamenti. Integra la sezione sui trasferimenti extra-UE con i meccanismi adottati e i riferimenti ai DPA firmati.
Non è un processo che si completa in un pomeriggio — ma iniziare dall’inventario dei fornitori richiede poche ore e permette di avere immediatamente una visione chiara dell’esposizione reale.
Hai bisogno di supporto nel mappare i tuoi trasferimenti extra-UE o nel negoziare i DPA con i tuoi fornitori?
Scrivici