Contratto di trattamento dei dati su commissione in Svizzera: quando serve — con checklist

«Abbiamo in realtà un contratto con il nostro hoster riguardo ai dati?» Pongo regolarmente questa domanda alle PMI svizzere — e la risposta più frequente è un'alzata di spalle. Eppure il contratto di trattamento dei dati su commissione (in inglese Data Processing Agreement, DPA) non è un lusso per i grandi gruppi: è un obbligo legale non appena un fornitore tratta dati personali per voi. Vale a dire, praticamente sempre.

Quando vi serve un simile contratto, cosa deve contenere e perché non dovreste mai riprendere senza verifica un modello trovato in internet — una guida pratica con checklist.

Due quadri giuridici, un unico concetto

Anzitutto un chiarimento terminologico. La legge federale sulla protezione dei dati (LPD) disciplina questa costellazione all'art. 9, sotto il titolo «trattamento di dati personali da parte di un responsabile»: un titolare fa trattare dati personali da un terzo per proprio conto. Il regolamento generale sulla protezione dei dati (RGPD) europeo regola lo stesso concetto all'art. 28.

In entrambi i casi si tratta della medesima situazione: voi decidete finalità e mezzi del trattamento, un terzo lo esegue secondo le vostre istruzioni. Il contratto che disciplina questo rapporto si chiama contratto di trattamento dei dati su commissione — nella Svizzera tedesca «Auftragsverarbeitungsvertrag» o AVV, in inglese Data Processing Agreement. Chi cerca un modello di contratto per la Svizzera intende esattamente il documento richiesto dall'art. 9 LPD e dall'art. 28 RGPD.

Quando serve un contratto di trattamento dei dati?

La regola pratica: non appena un fornitore esterno tratta dati personali di cui voi determinate la finalità, serve un contratto. La nozione di «trattamento» è ampia — bastano la semplice memorizzazione o l'accesso tecnico.

Casi tipici nelle PMI svizzere:

• Hosting provider — il vostro sito web con modulo di contatto gira su server di terzi; l'hoster memorizza quindi dati personali per voi.
• Tool per newsletter (Brevo, Mailchimp) — gli indirizzi e-mail dei vostri abbonati si trovano presso il fornitore.
• Archiviazione cloud e suite per ufficio (Microsoft 365, Google Workspace) — dossier dei clienti, documenti del personale, corrispondenza.
• Software CRM e di contabilità — dati dei clienti, informazioni di pagamento.
• Agenzie web con accesso di manutenzione — chi ha accesso al vostro database di produzione per gli aggiornamenti tratta dati personali per vostro conto.
• Fornitori di gestione del consenso ai cookie — spesso dimenticato: i consensi registrati contengono marche temporali e identificatori tecnici. Anche il vostro strumento di consenso è un responsabile del trattamento su commissione.

L'elenco lo dimostra: una PMI media non ha uno, bensì da cinque a quindici fornitori di questo tipo. Per ciascuno serve un contratto.

Quando non serve?

La delimitazione è altrettanto importante. Nessun contratto è necessario con i soggetti che trattano i dati personali sotto la propria responsabilità — cioè che decidono autonomamente finalità e mezzi. Esempi classici: la banca per il traffico dei pagamenti, la Posta per la spedizione, l'avvocato nell'ambito del mandato, l'ufficio di revisione per la verifica. Questi sono titolari del trattamento a pieno titolo, non responsabili su commissione.

Nessun contratto serve nemmeno per i servizi che non toccano alcun dato personale — per esempio un fornitore di licenze per font che integrate localmente. In caso di dubbio, ponetevi la domanda di controllo: «Questo fornitore potrebbe teoricamente accedere a dati personali di cui rispondo io?» Se sì, parlate di un contratto di trattamento dei dati.

