Open source ecommerce GDPR customer data compliance

How open source ecommerce meets GDPR customer data duties

A store owner selling to EU customers has to answer a simple question from a regulator or a customer: where does order and account data live, and how is it erased? The short answer is that the GDPR sets obligations for controllers and processors in Chapter IV (Articles 24 to 43), it does not require an audit report or certificate, and the compliance work sits in three places you control: the platform configuration, your retention rules and your processor contracts. The Regulation is binding in full and applies directly in every EU Member State, and it also applies in Iceland, Liechtenstein and Norway under the EEA Joint Committee Decision. Fines for breaches of the core principles and data subject rights can reach EUR 20 million or 4% of total worldwide annual turnover, whichever is higher (Article 83), so the store owner, not the software vendor, carries that exposure.

On a self-hosted store, the practical work is mapping every system that holds personal data. That usually means the storefront, the commerce database, the order and customer tables, the ERP, the shipping and payment connectors, the email and marketing tools, search indexes, caches, logs and backups. For each one, confirm which settings control retention and deletion, whether a customer erasure request can reach it, and whether the vendor or hosting provider acts as a processor under a written contract. Check how your platform handles guest checkout data, abandoned carts and account deletion, because the default behavior varies by platform and version. Confirm these settings against the documentation for the exact release you run, and record the answers in your record of processing activities.

Plan the evidence before anyone asks for it. Keep a dated decision log for each lawful basis you rely on for order, account and marketing data, a retention schedule that names each data set and its trigger for deletion, and a test record showing that an erasure request removed data from the shop, the ERP and the email tools. Review the processor contracts for hosting, payments, email delivery and any managed service, and confirm where data is stored and which transfer mechanism applies to any non-EEA access. Because the GDPR does not reward a certificate by itself, an independent review of this evidence is more useful than a badge. Ask your implementation partner to show how each control is configured and tested in your environment, and to agree on that scope in writing before work starts.

Which GDPR obligations the store must support and how to configure them

This table maps each GDPR obligation that a store touches to what the platform must do and how to configure it on Magento Open Source, WooCommerce, Saleor, Medusa or Sylius. Read each row as a control to design and then evidence, not as a checklist that a platform setting alone satisfies. Most gaps appear where the shop, ERP and email tools each hold a copy of customer data.

Requirement	What the function must do	How to configure it on Magento Open Source	How to configure it on WooCommerce, Saleor, Medusa or Sylius
Principles (Article 5)	Limit order and account data to stated purposes, keep it accurate and delete it when the purpose ends	Document each customer field in the data inventory, disable unused customer attributes and newsletter fields, and set a retention plan for guest checkout records	WooCommerce: remove unused checkout fields and plugins that store personal data. Saleor, Medusa, Sylius: map each customer and address model to a documented purpose and retention rule
Lawful basis (Article 6)	Record the basis for each use: contract for order fulfilment, consent or legitimate interest for marketing	Keep marketing opt-ins separate from account creation and order checkout, and store consent timestamps with the newsletter subscriber record	WooCommerce: separate checkout consent checkboxes from marketing opt-ins in the consent plugin. Headless stacks: store consent events in the customer service, not only in the email tool
Access and erasure (Articles 15 and 17)	Find all personal data for a person across shop, ERP and email tools, export it on request and erase or anonymize it where no legal retention duty applies	Use the built-in customer data export and erasure workflows, then extend them to custom tables and the ERP connector. Confirm order records are anonymized rather than deleted where tax retention applies	WooCommerce: use the core personal data export and erase tools and extend them to plugin tables. Saleor and Medusa: expose customer lookup and anonymization through the API. Sylius: add a resource-level erasure command that also calls downstream systems
By-design defaults (Article 25)	Ship with the least personal data collected and shared by default, and keep privacy settings on during upgrades	Turn off guest account data sharing and third-party tags by default, and review each third-party module after each patch release	Confirm marketplace plugins and headless storefront libraries do not send data before consent. Re-check defaults after each upgrade
Security of processing (Article 32)	Apply access control, encryption in transit and at rest, logging, patching and tested backups to customer data	Restrict admin roles, enforce HTTPS, configure Content Security Policy, keep the supported patch line, and separate database credentials from the app	Keep PHP, database and WordPress versions supported, enforce HTTPS, restrict REST API keys to needed scopes, and keep payment and admin access logged
Breach notification (Articles 33 and 34)	Detect incidents, assess risk, notify the supervisory authority within the statutory window and inform affected people when risk is high	Enable admin and order access logging, forward logs to a central store, and run a tested contact list and template for notices	Forward application and database logs to a central store, and keep a tested runbook for export of affected customer records
Processor terms (Article 28)	Sign written terms with every processor that touches customer data, including hosting, payments, email and support	List each processor and the data it receives in the record of processing. Confirm sub-processor notice and audit rights in each contract	Same for WooCommerce hosts, payment gateways, email services and plugin vendors that receive order data. Ask for data processing agreements before go-live
International transfers (Chapter V)	Identify transfers outside the EEA and apply an approved transfer mechanism and supplementary measures	Confirm where Adobe-supported search, cache, CDN and email services store data, and whether they run outside the EEA	Confirm where payment, analytics, email and CDN providers process data, and document the transfer mechanism for each

