Skip to content
5.0 Upwork, 100+ reviews Adobe Certified since 2021 New: become your own Magento developer Learn more →
Hire me
Toggle Nav
My Cart
Magento glossary

What is Magento GDPR?

Short answer Magento GDPR is the work of setting up a Magento 2 store so it complies with the EU General Data Protection Regulation (2016/679, in force since 2018-05-25) and the laws modelled on it: UK-GDPR, DSGVO in Germany, CCPA/CPRA, LGPD and India’s DPDP Act 2023. Magento gives you a few pieces: Cookie Restriction Mode, customer grid export, customer delete, a privacy-policy CMS page and newsletter opt-in. The merchant is the data controller, so turning those pieces into a working consent banner, DSAR, erasure, breach-response and retention process is on you. Fines go up to 4% of global turnover or €20M.

Need a GDPR audit? How it works

Written by Kishan Savaliya, Adobe Certified Magento & Hyvä developer, 10+ years on the platform

How it works
  1. Enable the cookie consent banner in admin 01
  2. Publish a real privacy policy CMS page 02
  3. Wire data-subject access requests (DSAR) 03
  4. Wire right-to-be-forgotten (erasure) 04
  5. Document + monitor + retain 05
Each step is explained below

Most common mistake Cookie banner pre-ticked or "accept all" by default

How it works

Five steps to a defensible Magento GDPR posture

GDPR is an ongoing process, not a box you tick once. These are the five things I set up on a Magento store, in the order I usually do them.

  1. 01

    Enable the cookie consent banner in admin

    In admin, open Stores → Configuration → General → Web → Default Cookie Settings and set Cookie Restriction Mode = Yes (config path web/cookie/cookie_restriction). Magento then shows its own notice. It is a single “Allow Cookies” button with no per-purpose choice, so on most stores I replace it with CookieYes, Cookiebot or Klaro to get separate consent for necessary, analytics and marketing cookies, which is what EDPB guidance expects. Then I check that GA and ad tags really wait for consent.

  2. 02

    Publish a real privacy policy CMS page

    Magento installs a CMS page at /privacy-policy-cookie-restriction-mode with sample text. That text is not a GDPR policy. Rewrite it to cover the lawful basis for each kind of processing (consent, contract, legitimate interest), what data you collect, how long you keep it, your sub-processors (Stripe, Google Analytics, Klaviyo and so on), the rights people have, a controller or DPO contact, and the supervisory authority they can complain to. Articles 13 and 14 ask for this in plain language at the point of collection.

  3. 03

    Wire data-subject access requests (DSAR)

    Magento Open Source has no one-click “export everything about this customer” button. You can pull customer and address data from System → Data Transfer → Export and orders from the sales grid, but collecting it all by hand is slow. On stores that get regular requests I add the Mageplaza GDPR or Amasty GDPR extension, which puts a Download my data button in the customer account. Article 12 gives you 1 month to answer, extendable by two more months for complex cases, and the clock starts when the request arrives.

  4. 04

    Wire right-to-be-forgotten (erasure)

    Deleting a customer under Customers → All Customers removes the account, but the sales_order and order address rows still hold the name, email and address in plain text. Proper erasure means anonymising those orders (overwrite customer_firstname, customer_email and the address fields, and keep the row itself for tax records), removing quotes, reviews and newsletter subscriptions, and revoking saved card tokens at the payment provider. The Mageplaza and Amasty GDPR extensions include an anonymise action that does this for you.

  5. 05

    Document + monitor + retain

    Keep a Record of Processing Activities (Article 30). For a small store a spreadsheet with each purpose, lawful basis, retention period and sub-processor is enough. Under Article 33 you have 72 hours after you become aware of a breach to notify the supervisory authority. Collect less: if you do not need date of birth or a phone number, turn those fields off under Stores → Configuration → Customers → Customer Configuration → Name and Address Options. Then purge inactive customers on a schedule that matches your policy. Tax records follow local law and usually need to stay longer.

When it applies

Four scenarios where GDPR (or a sibling) applies to your Magento store

