GDPR Checklist for Online Shops (Cookies, Consent, Data Rights)

If you run an online shop that sells to EU customers, GDPR compliance comes down to a finite list of concrete items: a cookie banner that actually blocks non-essential scripts until consent, a checkout that collects only what you need, a lawful basis for every marketing email, processor agreements with every tool that touches customer data, working answers to access and deletion requests, and a privacy policy that describes what you really do rather than what a template says. This article is that list, in checkable form.

One thing up front: we are an engineering studio that builds and hosts webshops, not a law firm. This checklist is practical and technical guidance based on the GDPR, the ePrivacy Directive, and published regulator decisions — it is not legal advice. For questions with real legal exposure (a data breach, a regulator inquiry, processing health or children’s data), talk to a lawyer or DPO. What this checklist will do is get the engineering side of your shop into a defensible state, which is where most shops actually fail.

Why online shops are exposed

An e-commerce site is one of the most data-heavy things a small business can operate. A single order touches names, addresses, emails, phone numbers, order history, and payment metadata — and a typical shop leaks that data into a dozen third-party tools: analytics, ad pixels, email platforms, review widgets, live chat, fraud scoring. Regulators have noticed. Fines against e-commerce operators have covered unlawful cookie practices (the French CNIL has fined large retailers and platforms tens of millions of euros over cookies alone), marketing without consent, excessive data retention, and inadequate security. You do not need to be Amazon to get a complaint: most enforcement starts with a single annoyed customer emailing their data protection authority, and the DPA is then obliged to look.

The good news is that shop compliance is mostly an engineering problem with known solutions. Here is the checklist we work through when we build or audit a shop. For the deeper build-side view, see GDPR-compliant webshop development.

Non-essential scripts do not load before consent. This is the single most-failed item. Under the ePrivacy Directive (implemented nationally, e.g. Germany’s TDDDG), anything stored on or read from the visitor’s device that is not strictly necessary requires prior opt-in consent. Analytics, ad pixels (Meta, Google Ads), heatmaps, and most chat widgets are not strictly necessary. Test it: open your shop in a private window, decline the banner, and check the network tab. If facebook.com or google-analytics.com requests fire anyway, you are non-compliant regardless of what the banner says.
“Reject all” is as easy as “Accept all.” Regulators (CNIL explicitly, others in guidance) treat a banner with a one-click accept and a buried reject as invalid consent. Same layer, same prominence.
Consent is recorded and revocable. You can prove who consented to what and when, and a visitor can change their choice later (a persistent “cookie settings” link in the footer).
Strictly necessary cookies are exempt — and only those. Session cookies, the cart, load balancing, and consent storage itself need no consent. Do not smuggle analytics into the “necessary” category; that is a named enforcement pattern.
Consider whether you need the trackers at all. Cookieless, EU-hosted analytics needs no banner interaction to run — see GDPR-compliant analytics. Every tracker you remove is a consent problem you no longer have.

Checkout and account data

Data minimization at checkout. Collect what the order requires: name, delivery address, email, and payment routing. A required phone number needs a reason (carrier notification is one); a required date of birth almost never has one unless you sell age-restricted goods.
Guest checkout exists. Forcing account creation means processing more data than the purchase requires. Offer guest checkout; invite account creation afterwards.
The marketing checkbox is unticked. Pre-ticked boxes are not valid consent (CJEU, Planet49). The newsletter opt-in at checkout must be an active, unticked choice — and never bundled into “accept terms.”
Payment data stays with the payment processor. Card numbers should never touch your server; use the hosted fields or redirect flow of Stripe, Mollie, Adyen, or your PSP of choice. This is also a PCI DSS requirement, and it dramatically shrinks your breach exposure.
Retention is defined and enforced. Order and invoice data must be kept for tax law (commonly 5–10 years depending on member state) — that is a legal obligation, and a legitimate reason to refuse deletion of invoices. But marketing profiles, abandoned carts, and inactive accounts have no such shield: define retention periods and actually delete on schedule, ideally as an automated job rather than a policy PDF nobody executes.