Which open-source ecommerce platform fits a GDPR data model

Magento Open Source is licensed under OSL-3.0, and 2.4.9 is the latest stable tag in the magento2 repository. Adobe's lifecycle policy gives 2.4.9 regular support until May 31, 2029, which gives a long planning window for a GDPR data model. Customer accounts, addresses and orders live in the MySQL or MariaDB database, while sessions and cache use Redis or Valkey, search indexes use OpenSearch 3, and message queues use RabbitMQ 4.3.

Where personal data sits: Map the database, search index, queues, logs, media uploads and any Varnish cache layer, since personal data can appear in more places than the order screens suggest.
Module vetting: Core code is under OSL-3.0, but each third-party privacy or consent extension carries its own license, maintainer and 2.4.9 compatibility. Review the source and upgrade path before installing.
Export and erasure tools: Confirm whether the admin, GraphQL and REST interfaces cover export and anonymization for every record type you hold, or whether custom development is needed.
Caching and logs: Confirm that full-page caching never stores personal data for logged-in customers and that log retention matches your policy.

Ask the implementation partner to demonstrate an access request and an erasure request end to end on a staging copy, including orders already sent to the ERP and email tools.

How an erasure request flows across the shop, ERP and email tools

An erasure request is handled as a documented sequence that confirms who is asking, finds every copy of the customer's data, keeps only what a stated legal basis requires, removes or pseudonymizes the rest, and proves each step was completed. The output is a closed request with a record that a supervisory authority could review.