GDPR applies to anyone selling to people in the EU, wherever the business is based. If your store fits one of these four cases, you have obligations under GDPR or a law built on it.

  • Selling into the EU, EEA, UK, or Switzerland

    If your Magento store ships to any of the 27 EU member states, Iceland, Liechtenstein, Norway, the UK, or Switzerland, the GDPR family applies. The EU GDPR covers EU/EEA, the UK-GDPR + Data Protection Act 2018 covers Britain, and the Swiss FADP (revised 2023-09-01) covers Switzerland. The three are close enough that one consent banner, one privacy policy and one DSAR process usually cover all of them with small per-country changes. Fines go up to 4% of global annual turnover or €20M, whichever is higher.

  • Selling into California (CCPA + CPRA)

    California’s CCPA (2020) + CPRA (2023) layer on a Do Not Sell Or Share My Personal Information link mandatory in the footer for any store with $25M+ revenue OR 100k+ California consumers OR 50%+ revenue from selling personal info. The opt-out model is the opposite of GDPR’s opt-in default. Magento extensions usually bundle both: one banner serves the EU opt-in path and the California opt-out path based on geo-IP. Texas, Virginia, Colorado, Connecticut, and Utah have similar state laws now, the patchwork is growing.

  • Selling into India, Brazil, or other DPDP / LGPD jurisdictions

    India’s DPDP Act 2023 introduced consent + data-fiduciary obligations broadly similar to GDPR, with rules phasing in through 2026. Brazil’s LGPD (2020) is a near-clone of GDPR including the 72-hour breach notification. Quebec’s Law 25 (phased 2022-2024) mirrors GDPR for Canadian operations. Australia’s Privacy Act amendments and Japan’s APPI add consent-style requirements. If your Magento store ships internationally, building for GDPR first covers most of what these other laws ask for, and you then add the local differences.

  • Breach-response or DSAR-readiness exercises

    Article 33 gives you 72 hours to report a breach. That is short, so rehearse it before you need it. Document the incident-response runbook: who detects, who triages, who decides whether the breach is reportable (was personal data accessed? was it encrypted at rest?), who drafts the notification, who contacts the supervisory authority + affected data subjects. Same for DSAR readiness: time the export, anonymisation, and response-letter generation end-to-end on a test customer once a quarter so the 1-month response clock is not a fire-drill.

Common mistakes

Three GDPR mistakes I see on most Magento stores

When I review a Magento store for GDPR, I usually find at least one of these three. Fix them before a regulator or a data request finds them for you.

  • Cookie banner pre-ticked or "accept all" by default

    GDPR + ePrivacy require OPT-IN, not opt-out, for every non-essential cookie. The default state of analytics, marketing, and personalisation cookies must be OFF until the user explicitly toggles them ON. Pre-ticked boxes, banners that fire _ga before the user clicks accept, and "by continuing to browse you agree" patterns have all been ruled non-compliant by the CJEU and the EDPB. Magento’s built-in banner is permissive, replace with Cookiebot, CookieYes, or Klaro for proper purpose-grouping with a real reject-all button equal in prominence to accept-all.

  • Customer deletion that doesn’t cascade to orders

    Admin clicks Delete on a customer and Magento removes the customer_entity row, but the sales_order table still holds the customer’s firstname, lastname, billing address, and email in plaintext, linked by customer_id that is now an orphan FK. That is not erasure under Article 17. Real right-to-be-forgotten requires anonymisation of the order rows: overwrite name + email + address fields with [ANONYMIZED], drop saved-card tokens at the PSP, delete reviews / quotes / newsletter rows. Use a data patch or the Amasty / Mageplaza bulk-anonymise tool, never just delete the customer row.

  • No data-retention policy for inactive customers

    Article 5(1)(e) sets storage limitation: do not keep personal data longer than you need it. Old accounts that have not ordered in years, and that no tax rule requires you to keep, should not sit in customer_entity forever. Write down how long you keep marketing data and order records (tax rules in your country decide the second), then enforce it with a cron job that anonymises or deletes what is past the limit. A policy nobody enforces does not help much in an audit.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

  • What is Magento PCI compliance

    Payment-card data is also personal data under GDPR. PCI-DSS scope-reduction (tokenisation, hosted fields) doubles as GDPR data-minimisation, the two regimes overlap heavily on the payments surface.

    Read the entry

  • What is Magento env.php

    Where PII / PCI config keys live. Database credentials, API keys, and crypt keys all sit here, locking down app/etc/env.php is part of any GDPR security baseline.

    Read the entry

  • Magento developer in London

    UK-GDPR + Data Protection Act 2018 + MTD compliance for British Magento stores. Local time-zone delivery, ICO familiarity, and HMRC-aligned tax wiring.

    See the city page

  • Magento developer in Berlin

    DSGVO (German GDPR) + GoBD + TTDSG-focused builds. German consent-banner conventions are stricter than EU baseline, this page covers the operational checklist for DACH stores.

    See the city page

  • Hire a Magento developer

    Adobe-Certified Magento & Hyvä developer, 10+ years on the platform. GDPR audits, consent-banner overhauls, customer-anonymisation patches, fixed-price or hourly.

    Hire me
