Conformità GDPR per i siti web: cosa serve davvero costruire

La maggior parte dei consigli sul GDPR che si trovano online è scritta per giuristi, o per chi sta comprando un generatore di informative. Molto poco è scritto per la persona che deve aprire un editor e cambiare qualcosa.

Questa guida è del secondo tipo. Percorre ciò che il Regolamento generale sulla protezione dei dati chiede a un sito e ai sistemi che stanno dietro, espresso come cose che si costruiscono, si configurano o si cancellano. Facciamo questo lavoro per aziende che operano nell'UE da quando il regolamento è diventato applicabile nel 2018, e lo schema di ciò che va storto non è quasi cambiato.

Una premessa: il GDPR non è diventato più facile perché sono arrivate normative nuove. È diventato più importante, perché quasi tutto nell'attuale ondata di regole digitali europee presuppone che i vostri dati personali siano già in ordine.

Partite da un inventario onesto dei dati

Quasi tutti i progetti GDPR falliti che abbiamo ereditato sono falliti nello stesso punto. Il team ha scritto prima la policy e ha scoperto i dati dopo.

Prima di ogni altra cosa, mappate quali dati personali il vostro sito raccoglie davvero. Non ciò che dice la specifica di prodotto. Ciò che c'è nel database, nei log, nella piattaforma di analytics, nel CRM, nello strumento di supporto, nello stack di marketing automation, nel tracker degli errori, nei log della CDN e negli script di terze parti presenti in pagina.

In pratica significa:

Setacciare lo schema. Ogni colonna che possa identificare una persona, da sola o combinata con un'altra.
Leggere la scheda di rete su un caricamento reale. Ogni richiesta in uscita verso un dominio che non controllate è un potenziale trasferimento di dati personali, perché un indirizzo IP più uno user agent sono dati personali.
Controllare cosa cattura il tracker degli errori. Gli stack trace contengono abitualmente indirizzi email, token e corpi di richiesta.
Controllare la conservazione dei log. Log di accesso con IP conservati per sempre sono uno dei rilievi più comuni e uno dei più facili da correggere.

Scrivetelo come registro delle attività di trattamento. L'articolo 30 lo richiede comunque per la maggior parte delle organizzazioni, e la versione utile agli sviluppatori è una tabella con sistema, dati, finalità, base giuridica, periodo di conservazione e destinatari.

Scegliete una base giuridica per finalità, non per sistema

L'articolo 6 offre sei basi giuridiche. L'errore più frequente è sceglierne una per l'intero prodotto.

Quasi certamente avete più finalità attive contemporaneamente. Eseguire un ordine è contratto. I controlli antifrode sono di solito legittimo interesse o obbligo legale. Conservare le fatture per il periodo di legge è obbligo legale. L'email di marketing è consenso nella maggior parte degli Stati membri. L'analytics non essenziale è consenso, per via delle regole ePrivacy sull'accesso alle apparecchiature terminali e non del GDPR in sé.

La conseguenza pratica è che il vostro modello dati deve sapere quale finalità serve ogni record. Se non potete separare il profilo di marketing dal record d'ordine, non potete onorare un'opposizione al marketing senza rompere lo storico ordini. Quella separazione è una decisione di schema ed è dolorosa da adattare dopo.

Il consenso deve essere reale e deve essere registrato

Se vi basate sul consenso, deve essere libero, specifico, informato e inequivocabile, e dovete poterlo dimostrare in seguito.

Concretamente:

Nulla di non essenziale parte prima che l'utente agisca. Questo include lo snippet di analytics, il pixel pubblicitario, il widget di chat, il font caricato da una CDN di terze parti e lo script di A/B testing.
Rifiutare deve essere facile quanto accettare. Stesso livello, stesso peso visivo, stesso numero di clic. Le autorità trattano qualsiasi altra cosa come dark pattern, e sono state coerenti su questo.
Il consenso è per finalità. Un unico interruttore che copre «analytics e marketing e personalizzazione» non è specifico.
La revoca è facile quanto la concessione. Un link permanente o un pulsante flottante, non un'email al supporto.
Conservate la prova: timestamp, la stringa di consenso o lo stato di ogni categoria, la versione del banner e il testo mostrato all'utente. Senza la versione non potete difendere un consenso di due anni fa.

