GDPR Data Subject Requests: Exporting and Deleting Customer Data in PrestaShop

GDPR and Ecommerce: What Store Owners Must Understand

The General Data Protection Regulation (GDPR) came into effect in May 2018 and fundamentally changed how ecommerce businesses handle personal data. If your PrestaShop store serves customers in the European Economic Area, you are subject to GDPR regardless of where your business is physically located. The regulation grants individuals specific rights over their personal data, and your store must have the technical and organizational capacity to fulfill those rights.

For PrestaShop store owners, the most operationally demanding aspects of GDPR are Subject Access Requests (SARs) and erasure requests. A SAR is when a customer asks you to provide a copy of all personal data you hold about them. An erasure request, also known as the right to be forgotten, is when a customer asks you to delete their personal data. Both must be handled within strict timelines, and failure to comply can result in significant fines.

This article covers the practical side: what data PrestaShop stores, how to export it, how to delete or anonymize it, what you must retain for legal reasons, and how to build a reliable process around these requests.

What Personal Data Does PrestaShop Store

Before you can respond to any data subject request, you need to know exactly where personal data lives in your PrestaShop installation. Personal data is any information that can identify a natural person, directly or indirectly. In a typical PrestaShop store, personal data is spread across many database tables and potentially across third-party modules.

Core PrestaShop Tables Containing Personal Data

The ps_customer table stores the core customer record: name, email address, date of birth, creation date, IP address at registration, and opt-in flags for marketing. The ps_address table stores delivery and invoice addresses including full name, street address, city, postcode, country, and phone numbers. A single customer can have multiple addresses.

The ps_orders table contains order history linked to customers, including payment methods and delivery details. The ps_order_detail table holds line items for each order. The ps_cart table stores shopping cart data, which includes product selections and can be linked back to a customer. The ps_message and ps_customer_message tables contain messages exchanged between the customer and your store through the contact form or order messaging system.

The ps_connections and ps_connections_source tables track visitor connections including IP addresses and referrer URLs. The ps_guest table stores guest visitor data linked to cookies. The ps_customer_session table (in newer versions) tracks login sessions.

Data in Third-Party Modules

Any module that collects or processes customer data creates additional data storage locations. Newsletter modules store email addresses. Review modules store customer names and review text. Wishlist modules link product preferences to customer accounts. Loyalty and reward modules track purchase behavior. Analytics modules may store browsing patterns. Each of these modules must be considered when responding to a data subject request.

This is why maintaining a data processing inventory, a document listing every place personal data is stored, is not just good practice but a GDPR requirement. Without it, you cannot guarantee completeness when responding to a SAR.

The PrestaShop GDPR Module

PrestaShop provides an official GDPR compliance module (psgdpr) that handles the basic requirements of data subject requests. This module is available for PrestaShop 1.7 and later versions and can be installed from the module catalog in your back office.

What the Module Does

The GDPR module adds a consent management framework to your store, allowing you to track when and where customers gave consent for data processing. It adds consent checkboxes to registration forms, contact forms, and newsletter signup forms. Each consent action is logged with a timestamp.

For data subject requests, the module provides two key features. The data export function generates a PDF or CSV file containing all personal data associated with a customer's email address. The data erasure function anonymizes or removes personal data for a given customer.

The module also adds a section to the customer's account page in the front office where customers can view and download their own data and submit erasure requests directly.

Module Configuration

After installation, navigate to the module configuration page. You will find sections for managing consent checkboxes (which forms require consent and what text to display), configuring which modules are GDPR-aware (the module can query compatible modules for their stored data), and setting up the customer-facing data portability and erasure pages.

The module hooks into other GDPR-compliant modules through a standardized interface. When a module implements the GDPR hooks, the psgdpr module can automatically include that module's data in export and erasure operations. Check which of your installed modules support this integration, because modules that do not support it will need to be handled manually.

Handling Subject Access Requests (SARs)

When a customer requests access to their personal data, you have one calendar month to respond. This deadline starts from the day you receive the request, and it includes the time needed to verify the requester's identity. If the request is complex or you receive a high volume of requests, you can extend this by an additional two months, but you must inform the customer of the extension within the first month.

Verifying Identity