FAQ

Magento GDPR, frequently asked questions

  • Is Magento GDPR-compliant out of the box?
    No, and no platform is. Magento ships building blocks: cookie restriction mode, a placeholder privacy-policy CMS page, customer export and delete actions in admin, and the Newsletter module for subscription consent. The merchant is the data controller under GDPR Article 4(7) and is responsible for actually configuring those building blocks into a compliant operation. That means enabling cookie restriction, replacing the default banner with a proper purpose-grouping tool, writing a real privacy policy with all Article 13 disclosures, wiring DSAR and erasure workflows that cascade to orders, documenting a RoPA per Article 30, and applying a retention policy. Adobe Commerce 2.3+ added more built-in helpers, but the operator still has to use them.
  • What’s the difference between GDPR and the German DSGVO?
    DSGVO (Datenschutz-Grundverordnung) is simply the German name for the same EU regulation. There is one GDPR, called GDPR in English, DSGVO in German, RGPD in French and Spanish, AVG in Dutch. The regulation text is identical across all 24 EU languages. What differs is the implementation layer on top: Germany adds the BDSG (federal data protection act), the TTDSG (cookie + telecommunications privacy), and GoBD (commercial record-keeping rules). German supervisory authorities are also among the strictest enforcers, so consent banners and privacy policies built for DACH markets typically run tighter than the EU baseline, what passes a French CNIL review may still fail a Hamburg DSB audit.
  • Do I need a Data Protection Officer (DPO)?
    Article 37 makes a DPO mandatory only if (a) you are a public authority, (b) your core activities require regular and systematic monitoring of data subjects at scale, or (c) your core activities involve processing of special categories of data (health, biometric, sexual orientation, etc.) at scale. Most ecommerce Magento stores do not trigger any of those tests and are not legally required to appoint a DPO. That said, many SMBs voluntarily appoint one or contract an external DPO-as-a-service provider for the governance benefit and to have a documented point of contact for the supervisory authority. If you do appoint a DPO, you must publish their contact details and notify the supervisory authority.
  • How long can I retain order data after a customer requests deletion?
    You can, and usually must, retain the order record itself for tax-audit purposes per local commercial law. In the EU, typical statutory retention is 6-10 years for invoicing data (HGB/AO in Germany sets 10 years, French Code de Commerce sets 10 years, UK HMRC sets 6). What you cannot retain is the personal data within those records beyond what tax law requires. The standard pattern is: immediately on receipt of an erasure request, anonymise the personal fields (name, email, phone, address) replacing them with placeholders; retain the pseudonymised order shell (order number, line items, totals, VAT, payment-method type) for the statutory tax-retention window; auto-purge entirely once the tax window expires.
  • Does GDPR apply to my US-only Magento store?
    Possibly yes, GDPR is extraterritorial under Article 3. If your store offers goods or services to data subjects in the EU (accepts EU shipping addresses, displays EUR pricing, runs ads targeting EU users) OR monitors the behaviour of EU users (uses Google Analytics, Facebook Pixel, or any tracking on visitors who happen to be in the EU), the regulation applies regardless of where your business is incorporated. The mere fact that your website is accessible from the EU is not enough on its own, the test is intent to offer or active monitoring. Most ecommerce stores with international shipping or untargeted analytics fall in scope. The safer answer is to bake the compliance in and not have to litigate the question.
  • What about CCPA, CPRA, and the other US state privacy laws?
    CCPA (California, 2020) + CPRA (amendments, 2023) is the most mature US state regime. Main differences from GDPR: opt-out by default rather than opt-in, a broader definition of sale of personal info that includes sharing for cross-context advertising, mandatory Do Not Sell Or Share My Personal Information link in the footer for stores over the revenue / consumer-count thresholds. Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Texas (TDPSA), and several others passed similar laws in 2023-2025. The patchwork is annoying but the operational answer is the same: build the GDPR-aligned stack with geo-IP-aware banner logic, and you cover the US state laws as a subset.
GDPR audit

Want a GDPR audit on your Magento store?

Send your storefront URL, I will check your consent banner, privacy policy completeness, DSAR + erasure wiring, customer-anonymisation cascade, and retention policy, then reply with a written remediation plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get a GDPR audit Hire me directly
Kishan Savaliya Online 10 AM to 7 PM IST Chat on WhatsApp