Una startup non ha bisogno di un programma privacy da multinazionale, ma ha bisogno di quattro cose dal day one: un’informativa e un registro dei trattamenti, un DPA firmato con ogni fornitore SaaS, la privacy by design nel prodotto e le clausole di trasferimento per i subprocessor statunitensi. Ignorarle non è solo un rischio sanzionatorio: è il motivo per cui un deal enterprise salta al primo vendor assessment, quando il cliente chiede il registro dei sub-responsabili e la startup non ce l’ha. Chi costruisce un SaaS, inoltre, è quasi sempre responsabile del trattamento per i dati dei clienti B2B, e deve saperlo dimostrare. Questa guida definisce lo stack minimo di conformità per fondatori e CTO.
Punti chiave
- Lo stack minimo: informativa, registro dei trattamenti, DPA con ogni vendor, privacy by design nel prodotto.
- Un SaaS B2B è quasi sempre responsabile del trattamento (art. 28) per i dati dei clienti e titolare per i propri dati (dipendenti, marketing).
- Ogni subprocessor (hosting, email, analytics, AI) va coperto da un DPA e mappato: i clienti enterprise lo chiedono nei vendor assessment.
- I trasferimenti extra-UE (fornitori USA) richiedono una base valida: adeguatezza (Data Privacy Framework) o clausole contrattuali tipo (SCC).
- La privacy by design e by default (art. 25 GDPR) va incorporata nel prodotto, non aggiunta dopo.
Titolare e responsabile: la startup è entrambi
Un fondatore deve capire subito la doppia natura del proprio ruolo. Per i dati dei propri clienti che transitano nel prodotto SaaS, la startup agisce come responsabile del trattamento (art. 28 GDPR): tratta quei dati seguendo le istruzioni del cliente, che ne resta titolare. Per i propri dati — dipendenti, contatti marketing, utenti del sito — la startup è titolare del trattamento. Questa distinzione determina tutto il resto: come responsabile deve offrire ai clienti un DPA e garantire sicurezza e sub-responsabili in regola; come titolare deve avere informativa, base giuridica e registro propri. La guida alla distinzione tra titolare e responsabile chiarisce i due ruoli e le clausole del contratto.
Lo stack minimo di conformità
Ecco cosa serve davvero a una startup nei primi mesi, senza sovra-ingegnerizzare:
| Elemento | Perché serve | Priorità |
|---|---|---|
| Informativa privacy (sito + prodotto) | Obbligo art. 13-14; trasparenza | Alta |
| Registro dei trattamenti | Obbligo art. 30; base di tutto il resto | Alta |
| DPA con ogni vendor SaaS | Copre la catena dei subprocessor | Alta |
| DPA-template per i clienti B2B | Richiesto nei vendor assessment | Alta |
| Privacy by design nel prodotto | Obbligo art. 25; riduce il rischio a monte | Alta |
| Gestione richieste degli interessati | Obbligo art. 15-22 | Media |
Il registro è la spina dorsale: mappa quali dati la startup tratta, per quali finalità, con quali fornitori. Si può partire da un modello di registro dei trattamenti e mantenerlo aggiornato a ogni nuovo tool integrato.
DPA con i vendor: la catena dei subprocessor
Ogni startup si appoggia a una filiera di SaaS: hosting (AWS, Google Cloud), email transazionale, analytics, CRM, strumenti di AI. Ciascuno di questi tratta dati per conto della startup e va coperto da un Data Processing Agreement ex art. 28. Il punto critico è che questi fornitori diventano subprocessor rispetto ai clienti della startup: quando un cliente enterprise conduce un vendor assessment, chiede l’elenco dei subprocessor, i relativi DPA e le garanzie di sicurezza. Una startup che non ha mappato questa catena fallisce l’assessment e perde il deal. Mantenere l’elenco aggiornato e i DPA archiviati è quindi anche una questione commerciale.
Trasferimenti extra-UE: SCC e Data Privacy Framework
Molti fornitori sono statunitensi, e trasferire dati fuori dall’UE richiede una base valida ai sensi degli artt. 44-49 GDPR:
- decisione di adeguatezza: per gli USA, l’EU-US Data Privacy Framework consente il trasferimento verso fornitori certificati;
- clausole contrattuali tipo (SCC): per i fornitori non certificati, integrate da una valutazione del trasferimento (TIA);
- misure supplementari dove necessarie (cifratura, pseudonimizzazione).
La pseudonimizzazione e la cifratura riducono il rischio anche nei trasferimenti: si veda la guida su anonimizzazione e pseudonimizzazione. Verificare la copertura dei trasferimenti è uno dei primi controlli in un vendor assessment.
Privacy by design: costruirla nel prodotto
L’art. 25 GDPR impone privacy by design e by default: la protezione dei dati va incorporata nell’architettura del prodotto, non aggiunta dopo. Per un SaaS significa scelte concrete fin dall’inizio — minimizzazione dei dati raccolti, impostazioni predefinite rispettose della privacy, controlli di accesso, log, cancellazione automatica a fine retention, cifratura. Rifare queste scelte a prodotto maturo costa dieci volte di più. La guida alla privacy by design traduce l’art. 25 in decisioni tecniche. Dove il prodotto tratta dati su larga scala o profila gli utenti, va valutata una DPIA.
Gestire registro, DPA, subprocessor e richieste degli interessati con fogli di calcolo diventa ingestibile appena la startup cresce e arrivano i primi clienti enterprise. Un software GDPR pensato per le PMI tiene insieme la documentazione e velocizza i vendor assessment. Le indicazioni ufficiali sono su garanteprivacy.it e il testo del GDPR su EUR-Lex.
AI nel prodotto: il livello di attenzione in più
Sempre più startup integrano funzioni di AI — modelli che elaborano i dati dei clienti per generare output, raccomandazioni, automazioni. Questo aggiunge un livello di attenzione. Primo: se i dati dei clienti alimentano un modello di terze parti (un provider di AI), quel provider è un subprocessor da coprire con DPA e da valutare per i trasferimenti extra-UE. Secondo: occorre chiarire nel contratto se i dati dei clienti possono essere usati per addestrare i modelli, cosa che i clienti enterprise vietano quasi sempre. Terzo: dal 2026 entrano in vigore gli obblighi dell’AI Act per molti sistemi, che si sommano al GDPR quando l’AI tratta dati personali. Progettare fin da subito flussi che tengano separati i dati dei clienti dai dati di addestramento è una scelta che semplifica sia la conformità sia le trattative commerciali.
Errori tipici e priorità di una startup
Le startup sbagliano in modo prevedibile. Il primo errore è rimandare tutto al primo cliente enterprise, ritrovandosi a costruire il registro e i DPA sotto la pressione di un deal. Il secondo è copiare un’informativa da un altro sito senza adattarla ai trattamenti reali del prodotto. Il terzo è ignorare i subprocessor, integrando decine di tool SaaS senza tracciarli. Il quarto è trattare la privacy come un problema solo legale, quando è anzitutto una scelta di architettura del prodotto. La priorità corretta è invertire questo ordine: partire dal registro e dalla privacy by design, poi formalizzare i DPA e le informative. Sono attività a basso costo se fatte presto, costose se rincorse dopo. Investire poche ore nei primi mesi evita mesi di rework quando l’azienda scala e i clienti diventano esigenti.
FAQ
Una startup è titolare o responsabile del trattamento?
Entrambi. Per i dati dei propri clienti che transitano nel prodotto SaaS la startup è responsabile del trattamento (art. 28), perché li tratta seguendo le istruzioni del cliente titolare. Per i propri dati — dipendenti, marketing, utenti del sito — la startup è titolare del trattamento.
Cosa chiedono i clienti enterprise in un vendor assessment?
Tipicamente: il DPA firmato, l’elenco aggiornato dei subprocessor con i relativi DPA, le misure di sicurezza (art. 32), la base per i trasferimenti extra-UE, il registro dei trattamenti e le procedure per le richieste degli interessati e per le violazioni. Non averli pronti fa saltare il deal.
Posso usare fornitori SaaS statunitensi?
Sì, con una base valida per il trasferimento: l’EU-US Data Privacy Framework se il fornitore è certificato, oppure le clausole contrattuali tipo (SCC) integrate da una valutazione del trasferimento e, dove serve, misure supplementari come la cifratura.
Da dove parte una startup senza budget per la privacy?
Dallo stack minimo: informativa, registro dei trattamenti, DPA con ogni vendor e privacy by design nel prodotto. Sono quattro elementi a basso costo che coprono gli obblighi essenziali e preparano i vendor assessment. Il resto si aggiunge man mano che l’azienda cresce.
Vedi anche: gli obblighi dell’AI Act in Italia per chi sviluppa prodotti basati sull’intelligenza artificiale.
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial