GDPR Compliance for PrestaShop Stores: What You Actually Need

Not legal advice. We're a PrestaShop module company based in the EU — GDPR is the law we ship under every day. But the technical patterns below are exactly that: technical. Your DPA wording, your Records of Processing, your breach reporting, and whether you need a DPO are jobs for a data protection lawyer in your jurisdiction. Treat this page as the developer-side companion to that conversation, not a substitute for it.

What "GDPR compliant" actually means (and what no module can give you)

We've built two modules in this space (Cookies Revolution for consent, and a customer-privacy toolkit for export/erasure) and we ship 151 modules total. The single thing we'd tell every merchant before they buy anything: "full GDPR compliance" is not something a module can sell you. A module covers cookies, consent logging, customer-side data export, account deletion, and retention sweeps. GDPR also covers Data Processing Agreements with every vendor, a Record of Processing Activities, a documented breach response, lawful basis decisions, and (depending on your size and what you do) a Data Protection Officer. Most of those are paperwork and policy, not PHP.

So when this page says "use a consent banner that actually blocks scripts," that's a real technical fix. When it says "you need a DPA with Stripe," that's still on you, not your module developer.

The principle that runs underneath all of it

Your customer owns their data. You're holding it to run the order. That single sentence reframes most of the requirements:

Tell people what you collect and why — no silent tracking, no buried third-party pixels
Only collect what the order actually needs — date of birth doesn't ship a parcel
Get real opt-in consent for anything that isn't strictly necessary
Let people see, correct, export, and delete their record on request
Protect what you hold, and don't hold it longer than you need to

Does GDPR apply to your shop?

If you ship to EU customers or your site is available in an EU language, yes. The regulation follows the data subject, not the company. We have US-based clients who insisted GDPR didn't apply to them — until their first French order came in. It applied from that order onwards.

Stop trying to argue your way out. The compliance work overlaps almost entirely with good engineering: HTTPS, sensible retention, decent consent UX, not collecting junk you don't need. You were going to do most of it anyway.

What counts as personal data in a PrestaShop database

Anything that can identify a person directly or in combination with other data. For a shop that means: name, email, phone, address, order history, password hash, IP, browser fingerprint, behavioural logs, and cookies. The trap people fall into is "IP isn't personal data" — it is, the moment you can combine it with a timestamp and a session.

Six legal bases, three of which you'll actually use

GDPR doesn't let you collect data "because you can." You need one of six justifications. For an e-commerce shop, three of them carry 99% of the load:

Contract — to fulfil the order. Shipping address, name, email, payment data.
Consent — newsletters, marketing, non-essential cookies. Must be active opt-in, granular, and as easy to withdraw as it was to give.
Legal obligation — invoices, tax records. Country-specific retention (typically 7–10 years across the EU).

"Legitimate interest" gets invoked for fraud prevention and basic security logs. The other two (vital interest, public interest) almost never apply to a shop.

What your PrestaShop store actually collects — and where it lives

Before you can describe what you collect, you need to know. Most merchants underestimate this by half. The audit we run on every shop we onboard goes through each table category below.

Customer accounts

ps_customer holds first name, last name, email, password hash, optional date of birth and gender, newsletter and optin flags, account creation date, last login, IP at registration, and B2B fields (company, SIRET/APE). Most stores ask for date of birth at registration without ever using it. If you're not running birthday campaigns, drop the field.

Orders and addresses

Every order writes to ps_orders, ps_order_detail, ps_order_payment, ps_order_history, ps_address, ps_order_carrier, and ps_message. ps_address alone can hold full postal data, two phone numbers, company name, VAT number, and a national ID (the dni field, used in Spain and a few other countries).

Guests, connections, page views — the table that quietly explodes

Even visitors who never register leave a trail across ps_guest, ps_connections, ps_connections_source, ps_connections_page, ps_page, and ps_page_viewed. On a moderately busy shop we've seen ps_connections hit eight figures of rows in a year. IP plus browsing behaviour is personal data, and nobody has ever told us "yes, we deliberately keep three years of it." It just accumulates because nothing clears it.

