GDPR Compliance Checklist for WordPress Stores

GDPR compliance for WordPress stores isn't a policy, it's a config

I've audited WordPress stores where the privacy policy was rewritten last year, the lawyer signed off, and the site still fired Google Analytics before anyone clicked accept. That gap between "we have a policy" and "the site actually behaves that way" is where most GDPR risk lives. This post is about closing that gap: the plugins, settings, and code patterns that actually enforce compliance, not the legal theory behind it.

GDPR applies to your store if you touch EU data, period

GDPR isn't a regional nice-to-have you can skip because your business is registered outside Europe. Under Regulation (EU) 2016/679, the law applies to the processing of personal data of anyone in the Union, regardless of where the company doing the processing is established. If you sell to EU customers, or even collect EU email addresses through a newsletter signup, this applies to you.

It's broader than checkout data too. Support tickets, marketing lists, analytics logs, anything that ties an action to an identifiable person falls under the regulation.

The fines are the part that gets people's attention. Under GDPR Article 83, penalties for serious violations can reach up to 4% of annual global turnover or €20 million, whichever is higher, according to the regulation itself. That's a business-ending number for most small stores, not a slap on the wrist.

My default assumption when I take on a store audit: treat it as in scope unless the owner can genuinely show zero EU traffic and zero EU subscribers. Most can't.

Consent and cookies: the configuration most stores botch

This is the single most common gap I find. Cookies for analytics, tracking pixels, and retargeting need explicit consent before they fire, not after. The EDPB's guidance on consent is specific: consent must be freely given, specific, informed, and unambiguous before cookies are placed on a user's device, according to the EDPB Guidelines 05/2020 on consent.

A cookie notice sitting quietly at the bottom of the page that doesn't block anything isn't consent. It's decoration. Real compliance means checkboxes default to unchecked, categories are separated (analytics, marketing, functional), and nothing in a non-essential category loads until the visitor actively opts in.

Plugins like Complianz or GDPR Cookie Consent for WordPress handle the mechanics reasonably well. But the plugin alone doesn't save you if your privacy policy doesn't match what the banner claims, or if a tag manager is still firing scripts in the background regardless of consent state.

Here's the test I run on every audit: open the site in an incognito window, don't touch the consent banner, and watch the network tab. If analytics or ad pixels fire before you click anything, that's a breach sitting right there in production. Worth checking on your own store before anyone else finds it for you.

Data retention schedules and the Right to be Forgotten

You cannot keep customer data forever just because deleting it is annoying. GDPR requires personal data be kept in a form that permits identification for no longer than necessary, per Article 5(1)(e) of the regulation.

In practice, that means you need an actual retention schedule: how long you keep order data, support emails, newsletter subscribers, abandoned cart records, analytics logs. Orders tied to tax or accounting obligations can legitimately be kept longer. Marketing lists and non-essential logs generally can't.

WooCommerce doesn't purge old data on its own. If you want automated retention, you're looking at a custom scheduled task, a retention-focused plugin, or a genuine quarterly manual review. None of these are hard to build, but none of them happen automatically either, which is exactly why they get skipped.

This connects directly to the Right to be Forgotten. Under GDPR Article 17, customers can request erasure of their personal data without undue delay, with exceptions where legal retention rules apply. If you can't produce a data map showing what you hold and where, you can't honor that request properly, and you definitely can't prove you honored it if you're ever asked. Build the data map before you need it, not after a request lands in your inbox.

Processor agreements and third-party tools

Every vendor that touches customer data on your behalf needs a signed Data Processing Agreement. Stripe, your email platform, your hosting provider, Google Analytics, all of them. GDPR Article 28 requires that processing by a processor be governed by a binding contract with the controller, meaning you, the store owner.

Big platforms make this easy. Stripe and PayPal offer standard DPAs you can accept through account settings. Smaller plugins and custom integrations are where it gets messy: some never mention a DPA at all, and if a vendor has a breach, you can end up personally liable for a contract that never existed.

On the API and webhook integration work I do, this is one of the first things I check before wiring anything into a client's checkout: does this vendor have a DPA path, and has anyone actually signed it. If a vendor refuses to offer one, that's a signal to find a different tool, or build a narrower custom integration where you control exactly what data leaves your server. I've written before about how loose API integration habits cause support headaches; the same sloppiness that causes silent sync failures is usually what causes missing DPAs too.

Customer data access and export rights

GDPR Articles 15 and 20 give customers the right to a copy of their personal data in a structured, commonly used, machine-readable format, according to the regulation.

WooCommerce has a built-in exporter under Tools > Export Personal Data, and it's a decent starting point. But it typically only covers order history and user profile fields. It doesn't touch email marketing lists, support ticket history, or custom fields you may have added through a plugin or your own code.

Test this yourself. Request your own data the way a customer would and check what actually comes back. If communications are stored separately, whether through a logging plugin or a third-party helpdesk, that data needs its own export path or a documented reason it's out of scope.

Data portability matters beyond compliance box-checking too. A customer's right to move their data to a competitor is uncomfortable to think about, but a clean export is genuinely the baseline for trust in an online store. Stores that hide behind a broken export process rarely have a good story to tell if they're ever asked to produce one under pressure.

Audit and verify: the final check

Everything above comes together in one worksheet. List every category of data you collect, where it physically lives, the legal basis for processing it under GDPR Article 6 (contract necessity and legitimate interest cover a lot of ordinary e-commerce processing without needing separate consent), how long you keep it, and which vendors touch it.

Then walk your own site as a stranger would. Does the consent banner load before any tracking script fires? Does the privacy policy actually describe the cookies you use, or a generic template from three years ago? Are your DPAs signed and filed somewhere you can find them again?

Run a plugin audit alongside this. Every plugin with network access or its own data storage is a compliance surface, not just a performance one. I've covered how a bloated plugin roster becomes a liability from a performance angle before; the privacy angle is just as real, since each plugin that phones home or logs data quietly expands what you're responsible for.

On a marketplace I run, this kind of audit is a recurring task, not a one-time project. Vendors change their terms, plugins get updated, new tracking scripts get added by someone testing a marketing tool. Compliance drifts if nobody checks it.

If any of this looks unfamiliar, don't just take a WordPress checklist as legal sign-off. Get a GDPR specialist or your own counsel to confirm anything you're uncertain about, especially around retention periods that intersect with local tax law. The engineering side is my job. The legal exposure calculation is theirs.

If you ran this audit on your own store today, how many of these would actually pass?

FAQ

FAQ

Do I need GDPR compliance if my store is outside the EU?

Yes, if you process data from EU customers. GDPR applies to the data, not the server location. Geolocation blocks don't exempt you; they're a partial control. Legal basis and DPAs still matter.

Is a cookie consent popup enough to satisfy GDPR?

No. The popup must allow granular consent, default to off, and your privacy policy must explain each cookie. Analytics and marketing cookies need explicit opt-in. Pre-checked boxes or bundled consent violates GDPR.

Can I delete customer orders to comply with the Right to be Forgotten?

Not if you're bound by tax or accounting law. Anonymize the order instead: delete names, emails, addresses, but keep transaction records for audit. Legal basis matters; check local tax retention rules.

What's a Data Processing Agreement and why do I need it?

A DPA is a contract with vendors confirming they handle data according to GDPR rules. Without it, you're liable for their breaches. Request DPAs from Stripe, Mailchimp, hosting providers, and other data-touching tools.