GDPR for Online Stores: What You Must Do (and What You Can Skip)

GDPR has applied since May 2018, and yet most store owners still sit in one of two camps: either it is a terrifying legal minefield, or it is something a "small" shop can quietly ignore. Both readings are wrong, and both cost you. The regulation is genuinely serious — fines are real and complaints are easy to file — but for a normal PrestaShop store selling normal consumer products, the actual obligations are finite, mostly one-time, and several of them are already built into the software you are running. The trick is knowing which requirements are non-negotiable, which are widely misunderstood, and which heavy-sounding obligations (a Data Protection Officer, an Impact Assessment, deleting every byte on demand) almost certainly do not apply to you at all. This guide draws that line for a PrestaShop merchant specifically.

One scoping note up front, because it changes everything: GDPR follows the customer, not your company's address. If you sell to people in the EU, GDPR applies to those orders even if your business is in the US, the UK, or anywhere else. There is no revenue floor and no "we're too small" exemption. So the question is never "does this apply to me" — it is "what does it actually require, and what can I stop worrying about."

The must-do list versus the can-skip list — at a glance

Before the detail, here is the whole article in one table. Everything below expands these rows; the point of the table is that the scary-sounding obligations on the right are the ones a typical store can set aside.

What you must do

1. A privacy policy that a human can read

This is the one obligation with zero wiggle room. You need a privacy policy written in plain language that tells customers what data you collect (names, emails, addresses, payment details, browsing and IP data), why you collect each type, how long you keep it, who you share it with, and how they exercise their rights. The "who you share it with" line matters more than people expect: every PrestaShop store quietly hands data to third parties — your payment gateway, your carrier, your analytics, your email-sending service. You are supposed to name those recipients or at least identify clear recipient/processor categories — and keep processor contracts (DPAs) in place with each of them.

In PrestaShop, build this as a CMS page (Design → Pages in 1.7/8/9, formerly Preferences → CMS in 1.6) and link it from the footer so it is reachable from every page. PrestaShop ships placeholder "Legal Notice" / "Terms and conditions" CMS pages on a fresh install — treat those as empty templates, not as a finished policy. So what does this buy you? A single, honest, footer-linked page is the document a data-protection authority asks for first, and it is the cheapest piece of compliance you will ever produce. It does not need a lawyer to write, though a review is money well spent; it does need to be true to how your store actually behaves.

2. Opt-in consent for marketing — and a lawful basis for everything else

You cannot drop customers onto a marketing list by default. Newsletter signup must be a deliberate, affirmative act: an unchecked box the customer ticks, or a separate signup form. A pre-ticked "subscribe to our newsletter" box during checkout is the single most common GDPR defect we see on PrestaShop stores, and it is squarely non-compliant. PrestaShop's native newsletter block (ps_emailsubscription) and the registration form both expose these checkboxes — your job is to make sure none of them ships pre-ticked, and that the consent wording is specific ("I want to receive offers" rather than a vague catch-all bundled with the privacy policy acceptance).

Order-related (transactional) emails — confirmations, shipping notices, invoices — need no separate consent; they are necessary to perform the contract. And in most EU countries the ePrivacy "soft opt-in" lets you email existing customers about similar products or services, but only where you obtained their email address during a sale, you offer opt-out at the point of collection and in every message, and you respect it — and the exact conditions vary by national implementation, so check your local rules. So what? You do not have to choke off all email marketing to be compliant — you have to be honest about how someone landed on the list and make leaving it effortless.

3. Data subject rights — and the PrestaShop module that handles most of them

Customers have the right to access their data, correct it, have it erased ("right to be forgotten"), and receive it in a portable, machine-readable format. This is the obligation merchants dread operationally — "am I going to be hand-assembling spreadsheets every time someone emails me?" — and it is exactly where PrestaShop does the heavy lifting for you.

Install the Official GDPR Compliance module (technical name psgdpr, free from PrestaShop). It does two concrete things. On the customer side, it adds a "GDPR - Personal data" block to the logged-in customer's account, where they can download their own data as PDF and CSV without ever contacting you — that single feature satisfies the access and portability rights for most requests. On your side, the module's configuration page (Modules → Module Manager → configure psgdpr) is where you action deletion and anonymization requests, customize the consent checkbox text, and choose which forms and modules display a consent block. Properly built modules register with psgdpr so their stored data is included in the export — that is what the platform's "make your module GDPR-compliant" hook is for, and it is worth checking that the third-party modules you rely on actually do this.

So what does that mean in practice? Most access requests resolve themselves — the customer self-serves from their account. The ones that reach you are deletion and anonymization requests, and the module gives you a controlled way to handle them rather than running raw SQL against the customer, address and orders tables and hoping you got the foreign keys right.

4. Cookie consent for non-essential cookies

If your store loads anything beyond strictly necessary cookies — analytics, ad pixels, retargeting — you need consent before those scripts fire, with a genuine reject option that is as easy to click as accept. This is a deep topic with its own implementation details on PrestaShop (banner behavior, blocking scripts until consent, the difference between session cookies and tracking cookies), and it deserves its own treatment rather than a rushed paragraph here. We cover exactly what the law requires and how to implement it without breaking your store in cookie consent for PrestaShop, and the broader cookie-and-tracking picture in GDPR and cookie compliance for PrestaShop. For the must-do checklist below, treat "compliant cookie banner in place" as one line item and follow those guides for the how.