Before releasing any personal data, you must verify that the person making the request is who they claim to be. If the request comes from a logged-in customer account, that is generally sufficient verification. If the request comes via email, you should ask the requester to confirm details that only the account holder would know, such as recent order numbers or the address on file. Do not ask for excessive verification documents, as this itself could be a GDPR violation (data minimization principle), but do enough to prevent unauthorized data disclosure.

Using the GDPR Module for Export

In the PrestaShop back office, go to the GDPR module configuration and find the personal data management section. Enter the customer's email address and use the export function. The module will generate a file containing data from the core PrestaShop tables and from any GDPR-compatible modules.

Review the exported data before sending it to the customer. The export should include: customer account details (name, email, date of birth, registration date), all addresses on file, order history with order details, cart history, messages and communication records, consent logs, and any module-specific data (newsletter subscriptions, reviews, wishlists).

What the Export Must Include

Under GDPR Article 15, the data export must include not just the raw data but also information about how the data is processed. Specifically, you should provide: the categories of personal data you process, the purposes of processing, any third parties the data has been shared with (payment processors, shipping carriers, marketing platforms), the retention period or criteria for determining it, and information about the customer's rights (rectification, erasure, restriction, objection).

The GDPR module handles the raw data export, but the contextual information about processing purposes and third-party sharing typically needs to come from your privacy policy. Consider including a link to your privacy policy alongside the data export or attaching a cover letter that summarizes this information.

Manual Export for Non-Integrated Modules

For modules that do not integrate with the GDPR module, you need to manually extract the data. This typically involves querying the module's database tables directly. For example, a product review module might store data in a table like ps_product_comment with the customer ID as a foreign key. You would need to export all rows associated with the customer's ID.

Document these manual steps in your SAR handling procedure so that they are not missed when a different team member handles a request.

Right to Erasure: Anonymization vs. Full Deletion

The right to erasure (Article 17) allows customers to request that their personal data be deleted. However, this right is not absolute. There are legitimate reasons to retain certain data, and understanding these exceptions is critical to handling erasure requests correctly.

When You Must Delete

If a customer requests erasure and none of the exemptions apply, you must delete or anonymize their personal data without undue delay (the same one-month timeline as SARs). The data must be removed from all systems, including backups if technically feasible. You must also notify any third parties you have shared the data with (payment processors, marketing tools) so they can delete their copies.

When You Can Refuse Deletion

GDPR Article 17(3) lists several exemptions where you can refuse an erasure request. The most relevant for ecommerce are:

Legal obligation: Tax law in most EU countries requires you to retain invoices and financial records for a specific period, typically between 5 and 10 years depending on the jurisdiction. This means you cannot delete order data that is needed for tax compliance, even if the customer requests erasure. You must retain the invoice data (name, address, order details, amounts) for the legally required period.

Legal claims: If there is an ongoing dispute, warranty claim, or potential legal action related to a customer's orders, you can retain the data necessary to establish, exercise, or defend against legal claims.

Contractual obligation: If an order is still being processed, shipped, or is within a return/warranty period, you have a legitimate reason to retain the associated data until the transaction is fully complete.

The Anonymization Approach

The practical solution for most ecommerce stores is anonymization rather than full deletion. Anonymization means replacing personal data with non-identifying placeholders while retaining the transactional records needed for accounting and legal compliance.

For example, instead of deleting an order record entirely, you would replace the customer name with something like "Anonymized Customer" or a hash, replace the email with a placeholder like "deleted@anonymized.invalid", replace the address with generic values ("Address Removed", "City Removed"), and remove phone numbers. The order itself, including product details, quantities, prices, and tax amounts, remains intact for accounting purposes, but it can no longer be linked to an identifiable individual.

The PrestaShop GDPR module uses this anonymization approach by default. When you process an erasure request through the module, it replaces personal identifiers with anonymized values rather than deleting records outright.

What Gets Anonymized vs. Deleted

In a typical GDPR erasure operation on PrestaShop, the following happens. The customer account is deactivated and personal fields are anonymized (name becomes anonymous, email becomes a hash, date of birth is cleared). All addresses associated with the customer are anonymized (names, street addresses, and phone numbers replaced). The customer's carts are deleted entirely since they have no legal retention requirement. Messages and customer service communications are anonymized or deleted. Newsletter subscriptions are removed. Guest records and connection logs associated with the customer are purged.

