GDPR-Compliant Webshop Development: Build Guide

GDPR-compliant webshop development means making the data protection decisions while the shop is being designed. Article 25 of the GDPR requires it: the shop owner must build in appropriate measures “at the time of the determination of the means for processing”, and by default process only the data each purpose needs. For a webshop, that comes down to seven build decisions: the data model, the checkout forms, how scripts are gated by consent, which third-party assets load, how payments are integrated, which hosting and services you pick, and how rights requests, retention and deletion run in code.

This guide is written for whoever specifies or builds the shop: the owner, a product lead or a developer. If you already run a shop and want to check how it is operated (privacy policy, processor agreements, breach routine), use our GDPR checklist for online shops instead. This is engineering guidance and not legal advice.

In short

• Article 25 applies from the design stage. The EDPB notes that changing processing that has already been designed “could be challenging and costly”.
• Map every data field to a purpose and legal basis before you design the database, and keep contract data apart from marketing data.
• Gate every non-essential script on the stored consent state. Google’s “basic” consent mode loads no Google tags until the visitor responds to the banner, while “advanced” mode sends cookieless pings, and those need their own legal assessment.
• Choose processors on evidence (Article 28(1)), and know which ones send data to the US.
• Build access, export and deletion as features, and make deletion a scheduled job that leaves invoices alone.

Why it has to happen at build time

Article 25(1) asks the controller to implement measures “both at the time of the determination of the means for processing and at the time of the processing itself”. Choosing a platform, a theme, a tag manager setup and a set of plugins is determining the means. The EDPB’s Guidelines 4/2019 on data protection by design and by default (version 2.0, adopted 20 October 2020) add that this “includes the time of procuring and implementing data processing software, hardware, and services”, and that the obligation also covers processing done by your processors.

A theme that hard-codes a pixel in the page template, or a database that stores marketing preferences in the same row as the order, can be fixed later, but every fix touches code that already works.

Start with a data map, then design the schema

List every field the shop will collect and give each one a purpose and a legal basis from GDPR Article 6(1):

Data	Purpose	Typical legal basis
Name, delivery address, email	Fulfilling the order	Contract, Art. 6(1)(b)
Invoice data	Tax and accounting	Legal obligation, Art. 6(1)(c)
Account login	Optional customer account	Contract, Art. 6(1)(b)
Newsletter address	Marketing	Consent, Art. 6(1)(a)
Saved card for future purchases	Faster checkout	Consent, Art. 6(1)(a)
Analytics and ad cookies	Measurement, retargeting	Consent (ePrivacy Art. 5(3))

“Contract” covers only what the contract really needs. In Mousse (C-394/23, 9 January 2025), the CJEU held that collecting customers’ titles to personalise communication was not “objectively indispensable” for selling train tickets online, so it could not rest on the contract basis.

The schema follows from the map. Keep order and invoice records, which you must retain, apart from marketing consent, browsing data and saved preferences, which you must be able to delete on request. Store each consent with a timestamp, the source and the wording shown, because Article 7(1) requires you to be able to demonstrate it. When the data model reflects the legal bases, a deletion request becomes a query rather than a manual investigation.

Checkout forms: minimal by default

Article 25(2) makes data minimisation the default. The EDPB’s own example in Guidelines 4/2019 is an online bookshop: date of birth and phone number cannot be mandatory fields for a prepaid order, and an e-book order should not ask for a postal address. The fields a form requires should therefore depend on the order type.

Three more decisions belong to the checkout:

• Build guest checkout and offer an account after the purchase. The EDPB’s draft Recommendations 2/2025 on the legal basis for requiring the creation of user accounts on e-commerce websites (version 1.0, adopted for public consultation on 3 December 2025; no final version had been published as of October 2026) find that forcing an account is justified only in a few cases, such as subscriptions, and describe guest mode as in principle the most privacy-protective option under Article 25.
• Make saved cards an unticked option on the payment step. The EDPB’s Recommendations 02/2021 say consent is the only appropriate basis for keeping card data to speed up later purchases, and withdrawing consent must delete the stored card.
• Give marketing its own unticked box, separate from accepting the terms. Recital 32 of the GDPR says pre-ticked boxes do not constitute consent, and the CJEU applied the same rule to cookie consent in Planet49 (C-673/17).

Consent: gate scripts in code

Article 5(3) of the ePrivacy Directive requires consent before anything not strictly necessary is stored on or read from the visitor’s device. In code, that means a tag must not load until the stored consent state says it may. A banner that describes trackers which are already running does not meet that. In practice:

• Keep tracking tags out of the page templates. Load them from one place that reads the consent state, and set every category to denied by default.
• Put reject on the same layer as accept, with equal prominence. Most authorities in the EDPB’s cookie banner taskforce treated a missing reject option on that layer as an infringement.
• Store the consent record and the banner version, and give the visitor a permanent way to change the choice (GDPR Article 7(3)).
• Remember that pixels count. The EDPB’s Guidelines 2/2023 (version 2.0, adopted 7 October 2024) treat tracking pixels and tracking links as covered by Article 5(3), and say IP-based tracking can be covered too.

