Magento Open Source GDPR compliance: what the platform covers and what stays with you
Magento Open Source helps with four GDPR duties on a self-hosted store: cookie consent, personal data lookups, security configuration and extension hygiene. It cannot satisfy lawful basis, retention periods, transfer assessments or breach handling on its own, because those depend on decisions your business makes and records. If your store takes orders from customers in the EU or EEA, you need to answer GDPR questions from your own documented decisions, and the platform can only support the technical part of those answers. The duties sit with you as the store operator, and the platform is a tool you configure to meet them.
Magento Open Source source files are licensed under the Open Software License 3.0 (OSL-3.0), and the distribution also includes the Academic Free License 3.0 (AFL 3.0). These licenses set the terms for using and modifying the code. They say nothing about your data protection obligations. The GDPR applies to the store operator regardless of edition, so the same obligations apply whether you run Magento Open Source or Adobe Commerce. Confirm the license of each extension and third-party module in your build, because each component may carry its own terms and those terms can change with the version you install.
The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, and it does not reduce the responsibility of the controller or processor for compliance. DeployOpen prepares configuration, evidence and documentation for your assessments, but DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Article 25 requires data protection by design and by default, including limiting the personal data processed to what each purpose needs. Article 32 requires security of processing appropriate to the risk. Both duties apply to you as controller and to any processor you engage, whatever the platform does.
Before the build starts, assign an owner for each duty. Ask your implementation partner to map each Magento setting you rely on to the article it supports, and to record who approved it and when. With your legal or privacy team, confirm the lawful basis for each processing purpose, the retention period for customer and order records, and the transfer assessment for any hosting or remote support access outside the EEA. Write down your breach handling process, including who decides on notification to the supervisory authority. These records are the evidence that an authority or auditor will ask for, and Magento cannot produce them for you.
Which GDPR requirements map to Magento Open Source controls
This table maps six GDPR provisions to what Magento Open Source documents and to the configuration or process a self-hosting team must run. Read each row from left to right: the requirement, the platform capability, then what you still configure or run. Where Adobe documents no capability, the cell says so and names the process owner who must close the gap.
| Requirement | Platform capability | Configuration |
|---|---|---|
| Article 15(1), access to personal data | Adobe's personal data maps help locate customer data. Confirm they cover your extensions' tables. | Name an owner to search orders, accounts and extension data, and log each access request. |
| Article 17(1), erasure without undue delay | Personal data maps help find data to erase. No documented erasure workflow for extensions; confirm per extension. | The privacy owner erases on a valid ground, records that ground and checks backups and extension stores. |
| Article 17(3), exceptions to erasure | Not a platform feature. Exceptions are a legal decision, so the process owner must document them. | Legal or the DPO lists retained order records and the legal obligation behind each retention period. |
| Article 25(2), data protection by default | No documented default limits collection. The process owner must review fields and storage periods. | Remove optional customer fields not needed for each purpose, and limit admin access to personal data. |
| Article 32(1), security of processing | Content Security Policy from 2.3.5; restrict mode by default on payment pages from 2.4.7; Adobe advises upgrading every patch cycle. | Enable and tune CSP, apply each patch cycle, and record the risk decision for each security control. |
| Article 44, transfers to third countries | No platform feature. Where data is stored or viewed determines transfers, including remote support access. | Map hosting, backup, support access and extension endpoints, then involve the process owner on transfer mechanisms. |
Evidence for Magento Open Source GDPR compliance reviews
These records are the controller's own evidence when a supervisory authority, a customer or an internal auditor asks how the store handles personal data. DeployOpen can prepare and structure them for a self-hosted Magento Open Source store, but the controller keeps and owns them, and no DeployOpen work produces an audit report, attestation or certification.
Record of processing for the store
The record of processing activities lists, for each activity such as checkout, account management and customer service, the purposes, categories of customers and personal data, recipients, third-country transfers and retention periods. It shows what the GDPR expects a controller to document, and it should name the Magento Open Source modules and integrations that handle each data set. Update it whenever a payment method, shipping connector or integration is added. The privacy lead owns the record, and engineering supplies the technical detail.
Cookie inventory with purposes
The cookie inventory lists every cookie the storefront and admin set, the party that sets it, its purpose, its duration and whether consent must be given before it is set. It shows how Cookie Restriction Mode and the consent banner behave in practice, including cookies added by third-party extensions and tag managers. Review it after every theme change, extension install and analytics tag update, and test it in a clean browser session. The web lead maintains the inventory, and the privacy lead approves each purpose.
Access and erasure response log
The response log records each access or erasure request, including the date received, how the requester was verified, the systems searched, the data found, the decision and the date of response. It should show the Article 15 and Article 17 steps taken and any exception applied, such as data kept to establish or defend a legal claim. Keep export and deletion steps repeatable so the team can show what was removed from the store, the search index and backups. The support lead owns the log, and the privacy lead signs off on refusals.
Order retention decisions and legal basis
This schedule states how long order, invoice and payment-related records are kept, the legal basis for each category and the reason the period was set. It shows that erasure requests were checked against retention duties before any deletion took place. Document the purge or anonymization jobs that enforce each period, and confirm retention periods with finance and tax advisers, since they vary by jurisdiction and by record type. The finance lead and privacy lead own the schedule, and engineering documents the jobs.
Extension data flow register
For each installed module, theme and integration, the register maps which personal data it reads or sends, where that data goes, whether it leaves the EEA and which transfer mechanism applies. It holds a transfer assessment file for each recipient outside the EEA, covering remote access for support, cloud storage and any exposure to third-country authority requests. Update the register at each install, upgrade or vendor change, and check each vendor's data processing terms. The engineering lead maintains the register, and the privacy lead approves each transfer file.
Configuration exports and patch records
Versioned configuration exports show the security of processing settings in place, such as admin two-factor authentication, Content Security Policy mode, HTTPS enforcement and logging. A patch and upgrade log records each Adobe release applied, its date and how it maps to Adobe's release cadence, including the annual full LTS patch each May and the security patches Adobe releases at least annually. Capture a new export after every change. The platform operations lead owns both records.
Answering access and erasure requests from the store database
The quality of an access or erasure response depends on how completely the team finds one person's data across the store database, so the search scope matters more than the response letter. Start with identity verification before any query runs. Match the requester to the account or order using a method proportionate to the data involved, record what you checked and who approved the request, and keep that log with the response. Then search every location where Magento Open Source stores customer data: customer and address records, sales orders and their comments, guest checkout data, newsletter subscriber records, and any tables added by extensions or custom modules. Search by email address, customer ID and order ID, because a single person may appear under several keys.
An access request under Article 15(1) asks for more than a data export. The response must confirm whether you process the person's data and, if you do, provide a copy of it plus information on purposes, categories of data, recipients (including any recipients in third countries), retention periods, the individual's rights, the source of the data, and any automated decision-making. The database can supply the data and the order history, but it cannot supply the purposes, retention periods or recipient list. Those come from your own records of processing and retention schedule, so confirm that they exist and name the payment, shipping, ERP and CRM services that receive customer data before the first request arrives.
Erasure under Article 17(1) applies on six grounds: the data is no longer needed for its purpose, consent is withdrawn where consent was the basis, an objection succeeds, the processing was unlawful, erasure is required by a legal obligation, or the data was collected from a child for information society services. Article 17(3) lists exceptions, including compliance with a legal obligation, the establishment, exercise or defence of legal claims, and others. In a store, order and tax records are the usual conflict. The retention period set by tax and commercial law in your jurisdiction decides how long those records stay, so erasure often means removing personal fields the retained record does not need and documenting that decision. Ask counsel to confirm which records and periods apply to you.
Adobe's personal data maps are the starting inventory for this work, but they are not a guarantee of full coverage. Before you rely on them, confirm which tables and extensions they cover for your installed version and how the export and erase steps use them. Then check each installed extension for customer data it stores, custom tables your team or a developer added, integrations that push data to a CRM or ERP, and backups that keep copies after erasure. The number of extensions storing customer data, the number of custom tables, the number of integrations and your backup retention rules are the main effort drivers. Ask any implementation partner to itemize them in the written scope, and agree how erased data is handled in backups before go-live.
How to set up Magento Open Source GDPR compliance in sequence
This sequence takes a self-hosted Magento Open Source store from a known release line to a documented GDPR position. Each step has one owner and closes with an item for the evidence file, so the file shows what you configured, tested and decided. Work through the steps in order, because later steps depend on the version record and the data map.
Confirm the release line and patch level
The platform engineer records the Magento Open Source release line and patch level in use, then checks both against Adobe's lifecycle policy and released versions page. Note the end of regular support date for that line: 2.4.6 reaches it on August 11, 2026, 2.4.7 on May 31, 2027, 2.4.8 on May 31, 2028 and 2.4.9 on May 31, 2029. Confirm the server stack against the system requirements for your release, because Adobe supports only the listed combinations. The step closes when the evidence file holds a dated version record with the release, patch level, support end date and stack versions, signed by the owner.
Inventory personal data flows and extensions
The privacy lead works with the store developer to map every point where personal data enters, moves through or leaves the store. Cover checkout, customer accounts, newsletter sign-up, order emails, analytics and marketing tags, payment redirects, search, and each installed extension and custom module. For each flow, record the data categories, the purpose, the legal basis and the system holding the copy. Use the personal data mapping Adobe documents for your release as a starting point, then confirm which extension and custom module data falls outside it. The step closes with a data flow register and an extension list showing the personal data each component touches.
Configure and test cookie consent in staging
The frontend developer enables cookie consent through Cookie Restriction Mode, after confirming the exact admin path and settings in the documentation for your release. Set the consent text and categories to match the cookie inventory from the previous step, and confirm that analytics, marketing and extension scripts stay blocked until a visitor agrees. Test in a staging store that mirrors production: accept, refuse, withdraw consent and clear cookies, then check stored cookies and outbound requests in each state. The privacy lead signs off the results. The step closes with a test report showing the consent state at each visit type and the fix for any cookie set before consent.
Define access, erasure and retention procedures
The privacy lead and legal counsel write the procedure for access requests under Article 15 and erasure requests under Article 17. Include identity checks, a search across the store, ERP, mail and support tools, the response log, and who approves each decision. Set retention rules for order records and related accounting data, identifying which records a legal obligation requires you to keep and which personal fields can be erased or anonymized when a request is valid. Article 17(3) lists exceptions, such as compliance with a legal obligation and the establishment or defence of legal claims, so every refusal needs a recorded basis. The step closes with a signed procedure, a retention schedule and a request template.
Restrict admin and database access
The security engineer reduces who can reach personal data, starting from roles. Review Magento admin users, roles and permissions, remove shared or unneeded accounts, and limit customer, order and export screens to the roles that need them. Limit database accounts to the application and to named administrators, keep production and staging data separate, and restrict remote administrative access to the servers that hold the store and its database. Article 32 requires measures appropriate to the risk, so record why each role holds its access. The step closes with an access register listing users, roles, database accounts and the date of the most recent access review.
Set Content Security Policy and integrity controls
The developer configures Content Security Policy for storefront and admin pages where your release supports it. Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages, so confirm the mode your release uses before changing it. List every external script and origin the store loads, allow only those, and test the policy in staging for blocked resources that break checkout or the consent banner. Apply Subresource Integrity to externally hosted files where the templates support it. The step closes with the CSP and integrity configuration, the allowed origins with reasons, and the staging test results.
Document transfer locations and remote support paths
The privacy lead works with hosting and support managers to list every place personal data is stored or viewed. Include the hosting region, backups, CDN, object storage, email and payment providers, logging and monitoring, and any support contractor who connects remotely. Under Chapter V, a transfer to a third country includes remote access from outside the EEA even when only a screen is viewed, and storage in a cloud outside the EEA, so mark each location and access path as inside or outside the EEA. Record the transfer safeguard for each one, and note any processor subject to third-country law that could be compelled to disclose data. The step closes with a transfer register and a remote access log template, reviewed with counsel.
Set the review cycle and triggers
The compliance lead writes a review interval for the whole evidence file and lists the triggers that force an earlier review. Triggers should include each Magento patch or release line change, each new or updated extension, changes to hosting or support access, any new processing purpose, and changes to the GDPR or related rules. Assign an owner to each artifact in the file, so no item goes stale without anyone responsible. At each review, check pending EU legislative and procedural changes, since the GDPR text had not been amended as of October 2026 and related proposals were still in progress. The step closes when the review calendar, trigger list and owner table are approved and filed with the evidence.
Transfers outside the EEA: hosting, remote support and extension vendors
A self-hosted Magento Open Source store can still create a restricted transfer under the GDPR, even when the software runs in infrastructure you control. Three situations commonly do this: a support engineer in a third country views customer or order records on screen during remote administration, backups or logs are written to a cloud service outside the EEA, or an extension vendor or SaaS integration receives customer data from checkout, account or order workflows. EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country, even only displaying data for support or administration, is a transfer, and so is storage in a cloud outside the EEA. Start by listing every place personal data can be seen or stored, not only the production database.
Example 12 of the same guidelines addresses a point that often surprises teams. Engaging an EU processor that is subject to third-country law with extraterritorial effect does not in itself create a transfer, but complying with a third-country authority request would. Controllers should assess that exposure before engaging such a processor. For each hosting, support and extension contract, ask the provider which legal regimes can compel access to data it holds, which entities in its group can reach that data, and whether it has a procedure for challenging a disclosure request. Those answers feed the transfer assessment directly.
Article 48 limits how far a third-country order can reach. A court judgment or administrative decision requiring disclosure of personal data can be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force between the Union or a Member State and the requesting country. The US CLOUD Act provision at 18 U.S.C. 2713 requires providers to preserve or disclose data in their possession, custody or control regardless of where that data is located. Schrems II (Case C-311/18, 16 July 2020) invalidated the Privacy Shield but held that standard contractual clauses remained valid. EDPB Recommendations 01/2020 add that where a cloud provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption alone therefore does not settle the question when the provider must read the data to support it.
The EU-US Data Privacy Framework can support a transfer only where the recipient is a US organization on the Data Privacy Framework List, as established by Commission Implementing Decision (EU) 2023/1795. Confirm the vendor's listing and its scope before relying on it, because an appeal against the General Court's September 2025 judgment upholding the decision is pending as Case C-703/25 P. Vendors outside that list, or processors with no listing, need another transfer tool, such as standard contractual clauses under Commission Implementing Decision (EU) 2021/914, supported by a documented assessment of local law.
The transfer assessment is the controller's decision, and it must be made and recorded by the controller. DeployOpen can document the data flows as part of the build: which support accounts can view customer data, where backups and logs are stored, and which extensions or SaaS services send data out of the store. Ask each vendor for its processing and support access locations, its sub-processor list and its contract terms on government access. The conclusion on whether a transfer is lawful and which safeguards apply needs legal advice from counsel familiar with GDPR Chapter V.
What Magento Open Source does not cover for GDPR
Magento Open Source provides cookie consent controls and the personal data maps Adobe documents, but it does not decide what your organization may collect, how long records are kept or who is accountable for them. The cards below cover the decisions and duties that stay with your organization and the outside parties you involve. The GDPR text had not been amended as of October 2026, and the Omnibus proposals are pending, so confirm the current text when the work starts.
Lawful basis and purpose decisions
Magento stores customer, order and marketing data, but it cannot tell you which Article 6 basis applies to each purpose or whether a purpose is specific enough to justify collection. Your privacy or legal team must document a basis and purpose for every processing activity, including newsletter sign-up, abandoned cart emails and product reviews. Marketing extensions need a separate consent decision covering who approves the consent wording, how withdrawal is recorded and whether the extension keeps consent evidence. Check each extension's data flows against these decisions before you enable it.
Retention periods for order and tax records
Order, invoice and tax records may have to be kept for a fixed period under national tax and commercial law, and that period can run longer than the time you would otherwise hold personal data. Magento does not set retention periods for these records, and deleting an order in the admin does not remove the accounting copies your finance systems hold. Ask your tax advisor and counsel to confirm the legal period for each country you sell in. Then document how the store, ERP and backups apply it, and assign an owner for the schedule.
Record of processing and processor contracts
Article 30 requires a record of processing activities, and Article 28 requires a written contract with each processor. Magento maintains neither. Your team must list the store, hosting provider, payment service, shipping carriers, email and analytics services, support partners and any extension with a hosted component. For each one, record the purpose, data categories and recipients, and confirm the data processing agreement and sub-processor terms before live customer data flows. Update both the record and the contracts whenever an extension is added or replaced.
Breach notification under Articles 33 and 34
Articles 33 and 34 require the controller to notify the supervisory authority after becoming aware of a personal data breach, and to inform affected individuals where the risk to them is high. Magento does not detect breaches, classify them or decide whether notification is required. Your incident response plan must name the decision maker, the assessment criteria, the contacts for each relevant supervisory authority and the templates for individuals. Test the plan against a store-specific scenario, such as card skimming on the checkout page or a leaked admin credential.
Transfer assessments for hosting and remote access
Chapter V applies to every transfer of personal data to a third country, including onward transfers. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, and so is storage in a cloud outside the EEA. Magento does not map where your hosts, backups, content delivery services, support tools or engineers are located. Document each location and access path, choose a transfer mechanism, and assess whether the destination's public authority powers allow effective protection. Involve your counsel in this assessment.
Erasure in backups and logs
Article 17 erasure applies beyond the live store database to copies in backups, search indexes, log files, exports and staging environments. Erasure handled through the admin reaches only the records the platform exposes, and it does not reach restored backups, archived logs or copies your team made for testing. Decide how long backups persist, how a restored backup is erased again after a request, and which logs hold personal data such as IP addresses or email addresses. Record each exception where a legal obligation or a legal claim justifies keeping data under Article 17(3).
Questions buyers ask before hiring outside help for GDPR on Magento
What drives the cost and effort of GDPR work on a Magento Open Source store?
Cost and effort follow the size of your personal data footprint and the number of places that data moves. The main drivers are the number of installed extensions and whether each one stores or sends personal data, custom tables or data stores your team has added, integrations with ERP, CRM, email and payment services, the number of storefront and admin locations, any consent tooling already in place and how much of it needs rework, and how far behind the current release line the store runs. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as drivers of upgrade effort, and an upgrade may be needed before compliance changes can be tested properly. Ask for a quote based on a written scope that lists each of these items, and check which parts are one-time work and which recur.
Can our store team handle GDPR on Magento without an outside partner?
Yes, your store team can do parts of this alone. Consent configuration, including Cookie Restriction Mode, and day-to-day handling of access and erasure requests can sit with trained staff, provided they can find personal data across the database, logs and extension tables. Lawful basis decisions, retention periods and transfer assessments need legal input. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, so support arrangements need legal review. Order records you must keep for tax or accounting reasons also need a legal decision before anything is erased. A partner is useful when your team lacks time, the codebase is heavily customized, or you want an engineering record of every change made.
How long does a GDPR project on Magento take?
Duration depends on scope, so no timeline can be given before the scope is known. The factors are the same as those that drive cost: extensions and their data flows, custom storage, integrations, the number of store views and admin areas, and the release line the store runs on. Timing also depends on how long your legal team needs to decide lawful basis, retention and transfer questions, and those decisions often set the critical path. Ask for a fixed scope in writing that states deliverables, dependencies and which tasks each side owns. Be cautious with any duration that is not tied to a written scope, and confirm which items you must supply and by when.
What do we need to provide before a GDPR engagement starts?
Expect to provide access, people and decisions. On the system side, that means staging and production access suited to the work, read access to databases and logs, and the code repositories and deployment process. On the people side, name a data owner for each data category, a legal reviewer who can sign off on decisions, and a technical contact who knows the store's customizations. For each extension, collect the vendor contact, documentation of what personal data it stores and sends, and its installed version. Also gather your current privacy notice, any records of processing you keep, and existing consent or request logs. Missing vendor information is a common cause of delay, so raise it during scoping.
Does hiring a partner get us a GDPR certificate?
No. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary. Where a certification exists, it is issued by an accredited certification body or supervisory authority for at most three years, and it does not reduce the controller's or processor's responsibility for compliance. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask any partner to state in writing what evidence it will produce, such as configuration records, test results and change logs, and treat any independent assessment as a separate decision you commission yourself.
What ongoing work does GDPR on Magento create after launch?
Recurring work is often larger than the initial build. Expect patch cycles, because Adobe recommends upgrading every patch cycle to stay secure and PCI compliant, and it ships a full patch for the 2.4.x LTS line annually in May. Extensions need updates, and each update may change a data flow that needs review. Access and erasure requests must be handled on a continuing basis within the time the GDPR allows. Data maps need updating whenever a new extension or integration goes live. Periodic reviews of consent settings, retention periods and transfer assessments keep the record accurate. Ask for these items as a separate recurring scope in the quote, with clear ownership between your team and the partner.
Which GDPR tasks on Magento need legal sign-off from our lawyers?
Legal sign-off is needed for decisions, while engineering handles implementation. Lawful basis for each processing purpose, retention periods, and whether an Article 17(3) exception applies to an erasure request, such as compliance with a legal obligation or the establishment, exercise or defence of legal claims, are legal decisions. Transfers to third countries need review under Chapter V, including onward transfers and remote support access from outside the EEA. Engineers can implement those decisions, configure consent, build request workflows and produce evidence, but they should not decide what the law allows. Agree in writing who signs off each decision before build work begins.
Do third-party extensions create GDPR exposure on Magento, and how do we check?
Yes, extensions are a common source of unplanned personal data flows. An extension can store customer data in its own tables, send it to external services or write it to logs. Start with an inventory of every installed extension, its version, its vendor and the personal data it touches. Ask each vendor for documentation of stored fields, third-party services used and where data is hosted, and confirm whether the vendor supports your current release line before you update. For custom modules, review the code for logging of personal data and for outbound calls. Adobe's developer documentation describes modules, themes and language packages as the component types that extend the platform, which helps structure the inventory. Confirm each vendor's answers in writing before you rely on them in your data maps.
How DeployOpen scopes, delivers and supports GDPR configuration and evidence
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For Magento Open Source GDPR compliance, each engagement starts with a written scope covering cookie consent, access and erasure requests, order records, extension data flows and security of processing.
How we scope
- The written scope lists each GDPR duty in play for your store, such as access, erasure, consent and security of processing.
- It names every extension and custom module that collects, stores or sends personal data from the storefront or admin.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before configuration work begins.
How we build
- Configure Cookie Restriction Mode and test that non-essential cookies stay off until the shopper gives consent.
- Map access and erasure requests to Adobe's personal data maps, then test each request type on a non-production copy.
- Review the order records you must keep against erasure duties, and document the retention rule applied to each record type.
How we hand over
- Written records of the configuration, data flows and retention decisions, delivered for your own compliance files.
- Test evidence showing which consent, access and erasure steps were run and what each one produced.
- A walkthrough for your data protection lead and engineers on running access and erasure requests after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- The configuration is rechecked after Magento patches, extension updates and changes to what the store collects.
- Retention periods and lawful bases are confirmed with your legal counsel, since DeployOpen does not set them for you.