Verify the requester's identity
Confirm that the person asking for erasure is the data subject or someone authorized to act for them, using the account login, a verified email address or a proportionate second check. Support staff log the request in a ticket with the date received, the channel used and the verification result. The step is complete when the ticket shows a confirmed identity or a documented reason for refusing, and the controller's response clock is recorded from the date of receipt.
Locate the customer across every system
Search each place the customer's data may live: storefront accounts, order and address tables in the shop database, the ERP customer and invoice records, the CRM, the marketing list in Mautic or another email tool, support tickets, analytics identifiers and logs. Keep a data map that lists each system, the owner and the identifier used to link records, so nothing depends on memory. The output is a per-system inventory of what was found, including copies held by processors.
Decide what must be retained
For each record, decide whether erasure applies in full or whether a retention duty requires keeping part of it, such as invoices that tax rules require to be kept for a set period or contract records needed to defend a dispute. Record the legal basis for each retained item and the date on which it will be deleted. Retained records should be restricted to the purpose that justifies them. Have legal or the data protection lead approve this decision and keep the approval with the request.
Delete or pseudonymize each record
Apply the decision to each system: delete marketing profiles and account data, and pseudonymize retained orders by replacing name, contact details and address with a placeholder while keeping the transaction totals needed for accounting. Run the change in the shop, the ERP and the email tool, and check that the customer identifier no longer resolves to personal data in each. The output is a before and after check for each system, saved with the request.
Address backups and archives
Identify where the customer's data persists in backups, search indexes, caches, exports and log archives. Because backups are often restored as a whole, document the rule that applies, such as deletion on the next rotation or a restore procedure that reapplies erasure, and confirm it with the data protection lead. Clear search indexes and caches directly, since they are rebuilt from source data. The output is a short note on each copy and how and when it is cleared.
Notify processors and recipients
Send erasure instructions to every processor that holds a copy, including hosting providers, payment providers, email delivery services and any outsourced support or analytics tools, using the contact route in each processor contract. Where personal data was disclosed to recipients, inform them of the erasure unless this proves impossible or involves disproportionate effort, and record that decision. The step is complete when each processor has confirmed receipt or the attempt is logged.
Respond to the requester and record the outcome
Tell the requester what was erased, what was retained and why, and which systems were covered, in plain language, and inform them of their right to complain to a supervisory authority if they are not satisfied. Close the ticket with a request log that lists the timestamps, systems touched, retention basis, processor notices and approver. Keep this log as evidence of how the controller handled the request. Review a sample of closed requests periodically to find gaps in the data map.

What configuration and tooling alone do not satisfy

A self-hosted store can be configured to hold less data, expire it sooner and show the right banner, but several GDPR duties sit with people and contracts rather than software. The cards below cover the gaps that remain after the platform is set up, and each one needs an owner outside the build team.

Lawful basis and records of processing

Each purpose that touches customer data needs a documented lawful basis, such as contract for order fulfilment or consent for marketing, and the decision must be recorded in a register of processing activities. Marketing data is the usual gap, because a shop often reuses order data for newsletters without recording a separate basis. Ask legal to review every data flow from checkout, ERP and email tools, and confirm who keeps the register current when a new extension or integration is added.

Processor contracts and transfers

Hosting providers, payment providers, email services and support tools that handle customer data act as processors, and each needs a written contract covering the instructions, security and sub-processor terms. Where data leaves the EEA, Chapter V requires a transfer mechanism, and the EU-US Data Privacy Framework is one such mechanism that depends on the recipient's certification. Check each vendor's transfer basis before go-live, not after an access request reveals an unexpected destination.

Retention schedules agreed with finance

Orders, invoices and accounts are kept for different periods, and the periods for tax and accounting records are set by national law rather than by the GDPR. Configuration can delete abandoned carts or inactive accounts on a timer, but the schedule itself must be agreed between legal and finance and written down. Ask who approves each category, how deletion is evidenced, and how backups and logs holding the same data are handled.

Consent banner accuracy against actual cookies

A consent banner is only as accurate as the list of cookies and scripts it describes. Marketing pixels, chat widgets, reviews and A/B tools are often added by agencies or through tag managers without updating the banner or blocking the script until consent is given. Run a scan of the live storefront, compare it against the banner categories, and repeat the check after each release, because extensions and theme updates change the script set.

Breach response under Articles 33 and 34

Article 33 requires the controller to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. Article 34 requires notifying affected individuals when the risk is high. These deadlines need a written procedure that names who decides, who contacts the processors and hosting provider, and how the facts are recorded. Test the procedure with a tabletop exercise, since the first real incident is a poor time to learn who holds the admin credentials.

No certificate removes controller responsibility

The GDPR does not require an audit or certificate, and Article 42 certification is voluntary, lasts for at most three years and does not reduce the controller's or processor's responsibility. A hardened, well-documented store can still be non-compliant if its purposes, contracts and retention are wrong. Use any certification or assessment as one input to accountability, and keep the evidence the controller must show regardless of what a third party has issued.

