Un ecommerce non tratta solo un nome e un'email: tratta indirizzi, storico ordini, mezzi di pagamento e comportamento di navigazione, spesso incrociati con pixel pubblicitari. Sapere chi risponde di cosa, tra te e i fornitori che usi (gateway di pagamento, piattaforma, strumenti di marketing), evita sia il rischio legale sia le promesse commerciali che nessuno può mantenere davvero.
Un ecommerce non tratta solo "un nome e un'email". Tratta indirizzi di fatturazione e spedizione, storico ordini, dati di pagamento (anche solo per farli transitare), comportamento di navigazione e, quasi sempre, cookie di remarketing che parlano con Meta o Google Ads. È un perimetro più ampio di quello di un sito vetrina, e va trattato come tale.
Questa guida non è un corso di diritto e non sostituisce un consulente privacy per il tuo caso specifico. Serve a chi gestisce (o sta per aprire) un negozio online e vuole capire quali obblighi sono reali, chi ne risponde tra te e i fornitori che usi, e dove si nascondono gli errori più comuni.
I dati che un ecommerce tratta davvero
Un account cliente, di per sé, non è diverso da quello di un sito con un modulo di contatto: nome, email, magari un telefono. Quello che cambia in un ecommerce è tutto quello che si aggiunge intorno all'acquisto:
Indirizzi di fatturazione e spedizione, spesso diversi tra loro, e a volte legati a più destinatari.
Storico ordini: cosa ha comprato, quando, con quale spesa media. È un profilo, anche se non lo chiami così.
Dati di pagamento, anche quando non li conservi tu: il fatto che "passino" dal tuo sito verso un gateway ti coinvolge comunque nella catena di responsabilità.
Comportamento di navigazione: carrelli abbandonati, prodotti visti, tempo sulle pagine, spesso raccolto da cookie e pixel di terze parti.
Dati per la fattura, in particolare per i clienti aziendali: partita IVA, codice fiscale, codice destinatario.
Il punto non è accumulare timore, ma chiarezza: più categorie di dati tratti, più aumentano gli obblighi di informativa (art. 13 del GDPR) e le decisioni su dove quei dati vivono, per quanto tempo, e chi può vederli.
Checkout e pagamenti: cosa tocca a te, cosa al gateway
Il dato di pagamento vero e proprio, numero di carta e CVV, è quello che la maggior parte dei commercianti online non dovrebbe mai vedere direttamente. Gli standard PCI DSS (Payment Card Industry Data Security Standard) esistono proprio per definire chi tratta quel dato e con quali garanzie.
Per i merchant che esternalizzano interamente il trattamento delle carte, tipicamente reindirizzando il cliente a una pagina di pagamento ospitata da un fornitore conforme (Stripe, PayPal, Nexi e simili) o integrandola tramite iframe, il PCI Security Standards Council prevede un questionario di autovalutazione semplificato, il SAQ A. Con l'aggiornamento della versione 4.0.1, in vigore dal 31 marzo 2025, il Council ha aggiunto criteri specifici per le integrazioni a iframe: il commerciante deve confermare che il proprio sito non è esposto ad attacchi di script che potrebbero compromettere la pagina di pagamento, ottenendo conferma scritta dal fornitore terzo oppure applicando in autonomia le misure previste dai requisiti 6.4.3 e 11.6.1 dello standard.
In pratica, per chi vende online la domanda giusta al proprio fornitore di ecommerce o al proprio sviluppatore non è "i pagamenti sono sicuri?", ma:
Il numero di carta transita mai dal mio server, anche per un istante?
L'integrazione è a redirect, a modulo ospitato o a iframe?
Quale livello di SAQ (autovalutazione PCI DSS) mi compete con questa integrazione?
Chi si assume la responsabilità se il gateway stesso viene violato?
Su KeideaCMS i pagamenti con carta, PayPal e bonifico sono dichiarati come integrati nel core tramite Stripe e PayPal: il numero di carta non transita quindi come testo libero salvato nel database del sito, ma il livello esatto di SAQ dipende dal tipo di integrazione tecnica usata e va verificato con il fornitore di pagamento per il caso specifico, non assunto a priori.
Cookie, pixel e remarketing: dove sbagliano quasi tutti
Il Garante per la protezione dei dati personali, con le "Linee guida cookie e altri strumenti di tracciamento" (provvedimento n. 231 del 10 giugno 2021), ha chiarito alcuni punti che restano l'errore più frequente sugli ecommerce italiani:
Il consenso deve derivare da un atto positivo inequivocabile. Il semplice scorrimento della pagina non vale come consenso.
I cookie di profilazione (compresi i pixel pubblicitari di Meta e Google Ads) richiedono consenso preventivo: non possono essere attivi per impostazione predefinita, in linea con il principio di privacy by design e by default dell'art. 25 del GDPR.
Il cookie wall, cioè obbligare l'utente ad accettare i cookie per poter usare il sito, è considerato illecito: viola il requisito di libertà del consenso.
L'errore tipico su un ecommerce non è l'assenza del banner: è il pixel di remarketing che parte comunque, magari perché installato direttamente nel tema o tramite un tag manager configurato "a tappeto", prima ancora che l'utente clicchi su qualcosa. Se fai retargeting su chi ha abbandonato il carrello, quella lista di utenti è costruita con dati raccolti da un cookie di profilazione: va bloccato fino al consenso, non solo dichiarato in privacy policy.
Email post-vendita e soft spam
Dopo un acquisto, molti ecommerce iscrivono automaticamente il cliente alla newsletter. Il GDPR ammette, a certe condizioni, l'invio di comunicazioni commerciali su prodotti o servizi analoghi a chi ha già acquistato, anche senza un consenso esplicito raccolto a parte: è la prassi nota come soft spam. Le condizioni chiave sono che il cliente sia stato informato chiaramente di questa possibilità al momento della raccolta dei dati, e che gli venga sempre offerta, in modo agevole e gratuito, la possibilità di opporsi, sia al momento della raccolta sia in ogni comunicazione successiva.
Due errori frequenti: iscrivere alla newsletter generica (non solo prodotti analoghi) chi ha comprato una volta, e non prevedere un link di disiscrizione chiaro in ogni email. Se il cliente non ha dato un consenso esplicito e ampio al marketing, il perimetro resta stretto: prodotti simili a quello acquistato, non l'intero catalogo o comunicazioni di terze parti.
Se il negozio viene violato: le 72 ore
Se un ecommerce subisce una violazione di dati personali, ad esempio un accesso non autorizzato al database ordini, il titolare del trattamento deve notificarla al Garante entro 72 ore dal momento in cui ne viene a conoscenza, salvo che sia improbabile che comporti un rischio per i diritti delle persone (art. 33 GDPR). Se il rischio per gli interessati è elevato, va comunicata anche direttamente ai clienti coinvolti, senza ingiustificato ritardo (art. 34 GDPR).
Il punto pratico: le 72 ore partono dalla scoperta, non da quando hai finito di capire tutto quello che è successo. Una procedura scritta, anche breve, che dica chi decide, chi scrive al Garante e chi avvisa i clienti, evita di perdere ore preziose a stabilire chi deve occuparsene mentre l'orologio già corre. Se il sito è sotto attacco in questo momento, la procedura per le prime ore è trattata nella guida su sito web hackerato, cosa fare; il tema delle copie da cui ripartire è in backup sito web.
Registro dei trattamenti e DPIA: quando servono davvero
Il registro dei trattamenti (art. 30 GDPR) non è riservato alle grandi aziende: si applica anche a chi tratta dati in modo non occasionale, cosa che vale per qualunque ecommerce con clienti ricorrenti. Tenerlo aggiornato, con le categorie di dati trattati, le finalità e i fornitori coinvolti (piattaforma, gateway di pagamento, corriere, strumenti di email marketing), è spesso il primo documento richiesto in caso di verifica.
La valutazione d'impatto (DPIA, art. 35 GDPR) è un livello diverso: serve quando il trattamento presenta probabilmente un rischio elevato, ad esempio con profilazione sistematica ed estesa usata per decisioni che producono effetti significativi sulle persone, o monitoraggio sistematico su larga scala. Un ecommerce che fa remarketing standard, con consenso raccolto correttamente, di norma non rientra in automatico in questo perimetro: ma la valutazione va fatta sul caso concreto, non data per scontata in un senso o nell'altro.
KeideaCMS
Vuoi sapere cosa succede oggi ai dati dei clienti sul tuo ecommerce attuale?
Richiedi l'audit di sicurezza →Contatti
Area di rischio, obbligo, chi se ne occupa
| Area | Cosa richiede la norma | Chi se ne occupa | Errore comune |
| Account e ordini | Informativa chiara (art. 13), misure tecniche adeguate (art. 32) | Titolare del sito | Privacy policy generica, scaricata da un template |
| Cookie e pixel remarketing | Consenso attivo, nessuna casella pre-spuntata (Garante 2021) | Titolare + piattaforme ads | Pixel già attivo prima del consenso |
| Dati di pagamento | Perimetro PCI DSS, SAQ in base al tipo di integrazione | Gateway di pagamento | Salvare numeri di carta "per comodità" fuori dal gateway |
| Email post-vendita | Soft spam solo su prodotti analoghi, opt-out sempre visibile | Titolare del sito | Newsletter generica senza consenso esplicito |
| Violazione dei dati | Notifica al Garante entro 72 ore (art. 33), ai clienti se rischio elevato (art. 34) | Titolare del sito | Attendere di "capire tutto" prima di far partire la procedura |
Cosa dichiara oggi KeideaCMS (e cosa no)
Sulla pagina sicurezza, al 18 settembre 2026, KeideaCMS dichiara WAF nativo nel core, cifratura AES-256-CBC dei dati inseriti nei form (nome, email, telefono, messaggio), autenticazione a due fattori TOTP, scansione file a 6 livelli, geo-blocking da paesi extra UE e un audit trail con retention dei log configurabile, con riferimento esplicito all'art. 32 del GDPR e alle misure tecniche richieste dalla direttiva NIS2. Sulla pagina realizzazione ecommerce sono dichiarati pagamenti con carta, PayPal e bonifico integrati nel core tramite Stripe e PayPal, con registro pagamenti e riconciliazione automatica degli ordini.
Va detto con precisione cosa questo copre e cosa no. La cifratura dichiarata riguarda i campi dei form: non risulta descritta, in quella pagina, come estesa automaticamente all'intero database ordini o ai dati di pagamento, che restano nel perimetro dei gateway usati. Un CMS gestito può ridurre alcuni rischi tecnici (WAF, scansione file, accessi protetti), ma non sostituisce gli obblighi che restano del titolare: informativa, consensi, registro dei trattamenti, procedura di data breach. Non presentiamo nessuna piattaforma, la nostra compresa, come "GDPR compliant" per il solo fatto di usarla: la conformità è un insieme di misure tecniche e organizzative, non una funzione da attivare. Il confronto tecnico con altre soluzioni è nella pagina di confronto; l'inquadramento generale degli obblighi GDPR su un sito, non specifico per l'ecommerce, è nella guida GDPR sito web.
Checklist prima di aprire o rinnovare l'ecommerce
Privacy policy scritta per il tuo negozio, non un template generico copiato da un altro sito.
Cookie banner con consenso attivo: nessuna casella pre-spuntata, nessun cookie wall.
Pixel di remarketing (Meta, Google Ads) bloccati finché l'utente non dà il consenso.
Verifica scritta con il fornitore di pagamento su tipo di integrazione (redirect, hosted, iframe) e livello SAQ che ti compete.
Nessun dato di carta salvato in campi note, fogli di calcolo o email interne.
Email post-vendita limitate a prodotti analoghi se non c'è consenso esplicito, con link di disiscrizione sempre visibile.
Procedura scritta per un data breach: chi decide, chi notifica il Garante, entro quante ore, chi avvisa i clienti.
Registro dei trattamenti aggiornato, anche per un negozio di piccole dimensioni.
Retention dei dati definita per categoria (ordini, fatturazione, marketing), non "per sempre" di default.
Verifica, con un consulente se serve, se il tuo tipo di profilazione richiede una DPIA.
Nessuno di questi punti rende un ecommerce invulnerabile o "a norma" in automatico. Sono gli obblighi e le domande che, verificati e messi per iscritto, evitano la parte più costosa di un incidente: scoprire dopo che nessuno sapeva chi doveva fare cosa.
Fonti e data di controllo
Consultate il 18 settembre 2026. Le norme descrivono obblighi generali: la loro applicazione al tuo caso specifico va verificata con un consulente privacy o legale. Le pagine prodotto descrivono ciò che il fornitore dichiara, non una certificazione di conformità.
Regolamento (UE) 2016/679 (GDPR), artt. 13, 25, 30, 32, 33, 34, 35, 37.
Garante per la protezione dei dati personali, Linee guida cookie e altri strumenti di tracciamento, provvedimento n. 231 del 10 giugno 2021.
PCI Security Standards Council, FAQ: How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts? (criteri v4.0.1, in vigore dal 31 marzo 2025).
KeideaCMS, pagina sicurezza e pagina realizzazione ecommerce.