Google’s consent mode documentation describes two setups. In basic mode, Google tags don’t load until the visitor interacts with the banner, and nothing is sent if they decline. In advanced mode, tags load straight away with consent set to denied and send “measurements without cookies”. Given the EDPB’s reading of pixels and IP-based tracking, the advanced mode’s pings need their own legal assessment before you rely on them. Separately, Google’s EU user consent policy requires sites that use its products to obtain legally valid consent from end users in the EEA, the UK and Switzerland where the law requires it, for cookies and for ad personalisation, and to keep records of that consent.

Consent tooling also affects page speed. We cover that in how cookie consent affects technical SEO. For measurement that needs no consent banner at all in some setups, see cookieless, GDPR-compliant analytics.

Third-party assets: self-host what you can

Every file loaded from another company’s server sends the visitor’s IP address to that company. In January 2022 the Munich Regional Court (LG München I, 3 O 17493/20) ordered a website operator to pay a visitor €100 in damages because the site loaded Google Fonts from Google’s servers without consent, passing on his IP address. The court noted that the fonts could have been used without connecting to Google. At build time, fonts, icons and scripts can be bundled and served from your own domain.

Fewer outside scripts also means fewer security dependencies. Stripe’s integration security guide warns that JavaScript included from other sites makes your page’s security depend on theirs, and recommends keeping it to a minimum. A Content Security Policy that lists only the domains you need, such as your payment provider, enforces that list in the browser.

Payments: keep card data out of your systems

Use the payment provider’s hosted checkout or embedded fields so that card numbers go straight to the provider. Stripe says its low-risk integrations send payment details directly to Stripe without them passing through your servers, which reduces your PCI DSS obligations. Handling raw card numbers yourself can mean meeting more than 300 security controls. What you then store (card brand, last four digits, payment status, order reference) is ordinary personal data and follows your normal retention rules. The payment provider is listed in your privacy policy and, depending on its role, covered by an agreement.

Hosting and integrations: choose on evidence

Every service that touches customer data on your behalf is a processor: hosting, the shop platform, email delivery, search, reviews, support desk, analytics. Article 28(1) lets you use only processors “providing sufficient guarantees”, and Article 28(3) requires a contract with set contents. Before choosing an integration, check where it stores and processes data, which sub-processors it uses, whether it signs a data processing agreement, and whether it reuses your customers’ data for its own purposes.

For US services, the EU-US Data Privacy Framework (Commission Implementing Decision 2023/1795) currently covers transfers to certified companies. The General Court upheld it on 3 September 2025 in Latombe v Commission (T-553/23), and an appeal (C-703/25 P) was still pending before the Court of Justice in October 2026. Each US integration is one more transfer to document and keep an eye on. EU-hosted alternatives remove that work where they are technically equal. Our explainer on EU hosting vs US cloud covers the background.

Rights requests as features

Customers can ask for access (Article 15), correction (Article 16), erasure (Article 17) and a copy of their data (Article 20), and the shop owner has one month to respond, extendable by two further months for complex cases (Article 12(3)). Build for that:

• An account page or admin action that exports the customer’s data “in a structured, commonly used and machine-readable format” (Article 20), such as JSON or CSV.
• A routine that anonymises or deletes the profile, marketing data and behavioural data, but keeps invoices and order records you are legally required to retain (Article 17(3)(b)).
• API calls that pass unsubscribes and deletions on to connected systems: the email platform, ad audiences and the support desk. Then nobody has to remember to do it by hand.

Retention and deletion in code

The EDPB’s guidelines on Article 25 list what storage limitation looks like in a system, including that “deletion of certain personal data should be automated”, that retention must be justified per data type, and that backups and logs need their own retention periods. For a webshop that means:

• A scheduled job that deletes or anonymises inactive accounts, abandoned carts and lapsed marketing profiles once their period ends.
• Invoice retention set to your national rule. The VAT Directive (Article 247) leaves the period to each member state.
• Server and application logs that hold IP addresses or emails only as long as you need them, with log rotation configured rather than left at the default.
• Backups that expire, so deleted data does not live on indefinitely in old snapshots.

Security and breach readiness

Article 32 requires security “appropriate to the risk” and names encryption, the ability to restore data in time after an incident, and regular testing of the measures. A breach must be reported to the authority without undue delay and, where feasible, within 72 hours of becoming aware of it (Article 33(1)). You can only become aware of a breach that your systems can detect, so build monitoring, alerting on admin logins and audit logs for access to customer data. The EDPB’s Guidelines 9/2022 on breach notification explain when a controller counts as “aware”.

What it costs to build it in

Most of the work is in default choices: EU hosting, gated scripts, self-hosted assets, minimal forms, a schema that separates contract data from marketing data, and scheduled deletion. Made at the start, those choices are part of the specification. Made later, each one means reworking parts of the shop that already work, which is the EDPB’s point about design-stage costs.

At Caladona, e-commerce builds fall under the Build tier at €7,900+ excl. VAT, as a fixed quote agreed in writing before work starts. See custom webshop builds for what we build and our pricing page for every plan. If you are budgeting the wider project, start with what it costs to build a website in Europe. If you are still deciding on a platform, read our comparison of Shopify and a custom webshop, or send us your current setup.