GDPR Compliance for PrestaShop Stores: What You Actually Need

Disclaimer: This guide provides general information about GDPR compliance for PrestaShop store owners. It is not legal advice. Data protection law varies by jurisdiction and is subject to interpretation by regulators and courts. Consult a qualified legal professional for advice specific to your situation, your country, and your business model.

What GDPR Actually Requires (In Plain English)

The General Data Protection Regulation sounds terrifying. The document is 88 pages long, full of legalese, and the fines go up to 20 million euros. No wonder store owners panic.

But here's the thing — most of what GDPR requires is just treating customer data with basic respect. If you're already a decent store owner who doesn't abuse customer information, you're probably 70% compliant without trying. This guide covers the remaining 30% — the practical steps you need to take to get your PrestaShop store into compliance.

The Core Idea

GDPR boils down to one principle: people own their personal data, not you. You're borrowing it to run your business, and you need to handle it responsibly. That means:

• Tell people what you collect and why — no hidden tracking, no secret data harvesting
• Only collect what you actually need — if you don't need someone's date of birth to sell them shoes, don't ask for it
• Get proper consent — "We use cookies, click OK" doesn't cut it anymore
• Let people see, correct, and delete their data — if someone wants out, you let them out
• Keep data secure — if you collect it, you protect it
• Don't keep data longer than necessary — storing abandoned cart data from 2018 is not necessary

Does GDPR Apply to You?

Yes. Almost certainly yes.

GDPR applies if:

• Your business is based in the EU or EEA
• You sell products or services to people in the EU (even if your business is in the US, Brazil, India, or anywhere else)
• You monitor the behavior of people in the EU (analytics, tracking, profiling)

If you accept euros, offer shipping to EU countries, or your website is available in an EU language — GDPR applies to you. The regulation is about protecting EU residents' data, regardless of where the business processing that data is located.

Don't waste time trying to figure out if GDPR applies to you. If you run an online store accessible from Europe, just comply. The cost of compliance is far less than the cost of non-compliance — and most of the requirements are good business practice anyway.

What Counts as Personal Data?

Personal data is any information that can identify a person, directly or indirectly. In the context of a PrestaShop store, this includes:

• Obvious stuff: name, email address, phone number, postal address, date of birth
• Order data: what they bought, when, how much they paid, payment method used
• Account data: passwords (even hashed ones), account creation date, login history
• Technical data: IP addresses, browser fingerprints, device information
• Behavioral data: pages visited, products viewed, cart contents, search queries
• Cookie data: session IDs, tracking cookies, preference cookies

The key word is "identifies." An IP address alone might not identify someone, but combined with a timestamp and server logs, it can. That combination makes it personal data under GDPR.

The Six Legal Bases for Processing Data

You can't just collect data because you feel like it. You need a legal justification — one of these six:

• Consent: The person explicitly agreed (newsletter signup, marketing emails)
• Contract: You need the data to fulfill an order (shipping address to deliver products)
• Legal obligation: The law requires you to keep it (invoices for tax purposes)
• Vital interests: Rarely applies to e-commerce
• Public interest: Doesn't apply to e-commerce
• Legitimate interest: You have a genuine business reason that doesn't override the person's rights (fraud prevention, basic analytics)

For most PrestaShop stores, you'll use three of these: contract (processing orders), consent (marketing and cookies), and legal obligation (keeping invoices).

