GDPR checklist for webshops: cookies, consent and customer data

GDPR compliance for a webshop comes down to a finite list: a cookie banner that actually blocks scripts until the customer says yes, a checkout that collects only what the order needs, a lawful basis for every marketing email, a data processing agreement with every tool that touches customer data, a working answer to “delete me”, and a privacy policy that describes what you really do. This article is that list, followed by how you build it in from the start so you never have to retrofit it.

One thing up front: we are developers who build and host webshops, not lawyers. Everything below is practical guidance based on the GDPR, the Danish cookie order, the Danish Marketing Practices Act and Datatilsynet’s published decisions. It is not legal advice. If you have a data breach, an inquiry from Datatilsynet, or you process health data or data about children, talk to a lawyer. What the checklist will do is get the technical side of your shop into a defensible state, which is where most shops actually fail.

Why webshops are exposed

A webshop is one of the most data-heavy things a small business can run. A single order touches name, address, email, phone number, order history and a payment reference, and a typical shop leaks that data into a dozen third-party tools: analytics, ad pixels, the newsletter platform, review widgets, live chat, fraud scoring.

Datatilsynet cannot issue fines itself; it reports cases to the police with a recommended fine. Its first recommendations under the GDPR went to a furniture chain and a hotel group, in both cases for keeping customer data far longer than they needed to, and in both cases the recommended fine was above a million kroner. Retention is also the item most webshops have never thought about. And enforcement rarely starts with an audit. It starts with one annoyed customer writing to Datatilsynet, which is then obliged to look.

The good news is that this is mostly an engineering problem with known solutions.

The checklist

1. Cookies and consent

1. Non-essential scripts do not load before consent. This is the most-failed item. Test it: open your shop in a private window, decline the banner, open the browser’s network tab. If requests to facebook.com or google-analytics.com fire anyway, you are not compliant, whatever the banner says.
2. “Reject all” is as easy as “Accept all”. Same layer, same size, one click.
3. Consent is logged and can be withdrawn. You can show who consented to what and when, and there is a persistent “cookie settings” link in the footer.
4. Only strictly necessary cookies are exempt. Cart, session, the consent cookie itself. Analytics smuggled into the “necessary” category is a named enforcement pattern.
5. Ask whether you need the trackers at all. Datatilsynet stated in September 2022 that Google Analytics cannot be used lawfully without additional measures. Cookieless, EU-hosted statistics need no banner. nbsweb.dk runs self-hosted Umami and has no cookie banner, and we build shops the same way. More in web statistics without cookies.

The full rules for what a banner must say and do are in cookie banner rules, so we will not repeat them here.

2. Checkout and account data

1. Collect what the order needs and nothing else. Name, delivery address, email, and what the carrier needs. A required phone number needs a reason (GLS and PostNord SMS notifications are one). A required date of birth almost never has one unless you sell age-restricted goods.
2. Guest checkout exists. Forcing account creation means processing more data than the purchase requires. Invite them to create an account afterwards.
3. The newsletter box is unticked. Pre-ticked boxes are not valid consent, and the box must never be bundled into “accept terms”.
4. Card data stays with the payment provider. Card numbers must never touch your server. Quickpay, Stripe and MobilePay all provide hosted payment windows or fields for exactly this reason. It is also a PCI DSS requirement, and it shrinks your breach exposure dramatically.
5. Retention is defined and enforced. The Danish Bookkeeping Act requires you to keep invoices and order records for five years from the end of the financial year. That is a legal obligation and a valid reason to refuse deleting invoices. Marketing profiles, abandoned carts and inactive accounts have no such shield: define a retention period and delete on schedule, as an automated job, not a policy PDF nobody runs.

3. Email marketing and abandoned carts

1. Newsletters require consent, with proof. Section 10 of the Danish Marketing Practices Act prohibits marketing emails without prior consent. Store the timestamp and where the sign-up came from. Double opt-in is not required by law but is the cleanest proof you can have.
2. The existing-customer exception is used correctly. Section 10 lets you email your own customers about similar products without fresh consent, if you got the address in connection with a sale, told them at the time, and offer an easy opt-out in every message. It covers buyers. It does not cover people who only created an account or abandoned a cart.
3. Abandoned-cart emails have a basis. If the person has not bought and has not consented to marketing, an abandoned-cart email is unsolicited marketing. Gate it behind the newsletter opt-in or an explicit “email me my cart” button.
4. Unsubscribe works in one click and propagates, including to any synced audiences in ad platforms.

4. Processors, transfers and hosting

