GDPR online shop checklist

What the GDPR actually asks of a shop

The GDPR does not require a particular technology or a particular form. It requires that processing is known, justified and documented, and that individuals can exercise their rights. In a shop that sounds simpler than it is, because few environments generate as many data flows in as short a time as a checkout.

The practical test is a comparison: does what you write about your processing match what technically happens? That is where most gaps sit, not in the existence of documents.

The checklist at a glance

Records of processing

The register is the central document because almost everything else hangs off it. For each activity it needs purpose, data category, group of individuals, recipients, legal basis and retention period.

In a shop that quickly becomes twenty to thirty entries: order processing, customer account, payments, shipping, invoicing, accounting, dunning, newsletter, reviews, contact form, live chat, analytics, retargeting, search engine visibility and so on. The effort is not in writing it, it is in capturing everything.

A useful habit: derive the register from the list of services in use rather than from memory. Anyone with a documented technical landscape almost has the register already.

Choosing legal bases correctly

Every activity needs a basis. Four are relevant in a shop.

• Contract performance for everything belonging to the order: name, address, payment data, delivery address.
• Legal obligation for retention, such as invoices and accounting records.
• Legitimate interest for things like fraud prevention or securing your own IT operation.
• Consent for everything not strictly necessary, above all analytics and advertising.

The most common misassignment is consent for things that are contractually required. Collecting consent for passing the delivery address to a carrier creates double work and makes the consent attackable, because for contract data it is not a viable basis.

Consent and the cookie banner

The banner is the most visible part and the one most often done wrong. Three requirements are central: nothing non essential may be set before a choice is made, declining must be as easy as accepting, and the choice must be documented in a traceable way.

Technically it fails at almost the same point every time. A tracking script loaded in the head sets cookies before the banner is even visible. The banner then looks correct while processing already runs. So check the network traffic on first page load rather than the banner. A look at the developer tools settles it in two minutes.

Processor agreements

You need a data processing agreement with every provider processing personal data on your behalf. That includes hosting, the shop system, payment providers, carriers, email sending, analytics tools and support providers.

The one most frequently overlooked is the hosting provider, because it feels self evident inside a project. In reality it is the provider with the deepest access to everything. Check that one first, and additionally check whether the providers' agreements are current, because the large vendors revise them regularly.

Making data subject rights work in practice

Individuals have the right to access, rectification, erasure, restriction, portability and objection. What matters is not that you know this but that the route exists and works.

For access, a technical export is the clean solution. For erasure, it has to be clear which data can be deleted and which has to remain under statutory retention. Offering both inside the customer account covers most of it. Anyone searching databases by hand for every request becomes the bottleneck as the business grows.

Note that erasure and retention obligations can apply at the same time. An invoice may not be deleted even when a customer asks. The correct route is to explain that this data is legally bound and to delete everything else.

Deletion concept

Every data category needs a period. A common breakdown looks like this: order data and invoices ten years for tax reasons, customer data until the account is closed plus the remaining period, cart data a few weeks, newsletter data until withdrawal, server logs a few months.

What matters is implementation, not the document. A concept without automated deletion stops being true after two years. Set up a job per category that deletes, and check once a quarter that it still runs.

When it becomes a breach

Not every mistake is a reportable breach. It becomes reportable when a risk to the rights and freedoms of individuals arises, for instance in a data leak involving personal data. Those cases usually carry short deadlines, which is why the process has to be known in advance.

The second part that regularly goes missing is internal documentation: what happened when, what was done, why it was or was not reported. Without those notes there is no evidence of an appropriate response when it matters. The legal framework for these questions is covered systematically in the Legal & Compliance seminar.

Frequently asked questions

Do I need a data protection officer?

It depends on the size and nature of the processing. A DPO is not triggered by a fixed headcount but by extensive processing. A shop with broad tracking, several payment services and a customer account can qualify even when the company is small. The threshold should be assessed against the actual processing.

Are guest orders better for privacy?

They are better in one respect: no customer account with its own data set is created. The difference is smaller than it looks though, because order data is processed and retained either way. The advantage for the merchant runs the other way, since a customer account raises the repurchase rate and therefore revenue.

What if tracking loads before consent?

Then processing happens without a legal basis, even if the banner looks correct. That is the most common technical mistake and the most severe one, because it affects every page. The check is simple: on first load, look at the network log and see whether analytics or advertising endpoints are called before the choice.

Do I have to write the privacy notice myself?

You are responsible regardless of who writes it. Templates can provide the frame, but adapting it to your actual processing remains your job, and that is exactly where mistakes arise. So at minimum verify that every service named is genuinely used and that every service used is named.

How long may I keep order data?

Order data and invoices fall under statutory retention periods and generally may not be deleted for ten years. That applies only to the data relevant to accounting however. Additional information, such as a free text field with a note or a list of products viewed, is not covered by that and should be deleted after its own period. A proper breakdown therefore separates mandatory accounting data from voluntary data within the same order.

Does the GDPR apply to reviews and guestbooks?

Yes. As soon as personal data is published, for instance a name next to a review, that is processing with its own legal basis and its own retention periods. What is frequently missing in such areas is a way to have your own review removed again. That option should exist to the same extent as the right to object.