Questo non è un parere legale. È la checklist pratica che ci siamo costruiti lavorando con clienti in Germania, Italia e Regno Unito, e che ripetiamo a ogni nuovo progetto. Non sostituisce il vostro avvocato, ma accorcia molto l'incontro con lui.
Il quadro di base: il vostro cliente è il titolare, voi quasi certamente il responsabile del trattamento, e ogni servizio cloud che usate è un sub-responsabile. Collocate bene queste tre parole e il resto dell'elenco si mette in ordine da solo.
Il GDPR non è burocrazia, è una decisione architetturale. I documenti descrivono l'architettura, non la sostituiscono.
01Il livello contrattuale: DPA e clausole contrattuali standard
Serve un accordo sul trattamento dei dati firmato con ogni cliente UE. Poiché la Turchia non ha una decisione di adeguatezza, se i dati saranno trattati in Turchia il DPA è accompagnato da clausole contrattuali standard e da una breve valutazione d'impatto sul trasferimento. In pratica questi tre documenti viaggiano insieme e, preparati bene una volta, si riusano in ogni progetto.
Il secondo passo è l'elenco dei sub-responsabili. Ogni servizio usato — hosting, email transazionali, tracciamento errori, analytics, backup — va elencato con nome, finalità e regione, e l'elenco va condiviso con il cliente. Aggiungere una riga è un evento da notificare per contratto: per questo la cosa più pratica è tenerlo come pagina e linkarlo nel contratto.
02Il livello architetturale: regione, conservazione, cancellazione
Per i clienti UE il nostro default è netto: database e object storage in una regione UE (Vienna o Irlanda), con i backup nella stessa regione. Quella sola decisione semplifica le risposte alle cento domande successive. Se il team di sviluppo vi accede dalla Turchia, è accesso remoto e come tale va descritto nel DPA.
I periodi di conservazione si definiscono per tipo di dato: contratti e fatture per gli anni richiesti dalla legge, consensi marketing fino alla revoca, log di accesso ai server novanta giorni, CV dei candidati sei mesi. Codificare quei periodi nel software — un campo di scadenza e un job notturno — è più affidabile che scriverli in un documento.
Trattate le richieste di cancellazione ed export come una funzione dal primo giorno. Se riuscite a esportare e cancellare i dati di un utente in un'unica operazione, i trenta giorni di legge smettono di essere una fonte di stress. Aggiungerlo dopo è sempre faticoso, perché intanto i dati si sono sparsi su cinque tabelle.
03Pratica quotidiana: cookie, moduli, piano di violazione
Il banner cookie non è un elemento di design ma una promessa tecnica: gli script di analytics e marketing non devono caricarsi prima del consenso, e "rifiuta" deve essere visibile quanto "accetta". Un sito che fa bene queste due cose ha già superato le prime due voci di qualunque lista di audit.
Nei moduli separate le finalità: la richiesta di progetto e l'iscrizione alla newsletter sono due consensi distinti, e nessuna casella arriva pre-spuntata. Ogni modulo rimanda a un'informativa che descrive davvero i campi di quel modulo.
L'ultima voce è quella che nessuno vuole preparare: il piano di violazione. Una pagina che dica chi viene avvisato, da dove si leggono i log, cosa si scrive al cliente e chi presidia le settantadue ore. Scrivere quella pagina in un giorno tranquillo costa molto meno che scriverla in un giorno brutto.
Scritto da
Il team Paradigma7
Prodotto, ingegneria e operations
Siamo un team con base a Ankara che sviluppa software per l'Europa. Qui non c'è teoria: sono i processi che usiamo davvero nei progetti dei clienti.
Chi siamo