Evidence auditors and supervisory authorities ask for

This table lists the records a store should be able to produce when an auditor, customer or supervisory authority asks how customer data is handled. Each row names what the evidence shows and which part of the store, ERP or email stack usually produces it. DeployOpen prepares these records as part of implementation, but independent auditors and certification bodies issue any reports or certificates.

Evidence item	What it shows	Which component produces it
Records of processing (Article 30)	Which customer data is collected, why, who receives it and how long it is kept	Documented data map maintained by the store owner, built from storefront, ERP and email configuration
Lawful basis register	The basis chosen for orders, accounts, marketing and analytics, and where consent is the basis	Governance document linked to checkout, account creation and newsletter opt-in flows
Retention schedule	How long customer accounts, orders, invoices and marketing lists are kept and when they are purged	Scheduled jobs or database procedures in the commerce platform, plus ERP and mailing list settings
Data subject request log with timestamps	Each access, rectification, erasure or objection request, when it was received, actioned and answered	Ticketing or request tool, with entries reconciled against storefront, ERP and email platform actions
Processor agreements	Contracts covering hosting, backups, payment, email delivery and support providers that handle personal data	Contract register held by the controller, with data processing terms confirmed for each supplier
Transfer assessments	Where personal data is stored or accessed from outside the EEA and which transfer mechanism applies	Hosting region settings, sub-processor list and transfer documentation kept by the controller
Cookie scan results	Which cookies and scripts load before and after consent on the storefront and checkout pages	Periodic scan output from the storefront, plus consent banner configuration and tag manager records
Access control and logging exports	Who accessed customer records in admin, ERP and email tools, and what changes were made	Commerce admin logs, database audit logs, identity provider logs and ERP audit trails
Backup and deletion test results	That restored backups and erased records behave as the retention schedule says, including backup expiry	Restore test reports from backup tooling and records of test erasures across systems
Breach register	Internal log of personal data incidents, assessment of risk and whether notification was made under Articles 33 and 34	Incident management records kept by the controller, fed by security monitoring and logs

Questions store owners ask before hiring implementation help

How much does GDPR compliance cost for an open-source ecommerce store?

No single price applies, because the cost follows the written scope of the work. The main cost lines are internal staff time, implementation partner effort for the data inventory and workflows, legal review of lawful bases and retention periods, and processor contracts that your counsel or vendors handle. Some work is one-time, such as the data map, consent setup and erasure workflow build. Some recurs, such as handling access and erasure requests, reviewing new processors, and retesting after platform upgrades. Effort rises with the number of systems that hold personal data (shop, ERP, email, CRM, analytics, payment and shipping tools), the number of integrations between them, and any custom code that reads or writes customer records. Ask for a quote that lists each system, each integration, each workflow, and who performs each task. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does it take to build a first erasure workflow?

The supplied materials do not give a duration, so the timeline should come from the written scope rather than a general estimate. The erasure workflow depends on how many systems must be reached, whether each one has an export or deletion interface, and how order records are kept for tax and accounting duties. Your team typically needs to name an owner for data subject requests, approve a retention rule for each record type (with counsel), grant admin access to the shop, ERP and email tools in a test environment, and confirm which fields may be anonymized instead of deleted. Ask the partner to show milestones for mapping, build, testing and a live dry run, and to state which tasks fall to your staff. Ask what happens to requests that arrive during the build.

Can our own engineering team do GDPR work on an open-source store?

Yes, many teams do part of the work in-house, and the split depends on the skills you already have. Data mapping and retention decisions need input from legal and business owners, while workflow code needs developers who know the shop platform, the ERP and the email tools. Risks for an in-house team include gaps in documentation, untested erasure paths, and changes that break consent or deletion after a platform or extension update. A practical split is to keep ownership of policy decisions and request handling in-house and to hire outside help for the inventory, build and test cycle. Ask any partner which tasks it would hand back to you, what documentation it would deliver, and whether it offers ongoing support as a retainer after the first delivery.

