GDPR for e-commerce: what actually needs fixing on your store in 2026
Your privacy policy says one thing. Your tag manager does another. What to audit, cut and fix on an EU-facing store, with the 2026 rule changes explained.
Shakil IlhamFounder
Commerce
On 1 September 2025 the French regulator fined Shein 150 million euro and Google 325 million euro over advertising cookies set without valid consent. Shein is an online shop. Its privacy policy was not the thing that failed. What its website did in the first two seconds of a page load was.
Your store is not Shein, and no supervisory authority is opening a file on you this quarter. The realistic version for a mid-sized shop selling into the EU is duller. A customer asks for a copy of their data, or complains about your banner, and you find out that nobody in the business can say what your email platform, your Meta pixel and your abandoned cart app are holding, or for how long.
That gap between what the policy page says and what the site does is the whole problem. Everything below is how to close it.
Not legal advice. This is technical and operational guidance from a development team. Your obligations depend on what you sell, who you sell it to and where your data goes. Get a lawyer or a data protection specialist to review the specifics before you rely on anything here.
Start by watching your own site load
Before you change anything, open your storefront in a private window with the browser network tab recording. Load a product page. Do not touch the cookie banner. Now count the requests going to domains you do not own.
On most WooCommerce and Shopify stores that have been running for a few years, the answer is somewhere between four and fifteen. Analytics, an ads pixel, a chat widget, a reviews script, a font file, a heatmap tool that someone trialled in 2023 and never removed.
If any of those fire before consent, your banner is decorative. That is the single most common finding, and it is usually a five minute fix in tag manager rather than a rebuild.
Where the rules actually stand in 2026
There has been a lot of noise about cookie banners disappearing. They are not disappearing.
| What you may have heard | Where it stands as of September 2026 |
|---|---|
| The ePrivacy Regulation will replace the old cookie directive | The Commission withdrew that proposal in its 2025 work programme after years of deadlock. The 2002 directive, as implemented in each member state's national law, still governs cookies. |
| Cookie rules are moving into the GDPR | Proposed. The Digital Omnibus package of 19 November 2025 would add Articles 88a and 88b to the GDPR. It is still in negotiation. |
| Browser-level consent signals will kill the banner | The Council's June 2026 position removed the browser-signal article from its negotiating text. Parliament has not settled its own position. |
| You can wait for the new rules before fixing anything | Application in 2027 at the earliest, if the consent provisions survive at all. Enforcement under the current rules has not paused. |
The useful read on all of this: if your store already blocks non-essential scripts until someone opts in, records refusals, and offers a reject option as easy to find as accept, you are already close to what the proposed text would ask for. Getting today's rules right is the cheapest way to prepare for whatever passes.
Build a data map before you buy a consent tool
Most stores skip this and go straight to installing a banner plugin. Then a subject access request arrives and nobody knows which systems to search.
A data map is a spreadsheet. One row per system that touches customer data, and it takes an afternoon.
| System | What it receives | Why | Where it sits | Kept for | Contract in place |
|---|---|---|---|---|---|
| Stripe | Name, email, billing address, card token | Take payment | EU and US | Per Stripe's terms | DPA signed |
| Klaviyo | Email, name, order history, browse events | Marketing email | US | Until unsubscribe plus X months | DPA signed |
| Meta | Hashed email, event data | Remarketing | US | Per Meta's terms | Controller terms |
| Reviews app | Email, order number, product | Post-purchase review request | Unknown | Unknown | Not checked |
The rows that say "unknown" are the ones worth your afternoon. Every app you have installed since launch is a row on this table, whether or not you filled it in.
Ask six things of each system. What does it get, why does it get it, where is it processed, who can see it, how long is it kept, and who does it pass the data on to.
Cookies: sort them properly, then actually block them
Installing a banner does not make a store compliant. What matters is whether the banner controls the scripts.
| Category | Typical examples | Consent needed before it loads |
|---|---|---|
| Strictly necessary | Session ID, cart contents, login token, CSRF token, load balancer routing, fraud checks at checkout | No |
| Preferences the user asked for | Currency selector, language choice, saved region | No, where the user actively chose it |
| Analytics | GA4, Hotjar, Microsoft Clarity, most heatmap and session recording tools | Yes |
| Advertising and remarketing | Meta pixel, Google Ads, TikTok, Pinterest, affiliate tracking | Yes |
| Everything else that loads a third party | Chat widgets, embedded video, review scripts, personalisation engines | Yes, unless it only loads after the customer clicks it |
Some national regulators carve out a narrow exemption for first-party audience measurement that never leaves your own site and is not used for anything else. France is the well-known example. Do not assume it covers your GA4 setup, because it usually does not.
The order of operations that matters:
- Page loads with nothing but necessary scripts.
- Consent tool loads and reads any stored preference.
- Customer chooses. Accept all, reject all, or per-category.
- Only the allowed tags fire.
- The choice is recorded with a timestamp and the version of the banner text they saw.
Point five is the one people forget. If you cannot show what someone consented to and when, you cannot demonstrate consent, and demonstrating it is your job rather than theirs.
Make reject as easy as accept
The banner pattern regulators keep striking down is the one where accept is a big coloured button and reject is grey text three clicks deep. The CNIL and other authorities have been issuing formal notices about exactly this since 2021, and the Shein decision came from the same programme of work.
Reject all on the first layer, same size, same prominence. No pre-ticked boxes. No treating scrolling as agreement. No cookie wall that blocks the shop unless the customer accepts tracking.
Withdrawal has to be as easy as consent was, which in practice means a small link in the footer that reopens the preferences panel. Two minutes of dev work, and it is one of the first things an auditor looks for.
Cut the checkout fields you do not need
Data minimisation and checkout conversion pull in the same direction here, which does not happen often.
| Field | Verdict | Reasoning |
|---|---|---|
| Name, delivery address, email | Keep | You cannot fulfil the order without them |
| Phone number | Keep only if your carrier needs it | Mark it optional if the courier does not require it |
| Date of birth | Drop unless you sell age-restricted goods | Otherwise you are storing an identity document field for no reason |
| Gender | Drop unless it changes what you ship | For personalisation is not a purpose, it is a wish |
| Company name and VAT number | Keep for B2B | Needed for the invoice |
| How did you hear about us? | Move it post-purchase | It is market research, not order data |
| Marketing opt-in, pre-ticked | Remove the tick | A pre-ticked box is not consent |
Every field you delete is one less thing to secure, one less thing to include in a data request, and one less reason for a customer to abandon on mobile.
Order updates and marketing are different things
Someone who bought a lamp expects to hear that the lamp has shipped. That is not the same as agreeing to your Black Friday campaign.
| Transactional | Marketing | |
|---|---|---|
| Examples | Order confirmation, dispatch notice, delivery delay, refund receipt, password reset | Newsletter, promotions, product launches, win-back flows, review requests in most cases |
| Basis | Performing the contract | Consent, or a national soft opt-in rule where one applies and its conditions are met |
| Opt-out | Not applicable, they need the information | Unsubscribe in every message, honoured within a day |
| Where the consent is captured | Not required | A separate unticked box, logged with time and source |
Soft opt-in rules for existing customers vary by member state, and your email platform will happily let you ignore all of them. Get your setup checked rather than reasoning from what a competitor does.
Write a privacy policy that matches the stack
The policy that was copied from another store in 2019 is worse than useless, because it now describes systems you do not use and omits the four apps you added last year.
It should name what you collect, why, on what legal basis, who receives it, how long you keep it, and how someone exercises their rights. If your data map is accurate, the policy is a rewrite of the data map in plain language. If the map does not exist, the policy is fiction.
One practical test: pick three named processors in your policy and check they are still in use. Then pick three apps in your admin and check they appear in the policy.
Third parties are where stores actually leak
A few failure patterns we see repeatedly:
Google Fonts loaded from Google's servers rather than self-hosted. A Munich court decision in early 2022 set off a wave of warning letters in Germany over exactly this, and the fix is to serve the font file from your own domain.
Server-side tracking added to recover data lost to consent, then wired straight past the consent record. If the customer said no, the server needs to know that too.
An abandoned cart flow that emails people who typed their address at checkout and left. Whether that is permitted depends on national rules and how the address was captured.
A staging copy of the production database sitting on a subdomain with no password.
Reviews and loyalty apps sending order data to a processor nobody has a contract with. Article 28 requires a processing agreement with anyone handling personal data on your behalf, and most reputable vendors publish one. If you cannot find theirs, that tells you something.
Security is part of this, not a separate project
HTTPS everywhere, multi-factor on every admin account, and staff accounts scoped to what the person actually does. Your customer service contractor does not need the ability to export the full order table.
Keep the platform and plugins patched. An abandoned plugin with a known vulnerability is both a security problem and a privacy one, and on WooCommerce stores it is the usual way data leaves the building.
Have a written breach process before you need it, because the GDPR gives you 72 hours to notify the supervisory authority once you are aware of a reportable breach. Working out who calls whom during those 72 hours is not the moment to invent the process.
Handling data requests without panic
A customer can ask for a copy of their data, ask you to correct it, or ask you to delete it. You generally have one month to respond, extendable by two further months for complex requests if you tell them why within the first month.
The hard part is never the reply. It is knowing where the data lives, which is what the map is for.
WordPress has had personal data export and erase tools under Tools since version 4.9.6 in 2018, and they cover core and any plugin that hooks into them, which is not all of them. Shopify exposes customer data requests in the admin and fires GDPR webhooks that apps are meant to honour, though whether a given app actually deletes anything is worth spot-checking.
Keep a log of requests and what you did. It costs nothing and it is the first thing anyone asks for.
Platform notes
| WooCommerce | Shopify | Custom or headless | |
|---|---|---|---|
| Who controls which scripts load | You, plus every plugin that injects its own | You, plus every app and anything pasted into theme.liquid | You, entirely |
| Built-in request tooling | WordPress export and erase tools, plugin coverage varies | Customer data requests in admin, GDPR webhooks to apps | Whatever you build |
| Usual weak point | An old plugin loading a third-party script directly, outside tag manager | An app that installs its own pixel at install time | Analytics wired in by a developer with no consent gate |
| Retention control | Your database, your scheduled jobs, your call | Shopify's retention plus every app's own store | Yours, and you have to design it |
| Effort to fix properly | Moderate, more plugins means more rows on the map | Lower for infrastructure, higher for app sprawl | Highest up front, cleanest afterwards |
None of these is more or less compliant than the others. The difference is how much of the work the platform does for you and how much visibility you have into what your add-ons are doing.
The audit, as a table you can work through
| Check | What good looks like | How to verify |
|---|---|---|
| Script blocking | Nothing non-essential fires before a choice is made | Network tab, private window, banner untouched |
| Reject option | Same layer, same prominence as accept | Look at it on a 375px phone screen |
| Consent records | Timestamp, categories, banner version stored | Ask your consent tool to export a record |
| Withdrawal | Footer link reopens preferences | Click it |
| Tag manager | Every tag has a consent condition | Open the container and read the triggers |
| Checkout fields | Every field maps to a purpose | Read your own checkout form aloud |
| Marketing opt-in | Unticked, separate, logged | Place a test order |
| Privacy policy | Matches the apps currently installed | Cross-check against the data map |
| Processor contracts | A DPA on file for each processor | Your data map's last column |
| International transfers | You know which processors are outside the EU and on what basis | Vendor documentation |
| Admin access | MFA on, least privilege, no shared logins | User list in your admin |
| Patching | Platform, theme and plugins current | Update screen |
| Backups | Encrypted, restorable, tested | Restore one |
| Breach plan | Named people, 72 hour clock understood | One page document |
| Retention | Old carts, logs and test accounts get deleted | Check the oldest record in each system |
| Data requests | A documented path with an owner | Send yourself one |
Work top to bottom. The first four cover most of the exposure for a typical store.
What this usually costs you
Not money, mostly. Time, and the awkward conversation about the four apps nobody can justify.
The audit takes longer than the fixes. Reading through a tag manager container that three agencies have edited is slow work, and so is chasing a DPA out of a vendor whose support address bounces. The remediation itself is normally a day or two of development for a store of ordinary complexity, plus whatever your consent tool costs.
The part that goes wrong most often is marketing losing data they were used to having. Consent mode, server-side tagging and modelled conversions soften that, but a real reject-all button means some visitors will not be measured. Decide how you feel about that before you brief the work, because a compliance project that quietly gets rolled back in month three has cost you twice.
How Webloom Labs helps
We work on the technical side of this, alongside whoever gives you the legal advice.
That usually means auditing what your storefront loads and when, rebuilding the tag setup so consent actually controls it, mapping where customer data goes across your apps and integrations, tightening checkout, and making sure the site is still fast once the consent layer is in place. When a store has outgrown its platform, we build the replacement on WooCommerce, Shopify or a custom headless stack with the data handling designed in rather than retrofitted.
Selling into the EU and not sure what your site is loading?
Send us the URL. We will run the network tab check, tell you what fires before consent, and you can decide from there whether you need us.
Frequently asked questions
Does GDPR apply if my business is outside the EU?
It can. The test in Article 3 is about what you do, not where you are. Offering goods or services to people in the EU, or monitoring their behaviour, can bring you in scope regardless of where the company is registered. Shipping to Germany and running ads targeted at German shoppers is a fairly clear case.
Do I need a cookie banner at all?
If your site only sets strictly necessary cookies, no. Almost no e-commerce store is in that position, because analytics and ad pixels are not strictly necessary. If you run either, you need consent before they load.
Are cookie banners about to be scrapped?
No. The Digital Omnibus proposal would change how consent works, but it is still in negotiation, the Council removed the browser-signal provision from its June 2026 text, and nothing applies before 2027 at the earliest. Plan around the rules that exist.
Is a privacy policy enough on its own?
No, and a policy that does not match your actual setup is evidence against you rather than for you. The Shein decision turned on what the site did, not what it said.
Will this hurt conversion?
The banner might cost you some measured traffic. The checkout changes usually go the other way, since most of what you cut was optional fields that people were abandoning on. Whether the net is positive depends on how badly your current banner is built.
WooCommerce, Shopify or custom for an EU store?
Pick on your business needs rather than on privacy. WooCommerce gives you control and hands you responsibility for every plugin. Shopify handles more of the infrastructure and hands you app sprawl instead. Custom makes sense when your workflows or performance requirements have outgrown both, and it means you design the data handling yourself. All three can be run properly and all three are routinely run badly.