Carts

ps_cart gets a row the moment a visitor drops something into the cart, whether they check out or not. Linked to a customer or a guest, with product selections, addresses, and timestamps. Abandoned carts that link back to a real person are personal data. Most shops never sweep them.

Newsletter, cookies, server logs, third-party modules

ps_emailsubscription (or ps_newsletter on older shops) holds emails, subscription dates, and sometimes the IP. PrestaShop's own cookies are functional (session, cart, admin auth) and don't need consent. The cookies that need consent are the ones your third-party modules drop: GA, Meta Pixel, Hotjar, chat widgets, retargeting tags. Apache/Nginx access logs are personal data too (IP + timestamps + URLs). Audit every module that creates its own tables — reviews, wishlists, live chat, loyalty, cart recovery, analytics modules. If you don't know which tables a module created, you can't be transparent about what you collect.

Open phpMyAdmin, filter the table list by your module prefix, and check what's in there. We do this on every shop we audit and it always finds something the merchant forgot they installed.

Cookie consent: where most shops are still wrong

If we audit a random shop tomorrow, the most likely violation we'll find is cookie consent. Either the banner is cosmetic (it shows, GA loads anyway), or the boxes are pre-ticked, or there's no granular control. This is the part regulators look at first because it's the easiest to verify with a browser inspector.

What ePrivacy + GDPR actually require

Strictly necessary cookies (session, cart, CSRF, admin auth) don't need consent
Anything else (analytics, marketing, personalisation, social) needs explicit opt-in before the cookie is set or the script runs
Consent must be freely given, specific (per category), informed, and active
Withdrawing consent must be as easy as giving it

What is not valid consent

"By continuing to browse, you accept cookies" — implied consent is not consent
A banner with only "OK" — no real choice
Pre-ticked boxes — must be opt-in, not opt-out
Cookie walls ("accept or leave") — most EU regulators have ruled against these
A banner that shows while the scripts have already run — purely decorative

What a working implementation looks like

The script tag pattern that actually works:

<!-- 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>

type="text/plain" prevents the browser from executing. After consent, your consent manager changes it to type="text/javascript" and executes it. If your "consent banner" doesn't do this (if you can see _ga in DevTools before clicking anything) it's broken.

The Google Analytics problem nobody talks about honestly

If you implement consent properly, a meaningful fraction of visitors will decline analytics, and your GA numbers will drop. That is the correct outcome. The data you used to have was collected without lawful basis. Three honest paths forward:

Keep GA4 with proper consent and accept incomplete data. Trends still work; absolute numbers don't.
Switch to self-hosted Matomo or Plausible configured to work without identifying cookies. Some lawyers accept "no consent needed" under legitimate interest for these — check yours.
Use GA4 Consent Mode, which sends cookieless pings on refusal and models the gap. A compromise, not a fix.

The official psgdpr module vs. dedicated CMPs

PrestaShop ships psgdpr which adds a consent banner, a customer-facing data export/erasure flow, and a consent log. It's a reasonable starting point. It doesn't always block third-party cookies before consent (that depends on how your theme and modules load scripts) and the banner UX is basic. For a small shop with GA and nothing else, it's enough. For a shop running GA + Pixel + Hotjar + chat + retargeting + affiliate pixels, you'll want either our Cookies Revolution, or a dedicated CMP like Cookiebot or CookieYes.

Whatever you install, test it. Private browser window, DevTools open on Application → Cookies, reload the homepage. If _ga, _fbp, or any tracker cookie is set before you click anything, the implementation isn't doing its job.

Your privacy policy

This is a legal document. Generic templates lifted from the internet fail because they describe a shop that isn't yours. Yours has to name your processors, your retention periods, and your specific data flows.

What it has to cover (GDPR Articles 13 and 14)