Un caso particolare che riguarda soprattutto le agenzie web: la stessa azienda può ricoprire entrambi i ruoli contemporaneamente. L'agenzia che cura i siti dei propri clienti agisce come responsabile su commissione — ma per la propria anagrafica clienti e la fatturazione è essa stessa titolare del trattamento. Ciò che conta è sempre il trattamento concreto, non l'insegna dell'azienda. Un'agenzia che gestisce progetti per i clienti dovrebbe quindi proporre di propria iniziativa un contratto a ogni cliente — ormai è un segno di professionalità.

Cosa richiede concretamente l'art. 9 LPD

La legge svizzera è di una piacevole concisione su questo punto. L'art. 9 LPD pone quattro condizioni:

1. Il trattamento può essere effettuato solo nel modo in cui sareste autorizzati a farlo voi stessi.
2. Nessun obbligo legale o contrattuale di mantenere il segreto deve vietare l'esternalizzazione.
3. La base è un contratto o la legge — è qui che entra in gioco il contratto di trattamento dei dati.
4. Il responsabile può affidare il trattamento a un terzo solo con la vostra autorizzazione preventiva — la questione dei subfornitori.

A ciò si aggiunge l'obbligo generale di sicurezza dei dati (art. 8 LPD): dovete accertarvi che il fornitore protegga i dati in modo adeguato. L'art. 28 RGPD segue la stessa logica, ma in modo nettamente più dettagliato — prescrive un catalogo di contenuti contrattuali minimi. Chi ha clienti nell'Unione europea fa quindi bene a orientarsi allo standard RGPD, più severo, che copre al tempo stesso la LPD.

La checklist: cosa deve contenere ogni contratto

Che stiate esaminando il contratto di un fornitore o partiate da un modello — questi punti devono essere disciplinati:

• Oggetto e durata — Quale prestazione viene fornita, quanto dura il contratto, cosa succede alla disdetta?
• Natura e finalità del trattamento — Categorie di dati e cerchia delle persone interessate (clienti, collaboratori, visitatori del sito).
• Vincolo alle istruzioni — Il fornitore tratta i dati esclusivamente secondo le vostre istruzioni documentate, mai per finalità proprie.
• Riservatezza — Tutte le persone con accesso ai dati sono vincolate al segreto.
• Misure tecniche e organizzative — Cifratura, controllo degli accessi, backup; descritte concretamente, non solo «sicurezza adeguata» come formula vuota.
• Subfornitori — Elenco dei subappaltatori impiegati, meccanismo di approvazione e obbligo di informazione in caso di cambiamenti.
• Obblighi di assistenza — Il fornitore vi assiste nelle richieste delle persone interessate e notifica senza indugio le violazioni dei dati.
• Cancellazione e restituzione — Alla fine del contratto i dati vengono restituiti o cancellati in modo verificabile.
• Diritti di audit — Potete verificare il rispetto del contratto o esigere prove riconosciute (certificazioni, rapporti di audit).
• Trasferimenti di dati all'estero — Dove si trovano i server, quali garanzie coprono un trasferimento (per esempio le clausole contrattuali tipo)?

Se manca uno di questi punti, il contratto è lacunoso — e in caso di controversia l'onere della prova ricade su di voi.

Un contratto RGPD vale anche per la LPD?

La domanda emerge in ogni consulenza: il fornitore cloud statunitense presenta un contratto RGPD — basta per la Svizzera? Risposta breve: nella sostanza quasi sempre; nella forma meritano un esame due punti.

Primo: il contratto dovrebbe includere espressamente il diritto svizzero della protezione dei dati — molti fornitori internazionali hanno nel frattempo integrato i loro contratti con una clausola per la Svizzera. Secondo: l'art. 9 cpv. 3 LPD esige l'autorizzazione preventiva dei subfornitori; un semplice meccanismo di opposizione, come previsto da alcuni contratti RGPD, dovrebbe quindi essere formulato correttamente come autorizzazione generale con obbligo di informazione. Se entrambi i punti sono coperti, un contratto RGPD vi serve bene anche sotto la LPD.