Order records are anonymized but retained: the customer name and address on the order are replaced with anonymous values, but the order details (products, prices, taxes) remain for accounting compliance. The invoices generated from these orders continue to exist but with anonymized customer data.

Technical Steps for Processing an Erasure Request

Step 1: Verify Identity and Document the Request

Before processing any erasure, verify the requester's identity using the same methods described for SARs. Log the request with a timestamp, the requester's identity, and the verification method used. This log is itself a compliance requirement. You need to demonstrate that you processed the request and when.

Step 2: Check for Retention Exemptions

Review the customer's order history. If they have orders within your legal retention period (check your local tax law requirements), those order records must be retained in anonymized form. If there are open orders, ongoing disputes, or active warranty claims, the erasure of related data should be postponed until these are resolved.

Step 3: Process the Erasure

Use the GDPR module's erasure function for the core data. Enter the customer's email address in the module's administration panel and execute the erasure. The module will anonymize the data across core tables and any GDPR-integrated modules.

For modules not integrated with the GDPR module, you will need to handle erasure manually. This might involve running SQL queries to anonymize or delete data in module-specific tables, or using the module's own administration interface to remove the customer's data.

Step 4: Handle Third-Party Data Processors

Identify all third-party services that have received the customer's data. This typically includes your payment processor (Stripe, PayPal, Mollie), shipping carriers who received delivery addresses, email marketing platforms (Mailchimp, Sendinblue), and any analytics services that process personal data. Contact each processor and request erasure of the customer's data. Most major processors have their own GDPR data deletion processes. Document each communication.

Step 5: Confirm Completion

Send a confirmation to the customer (at their email address, before you anonymize it, or through whatever communication channel they used for the request) stating that their data has been erased. Include the date of erasure and a note about any data that was retained under legal exemptions, explaining the legal basis for retention.

Order Data Retention Requirements

The intersection of GDPR's right to erasure and tax law retention requirements is one of the most commonly misunderstood areas. Here is a practical breakdown by major EU jurisdictions.

Germany: Commercial and tax records must be retained for 10 years (Section 147 AO, Section 257 HGB). This includes invoices, accounting records, and related correspondence.

France: Commercial documents must be retained for 10 years (Article L123-22 Code de Commerce). Tax-related documents for 6 years after the last tax-relevant operation.

Netherlands: Tax administration records must be retained for 7 years (Article 52 AWR).

Italy: Civil code requires 10 years for commercial records (Article 2220 CC). Tax documents for 5 years minimum.

Spain: Commercial records for 6 years (Article 30 Codigo de Comercio). Tax documents for 4 years.

In all cases, what must be retained is the financial and transactional record, not the marketing profile. You must keep the invoice data (what was bought, for how much, taxes paid) but you can anonymize the personal identifiers once the contractual relationship is fully concluded (all deliveries made, return periods expired, payments settled).

A practical approach is to implement a two-stage process: immediate anonymization of non-essential data (marketing preferences, browsing history, newsletter subscriptions, cart data) combined with scheduled anonymization of order-related personal data once the legal retention period expires.

Building an Audit Trail

GDPR requires that you be able to demonstrate compliance, not just achieve it. This means maintaining records of every data subject request received and how it was handled.

What to Log

For every request, record the following: the date the request was received, the type of request (access, erasure, rectification, etc.), the identity of the requester and how their identity was verified, the date the request was processed, what actions were taken (data exported, data anonymized, etc.), any exemptions applied and the legal basis for them, any third parties notified, and the date the requester was informed of the outcome.

Where to Store the Log

The request log should be stored separately from the customer data. If the customer's data is erased, you need to retain the log entry showing that you processed the erasure request. However, the log itself should contain minimal personal data. Record the request using a reference number rather than storing the customer's full name and email in the log. A reference like "GDPR-2026-0042" linked to a securely stored original request document is preferable to repeating personal data across multiple systems.

The PrestaShop GDPR module maintains its own log of data operations, which you can access in the module's administration section. Supplement this with your own records if your process involves manual steps or third-party communications.

Response Timelines and Practical Workflow

The One-Month Rule