Who you are — company name, registered address, contact email for privacy queries
Your DPO contact if you've appointed one
What personal data you collect, broken down by category
Why you collect each category — the purpose
The legal basis per category (contract, consent, legitimate interest, legal obligation)
Who you share data with — payment, shipping, email, analytics, hosting
International transfers and the legal mechanism behind them
Retention periods per data type
The data subject's rights — access, rectification, erasure, portability, objection, restriction
How to exercise those rights
Right to complain to a supervisory authority
Whether providing data is required to use the service
Any automated decision-making (most shops have none)
Cookie information, or a link to a separate cookie policy

Skeleton you can adapt

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 it

Footer (every page), registration form, checkout, contact form, newsletter signup, and the cookie banner. In PrestaShop you'd usually create the policy as a CMS page (Design → Pages) and surface it via the Link Widget or your theme footer.

Customer data rights

Your customer can ask for their data, ask you to correct it, ask you to delete it, or ask for it in a portable format. The clock for responding is 30 days.

Right to access — data export

Not just their account page. Everything: orders, addresses, consent records, messages, newsletter status, and whatever your modules have stored. The psgdpr module adds an account-page button that generates a PDF/CSV from PrestaShop's core tables. If you're doing it by hand:

-- 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

Not absolute. You can refuse where you have a legal obligation to keep the record (invoices for tax purposes, typically 5–10 years across the EU) or an active legal dispute. In practice this means a mix of delete, anonymise, and keep:

Delete: the account itself, unused addresses, abandoned carts, newsletter subscription, guest records, wishlist, reviews
Anonymise: orders — replace personal fields with "Deleted Customer", keep the financial record for accounting
Keep: invoices, with anonymised customer details on the customer-facing copy, the full record retained for tax

Manual approach if you can't use a module:

-- 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}';

Always back up first, always run the SELECT version of each query and check the row count, always test on staging. Anonymise where rows are linked to orders. We've cleaned up enough botched manual erasures to mean every word here.

Right to portability

Machine-readable export (JSON or CSV) so the data subject can take it elsewhere. The psgdpr export covers it. If you're doing it manually, the same query set as right-of-access, formatted as CSV or JSON.

Right to rectification

The simplest one. Customers can self-serve most of this from their account page. If they email you, fix it in the back office. Done.

Running the process

Verify identity — same email as the account, or a real-name match on the customer record. We've seen attempted-takeover requests via "right to erasure" emails.
Log it — who asked, when, what they wanted
Respond within 30 days — extendable by 60 more in complex cases, but you must notify them inside the first 30
Fulfil or refuse with a documented reason — e.g. "we'll anonymise everything except invoices, kept under legal obligation for 7 years"
Confirm completion in writing

Consent management

Registration form

Unchecked privacy-policy consent box, linking to the policy. Not pre-ticked. Not bundled with newsletter consent — those are separate consents for separate purposes.

Active opt-in, clear about what they're signing up for, easy unsubscribe in every email. Check your theme's newsletter block template — older themes ship a pre-checked box that you have to manually unstick.

Marketing / advertising consent

If you push email lists to Facebook Custom Audiences or similar, that's a distinct purpose and needs its own opt-in. The privacy policy consent doesn't cover it.

Keeping the receipts

You have to be able to prove consent was given. Who, when, for what, how, and which version of the policy was in force. psgdpr keeps a log. If you're rolling your own:

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;

Retention: how long can you keep it?

GDPR says "no longer than necessary." It doesn't hand you specific numbers — you define them, document them, and stick to them. Our defaults across the shops we run:

Active accounts: as long as they're active. We treat 24–36 months without a login or purchase as inactive.
Inactive accounts: re-engagement email, then anonymise if no response in 30 days.
Order data: tax-retention period in your country (typically 5–10 years EU-wide). Anonymise personal fields, retain the financial record.
Invoices: the legally mandated period, full stop.
Abandoned carts: 6–12 months max. There's no business reason to keep them longer.
Guest / connections: 6 months. ps_connections is the table that hurts the most if you forget about it.
Newsletter subscribers: until they unsubscribe. Re-confirm long-inactive subscribers periodically.
Server logs: 30–90 days, rotate aggressively.
Consent records: at least the duration of the consent (usually 12 months minimum).