What Your PrestaShop Store Collects (And Where It's Stored)

Before you can be transparent about data collection, you need to know exactly what your store collects. PrestaShop stores accumulate more data than most owners realize.

Customer Accounts

The ps_customer table stores everything about registered customers:

• First name, last name, email address
• Password (hashed with bcrypt or the legacy md5+cookie_key method)
• Date of birth (if you ask for it — consider whether you actually need this)
• Gender / social title
• Newsletter and opt-in flags
• Account creation date, last login date
• IP address at registration
• Associated company name and SIRET/APE numbers (B2B fields)

Orders and Addresses

Every order creates records in multiple tables:

• ps_orders — order details, totals, payment method, current state
• ps_order_detail — individual products in each order
• ps_order_payment — payment transaction references
• ps_order_history — status changes with timestamps
• ps_address — delivery and billing addresses (linked to customer)
• ps_order_carrier — shipping method and tracking numbers
• ps_message — customer service messages attached to orders

Note that ps_address can contain full postal addresses, phone numbers, and even a national ID number (DNI field) depending on the country.

Guest Data and Connections

Even visitors who never create an account leave traces:

• ps_guest — browser/OS identification for every visitor
• ps_connections — every visit recorded with IP address and timestamp
• ps_connections_source — HTTP referer (where they came from)
• ps_connections_page — every page they viewed during the visit
• ps_page and ps_page_viewed — page view statistics

These tables grow fast. A moderately busy store can accumulate millions of rows in ps_connections within a year. This is personal data (IP addresses + browsing behavior), and most stores keep it indefinitely without realizing it.

Cart Data

PrestaShop creates a cart record (ps_cart) the moment a visitor adds something to their cart — even if they never check out. This includes:

• Products selected (with combinations/attributes)
• Associated customer ID or guest ID
• Delivery and billing address references
• Carrier selection
• Cart creation and last update timestamps

Abandoned carts are personal data if they're linked to a customer account or contain enough information to identify someone. Most stores never clean these up.

Newsletter Subscriptions

The default newsletter module stores email addresses in ps_emailsubscription (or ps_newsletter in older versions). This includes the email, subscription date, and sometimes the IP address. If you use a third-party email marketing service, the data is also stored there.

Cookies

PrestaShop sets several cookies by default:

• PrestaShop session cookie — identifies the user session (essential for the shop to function)
• Cart cookie — remembers cart contents
• Employee/admin cookie — back-office authentication

These are functional cookies. The GDPR concern is mainly with non-essential cookies added by third-party modules — Google Analytics, Facebook Pixel, remarketing tags, chat widgets, and similar tracking tools.

Server Logs

Your web server (Apache or Nginx) logs every request by default. These logs contain IP addresses, timestamps, URLs requested, user agents, and HTTP referers. They're stored as plain text files on the server and are personal data under GDPR.

Most hosting providers retain these logs for 30-90 days. Know what your hosting setup does — and configure log rotation if you manage your own server.

Module-Specific Data

Third-party modules often create their own database tables. Common examples:

• Review/rating modules: customer name, email, review content, IP address
• Wishlist modules: products saved, customer links
• Live chat modules: full chat transcripts, customer names, emails
• Analytics modules: detailed browsing behavior, conversion tracking
• Loyalty/rewards modules: point balances, transaction history
• Abandoned cart recovery modules: email addresses, cart contents, reminder history

Audit every module you have installed. Check what database tables they create (look for tables with the module's prefix in phpMyAdmin). You can't be transparent about data collection if you don't know what your modules collect.

Cookie Consent: Getting It Right

Cookie consent is where most PrestaShop stores fail GDPR compliance. The bar is higher than most people think.

What the Law Actually Requires

The ePrivacy Directive (which works alongside GDPR) requires that:

• Essential cookies (session, cart, security) can be set without consent — they're necessary for the site to function
• Non-essential cookies (analytics, marketing, social media, personalization) require explicit, informed, opt-in consent before they're set
• Consent must be freely given — you can't make it a condition of using the site
• Consent must be specific — users should be able to accept analytics but reject marketing cookies
• Consent must be informed — users need to know what cookies you set and why
• It must be as easy to withdraw consent as it was to give it

What Doesn't Count as Valid Consent

These common approaches are not GDPR-compliant:

• "By continuing to browse, you accept cookies" — implied consent is not consent
• A banner with only an "OK" button — no real choice is offered
• Pre-checked consent boxes — consent must be opt-in, not opt-out
• Cookie wall (accept all or leave) — this is contested, but most regulators consider it non-compliant
• A cookie banner that displays but loads tracking scripts anyway — the banner must actually block non-essential cookies until consent is given

Default PrestaShop Cookies

Out of the box, PrestaShop sets these cookies:

• PrestaShop-[hash] — main session cookie (essential)
• PHPSESSID — PHP session ID (essential)
• PrestaShop_admin — back-office session (essential, admin only)

These are all strictly necessary cookies. A vanilla PrestaShop installation without third-party modules doesn't need a cookie consent banner for these. The problems start when you add Google Analytics, Facebook Pixel, Hotjar, live chat tools, or any marketing module that drops tracking cookies.

How to Implement Proper Cookie Consent

A compliant cookie consent implementation needs to:

1. Block all non-essential cookies by default — Google Analytics, Facebook Pixel, and similar scripts must not load until consent is given
2. Show a clear consent banner on the first visit with options to accept, reject, or customize
3. Offer granular control — at minimum, separate categories: Necessary, Analytics, Marketing, Preferences
4. Remember the choice — don't ask again on every page load (store consent in a cookie — yes, the irony)
5. Allow withdrawal — provide a way to change cookie preferences later (typically a link in the footer)
6. Keep a record — log when consent was given and for which categories

The technical implementation typically works like this:

<!-- Instead of loading Google Analytics directly: -->
<script src="https://www.googletagmanager.com/gtag/js?id=GA_ID"></script>

<!-- Load it conditionally based on consent: -->
<script type="text/plain" data-cookieconsent="statistics">
  // This script only executes after the user consents to statistics cookies
  (function(){ /* GA code here */ })();
</script>

The type="text/plain" attribute prevents the browser from executing the script. Your consent management tool replaces it with type="text/javascript" after consent is given.

The Google Analytics Problem

Google Analytics is the biggest cookie consent headache for store owners. Here's why:

• GA sets multiple cookies (_ga, _gid, _gat) that are classified as analytics/statistics cookies
• These require explicit consent under GDPR
• If most visitors decline analytics cookies (and many do), your analytics data becomes unreliable
• Google Analytics 4 still transfers data to Google's US servers, which raises additional data transfer concerns under the EU-US Data Privacy Framework

Options to consider:

• Keep GA with proper consent: Accept that you'll lose data from visitors who decline. Your analytics will still be useful for trends, just less complete.
• Use server-side analytics: Tools like Matomo (self-hosted) or Plausible can be configured to work without cookies, which may allow use under "legitimate interest" without consent. Consult your legal advisor on this approach.
• Use Google's Consent Mode: GA4 supports consent mode, which sends cookieless pings when consent is denied and uses modeled data to fill gaps. It's a compromise.

The Official PrestaShop GDPR Module

PrestaShop provides an official GDPR module (psgdpr) that handles some cookie consent functionality. It:

• Displays a cookie consent banner
• Allows customers to request data export and erasure from their account
• Lets you configure which modules are GDPR-relevant
• Provides a consent log

However, the official module has limitations. It may not block all cookies before consent (depending on your theme and other modules), and the banner customization is basic. Many stores supplement it with a more robust cookie consent platform or replace it entirely with a dedicated Consent Management Platform (CMP) like Cookiebot, Complianz, or CookieYes.

Whatever consent solution you use, test it. Open your store in a private browser window, open DevTools (F12 > Application > Cookies), and check what cookies are set before you interact with the consent banner. If you see Google Analytics or Facebook cookies there, your implementation is broken — consent is being bypassed.

Your Privacy Policy Page

Every store needs a privacy policy. It's not optional, and a vague two-paragraph statement doesn't meet the requirements. Your privacy policy must be specific to your store and cover exactly what you do with customer data.

What Must Be Included

Under GDPR Articles 13 and 14, your privacy policy must include:

• Your identity and contact details — company name, address, email
• Data Protection Officer contact (if you have one — most small stores don't need one)
• What personal data you collect — be specific (names, emails, addresses, IP addresses, cookie data)
• Why you collect it — the purpose for each type of data
• The legal basis for each type of processing (consent, contract, legitimate interest, legal obligation)
• Who you share data with — payment processors, shipping carriers, email services, analytics providers
• International data transfers — if data goes outside the EU (Google, Stripe, US-based services)
• How long you keep data — retention periods for each data type
• Customer rights — access, rectification, erasure, portability, objection, restriction
• How to exercise those rights — contact details, process
• Right to complain to a supervisory authority
• Whether data provision is required (e.g., you need an address to ship an order)
• Automated decision-making — if you use any (most stores don't)
• Cookie information — or a link to a separate cookie policy

Privacy Policy Structure Template

Here's a practical structure for a PrestaShop store privacy policy. You'll need to fill in the specifics for your store:

1. Who We Are
   - Company name, registration number, address
   - Contact email for privacy matters

2. What Data We Collect
   - Account registration data (name, email, password)
   - Order data (shipping address, billing address, order contents)
   - Payment data (note: we don't store card numbers — our payment processor does)
   - Communication data (contact form messages, order messages)
   - Technical data (IP address, browser type, cookies)
   - Newsletter subscription (email address)

3. Why We Collect It (Purposes and Legal Basis)
   - To process your orders (contract)
   - To create and manage your account (contract)
   - To send order confirmations and shipping updates (contract)
   - To send marketing emails (consent — you can unsubscribe at any time)
   - To improve our website (legitimate interest / consent for analytics cookies)
   - To comply with tax and accounting laws (legal obligation)
   - To prevent fraud (legitimate interest)

4. Who We Share Your Data With
   - Payment processor: [Name] — processes card payments
   - Shipping carrier: [Name] — receives delivery address and phone number
   - Email service: [Name] — sends transactional and marketing emails
   - Analytics: [Name] — website usage statistics
   - Hosting provider: [Name] — stores all website data

5. International Transfers
   - [List any services that transfer data outside the EU/EEA]
   - Safeguards in place (EU-US Data Privacy Framework, Standard Contractual Clauses)

6. How Long We Keep Your Data
   - Account data: until you delete your account
   - Order data: [X] years (legal requirement for invoices)
   - Abandoned cart data: [X] months
   - Analytics data: [X] months
   - Server logs: [X] days

7. Your Rights
   - Access, rectification, erasure, portability, objection, restriction
   - How to exercise them (email, account settings, GDPR module)
   - Right to complain to [your country's supervisory authority]

8. Cookies
   - [Summary or link to cookie policy]

9. Changes to This Policy
   - Last updated: [date]

10. Contact Us
    - Email for privacy inquiries

Where to Link Your Privacy Policy

Your privacy policy must be easily accessible. Link it from:

• Website footer — on every page
• Registration form — with a checkbox ("I have read and agree to the privacy policy")
• Checkout page — especially if guest checkout is enabled and you're collecting data from non-registered users
• Contact form — before they submit personal information
• Newsletter signup — next to the subscription form
• Cookie consent banner — link to the full policy from the banner

In PrestaShop, you can create the privacy policy as a CMS page (Back Office > Design > Pages) and configure the link in your footer through the "Link Widget" module or your theme's footer configuration.

Customer Data Rights

GDPR gives your customers specific rights over their personal data. You must be able to fulfill these requests within 30 days.

Right to Access (Data Export)

Any customer can ask: "What data do you have about me?" You must provide a comprehensive answer including all data across all systems — not just their account page information, but order history, addresses, consent records, newsletter status, and any data stored by third-party modules.

The official PrestaShop GDPR module adds a "GDPR" section to the customer's account page where they can request a data export. This generates a PDF or CSV containing their data from the PrestaShop database.

If you handle this manually, you'll need to query multiple tables:

-- Get all data for a specific customer
SELECT * FROM ps_customer WHERE id_customer = {ID};
SELECT * FROM ps_address WHERE id_customer = {ID};
SELECT * FROM ps_orders WHERE id_customer = {ID};
SELECT * FROM ps_cart WHERE id_customer = {ID};
SELECT * FROM ps_message WHERE id_customer = {ID};
SELECT * FROM ps_customer_message WHERE id_customer = {ID};

-- Don't forget module-specific tables
SELECT * FROM ps_emailsubscription WHERE email = '{EMAIL}';
-- Check any other module tables that store customer data

Right to Erasure (Right to Be Forgotten)

Customers can request that you delete all their personal data. However, this right is not absolute — you can refuse if:

• You need to keep the data for legal reasons (invoices, tax records — typically 5-10 years depending on your country)
• There's an ongoing legal dispute
• The data is needed for a legitimate purpose that overrides the request

In practice, for a PrestaShop store, this usually means:

• Delete: customer account, addresses not linked to orders, abandoned carts, newsletter subscription, guest records, wishlist, reviews
• Anonymize: order data (replace personal details with "Deleted Customer" or similar — keep the order for accounting but remove identifying information)
• Keep: invoices (legal requirement) — but you can anonymize the customer copy and keep only the financial record

The GDPR module can automate customer account deletion and data anonymization. If you're handling it manually, here's the approach:

-- Anonymize customer record (don't DELETE — linked orders would break)
UPDATE ps_customer SET
  firstname = 'Deleted',
  lastname = 'Customer',
  email = CONCAT('deleted_', id_customer, '@anonymous.invalid'),
  passwd = '',
  birthday = '0000-00-00',
  phone = '',
  optin = 0,
  newsletter = 0,
  deleted = 1,
  active = 0
WHERE id_customer = {ID};

-- Anonymize addresses not linked to delivered orders
UPDATE ps_address SET
  firstname = 'Deleted',
  lastname = 'Customer',
  address1 = 'Deleted',
  address2 = '',
  postcode = '00000',
  city = 'Deleted',
  phone = '',
  phone_mobile = '',
  other = '',
  company = '',
  vat_number = '',
  dni = '',
  deleted = 1
WHERE id_customer = {ID}
AND id_address NOT IN (
  SELECT id_address_delivery FROM ps_orders WHERE id_customer = {ID}
  UNION
  SELECT id_address_invoice FROM ps_orders WHERE id_customer = {ID}
);

-- Delete abandoned carts (not converted to orders)
DELETE FROM ps_cart_product
WHERE id_cart IN (
  SELECT id_cart FROM ps_cart
  WHERE id_customer = {ID}
  AND id_cart NOT IN (SELECT id_cart FROM ps_orders)
);
DELETE FROM ps_cart
WHERE id_customer = {ID}
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Remove newsletter subscription
DELETE FROM ps_emailsubscription WHERE email = '{ORIGINAL_EMAIL}';

Warning: Always back up before running deletion queries. Anonymize rather than delete wherever data is linked to orders or invoices. Test on staging first. And remember — the queries above are examples; your specific setup may have additional module tables that also need cleaning.

Right to Portability

Customers can request their data in a machine-readable format (JSON, CSV, XML). This is so they can transfer their data to another service. The GDPR module's export feature typically covers this, generating a CSV or PDF.

If you handle it manually, provide the data in a structured format — JSON or CSV — covering all the same data points as the "right to access" response.

Right to Rectification

Customers can ask you to correct inaccurate data. In most cases, PrestaShop customers can do this themselves through their account page (update name, email, address). But if they ask you to do it, you must comply within 30 days.

This is usually the easiest right to fulfill — just update the record in the back office.

Handling Data Requests in Practice

Set up a process for handling GDPR requests:

1. Verify identity — before sending someone's data or deleting an account, make sure it's actually them. Ask them to send the request from the email address associated with their account.
2. Log the request — record when you received it and what was requested
3. Respond within 30 days — this is the legal deadline. If a request is complex, you can extend by another 60 days, but you must notify the requester within the first 30 days.
4. Fulfill the request — export, delete, correct, or explain why you can't (with legal justification)
5. Confirm completion — notify the customer that the request has been fulfilled

Keep a log of all data subject requests and your responses. This demonstrates accountability if a regulator ever asks.

Consent Management

Consent under GDPR must be freely given, specific, informed, and unambiguous. Here's what that means in practice for your PrestaShop store.

Registration Form

When customers create an account, you need:

• A checkbox (unchecked by default) linking to your privacy policy: "I have read and agree to the Privacy Policy"
• This checkbox must not be pre-checked — the customer must actively tick it
• You cannot bundle this with marketing consent — they're separate things

In PrestaShop 1.7+ and 8.x, you can configure this through the GDPR module settings or by editing the customer registration template. The module typically adds consent checkboxes to the registration form, checkout process, and contact form.

Newsletter Consent

Newsletter subscription requires its own separate consent. The customer must:

• Actively opt in (unchecked box or separate signup form)
• Know what they're signing up for ("Receive our weekly deals and product news")
• Be able to unsubscribe easily (unsubscribe link in every email)

PrestaShop's newsletter module includes an opt-in checkbox. Make sure it's not pre-checked — check your theme's newsletter block template.

Marketing Consent

If you share customer data with third parties for marketing purposes (e.g., passing email lists to Facebook for Custom Audiences), you need explicit consent for that specific purpose. "I agree to the privacy policy" doesn't cover it — you need a separate checkbox like: "I agree to receive personalized advertising based on my shopping behavior"

Most PrestaShop stores don't need this unless they're doing advanced marketing integrations.

Keeping Consent Records

You must be able to prove that consent was given. This means logging:

• Who gave consent (customer ID or email)
• When consent was given (timestamp)
• What they consented to (privacy policy, newsletter, marketing)
• How consent was given (registration form checkbox, newsletter popup, etc.)
• Which version of the privacy policy was in effect at the time

The official GDPR module keeps a consent log. If you're managing this manually, create a database table to track consent events:

CREATE TABLE ps_gdpr_consent_log (
  id_consent_log INT AUTO_INCREMENT PRIMARY KEY,
  id_customer INT DEFAULT NULL,
  customer_email VARCHAR(255) NOT NULL,
  consent_type VARCHAR(50) NOT NULL,  -- 'privacy_policy', 'newsletter', 'marketing'
  consent_given TINYINT(1) NOT NULL,  -- 1 = given, 0 = withdrawn
  ip_address VARCHAR(45) DEFAULT NULL,
  date_add DATETIME NOT NULL,
  request_details TEXT DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Data Retention: How Long Can You Keep Data?

GDPR doesn't specify exact retention periods — it says data should be kept "no longer than necessary." You need to define your own retention policy and stick to it.

Recommended Retention Periods

• Active customer accounts: Keep as long as the account is active. Consider accounts inactive after 24-36 months of no login or purchase.
• Inactive customer accounts: Send a re-engagement email, then anonymize if no response within 30 days.
• Order data: Keep for as long as legally required for tax/accounting purposes. In most EU countries, this is 5-10 years. Anonymize the personal details but keep the financial records.
• Invoice data: Must be kept for the legally mandated period (typically 7-10 years in most EU countries).
• Abandoned cart data: Delete after 6-12 months maximum. There's no justification for keeping abandoned carts longer.
• Guest/visitor data: ps_guest and ps_connections data should be cleaned regularly — 6 months maximum for most stores.
• Newsletter subscribers: Keep until they unsubscribe. Periodically re-confirm inactive subscribers.
• Server logs: 30-90 days is standard. Rotate and delete older logs.
• Cookie consent records: Keep for at least the duration of the consent (typically 12 months).

Cleaning Old Data: SQL Queries

Here are safe cleanup queries for common PrestaShop data. Always backup first and test on staging.

-- Delete guest records older than 6 months
DELETE FROM ps_guest
WHERE id_guest NOT IN (SELECT id_guest FROM ps_cart WHERE id_cart IN (SELECT id_cart FROM ps_orders))
AND id_guest IN (
  SELECT g.id_guest FROM ps_guest g
  INNER JOIN ps_connections c ON c.id_guest = g.id_guest
  GROUP BY g.id_guest
  HAVING MAX(c.date_add) < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

-- Delete old connection records (keeps stats but removes IP-linked data)
DELETE FROM ps_connections_source
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections_page
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections
WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

-- Delete abandoned carts older than 12 months (not converted to orders)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
WHERE c.date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND c.id_cart NOT IN (SELECT id_cart FROM ps_orders);

DELETE FROM ps_cart
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Clean old page view statistics (anonymous aggregate data — lower priority)
DELETE FROM ps_page_viewed
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH);

Consider automating these cleanups with a cron job. Run them monthly during off-peak hours. Always wrap destructive queries in a transaction or at least verify the row count with a SELECT before running the DELETE. And never skip the backup.

Automating Data Retention

Create a PHP script or cron job that runs these cleanup queries on a schedule:

# Example crontab entry — runs at 3 AM on the 1st of each month
0 3 1 * * /usr/bin/php /path/to/your/store/scripts/gdpr-cleanup.php >> /var/log/gdpr-cleanup.log 2>&1

The script should log what was deleted and when — this is part of your GDPR accountability documentation.

Third-Party Services and Data Processors

Your PrestaShop store doesn't operate in isolation. You share customer data with various third-party services. Under GDPR, these are called "data processors" — they process data on your behalf.

Common Data Processors for PrestaShop Stores

• Payment gateways (Stripe, PayPal, Adyen, Mollie) — receive customer name, email, billing address, card details
• Shipping carriers (DHL, UPS, DPD, local carriers) — receive delivery name, address, phone number, sometimes email
• Email marketing services (Mailchimp, Brevo/SendinBlue, Klaviyo) — receive email addresses, names, purchase history
• Analytics (Google Analytics, Matomo) — receive IP addresses, browsing behavior, device information
• Hosting provider — stores all your data (database, files, logs)
• CDN / security services (Cloudflare, Sucuri) — sees all traffic, including IP addresses
• Customer support tools (Zendesk, Freshdesk) — may store customer communications and data
• Social media pixels (Facebook, TikTok, Pinterest) — receive browsing behavior and conversion data
• ERP / accounting software — receives order and customer data for business management

Data Processing Agreements (DPAs)

GDPR requires you to have a Data Processing Agreement with every processor that handles personal data on your behalf. The DPA must specify:

• What data is processed
• The purpose and duration of processing
• The processor's obligations regarding data security
• What happens to the data when the agreement ends
• The processor's obligation to notify you of data breaches

The good news: most major service providers already have standard DPAs available:

• Stripe: Built into their Terms of Service
• PayPal: Available in their legal documentation
• Google: Data Processing Amendment available in Google Analytics admin
• Mailchimp: Standard DPA available on their website
• Brevo/SendinBlue: DPA included in their terms or available on request
• Cloudflare: DPA available in their trust documentation

Download and sign (or accept online) the DPA for every service you use. Keep copies. A regulator may ask to see them.

International Data Transfers

If any of your processors are based outside the EU (and many are — Stripe, Google, Mailchimp are all US-based), you need a legal mechanism for the data transfer. Currently, the main options are:

• EU-US Data Privacy Framework — US companies that are certified under this framework can receive EU personal data. Check if your processors are on the list at dataprivacyframework.gov.
• Standard Contractual Clauses (SCCs) — contract terms approved by the EU Commission for international transfers. Most large providers include these in their DPAs.
• Adequacy decisions — some countries outside the EU have been deemed to have adequate data protection (UK, Canada, Japan, South Korea, and others).

List all international data transfers in your privacy policy. Specify the country and the legal mechanism that protects the transfer.

Data Breach Procedure

A data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. For a PrestaShop store, this could be:

• Your store gets hacked and customer data is stolen
• A database backup is left publicly accessible
• Customer order data is accidentally emailed to the wrong person
• A module vulnerability exposes customer information
• An employee accesses customer data without authorization
• Ransomware encrypts your database and you lose access to customer records

The 72-Hour Rule

If you experience a data breach that's likely to result in a risk to people's rights and freedoms, you must:

1. Notify your supervisory authority within 72 hours of becoming aware of the breach
2. Notify affected individuals without undue delay if the breach is likely to result in high risk to their rights

"72 hours of becoming aware" means from when you reasonably determined a breach occurred — not from when the breach happened. But you're expected to have monitoring in place to detect breaches promptly.

What to Include in a Breach Notification

Your notification to the supervisory authority must include:

• The nature of the breach (what happened)
• Categories and approximate number of individuals affected
• Categories and approximate number of personal data records affected
• Contact details of your DPO or main contact point
• Likely consequences of the breach
• Measures taken or proposed to address the breach

Notification to affected individuals should describe the breach in clear language and include the same information plus advice on how they can protect themselves (change passwords, watch for phishing, etc.).

Breach Response Plan

Don't wait for a breach to figure out what to do. Prepare in advance:

1. Identify your supervisory authority — this is the data protection authority in the EU country where your company is based (e.g., CNIL in France, ICO in the UK, UODO in Poland, BfDI in Germany)
2. Know the notification process — most authorities have an online form. Bookmark it.
3. Prepare a template for breach notification (to the authority and to customers)
4. Document everything — even breaches you decide don't need to be reported. The documentation of your decision-making process is itself required by GDPR.
5. Have a technical response plan — who investigates, who patches, who communicates

Not every security incident is a reportable breach. If your firewall blocks an attack and no data is compromised, that's an incident, not a breach. But log it anyway — it shows you have monitoring in place.

Common GDPR Mistakes PrestaShop Stores Make

After reviewing hundreds of PrestaShop stores for GDPR compliance, these are the mistakes we see most often:

1. Pre-Checked Consent Boxes

The newsletter checkbox on registration or during checkout is pre-checked. This is a clear GDPR violation. Consent must be opt-in. Search your theme templates for any checkbox that has checked or checked="checked" as a default attribute on consent-related forms.

2. No Way to Delete Accounts

Many PrestaShop stores have no mechanism for customers to delete their accounts. The default PrestaShop front-office doesn't offer account deletion. You need the GDPR module or a custom solution to provide this.

3. Keeping Data Forever

No data retention policy. Guest records from 2015 still in the database. Connection logs going back years. Abandoned carts from customers who forgot your store exists three years ago. Set retention periods and enforce them.

4. Inadequate Data Security

GDPR requires "appropriate technical and organizational measures" to protect data. Common failures:

• No SSL certificate — all stores should use HTTPS. There's no excuse in 2026.
• Weak admin passwords — enforce strong passwords for all back-office accounts
• Outdated PrestaShop version — security patches matter. Running PrestaShop 1.6 with known vulnerabilities is a risk.
• Unpatched modules — modules with known security vulnerabilities are a common attack vector
• No database backups — or backups stored in publicly accessible locations
• Shared hosting with poor isolation — if another site on the same server gets compromised, your data could be at risk
• FTP instead of SFTP — FTP transmits credentials in plain text

5. Google Analytics Without Consent

The most common violation we see. Google Analytics tracking code loads on every page for every visitor, regardless of cookie consent. This sends personal data (IP address, browsing behavior) to Google before the visitor has any chance to consent.

6. Cookie Banner That Doesn't Actually Work

A cookie banner is displayed, but the non-essential cookies are loaded before consent is given. The banner is cosmetic — it doesn't actually control cookie behavior. Test this yourself: open DevTools, check what cookies and network requests are made before you interact with the banner.

7. No Privacy Policy (or a Generic One)

Either there's no privacy policy at all, or it's a generic template copied from the internet that doesn't reflect what the store actually does. Your privacy policy must be specific to your store, your data practices, and your third-party services.

8. Not Keeping Consent Records

Customers checked the consent box, but there's no log of when, what they consented to, or which version of the privacy policy was in effect. If a regulator asks "prove this customer consented to marketing emails," you need to be able to show the receipt.

9. Ignoring Module Data

Store owners audit their core PrestaShop data but forget about data collected by third-party modules. Review modules, wishlist modules, abandoned cart modules, chat tools — they all collect personal data that falls under GDPR.

10. No Data Processing Agreements

Using Stripe, Google Analytics, Mailchimp, and a dozen other services without having DPAs in place. These are often available for free from the service provider — you just need to sign them.

GDPR Compliance Checklist for PrestaShop Stores

Use this checklist to assess your store's GDPR compliance. Go through each item and mark whether it's done, in progress, or needs attention.

Legal Foundation

• Privacy policy created and published on the store
• Privacy policy covers all required information (see section above)
• Privacy policy is linked from the footer, registration form, checkout, and contact form
• Cookie policy created (separate page or section within privacy policy)
• Terms and conditions updated to reference privacy policy
• Data Processing Agreements signed with all third-party processors
• Record of Processing Activities (ROPA) created — a document listing all data processing activities
• Data Protection Officer appointed (if required — generally for large-scale processing)

Consent

• Registration form has unchecked privacy policy consent checkbox
• Newsletter signup requires active opt-in (no pre-checked boxes)
• Marketing consent is separate from privacy policy consent
• Cookie consent banner implemented and functional
• Cookie banner blocks non-essential cookies until consent is given
• Cookie banner offers granular choice (accept all, reject all, customize)
• Cookie preferences can be changed after initial choice (e.g., footer link)
• Consent records are logged with timestamp, user, and consent type

Customer Rights

• Customers can access/export their personal data
• Customers can request account deletion
• Customers can correct their personal data
• Customers can download their data in machine-readable format
• Process exists to handle data subject requests within 30 days
• Identity verification process for data requests
• GDPR module installed and configured (or equivalent functionality)

Data Management

• Data retention periods defined for all data categories
• Automated cleanup of old guest/connection data
• Automated cleanup of abandoned carts beyond retention period
• Server log rotation configured
• Inactive customer accounts are identified and handled
• All data storage locations are documented (database, file system, third-party services)

Security

• SSL/TLS certificate installed (HTTPS enforced)
• PrestaShop version up to date with security patches
• All modules up to date
• Strong passwords enforced for admin accounts
• Admin directory renamed from default
• Regular backups configured and tested
• Backups stored securely (not in public web directory)
• SFTP or SSH used instead of FTP
• File permissions properly configured (no 777 directories)
• Database access restricted (no remote root access)

Breach Preparedness

• Supervisory authority identified
• Breach notification process documented
• Breach notification template prepared
• Contact person for breach incidents designated
• Security monitoring in place (log review, intrusion detection)

Third-Party Services

• All third-party services that process customer data are listed
• DPA in place with each processor
• International data transfers documented with legal basis
• Third-party services listed in privacy policy
• Analytics scripts load only after cookie consent
• Marketing pixels load only after cookie consent

Final Thoughts

GDPR compliance isn't a one-time project — it's an ongoing practice. Your privacy policy needs updating when you add new modules or services. Your data cleanup needs to run regularly. Your consent mechanisms need testing after every theme or module update.

The good news is that most of the heavy lifting is done once. Setting up proper cookie consent, writing your privacy policy, signing DPAs, and configuring data retention — these are one-time tasks with occasional maintenance.

And here's something most GDPR guides won't tell you: perfection is not the standard. Regulators are looking for genuine effort and a reasonable approach to data protection. A store that has a good privacy policy, proper cookie consent, data retention rules, and a process for handling customer requests is in a strong position — even if every tiny detail isn't perfect.

What regulators penalize is negligence: stores that do nothing, ignore customer requests, collect data they don't need, and leave it unprotected indefinitely. Don't be that store.

Start with the checklist above, work through it over the next few weeks, and revisit it quarterly. That's GDPR compliance in practice — not panic, not perfection, just consistent good practice with customer data.

Remember: this guide is about general GDPR compliance principles for PrestaShop stores. Data protection law is complex and evolving. For binding legal advice specific to your business, your jurisdiction, and your data processing activities, consult a qualified data protection lawyer or consultant. The investment in professional legal advice is small compared to the potential consequences of getting it wrong.