Is Magento, WooCommerce or Saleor easier to make GDPR compliant?

No platform is compliant by default, because GDPR applies to what you collect, why you keep it, who processes it and how requests are handled. The platform affects the work, though. On WooCommerce, high-performance order storage keeps orders in dedicated tables such as wc_orders and wc_orders_meta, which gives a clear starting point for mapping order data. Magento Open Source is licensed under OSL-3.0, and Adobe documents content security policy support, so the team must confirm how extensions handle customer data. Saleor is a headless API licensed under BSD-3-Clause, so personal data often sits across the API, the storefront and the connected tools. Compare the three by listing the personal data fields, the extensions or apps involved, and the integrations each one would need, then ask for the effort to build the same workflows on each.

How could pending Omnibus proposals and Regulation 2025/2518 change our work?

As of October 2026 the GDPR text has not been amended, so current obligations still apply. The Omnibus IV proposal (procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote. The Digital Omnibus proposal (procedure 2025/0360(COD)) is awaiting committee decision. Regulation (EU) 2025/2518 sets additional procedural rules for cross-border enforcement and applies from 2 April 2027. It does not change your store's duties directly, but it can affect how a complaint moves between authorities. Build the data map, retention rules and request workflows so they can be updated without rebuilding the whole system, and ask counsel to confirm the effect of any change before you act on it. You can follow the Legislative Observatory procedure for Omnibus IV) to track progress.

What should an implementation partner see before quoting a GDPR scope?

A partner needs enough detail to price the work and to name what is excluded. Ask for these inputs before the quote is written:

A list of every system that holds personal data, with the fields collected, such as shop accounts, orders, addresses, support tickets and marketing segments.
The integrations between those systems, including ERP, email, payment, shipping, analytics and tag management tools, and how each one moves data.
The extensions, plugins and custom code that read or write customer records, with versions and who maintains them.
The hosting locations, backup locations and processors involved, with contract status.
The current cookie banner, consent logic and retention decisions, if any exist.
The expected volume and current process for access and erasure requests, and who answers them.

With these inputs, the written scope can state deliverables, assumptions, client tasks and acceptance tests.

Does GDPR require an audit or certificate for our online store?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. What the GDPR does require is that you can show the measures you took, which is why evidence matters: records of processing, consent logs, retention rules, processor contracts, test results for erasure and access workflows, and security records. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles. Ask any partner which evidence it will produce and which parts still need your legal team's review.

What fines can apply to an online store that breaks GDPR rules?

Article 83 of the GDPR sets two maximum tiers, and in each case the higher figure applies. Infringements such as those in Articles 25 to 39, which cover data protection by design, security of processing and breach notification, can reach EUR 10 million or 2% of total worldwide annual turnover. Infringements of the principles, lawful basis, data subject rights and transfer rules can reach EUR 20 million or 4%. National supervisory authorities enforce the regulation, so the actual outcome depends on the authority, the facts and the controller's response. Fines are a reason to document decisions early and to test erasure and access workflows before a request arrives. Read the GDPR text on EUR-Lex for the full article, and confirm your exposure with counsel.

What changes in the GDPR rules could alter store work

The GDPR text has not been amended as of October 2026, so store decisions should be designed against the current Regulation (EU) 2016/679 and its Articles 5, 6, 17 and 32 as they stand. Two pending files could change the picture. Omnibus IV (procedure 2025/0130(COD)) has text agreed in interinstitutional negotiations on 26 June 2026 and is awaiting Parliament's first-reading vote. The Digital Omnibus (procedure 2025/0360(COD)) is still awaiting a committee decision. Neither has become law, so neither should be treated as settled when you sign off a retention schedule or a consent flow.

Separately, Regulation (EU) 2025/2518 lays down additional procedural rules for complaints and investigations in cross-border enforcement cases and applies from 2 April 2027. It changes how a case involving customers in several Member States moves between authorities, not what a store must do with an order record. For a store selling across borders, the practical point is that a complaint may be handled under a different timetable, so evidence of your access, erasure and consent logs should be retrievable without relying on the store team's memory. Confirm with counsel which supervisory authority is lead for your main establishment.

Build a change watch into the project. Assign an owner to track both procedures on the Legislative Observatory) and record the decision date of each design choice that depends on a contested rule, such as retention periods for guest checkout or the handling of marketing consent. Keep retention periods and lawful basis mappings as configuration, not hard-coded logic in the theme or extension, so a change touches one register and a small number of jobs in the ERP, email tool and storefront. Ask your implementation partner to document where each setting lives and to include a review of those settings in the upgrade plan.