Cleanup SQL we actually run

-- 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);

Wrap any DELETE in a SELECT first and check the row count before you run it. Run it monthly off-peak via cron. Always back up first. The first time you forget the WHERE clause is the last time you'll forget it.

# 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 write what it deleted and when — that log is part of your accountability paper trail.

Third-party processors

Your shop doesn't operate in isolation. Every vendor you push customer data to is a data processor acting on your behalf, and you need a Data Processing Agreement with each of them.

The processors a typical PrestaShop shop has

Payment — Stripe, PayPal, Adyen, Mollie
Carriers — DHL, UPS, DPD, local national posts
Email marketing — Mailchimp, Brevo, Klaviyo
Analytics — GA, Matomo, Plausible
Hosting — your VPS, dedicated, or cloud provider
CDN / WAF — Cloudflare, Sucuri
Support tooling — Zendesk, Freshdesk
Marketing pixels — Meta, TikTok, Pinterest
ERP / accounting — whatever pulls orders into your back office

DPAs

Every one of them needs a signed DPA. The good news: the big providers all have ready-made versions you can accept inside their dashboard.

Stripe — baked into their Terms of Service
PayPal — in their legal docs
Google — Data Processing Amendment, toggle in GA admin
Mailchimp — standard DPA on their legal page
Brevo — DPA in terms or on request
Cloudflare — DPA in their trust documentation

Accept them, keep copies, file them somewhere you can find them under audit. We use a shared folder per shop with one PDF per vendor.

International transfers

If a processor is outside the EU/EEA (and most of the SaaS list above is US-based) you need a legal mechanism for the transfer. Currently:

EU-US Data Privacy Framework — US companies that have certified. Check at dataprivacyframework.gov.
Standard Contractual Clauses — boilerplate the EU Commission approved. Most large providers include them in their DPAs.
Adequacy decisions — UK, Canada, Japan, South Korea, Switzerland and a handful of others.

List every transfer in your privacy policy with the country and the mechanism.

When something leaks: the breach procedure

A "data breach" under GDPR isn't just "we got hacked." It's any incident leading to accidental or unlawful destruction, loss, alteration, disclosure, or access — so a misdirected order export, a misconfigured backup bucket, a stolen laptop, a rogue employee query, or ransomware that locks you out of customer records all qualify.

The 72-hour clock

If the breach is likely to affect data subjects' rights, you notify your supervisory authority within 72 hours of becoming aware. If the risk is high, you also notify the affected individuals without undue delay. "Becoming aware" means the moment you've reasonably concluded a breach occurred — and you're expected to have monitoring in place to make that moment come quickly.

What goes in a breach notification

Nature of the breach
Categories and approximate number of data subjects affected
Categories and approximate number of records affected
DPO contact or main point of contact
Likely consequences
Measures taken or proposed

Have the plan before you need it

Identify your supervisory authority — CNIL (France), ICO (UK), UODO (Poland), BfDI (Germany), Garante (Italy), AEPD (Spain), and so on
Bookmark their breach notification form
Draft a template notification now — for the authority and for affected customers
Document every incident, even ones you decide didn't need reporting. The reasoning is itself required by GDPR.
Know who investigates, who patches, who communicates

A blocked attack with no data lost is an incident, not a breach. Log it anyway — it shows the monitoring exists.

The mistakes we see most often

Across the audits we've run on PrestaShop shops, the same ten things come up.

1. Pre-ticked consent boxes

Newsletter checkbox at checkout or registration pre-checked. Search your theme templates for checked or checked="checked" on any consent-related input. Untick.

2. No way to delete an account

Out of the box PrestaShop doesn't let a customer self-serve account deletion. Either install psgdpr, our customer-privacy module, or roll your own button on the My Account page.