You have one calendar month from receipt of the request to respond. This means if you receive a request on March 15, you must respond by April 15. If a request arrives on January 31, the deadline is February 28 (or 29 in a leap year). If the deadline falls on a weekend or public holiday, it extends to the next business day.

Extension for Complex Requests

If the request is particularly complex (for example, the customer has an extensive order history across many years) or if you receive a high volume of requests simultaneously, you can extend the deadline by two additional months. But you must inform the requester within the first month that you are taking the extension and explain why.

Building an Internal Workflow

For stores receiving regular GDPR requests, establish a standardized workflow. Designate a responsible person or team for handling requests. Create a shared inbox or ticketing system where requests are logged. Develop step-by-step checklists for each type of request. Set internal deadlines that are shorter than the legal deadline to allow for review and quality checking. Conduct periodic training so that customer service staff recognize data subject requests (customers do not always use legal terminology).

A customer might say "I want my account deleted" or "send me everything you know about me" without ever mentioning GDPR or data subject rights. Your team must recognize these as formal requests and route them appropriately.

Front Office Self-Service

The PrestaShop GDPR module adds a section to the customer account area where logged-in customers can view their stored data and initiate requests themselves. This self-service approach has several advantages.

It reduces the manual workload on your team because customers can export their own data without involving your staff. It provides an immediate response for data access requests since the export is generated on the spot. And it creates a documented trail of the request and fulfillment.

However, erasure requests submitted through the self-service portal should still be reviewed before processing. An automated immediate erasure could cause problems if the customer has open orders or if there are retention requirements that need to be evaluated. Configure the module to treat self-service erasure requests as requests that require your review and approval rather than automatic execution.

Handling Edge Cases

Guest Checkouts

Customers who checked out as guests (without creating an account) can still submit data subject requests. Their data is linked to their email address rather than a customer account ID. The GDPR module can search by email address to find guest order data. The same export and anonymization procedures apply.

Customers with Multiple Accounts

Some customers create multiple accounts using different email addresses. When processing a request, verify whether the customer has additional accounts. The customer should be able to tell you which email addresses they have used. Process each account separately unless you can verify that all accounts belong to the same person.

Data in Backups

GDPR acknowledges that deleting data from backups may not always be technically feasible. If your database backups contain personal data that has been erased from the live system, document this in your records. If a backup is ever restored, you must re-process any erasure requests that were fulfilled after the backup was taken. Maintain your GDPR request log separately from the database so it survives a backup restoration.

Employees Accessing Customer Data

GDPR requires that personal data be accessible only to those who need it for their role. Review your PrestaShop employee permissions to ensure that only authorized staff can access customer data, run data exports, or process erasure requests. The employee profile system in PrestaShop allows you to restrict access to specific back office sections.

Consequences of Non-Compliance

The enforcement of GDPR is handled by national Data Protection Authorities (DPAs). Fines can reach up to 20 million euros or 4% of global annual turnover, whichever is higher. In practice, fines for small to medium ecommerce businesses have been significantly lower, but they are not negligible. DPAs have issued fines in the tens of thousands of euros range for failures to respond to data subject requests within the required timeframe.

Beyond fines, failing to handle data subject requests properly damages customer trust. Customers who feel their privacy rights are being ignored will take their business elsewhere and may file complaints with their national DPA, which triggers investigations that consume time and resources regardless of the outcome.

Summary and Checklist

Handling GDPR data subject requests in PrestaShop requires preparation, not just reaction. Install and configure the official GDPR module. Create a data processing inventory that maps every location where personal data is stored, including third-party modules and external services. Establish a documented workflow for receiving, verifying, processing, and responding to requests. Understand your local data retention requirements so you know what must be kept and for how long. Implement anonymization rather than full deletion for data with legal retention obligations. Maintain an audit trail of every request and action taken. Train your team to recognize data subject requests even when they are phrased informally.

GDPR compliance is not a one-time setup but an ongoing operational commitment. Regular reviews of your data processing activities, module integrations, and handling procedures ensure that you remain compliant as your store evolves and as regulatory guidance develops.

For more details, read our guides: GDPR for Online Stores: What You Must Do (and What You Can Skip) and GDPR and Cookie Compliance for PrestaShop: What You Actually Need. For a real-world example, see our privacy policy.