Perché qui non offriamo un modello da copiare

Una parola sulle aspettative: in questo articolo non troverete deliberatamente alcun testo contrattuale da copiare. Un contratto di trattamento dei dati disciplina questioni di responsabilità — e un modello che non corrisponde alla vostra situazione crea più rischi di quanti ne elimini. Chi garantisce, in caso di controversia, che le misure tecniche e organizzative copiate esistano davvero presso il vostro fornitore?

Un modello serio per la Svizzera si riconosce da tre cose: copre i dieci punti della checklist qui sopra, menziona espressamente la LPD e lascia spazio alle indicazioni concrete — categorie di dati, subfornitori, ubicazione dei server. Queste lacune spetta a voi colmarle. Altrimenti il modello è giuridicamente privo di valore, esattamente come le dichiarazioni sulla protezione dei dati copiate da un modello standard.

Come costruire il vostro inventario dei fornitori

Prima di esaminare i contratti vi serve la visione d'insieme: quali fornitori trattano effettivamente dati personali per voi? Tre fonti producono l'elenco in un'ora:

1. La vostra dichiarazione sulla protezione dei dati — tutti i destinatari di dati personali dovrebbero già figurarvi. Se è aggiornata, è il vostro miglior inventario.
2. Una scansione dei cookie del sito — mostra quali servizi di terzi sono realmente integrati, compresi i tool che nessuno aveva più sul radar.
3. La contabilità fornitori — ogni fattura software ricorrente è un candidato. Chi paga mensilmente con ogni probabilità tratta anche dati.

Per ogni voce annotate: esiste un contratto, in quale versione, con quale data — e dove è archiviato? In caso di audit questa semplice tabella vale più di qualsiasi raccoglitore pieno di PDF contrattuali mai letti. Per i fornitori con server al di fuori della Svizzera e dell'Unione europea annotate inoltre la base del trasferimento — di norma le clausole contrattuali tipo con gli adeguamenti svizzeri.

Tre errori visti nella pratica

Errore 1 — Dimenticare i tool «piccoli». Il contratto con Microsoft è concluso, ma il tool per la prenotazione degli appuntamenti, il fornitore del widget di chat e lo strumento di consenso funzionano senza contratto. Sono proprio i piccoli servizi che gli audit trovano per primi.

Errore 2 — Firmare e archiviare. Il contratto è stato concluso nel 2023; da allora il fornitore ha modificato tre volte il suo elenco di subfornitori. Ignorare queste notifiche di modifica significa approvare alla cieca — e trascurare il proprio dovere di verifica.

Errore 3 — Nessuna prova. In caso di emergenza l'Incaricato federale della protezione dei dati e della trasparenza (IFPDT) o l'avvocato della controparte chiede: «Quale versione del contratto era in vigore il giorno della violazione?» Un PDF da qualche parte nell'archivio di posta, senza versione né data di conclusione, è una prova debole.

Come Aiara risolve la questione per i suoi clienti

In quanto fornitore di gestione del consenso ai cookie, Aiara è a sua volta un responsabile del trattamento su commissione per i suoi clienti — i registri dei consensi sono dati personali. Per questo Aiara offre il contratto in self-service nel suo Trust Center: concludete il contratto in modo digitale, in italiano, tedesco, francese o inglese. Ogni conclusione è sigillata con un hash SHA-256 — un'impronta crittografica del documento che dimostra in qualsiasi momento quale versione del contratto avete accettato, e quando. Niente scartoffie, niente ping-pong di e-mail, e la prova per gli audit resta consultabile in modo permanente.

È così che la conclusione di un contratto di trattamento dei dati dovrebbe funzionare nel 2026, con ognuno dei vostri fornitori. Dove non funziona così, ora sapete cosa esigere — la checklist qui sopra è la vostra griglia di controllo.