3. Hoarding data forever

No retention policy. ps_connections rows from 2019. Carts abandoned three years ago still sitting there. Define retention windows and automate the sweep.

4. Weak technical baseline

GDPR Article 32 wants "appropriate technical and organisational measures." The fails we see:

No HTTPS — there's no excuse for this in 2026
Admin accounts on weak passwords or shared between staff
PrestaShop versions years behind security patches
Modules with known CVEs still installed
No backups, or backups in a publicly-readable directory
Shared hosting with poor tenant isolation
FTP instead of SFTP — credentials in cleartext

5. Google Analytics firing before consent

The classic. Banner appears, GA already loaded. The banner is theatre.

6. Cosmetic cookie banner

Banner exists, scripts run regardless. Open DevTools and watch the Network tab while the page loads — if Pixel and GA fire before any click, the banner is decoration.

7. Missing or generic privacy policy

Template copy-paste with placeholders unfilled, or naming processors the shop doesn't actually use. The policy has to describe your shop.

8. No consent log

"Prove this customer agreed to marketing emails" — and there's nothing to show. Either psgdpr's log, our Cookies Revolution log, or your own consent table.

9. Auditing core only, ignoring modules

Reviews, wishlists, abandoned-cart recovery, live chat — every one of them stores personal data, every one of them needs to be in your privacy policy and your retention sweep.

10. No DPAs

Stripe, GA, Mailchimp, Cloudflare in use, zero signed DPAs on file. Spend an hour, accept them all, file the PDFs.

The checklist

Work through this once, then revisit quarterly.

Legal foundation

Privacy policy written, published, specific to this shop
Linked from footer, registration, checkout, contact form
Cookie policy (separate page or section)
T&Cs reference the privacy policy
DPAs signed with every processor
Record of Processing Activities (ROPA) maintained
DPO appointed if required (usually only for large-scale or sensitive processing)

Consent

Registration: unchecked privacy-policy box
Newsletter: separate active opt-in
Marketing: separate from privacy policy consent
Cookie banner blocks non-essential cookies before consent
Granular choice — accept all / reject all / customise
Withdrawable from a persistent footer link
Consent log with timestamp, subject, type, version

Customer rights

Customers can export their data
Customers can request account deletion
Customers can correct their data
Portable (machine-readable) export available
30-day response process documented
Identity verification on every request
psgdpr or equivalent installed and tested

Data management

Retention periods defined per data category
Automated cleanup for guest/connection tables
Automated cleanup for abandoned carts
Server log rotation in place
Inactive accounts handled
All data locations documented (DB, files, third-party)

Security

HTTPS enforced
PrestaShop on a supported version with security patches applied
Modules up to date
Strong admin passwords (and 2FA where supported)
Admin directory renamed
Backups configured, tested, stored off-web-root
SFTP/SSH only
Sensible file permissions (no 777)
Database access restricted

Breach preparedness

Supervisory authority identified
Notification template drafted
Designated incident contact
Monitoring (logs, intrusion detection) in place

Third-party

Every processor listed
DPA on file for each
International transfers documented with legal basis
Processors named in privacy policy
Analytics and marketing pixels gated behind consent

Closing honesty

Regulators aren't looking for perfection. They're looking for genuine effort and reasonable practice. A shop with a real privacy policy, working consent, retention rules, and a process for subject requests is in a strong position even if every edge case isn't covered. What gets penalised is negligence: shops that ignore requests, hoard data they don't need, and run cosmetic banners that do nothing.

Pick the checklist above. Work through it over the next few weeks. Revisit quarterly. That's compliance in practice — paperwork plus engineering, neither one alone.

We've said this twice and we'll say it once more: this is the developer-side companion to a conversation with a data protection lawyer. The technical pieces (consent gating, retention sweeps, erasure flows, audit logging) we can ship. The DPA wording, the ROPA, the breach reporting, the lawful-basis decisions, and whether you need a DPO are jobs for legal counsel in your jurisdiction.