Qui l'applicazione non è teorica. A settembre 2025 l'autorità francese ha multato lo stesso giorno Google per 325 milioni di euro e Shein per 150 milioni per pratiche sui cookie. Entrambi i casi vertevano sulla meccanica e non sul testo della policy: cookie depositati prima di qualsiasi interazione, e pulsanti di rifiuto che non rifiutavano davvero.

Anche le regole sono in movimento. La proposta Digital Omnibus sposterebbe il consenso sulle apparecchiature terminali dentro il GDPR e renderebbe vincolanti i segnali del browser. Abbiamo coperto cosa cambierebbe in il consenso ai cookie dopo il Digital Omnibus.

Costruite presto la macchina dei diritti degli interessati

Gli articoli da 15 a 22 danno alle persone diritto di accesso, rettifica, cancellazione, limitazione, portabilità e opposizione. Avete un mese per rispondere, estendibile a tre nei casi complessi.

I team tendono a gestire a mano le prime richieste, il che funziona finché non funziona più. Cosa vi serve, ben prima che arrivi il volume:

Un risolutore che trovi una persona nei vari sistemi. Dato un indirizzo email, restituire tutto: l'account, gli ordini, i ticket di supporto, il profilo di marketing, l'identificativo analytics, i log. Se un umano deve ricordare che esiste una piattaforma di recensioni di terze parti con dei dati, prima o poi qualcuno se ne dimenticherà.

Un percorso di cancellazione che rispetti gli obblighi di conservazione. La cancellazione non è assoluta. Le fatture di solito devono sopravvivere per motivi fiscali. Serve una cancellazione logica con cancellazione fisica per finalità, così da rimuovere il profilo di marketing mantenendo la scrittura contabile, e così che quella scrittura scada a sua volta nei tempi.

Un export portabile. Strutturato, di uso comune, leggibile da macchina. JSON va bene. Un PDF di una pagina HTML renderizzata no.

Un flag di opposizione che tutto il sistema legga. Opporsi alla profilazione deve fermare davvero la profilazione, incluso il job batch che gira alle tre di notte e non controlla il flag.

La conservazione è un lavoro, non una riga di policy

La limitazione della conservazione è il principio più violato da sistemi per il resto ben costruiti, perché cancellare richiede che qualcuno scriva e pianifichi un job che nessuno chiede.

Date a ogni categoria di dati una durata definita, poi implementatela. Log di accesso, sessioni, carrelli abbandonati, iscrizioni non verificate, ticket chiusi, backup vecchi e dati grezzi di analytics hanno tutti bisogno di una scadenza. I backup meritano attenzione particolare: se il processo di ripristino resuscita dati cancellati, la vostra cancellazione è incompleta, e la risposta abituale è una rotazione documentata con età massima più la riapplicazione delle cancellazioni dopo ogni ripristino.

Trasferimenti, sub-responsabili e dove gira davvero il vostro stack

I trasferimenti fuori dallo SEE necessitano di un meccanismo giuridico, di solito il quadro UE-USA sulla privacy dei dati per destinatari statunitensi certificati o le clausole contrattuali tipo più una valutazione d'impatto del trasferimento negli altri casi.

L'angolo ingegneristico è più semplice di quello giuridico: sapere dove stanno fisicamente i vostri dati. Significa la regione cloud di ogni servizio, la posizione dei backup, la regione del database gestito, la configurazione degli edge della CDN e, soprattutto, il modello di supporto di ogni strumento SaaS che usate. Un fornitore ospitato a Francoforte il cui team di supporto accede alla produzione da fuori SEE è comunque un trasferimento.

In generale consigliamo di tenere i dati personali in regioni UE quando non c'è una ragione forte per fare altrimenti. Elimina un'intera categoria di discussioni, e la differenza di costo è di solito rumore.

Mantenete una lista dei sub-responsabili e tenetela aggiornata. L'articolo 28 richiede un contratto scritto con ciascuno, e quella lista è anche ciò che i vostri clienti chiederanno in due diligence.

Sicurezza per impostazione predefinita, espressa come configurazione