Email marketing and abandoned carts

Newsletter = consent, with proof. Double opt-in is not literally mandated everywhere, but it is standard practice in Germany and Austria and the cleanest way to prove consent anywhere. Store the timestamp and source.
The existing-customer exception is used correctly. ePrivacy allows emailing your own customers about similar products without fresh consent, if you told them at collection and offer opt-out in every message. This “soft opt-in” covers post-purchase marketing to buyers — it does not cover people who only signed up for an account or abandoned a cart without buying.
Abandoned-cart emails have a lawful basis. If the person has not purchased and has not consented to marketing, an abandoned-cart email is unsolicited marketing in most member states’ interpretation. Gate it behind the newsletter opt-in or an explicit “email me my cart” action.
Unsubscribe works in one click and propagates. Including to any synced audiences in ad platforms.

Third parties, transfers, and hosting

Every processor has a DPA. Your hosting provider, email platform, payment processor, fulfilment partner, and analytics tool each need an Article 28 data processing agreement. The big vendors all offer one; the checklist item is confirming you have actually accepted it and know where it is.
You maintain a record of processing (Article 30). A simple table: what data, why, lawful basis, where stored, which processors, retention. Most shops that get an inquiry lose days reconstructing this; maintaining it takes an hour a quarter.
US transfers are identified and covered. Data sent to US providers currently rides on the EU–US Data Privacy Framework. The DPF is a valid mechanism today, but it is the third attempt after Safe Harbor and Privacy Shield were both struck down by the CJEU (the latter in Schrems II), and it faces ongoing challenges. Treating US transfers as a dependency risk — and preferring EU-hosted services where an equivalent exists — is the resilient position. We build on EU infrastructure for exactly this reason; the full argument is in EU hosting vs US cloud.
Security basics are in place. TLS everywhere, patched platform and plugins, hashed passwords, admin access restricted and 2FA’d, encrypted backups. Article 32 requires “appropriate” security; unpatched shop software is the most common breach vector and the least defensible.

Data rights and the paperwork

You can answer an access request within one month. A customer can ask for everything you hold on them. Know now which systems you would export from (shop database, email tool, support desk, ad audiences) rather than discovering it under deadline.
You can delete — except what law requires you to keep. Deletion requests get honored across all systems, with invoices retained under tax law and the customer told so.
Your privacy policy is written from your actual stack. List the real processors, real retention periods, real transfers, and the contact for rights requests. A copied template that names tools you do not use is itself a transparency violation — and the first thing a DPA reads.
Breach process exists. You know that notifiable breaches go to the supervisory authority within 72 hours, and you know who would send that notification.
Check whether you need a DPO or an EU representative. Most small shops do not need a DPO, but large-scale tracking can trigger it, and non-EU shops selling into the EU generally need an Article 27 EU representative.

What this costs — and what non-compliance costs

Honest market numbers: a consent management platform runs €0–60/month at small-shop scale; a lawyer-drafted privacy policy for a standard shop typically €500–1.500; a compliance audit of an existing shop €1.000–5.000 from specialist consultancies. The expensive path is retrofitting: rebuilding a shop whose theme hard-codes trackers, whose checkout over-collects, and whose email flows lack consent records routinely costs more than building it right the first time.

Our first-party pricing: we build webshops with this checklist implemented from day one — Establish at €1.000 one-time, Build from €2.200 — and keep them that way (platform updates, consent tooling, security patching) under our monthly plans from €50 (Essential) to €130 (Growth). Compare that to the enforcement side: GDPR fines reach €20M or 4% of global turnover in theory, but the realistic small-shop exposure is four-to-five-figure fines plus the hours lost to a DPA inquiry — and the conversion cost of a distrustful checkout, which you pay every day.

If you would rather have this list implemented than maintained as a spreadsheet, that is what our webshop development service is for. And if you are still choosing a platform, the compliance workload differs meaningfully between hosted and custom — see Shopify vs custom webshop.