GDPR per Sviluppatori Software e Provider SaaS
Chi sviluppa software o eroga servizi SaaS è responsabile del trattamento dei dati dei propri clienti, con obblighi di privacy by design, DPA e documentazione tecnica.
I provider di servizi SaaS e i team di sviluppo software occupano una posizione peculiare nel panorama GDPR: trattano dati personali degli utenti finali dei propri clienti, configurandosi come responsabili del trattamento. Allo stesso tempo, raccolgono dati propri (analytics, account) in qualità di titolari. Questa doppia veste richiede un approccio strutturato e documentato.
Obblighi e adempimenti
Privacy by design nel ciclo di sviluppoPrioritario
La protezione dei dati deve essere integrata nel ciclo di sviluppo (SDL – Secure Development Lifecycle): threat modeling, scelta di architetture che minimizzano la raccolta di dati, cifratura dei dati a riposo e in transito, gestione granulare delle autorizzazioni.
DPA standard per i clientiPrioritario
Ogni cliente che carica dati personali propri o dei propri utenti sulla piattaforma SaaS deve ricevere un DPA ex art. 28 GDPR. I provider strutturati offrono un DPA standard disponibile online, che i clienti accettano contestualmente ai ToS.
Trasparenza su sub-processoriPrioritario
Il DPA deve elencare i sub-processori (es. AWS, Stripe, SendGrid) utilizzati per erogare il servizio, con meccanismo di notifica delle modifiche e diritto del cliente di opporsi.
Gestione delle richieste degli interessati
Il provider SaaS deve definire procedure per supportare i clienti nel rispondere alle richieste degli interessati (cancellazione, accesso, portabilità) che coinvolgono dati archiviati sulla propria piattaforma.
Data breach: notifica al cliente-titolarePrioritario
In caso di data breach, il responsabile (provider SaaS) deve notificare il titolare (il cliente) senza ingiustificato ritardo e comunque in tempo utile perché il titolare rispetti le 72 ore verso il Garante.
Rischi specifici del settore
Assenza di DPA come ostacolo commerciale
Clienti enterprise e pubbliche amministrazioni richiedono sistematicamente il DPA prima di sottoscrivere. L'assenza di un DPA strutturato è un blocco commerciale prima ancora che un rischio normativo.
Domande frequenti
Chi è titolare e chi è responsabile in un SaaS B2B?
Il cliente che carica i dati dei propri utenti o dipendenti è titolare del trattamento (Art. 4 n. 7 GDPR); il provider SaaS che li archivia ed elabora per conto del cliente è responsabile del trattamento (Art. 4 n. 8 GDPR). Per i dati degli account del cliente stesso (es. l'email del responsabile che si iscrive alla piattaforma), il provider SaaS è titolare. Le Linee Guida EDPB 07/2020 sul concetto di titolare e responsabile forniscono i criteri di classificazione.
Come deve essere strutturato il DPA standard per i clienti di un SaaS?
Il Data Processing Agreement deve contenere gli elementi obbligatori elencati all'Art. 28.3 GDPR: oggetto e durata del trattamento, natura e finalità, tipo di dati personali e categorie di interessati, obblighi e diritti del titolare, obbligo di trattare i dati solo su istruzione documentata, riservatezza del personale autorizzato, misure di sicurezza ex Art. 32 GDPR, condizioni per il ricorso a sub-responsabili, assistenza per l'esercizio dei diritti degli interessati, restituzione o cancellazione dei dati alla cessazione del contratto. I provider strutturati pubblicano il DPA come allegato ai Termini di Servizio.
Cosa deve contenere la lista dei sub-processor di un SaaS?
Ai sensi dell'Art. 28.2 GDPR, il provider SaaS non può ricorrere a un sub-processor senza previa autorizzazione scritta del titolare (specifica o generale). La lista deve indicare: nome del sub-processor, servizio fornito, sede del trattamento, e deve essere aggiornata quando vengono aggiunti o sostituiti sub-processor, con un meccanismo di notifica che consenta al cliente di esercitare il diritto di opposizione entro un termine ragionevole.
Quando è obbligatoria la DPIA per un provider SaaS?
La DPIA è obbligatoria ai sensi dell'Art. 35 GDPR quando il trattamento è suscettibile di presentare un rischio elevato. Il Garante ha pubblicato l'elenco delle tipologie che la richiedono (Provvedimento 11 ottobre 2018). Per un SaaS, ricorrono generalmente i criteri che la impongono in presenza di: profilazione degli utenti su larga scala, trattamento di dati particolari (sanitari, biometrici), monitoraggio sistematico del comportamento, o valutazioni automatizzate con effetti giuridici. Le Linee Guida WP248 individuano 9 criteri: la presenza di 2 o più di essi rende la DPIA obbligatoria.
Un SaaS con meno di 250 dipendenti è tenuto al registro dei trattamenti?
L'Art. 30.5 GDPR prevede un'esenzione per le organizzazioni con meno di 250 dipendenti, ma con eccezioni che in pratica riguardano quasi tutti i SaaS: il trattamento presenta un rischio per i diritti degli interessati, non è occasionale, oppure include dati particolari (Art. 9) o relativi a condanne penali (Art. 10). Un provider SaaS che tratta dati degli utenti finali dei propri clienti in via continuativa rientra normalmente nell'eccezione "non occasionale", rendendo il registro obbligatorio.
Entro quando il provider SaaS deve notificare un data breach al cliente titolare?
Il provider SaaS, quale responsabile del trattamento, deve notificare la violazione dei dati personali al cliente (titolare) "senza ingiustificato ritardo" dopo averne preso conoscenza, ai sensi dell'Art. 33.2 GDPR. Il DPA deve definire un termine contrattuale specifico — generalmente 24 o 48 ore — per consentire al cliente di rispettare il termine di 72 ore verso il Garante Privacy previsto dall'Art. 33.1 GDPR.
Cosa significa "privacy by design" in pratica per un team di sviluppo?
L'Art. 25.1 GDPR richiede di integrare misure di protezione dei dati nella fase di progettazione del prodotto. In pratica: definire prima del codice quali dati raccogliere e perché (minimizzazione); progettare architetture con pseudonimizzazione dei dati a riposo e cifratura in transito; implementare controlli di accesso granulari (principio del minimo privilegio); prevedere funzionalità di cancellazione e portabilità nell'architettura del database. L'Art. 25.2 aggiunge il principio di "privacy by default": le impostazioni predefinite devono trattare il minimo di dati necessario, senza richiedere un'azione dell'utente per tutelarsi.