L'articolo 32 chiede misure tecniche e organizzative adeguate. È volutamente vago, ma la base per un sito nel 2026 non è negoziabile:

TLS ovunque, HSTS attivo, nessun contenuto misto.
Password con hash tramite una funzione moderna a costo di memoria, e autenticazione a più fattori disponibile per gli account che contengono dati personali.
Cifratura a riposo per database e backup.
Accesso ai dati personali di produzione limitato per ruolo e registrato, con revisioni che avvengono davvero.
Pseudonimizzazione dove possibile: hash dell'identificativo in analytics, tabella di corrispondenza separata e ad accesso limitato.
Un ripristino testato, non solo un backup.

Protezione dei dati fin dalla progettazione e per impostazione predefinita, all'articolo 25, significa che l'opzione più protettiva è quella che si ottiene senza fare nulla. Casella newsletter non spuntata. Visibilità del profilo privata. Campi facoltativi facoltativi.

La notifica delle violazioni ha bisogno di un runbook

Settantadue ore dalla conoscenza alla notifica all'autorità di controllo non sono molte, soprattutto se la violazione si scopre un venerdì sera. Notate che la proposta Digital Omnibus porterebbe il termine a novantasei ore, ma non è ancora legge.

Preparate in anticipo: chi dichiara un incidente, chi valuta se sono coinvolti dati personali, chi contatta l'autorità, cosa contiene la notifica e come informate gli interessati se il rischio è elevato. Scrivetelo come runbook con ruoli nominati e provatelo una volta. La prima volta che lo usate non dovrebbe essere la prima volta che lo leggete.

La superficie del sito stesso

Una parte del GDPR è visibile in pagina, e vale la pena curare questi dettagli perché sono quelli che vengono segnalati.

L'informativa deve indicare identità e contatti del titolare, finalità e basi giuridiche, destinatari e categorie di destinatari, meccanismi di trasferimento, periodi di conservazione, l'elenco completo dei diritti incluso il reclamo all'autorità di controllo, e se esistono decisioni automatizzate. Scrivetela in un linguaggio che una persona normale possa seguire. Le informative a livelli, con una versione breve che rimanda al dettaglio, funzionano meglio di un muro di testo.

I moduli dovrebbero raccogliere solo il necessario. Ogni campo è una giustificazione che potreste dover dare. Se la casella di consenso al marketing sta nello stesso invio dell'ordine, deve essere separatamente non spuntata e separatamente formulata.

Gli embed di terze parti sono il guasto silenzioso. YouTube in modalità privacy avanzata, mappe dietro un segnaposto da caricare al clic, font auto-ospitati invece che presi da una CDN di terze parti. Ognuna di queste modifiche è piccola ed elimina un rilievo.

Cosa vediamo andare storto più spesso

Dopo abbastanza audit, ricorre sempre la stessa breve lista:

Analytics che carica prima del consenso, di solito perché un tag manager è stato configurato dal marketing e mai rivisto dall'ingegneria.
Pulsanti di rifiuto che attivano comunque il consenso per il comportamento predefinito di uno script di terze parti.
Nessun job di conservazione, su nessuna tabella.
Cancellazioni che dimenticano backup, log e CRM.
Un'informativa che descrive un flusso di dati cambiato diciotto mesi fa.
Liste di sub-responsabili che si fermano ai tre fornitori ovvi.
Registrazioni di consenso senza la versione del testo mostrato.

Nessuno di questi è un problema difficile. È semplicemente lavoro che nessuno ha assegnato.

Chiedere aiuto

Se volete un secondo paio di occhi su un sito esistente, facciamo audit GDPR tecnici che producono un backlog prioritizzato anziché un report: cosa correggere, in che ordine, con una stima per ogni voce. Se state costruendo qualcosa di nuovo, è molto più economico impostare bene modello dati e architettura del consenso fin dall'inizio.

Copriamo anche la superficie più ampia della conformità UE, inclusa l'accessibilità e l'ingresso nel mercato europeo. Ci trovate a office@c9group.dev.

Costruiamo software. Non diamo consulenza legale, e l'interpretazione di un requisito specifico spetta ai vostri legali. Quello che possiamo fare è assicurarci che il sistema faccia ciò che i vostri legali dicono debba fare.