5. Reasonable security — not enterprise security

GDPR requires "appropriate technical and organisational measures," and the operative word is appropriate, scaled to the data you hold. For a store processing names, addresses and orders, that means HTTPS across the whole site, current PrestaShop core and modules, strong admin passwords with limited access, secure card handling (which your PCI-compliant gateway already provides — your store should never touch raw card numbers), and backups kept somewhere safe. You do not need a security operations centre. The depth on hardening a PrestaShop install — employee permission profiles, the Advanced Parameters logs, brute-force protection — sits in payment security in PrestaShop for the payment layer and general store-security practice for the rest.

What you can almost certainly skip

This is the half of the topic that nobody tells store owners, and it is where most of the anxiety evaporates. The following obligations exist, but they are written for organisations whose core activity is processing personal data at scale — not for a shop that sells products and happens to keep customer records.

You probably do not need a Data Protection Officer

A DPO is mandatory only if your core activities involve large-scale regular monitoring of individuals, or large-scale processing of special-category data (health, religion, biometrics, and the like). A store selling consumer goods does none of that. You should have someone who owns data protection — usually you, or whoever runs operations — but it is not a formal, registered DPO role, and you do not need to publish DPO contact details.

You probably do not need a Data Protection Impact Assessment

A DPIA is triggered by high-risk processing: systematic large-scale profiling, monitoring of public spaces, or handling sensitive data at scale. Taking orders and sending marketing emails is not high-risk processing. If you later add something genuinely invasive — biometric login, large-scale behavioural profiling, age-verification for restricted goods — revisit this. For a standard catalogue, skip it.

You do not need a checkbox for every individual cookie

A persistent myth says each cookie needs its own consent. In practice, grouping cookies by purpose — strictly necessary, analytics, marketing — and capturing consent per category is what data-protection authorities expect. One toggle per category, not per cookie.

You do not have to delete everything the instant someone asks

The right to erasure has built-in exceptions, and this is the one that protects you. You may — and in most cases must — retain data needed to complete an open order, to meet legal obligations (tax and accounting records, typically held for several years depending on country), or to establish and defend legal claims. So when a customer asks to be forgotten, you remove their marketing profile and account login data, but you keep the order and invoice records the tax authority requires. This is exactly why anonymization exists alongside deletion: the psgdpr module and most third-party GDPR tools let you anonymize a customer (replace the name and contact details with random values) while preserving the order and accounting trail underneath. So what? You stay compliant with the customer's request and with your bookkeeping obligations at the same time — they are not in conflict.

Misconceptions worth puncturing

"GDPR only applies to EU companies." It applies to anyone processing the data of people in the EU, wherever the company sits. Sell into the EU and it applies to you.

"Small stores are exempt." There is no size exemption. A few obligations get a lighter touch for small organisations — the formal record of processing activities (ROPA) can be simplified — but the core duties (lawful basis, transparency, security, data-subject rights) apply at any scale.

"IP addresses aren't personal data." The Court of Justice of the EU settled this: dynamic IP addresses are personal data. That matters in PrestaShop because the platform logs IPs in the connections table (joined to the guest table) and in the admin employee log — so IP logging is processing personal data, and your privacy policy needs to say so.

"We need consent before any page loads." No. Strictly necessary cookies — session, cart, security tokens — load without consent; your store works before a visitor makes a cookie choice. What must wait for consent is analytics and marketing scripts.

The PrestaShop GDPR checklist

Run this once and you have handled the GDPR exposure of a typical store. None of it requires a developer beyond installing a free module.

• Write a real privacy policy as a CMS page under Design → Pages, link it in the footer, and make sure it names your actual processors (payment, carrier, analytics, email).
• Audit every consent box: newsletter block and checkout (ps_emailsubscription) must ship unchecked, with specific wording.
• Install and configure the psgdpr module so customers can self-export their data and you can action deletion/anonymization cleanly.
• Put a compliant cookie banner in place — follow the cookie consent guide for the implementation.
• Confirm HTTPS everywhere and that core, theme and modules are current.
• Set retention periods deliberately — do not keep data forever "just in case." Lean on anonymization to reconcile erasure requests with tax-record retention.
• Write a short record of processing activities (what you collect, why, where it goes, how long you keep it) — for most stores a one-page document, not a project.
• Make sure your terms and conditions reference the privacy policy, and that your wider EU e-commerce obligations (consumer information, withdrawal rights, pricing) are met alongside data protection.

That list covers the overwhelming majority of what a small-to-medium PrestaShop store needs. If you process unusual data, sell age-restricted goods, or operate in a regulated sector like health or finance, you cross into the territory where a DPIA or specialist legal advice genuinely pays for itself — but you will know if that is you.

The honest summary is this: GDPR enforcement is increasing, and the regulation is not going anywhere, but for a normal PrestaShop store it is a finite, mostly one-time setup rather than an ongoing burden. Most of it is a privacy policy, honest consent, a free module, and a cookie banner. The grand, intimidating obligations — DPO, DPIA, instant total erasure — are written for someone else. Handle personal data the way you would want yours handled, name your processors honestly, and give customers the control the law says they are owed. That is compliance, and it is also just a well-run shop.