Most eCommerce brands treat GDPR as a cookie banner problem. A banner helps with one slice of processing — typically non-essential cookies and similar technologies — but GDPR Article 6 applies to every operation that processes personal data: orders, email lists, analytics, pixels, customer service tools, loyalty programs, and backups. If your brand cannot name the legal basis for each activity, your brand does not have a completed GDPR story — your brand has a UI pasted on top of an unmapped stack.
The regulation sets out six legal bases for processing. Picking the wrong one — or defaulting to consent when contract or legal obligation would apply, or claiming legitimate interests where consent is required — creates friction (unnecessary banners and blocks) or exposure (processing without a defensible basis).
The operational backbone that forces honesty is Article 30: Records of Processing Activities (ROPA) — a structured inventory of what your brand processes, why, and on what basis. That mapping is a legal requirement for many controllers and best practice for everyone else. The thesis here is simple: legal basis discipline is the foundation of GDPR compliance for eCommerce — and for tracking-heavy marketing stacks, the analysis almost always returns to valid consent and the infrastructure that supports it.
If your brand treats one legal basis as a default for everything — usually consent or legitimate interests — your brand will either over-block core operations or over-collect for marketing. Neither is a strategy; both are audit findings waiting to happen.
The Six GDPR Legal Bases — Plain Language
1. Consent (Article 6(1)(a))
The data subject has given clear, specific, informed, and unambiguous consent. Under GDPR standards, consent must be:
- Freely given — no bundling required unrelated processing; no “consent or no service” unless strictly necessary
- Specific — separate choices where purposes differ (for example analytics vs. advertising)
- Informed — plain language about what happens to personal data
- Unambiguous — affirmative action; no pre-ticked boxes for non-essential processing
- Withdrawable — as easy to withdraw as to give
eCommerce examples: non-essential analytics and advertising cookies; behavioral measurement; email to new marketing subscribers where marketing is not strictly necessary for the sale; many A/B tests and personalization tools that identify individuals.
2. Contract (Article 6(1)(b))
Processing is necessary to perform a contract with the data subject, or to take pre-contractual steps at their request.
eCommerce examples: taking payment, fulfilling and shipping an order, managing returns tied to that purchase, account features the customer actually uses under your terms. This basis does not stretch to “whatever marketing your brand wants later” — when the transactional necessity ends, the contract basis often ends with it.
Common mistake: stuffing newsletter sign-up into checkout fields and claiming contract for all email uses. If promotional email is not necessary to complete the purchase the customer wanted, consent or another valid path is doing the work — not Article 6(1)(b).
3. Legal obligation (Article 6(1)(c))
Processing is necessary to comply with EU or Member State law that applies to your brand.
eCommerce examples: tax and accounting retention, invoice storage where required, responding to competent authority requests where law mandates cooperation, and DSAR handling where the statute imposes duties your brand must perform.
4. Vital interests (Article 6(1)(d))
Processing is necessary to protect someone’s life. Rare in routine retail; keep it on the list so your brand does not confuse “brand safety” with “vital interests.”
5. Public task (Article 6(1)(e))
Processing necessary for a task in the public interest or official authority. Not a fit for private eCommerce controllers in normal trading.
6. Legitimate interests (Article 6(1)(f))
Processing is necessary for your or a third party’s legitimate interests, unless those interests are overridden by the data subject’s rights and interests. This is flexible — and frequently misapplied.
eCommerce examples that can qualify when the tests are met: fraud prevention, network security, some first-party service improvement — not a blank check for adtech-style profiling.
Interaction with ePrivacy: For many on-device technologies (cookies, similar identifiers, some SDK behaviors), GDPR Article 6 is only half the question. The ePrivacy Directive (implemented nationally) and related rules often require consent or strictly necessary treatment before storage or access — even when your brand wishes Article 6 looked tidier. Your legal basis table and your cookie/tracker policy must match.
| Legal basis | One-line idea | eCommerce-flavored example | Consent banner for this basis alone? |
|---|---|---|---|
| Consent | Permission for specific processing | Non-essential cookies, many pixels, new marketing opt-ins | Yes — for the consent-gated parts |
| Contract | Needed to do what the customer asked | Checkout, fulfillment, core account functions tied to sale | No — not “consent” in the cookie sense |
| Legal obligation | Law says your brand must | Tax retention, certain regulatory responses | No |
| Vital interests | Protect life | Emergency edge cases | No |
| Public task | Public authority tasks | Not typical for private stores | No |
| Legitimate interests | Balanced purpose + necessity + rights | Fraud checks, some security monitoring | No — but not a substitute for consent where consent is required |
Consent vs. Legitimate Interests: The Distinction That Matters Most
This is where mid-market eCommerce teams misallocate bases.
Consent is typically required when:
- Non-essential cookies and similar technologies (analytics, ads, social widgets that profile)
- Behavioral tracking via pixels and SDKs that follow users across contexts
- Email marketing to new subscribers where promotional messaging is not necessary to perform the purchase contract
- Profiling for ad targeting beyond strictly necessary service delivery
- Session replay and similar tools that capture interaction content at individual level
If your brand cannot articulate which granular purpose the user agreed to, the consent is probably not specific enough — GDPR Article 4 and Recital 32 are unforgiving about bundling. Separate toggles and clear wording beat a single “accept all” paragraph buried in a privacy policy nobody read at checkout.
Legitimate interests may be available when:
- Fraud prevention and abuse detection with proportionate monitoring
- Certain security operations (for example anomaly detection) scoped and documented
- Some direct marketing to existing customers under ePrivacy national implementations and soft opt-in rules where they apply — not a universal EU shortcut; your brand must align email practices with ePrivacy and marketing law, not GDPR Article 6 alone
- Aggregated analytics that do not identify individuals — a design outcome, not a vendor promise on autopilot
Legitimate interests is not “easier consent.” Your brand must complete a Legitimate Interests Assessment (LIA) with three tests:
- Purpose — is the interest legitimate (lawful and ethical in a real sense)?
- Necessity — is processing necessary for that purpose, or could your brand achieve it with less intrusive means?
- Balancing — do the individual’s rights and expectations override your interest?
For behavioral advertising and cross-context measurement, the balancing test is hard to pass at scale — the Irish DPC’s May 2023 decision on Meta included a €1.2 billion fine and rejected legitimate interests as the basis for behavioral advertising in that context, pointing operators toward consent. Translation for eCommerce: do not paste “legitimate interests” on ad stacks because it reads shorter than “consent.”
Practical test your brand can run: If the processing would surprise a shopper who only expected a package on the doorstep, it probably is not contract. If it would surprise them after reading a generic privacy notice, legitimate interests may not be doing the work your brand thinks — consent or restraint might be required.
US overlap: GDPR governs EU/EEA/UK visitors (and UK has its own UK GDPR regime). California’s CIPA imposes prior-consent expectations around certain interceptive tracking technologies for California visitors that do not disappear just because a GDPR analysis might entertain legitimate interests elsewhere. For a plain-language introduction, read why CIPA requires prior consent even when GDPR allows legitimate interests.
Mapping Legal Bases to eCommerce Processing Activities
Use this as a starting ROPA-style map — your brand must validate each row against actual contracts, vendor roles, and jurisdictional overlays (notably ePrivacy for cookies and electronic marketing).
Processors vs. controllers: Your brand may not control every system row — Shopify and Klaviyo process on your instructions — but your brand still must know which Article 6 story your purposes rely on and ensure contracts (Article 28) match reality.
| Processing activity | Typical legal basis | Why (high level) | Consent banner / CMP gate? |
|---|---|---|---|
| Order fulfillment (pick, pack, ship) | Contract | Necessary to perform the sale | No (not for this core processing) |
| Payment processing | Contract / sometimes legal obligation | Necessary to charge; scheme rules and law apply | No for core payment steps |
| Transaction and invoice retention | Legal obligation / contract | Tax, accounting, dispute handling | No |
| Email marketing to new subscriber | Consent (or national soft-opt where strictly available) | Promotional messaging not necessary to complete purchase | Yes for consent-track signups |
| Email marketing to existing customers | Legitimate interests or consent — national ePrivacy rules decide | Depends on soft opt-in, preferences, and content | Depends — often preference center + unsubscribe |
| Google Analytics (common GA4 web setup) | Consent for non-essential measurement cookies | Tracking / storage on device typically needs consent under ePrivacy | Yes |
| Meta Pixel (behavioral / ads measurement) | Consent | Cross-site behavioral measurement and ad use cases | Yes |
| Session replay (Hotjar, FullStory-class) | Consent | Captures on-page interaction; high intrusiveness | Yes |
| Fraud screening (rules + risk scoring) | Legitimate interests (with LIA) | Security and loss prevention | No — still document scope |
| Logged-in personalization (features user asked for) | Contract or consent | If truly part of the service under terms, contract may cover | Depends on scope |
| Loyalty program | Contract and consent elements | Terms join program; marketing may need separate consent | Often mixed — split purposes |
| DSAR handling | Legal obligation / contract for portal access | Statutory duties and customer care | No |
| Abandoned-cart email (non-transactional cadence) | Consent or legitimate interests / soft-opt — depends on content and law | Transactional service emails differ from promotional series | Depends — design flows carefully |
| SMS marketing | Consent (strong default) | Highly regulated channel; ePrivacy-sensitive | Yes — clear opt-in path |
| Chat widgets that profile visitors | Consent | Often analytics + content risk | Yes |
| Post-purchase product review requests | Legitimate interests or consent | Narrow, expected messages may differ from broad promos | Often low friction — still map |
Records of Processing Activities (ROPA): Why You Need This
Article 30 requires many organizations to maintain a Record of Processing Activities: essentially a living inventory of purposes, categories of data, categories of recipients, transfers, retention, and security measures. Thresholds exist — for example 250+ employees triggers the obligation for many controllers unless an exemption applies — but high-risk processing can pull smaller brands into scope. Even when a formal Article 30 filing is debatable, regulators and enterprise customers treat a ROPA-style map as the first document in a serious conversation.
For eCommerce, the practical artifact is often a spreadsheet: Shopify, Klaviyo, GA4, Meta, helpdesk, loyalty, each row listing personal data categories, Article 6 basis, Article 9 if special categories appear, processors, retention, and transfer tools (SCCs, etc.). The value is prevention: your brand surfaces orphan systems — the A/B tool nobody told legal about — before they surface in a complaint.
Update the ROPA when your brand launches a new market, new app, or new integration. Black Friday is not the right week to discover a pixel with no Article 6 owner.
Where processing is likely to result in high risk to individuals — for example large-scale profiling that affects significant decisions — your brand may also owe a Data Protection Impact Assessment (DPIA) under Article 35. A ROPA does not replace a DPIA; it feeds the conversation about where risk concentrates.
The Bottom Line: Why Consent Management Is the Foundation
Once your brand maps processing, a pattern appears: everything that fuels acquisition and retargeting — non-essential measurement, ad tags, many ESP journeys for cold audiences — wants consent (plus ePrivacy compliance for storage/access on devices). Contract covers checkout. Legal obligation covers retention your brand cannot wish away. Legitimate interests covers narrow, documented security and fraud work — not a free pass for behavioral ads.
That is why consent management is not decoration. It is the control plane for lawful processing in the marketing layer: capture choices, store proof, sync downstream, withdraw on request. A CMP that does this well for GDPR also aligns your brand with technical pre-consent blocking expectations that California CIPA enforcement emphasizes — separate statute, overlapping reality for US traffic.
CCPA/CPRA uses a different vocabulary (sale, sharing, opt-out), but honoring limit signals and not firing non-essential tags early still depends on the same operational discipline: signals that are real, timestamped, and wired to tags.
If your brand is unsure whether tooling enforces choices or only logs them, start with how to audit whether your consent tool is actually blocking tracking.
Conclusion
GDPR compliance for eCommerce is not a one-size-fits-all banner text. It is a mapping exercise: each processing activity needs a basis, and that basis must survive questions regulators actually ask — purpose, necessity, balancing, and evidence.
For tracking, analytics, and advertising — the activities that sit under modern performance marketing — consent is the reliable path for many setups your brand actually runs. That makes consent infrastructure the legal foundation of the program, not an IT afterthought.
See PieEye’s approach to consent management with GDPR-aligned collection and enforcement — and continue with the complete GDPR compliance guide for eCommerce for a broader playbook.
Treat legal basis choices as living: when product roadmaps add AI features, subscriptions, or B2B portals, the Article 6 column for those flows must be updated before launch — not after a regulator asks why retention doubled.
If your brand’s ROPA still has blank rows next to Meta, GA4, and Klaviyo, fix the map before your brand scales spend on top of it.