Common mistakes that expose store data

Most GDPR problems in a self-hosted store do not come from the platform itself. They come from data that moves between the storefront, the ERP, email tools and third-party scripts without a documented reason or a deletion path. The four patterns below are the ones we check first when reviewing an existing shop.

Reused marketing and order data

Order records collected to fulfil a purchase often end up in newsletter lists, retargeting audiences or segmentation exports. Each new use needs its own lawful basis under Article 6, and for marketing it usually means consent or a documented legitimate interest that survives a balancing test. Check whether the store records which basis applies to each data flow, and whether the checkout checkbox, the account settings and the mailing tool all reflect the same choice. Ask your implementation partner to map every export job to a stated purpose.

Deleted accounts still in downstream tools

Deleting a customer in the storefront admin rarely removes them from the ERP, the invoicing module, the helpdesk or the mailing platform. Copies persist in backups, search indexes, log files and message queues as well. Erasure has to be designed as a workflow with a named owner, a checklist of systems and a record of completion. Where legal retention applies to invoices, the workflow should anonymize the customer record rather than keep the full profile. Confirm the exact list of systems that hold customer identifiers before go-live.

Cookies set before consent

Storefront themes, tag managers and embedded widgets often set analytics, advertising or session cookies on the first page load, before the visitor has chosen anything. Non-essential cookies need prior consent under the ePrivacy rules as implemented in each Member State, and the consent banner must reflect what actually loads. Test the store in a clean browser profile, reject all, and inspect what is still set or sent. Also check that scripts added by extensions are gated the same way as first-party tags.

Extensions sending data without contracts

Payment, shipping, review, chat and recommendation extensions frequently transmit customer names, addresses or order contents to a vendor's servers. Under Article 28, a processor needs a written contract that sets instructions, security duties, subprocessor controls and deletion at the end of service. Many free or community extensions have no such contract, and some vendors are outside the EU, which raises transfer questions under Chapter V. Build an inventory of every extension that receives personal data, obtain its data processing terms and record the transfer basis for each one.

How DeployOpen scopes and delivers GDPR-ready commerce

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source commerce inside your own cloud accounts, data centers or air-gapped networks. For stores with EU customers, we treat customer, order and marketing data flows as part of the build, then prepare the controls and evidence your compliance team needs for its own assessment.

How we scope

Written scope lists every system holding customer or order data, including the storefront, ERP, email tools and payment providers.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope names the retention periods, data subject request workflows and cookie categories your legal team confirms.

How we build

We configure the chosen commerce platform, its consent banner and data retention jobs within the agreed scope.
Access and erasure request handling is built across the shop, ERP and email tools, with each step tested end to end.
Security testing of the storefront, checkout and APIs runs before go-live, and findings are tracked to closure.

How we hand over

You receive documentation of data flows, retention settings, consent configuration and processor inventory.
Runbooks describe how a data subject request moves through each system and who approves it.
Evidence packs are prepared for your auditors or supervisory authority contacts, which DeployOpen does not itself issue or certify.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Patches for the commerce platform and its extensions are tracked against each vendor's support window.
Changes to privacy law, including pending EU procedural rules, are reviewed with your legal team before they are applied.

Open source ecommerce and GDPR customer data