1. Every processor has a data processing agreement. Hosting, payment provider (Quickpay, Stripe), shipping platform (Shipmondo, GLS, PostNord), newsletter tool, analytics, helpdesk. The big vendors all offer one; the checklist item is confirming you have actually accepted it and know where it is.
2. You keep a record of processing (Article 30). A simple table: what data, why, lawful basis, where stored, which processors, how long. Shops that get an inquiry lose days reconstructing this. Maintaining it takes an hour a quarter.
3. US transfers are identified. Data sent to US providers currently rests on the EU-US Data Privacy Framework. It is valid today, but it is the third attempt after two predecessors were struck down by the EU Court of Justice, and it is being challenged. Prefer Danish or European providers where an equivalent exists. The full argument is in Danish hosting or American cloud.
4. Security basics are in place. TLS everywhere, a patched platform and plugins, hashed passwords, admin access restricted and behind two-factor, encrypted backups. Unpatched shop software is the most common breach vector and the least defensible.

5. Access, deletion and paperwork

1. You can answer an access request within a month. Know now which systems you would export from: shop database, newsletter tool, helpdesk, ad audiences.
2. You can delete, except what the law says you keep. Deletion is honoured across all systems, invoices stay under the Bookkeeping Act, and the customer is told so.
3. The privacy policy is written from your actual stack. Real processors, real retention periods, real transfers, and a contact for requests. A copied template naming tools you do not use is itself a transparency violation, and it is the first thing Datatilsynet reads.
4. A breach process exists. Notifiable breaches go to Datatilsynet within 72 hours, and you know who would send that notification.

6. What fines actually look like

GDPR fines reach EUR 20 million or 4 % of global turnover on paper. The realistic exposure for a small Danish shop is a recommended fine in the five- to seven-figure kroner range, the hours lost to a Datatilsynet inquiry, and the conversion cost of a checkout customers do not trust, which you pay every single day.

Building it in from the start

Everything above can be bolted on afterwards. It is just expensive: auditing every script, restructuring retention, rewriting policies. Building it in costs almost nothing extra, because it is mostly a matter of making the right default choices.

Data mapping before code

List every data point the shop collects and give each a lawful basis:

Two things follow. Checkout must work without consenting to marketing. And retention differs by basis: invoices are kept for five years, marketing data must be deletable on request. The database schema should reflect that separation, so that deleting a customer anonymises the marketing and behavioural data while keeping the order records the law requires. That is cheap to design in and painful to retrofit.

Hosting in Denmark or the EU

Every service in the stack that touches personal data is a processor, and each one that processes data outside the EU needs a transfer assessment. The fewer of those your shop needs, the more robust it is. We host webshops on European infrastructure by default and prefer Danish or European processors where they are technically equal: Quickpay for payments, Shipmondo for shipping, self-hosted statistics. That way the privacy policy describes reality instead of hedging it.

Payment data out of your hands

With a properly integrated payment provider you never see a card number. What you do store, order references, billing addresses and payment status, is ordinary personal data and follows your normal retention rules. Your job is to sign the provider’s DPA, name them in the privacy policy and understand where they process data.

Logging that helps you rather than hurts you

Three logs a compliant shop should have, and one it should not:

1. A consent log. Who accepted what, when, and which version of the banner.
2. A retention job. A scheduled task that anonymises accounts and carts past their period, and writes down that it ran.
3. An access log for the admin panel. Who looked at which customer, so that you can answer a breach question.
4. Not: raw server logs with IP addresses kept for years “just in case”. Logs are personal data too. Rotate them.

The paperwork the shop ships with

A privacy policy generated from the real data map, a cookie policy that matches what the banner controls, the Article 30 record, signed DPAs, and terms of sale covering the 14-day right of withdrawal. All of it must match the actual implementation.

What this costs

A consent platform runs DKK 0–450 a month at small-shop scale; a lawyer-drafted privacy policy typically DKK 4,000–11,000; a compliance review of an existing shop DKK 7,500–37,000 from specialist consultancies. All prices excluding VAT.

We build webshops with this checklist implemented from day one, from DKK 14,995 as a fixed quote (Byg), and keep them that way under our monthly plans from DKK 375 a month (Basis) to DKK 975 (Vækst): platform updates, consent tooling, security patching. See pricing and webshops.

If you already run a shop and want to know where you stand, the fastest first step is the self-audit from item one: private window, decline the banner, network tab. If more than zero third-party requests fire, you know where to start. And if you are still choosing a platform, the compliance workload differs between hosted and custom, which we cover in Shopify or your own webshop.