When a customer asks you to delete their data, and your orders must stay

An e-mail arrives: "Please delete all the personal data you hold about me." The person has an account and six orders from the last three years. Someone in the team opens Customers > All Customers, finds the account, clicks Delete, and replies that it is done.

It is not quite done. And depending on your obligations, deleting everything might not be what you are allowed to do either. This post explains what Magento does on its own, the tension between deleting personal data and keeping order records, and how our GDPR Data Rights module handles these requests. It describes software, not law: which data you must delete, keep or hand over, and by when, is a question for your legal adviser.

What deleting an account does in Magento

When you delete a customer account, Magento removes the account and its saved addresses. Orders are not deleted. The link between each order and the account is simply set to empty, so the orders are no longer attached to any account¹. The order still holds the customer's name and e-mail address, and the order addresses (billing and shipping, with street, postcode and phone number) are stored with the order, not with the account. Invoices, shipments and credit memos use those order addresses.

So after the delete button, the person's name, e-mail, address and phone number are still in your database, on every order, and visible in the order grid. Magento has no built-in tool to find a person's data across the account, orders, baskets, reviews and newsletter, to export it, or to anonymise it while leaving the order intact.

On one side, people can ask for a copy of their data, ask you to correct it, or ask you to erase it. On the other, a business usually has to keep records of what it sold, for how much and with how much tax, for accounting and tax purposes, and you need order totals that do not change after the fact.

A common way to reconcile the two is anonymisation: the order stays, with its items, amounts and tax, but the personal details on it are replaced. Whether that is the right answer for a given request, and which details you may or must keep, depends on your situation. The software can only make the chosen answer easy and repeatable.

How GDPR Data Rights handles a request

The module gives requests a place to live: CommerceGears > GDPR Data Rights > Requests. Requests made by customers in My Account appear there, and you can add requests received by e-mail or post with the date they arrived. Each request has a reply-by date one calendar month after receipt and shows the days left in the grid. You can pause the clock while you wait for identity details (the paused time is added to the deadline), extend the deadline once by one or two months with a reason, keep internal notes, and complete or deny the request with an e-mail to the customer. Whether those periods match your obligations is, again, for you and your adviser to confirm; the module just counts.

For a copy of the data, the request opens a data pack: account, saved addresses, orders (including guest orders with the same e-mail address), shopping baskets, product reviews, wish list, newsletter, consents, sign-in activity and earlier privacy requests. You see a preview of every section and can untick sections you must not hand out, for example because they contain data about someone else, before downloading JSON or a ZIP of CSV files.

For erasure, the module anonymises rather than deletes orders. Names, e-mail, street, phone, company, VAT number, date of birth and IP address are replaced in the account, the orders, the order addresses, payment details and the sales grids. Saved addresses, saved payment cards, wish lists, open baskets and the newsletter subscription are removed. Product reviews stay under a nickname. Amounts, items and tax are never changed, and you can choose address fields to keep, such as country and region. Deletion means anonymising the orders, unlinking them and then deleting the account.

Every run starts with a dry run that shows what would change, in the admin and on the command line. Anonymisation is blocked while the customer has an order in a status you choose, by default pending, processing, on hold and similar, so you do not anonymise an order that still has to be shipped.

Letting customers do it themselves, and guests too

Customers can also act on their own under My Account > Privacy Settings: download their data, see and withdraw consents, anonymise their account straight away, or ask for deletion, which creates a request in the desk. You decide which of these actions are offered, and whether the password is asked first.

Guests are harder, because they have no account. The module has a page where a guest enters an e-mail address and an order number. If they match, a one-time link is sent to that address, leading to the guest orders with that address, with download and anonymisation. The answer on the page is the same whether the details match or not, so it cannot be used to test which e-mail addresses have ordered.

Consent records and retention

Two more parts of the module deal with the time before and after a request. Consent checkboxes can be added to registration, account information, contact, newsletter sign-up and checkout, never ticked in advance, and each consent is logged with the checkbox text, the privacy policy version, the store view and a hash of the IP address. Privacy policies are versioned, and signed-in customers can be asked to accept a new version.

Retention rules can anonymise old completed orders, or handle accounts with no sign-in or order for a number of days, by creating a deletion request, anonymising or deleting. They start in dry run mode and can only be switched to live after a recent dry run. The periods are yours to set; the module has no opinion on what they should be.

What the module does not do

It does not make a store compliant with any law by itself, and it does not write your policy texts. It has no cookie banner (that is a separate module). Order comments and the free text of product reviews are kept as written, so check those by hand if they might contain personal details. Checkout consent boxes are checked when the Luma checkout places the order, but orders placed through GraphQL or the REST call that only places the order are not checked. Hyvä Checkout is not supported yet; the Luma checkout fallback is.

If you get one request a year, you can handle it by hand with care: export what you find, edit the orders, and keep notes. The module is for stores where requests are regular enough that a repeatable, logged process is worth having.

The GDPR Data Rights page lists every setting, and the user guide explains each screen. Please check your process and texts with your legal adviser before you rely on it.

Sources

1. Magento Open Source 2.4.9 source code, app/code/Magento/Sales/etc/db_schema.xml, foreign key SALES_ORDER_CUSTOMER_ID_CUSTOMER_ENTITY_ENTITY_ID with onDelete="SET NULL"; app/code/Magento/Customer/etc/db_schema.xml (saved addresses deleted with the account, onDelete="CASCADE"); customer name and e-mail columns on sales_order and addresses in sales_order_address, checked 12 October 2026. ↩