Does GDPR apply to our online shop, and what does it require first?
The GDPR applies to any online shop that processes personal data of people in the EU, whether the shop is based in the EU or not, and it requires no audit, attestation or certificate. Compliance is therefore work the shop owns as controller, and it is proven by the shop's own records: what it collects, why, on which legal basis, where the data goes and how customer requests are answered. An implementation partner can prepare systems and gather evidence, but only an independent auditor or certification body issues a report or certificate, and the GDPR's optional Article 42 certification does not reduce the shop's responsibility either.
Scope depends on how the shop actually works, not on its size. Relevant factors include the order flows (physical goods, digital downloads, subscriptions, marketplace sellers), the marketing tools that receive customer data, the cookies and tags set on the storefront, and the number of systems that hold customer records, such as the storefront, payment provider, carrier integrations, email platform, analytics and support desk. Before drafting any policy, the shop should inventory these systems and mark which ones store personal data and which external parties receive it. That inventory drives every later decision on minimization, lawful basis and transfers.
The financial stakes are set out in Article 83. Infringements such as failures of data protection by design, security of processing or breach notification can attract administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Infringements of the processing principles, lawful basis conditions, data subject rights or transfer rules can reach EUR 20 million or 4%, whichever is higher. Leaders should ask their counsel and any outside adviser to confirm how these ceilings apply to their group structure and which supervisory authority would lead, since cross-border cases follow the procedural rules in Regulation (EU) 2025/2518 from 2 April 2027.
How to collect only what each order needs
This sequence turns a checkout form into a set of fields that each serve a named purpose, and leaves a written record that shows why each field exists. The result is a checkout that asks for less, with the reasons documented and the changes carried through to every system that receives order data.
Inventory every field the checkout collects
Start by listing every field the checkout asks for, including optional fields, hidden fields, account creation fields and anything captured by the payment or delivery widgets. Export the live form definition and the database columns it writes to, so the list reflects what is actually collected rather than what the design brief says. The output is a single register with one row per field, its source, and the screen where it appears. You know this step is done when the register matches a test order placed through every product path, including digital-only purchases.
Map each field to a specific purpose
For each row, the controller states the purpose the field serves and the lawful basis for that purpose, such as the contract needed to complete the order, a legal obligation for tax records, or consent for marketing. The EDPB's web shop example shows the test: a bookshop that made date of birth, phone number and home address mandatory for all orders had no purpose that required them for every order. A field with no named purpose, or only a vague purpose such as 'may be useful later', fails this step. The product owner signs off the mapping, and legal or privacy staff reviews any field tied to marketing or profiling.
Remove or make optional the fields without a purpose
Delete fields that no purpose requires. Where a field serves only a purpose that needs consent or a different basis, move it out of the order flow so it is not a condition of buying. In the illustrative bookshop case, the team splits the form so that an eBook order no longer asks for a delivery address, because no delivery takes place, while physical book orders keep the address. Date of birth and phone number are removed from the mandatory set unless a documented purpose needs them. The output is a revised form specification and a short note explaining each removal.
Split the form by order type
Where different products need different data, design separate branches of the checkout so each order type only sees the fields it needs. Digital and physical orders are the usual split, but subscriptions, gift orders and pickup orders can follow the same logic. Test each branch with real data flows to confirm that a digital order never writes a delivery address to the order record. The check is complete when each branch has a written field list and a test result showing the fields stored for that order type.
Document the result in the record of processing
Update the record of processing for the shop with the revised field set, the purpose and lawful basis for each field, the categories of data subjects and recipients, and the retention period for each group. This record is the controller's own document, and it is the evidence an assessor or supervisory authority would ask to see. Confirm with counsel which retention periods apply in each market you sell into, because the record should state the periods you actually apply. You know the step is done when every stored field appears in the record with a purpose and a retention rule.
Push the field changes to every connected system
Field changes only protect data if every system that receives or stores the data follows them. Update the checkout, the order management or ERP system, the payment and shipping integrations, the customer account database, the email and marketing platforms, and any analytics or data warehouse feeds. Remove the retired fields from API payloads, export jobs and mapping tables, and check that old values are not copied into new records. Ask each system owner to confirm in writing which fields they now receive, because a field that still syncs to the marketing tool undermines the purpose limit set at checkout.
Confirm decisions remain with the controller
Throughout this sequence the shop owns the decision. An implementation partner or consultant can map systems, test flows and draft the documentation, but the controller decides which purposes are legitimate and which fields to keep. Record who approved the final field set and when, and keep that approval with the record of processing. Review the set again when a new product type, payment method or marketing tool is added, since each new addition can introduce a field that has no documented purpose.
Contract necessity or consent: which basis fits each purpose
Contract necessity is the basis for processing that the sale cannot happen without. The EDPB's guide for small business gives card details needed to complete a purchase as an example. Delivery address, invoice data and order confirmations usually fall here too, but only to the extent each is needed for the specific order. The test is practical: if the order cannot be performed without the data item, contract necessity is likely to apply. If the form asks for data the order does not need, that data must rest on another basis or should not be collected.
- Card details and payment: needed to take payment, so contract necessity generally applies to the payment flow itself.
- Delivery address: required for physical goods, but not for an eBook or other digital delivery, as the EDPB's bookshop example shows.
- Invoice and tax data: needed where a legal invoice must be issued, which may also rest on a legal obligation.
- Optional fields: date of birth or a phone number that the order does not need should not be mandatory for checkout.
- Order-related service messages: shipping and delivery updates tied to the contract.
Confirm with counsel which fields each product category genuinely requires, and document that reasoning in your records of processing.
Marketing is not part of contract performance. The EDPB guide states that marketing needs consent or legitimate interest, so a customer's purchase does not by itself permit promotional emails. Where you rely on consent, it must be freely given, specific, informed and unambiguous, and you must be able to demonstrate it. Where you rely on legitimate interest, you must balance your interest against the customer's reasonable expectations and offer an easy way to object. Under Article 21, a customer may object to direct marketing at any time, and processing for that purpose must then stop.
- Consent for newsletters: an unticked, separate opt-in that records when and how consent was given.
- Soft opt-in or legitimate interest: a possible route for similar products to existing customers, subject to the ePrivacy rules and a documented balancing test.
- Objection handling: a working unsubscribe that stops marketing processing, not only email delivery.
- Withdrawal of consent: the same ease as giving it, and a record that it was honored.
- Refreshing consent: the EDPB recommends refreshing consent at appropriate intervals.
Confirm which route applies to each marketing channel with counsel, since national ePrivacy rules can change the answer.
Recommendations built from a customer's purchase history are a separate purpose from completing that purchase. The EDPB's bookshop example makes this explicit: using past purchases to suggest other books cannot rely on contract necessity. The shop needs consent or, depending on the circumstances, legitimate interest. Because profiling of this kind can be intrusive, the choice of basis should be reasoned and recorded, not assumed.
- Separate purpose: treat recommendations as their own processing activity in your records.
- Consent route: a clear, optional choice to receive personalized suggestions, with a way to turn it off.
- Legitimate interest route: possible in some circumstances, but it requires a documented balancing test and an objection right that works.
- Data minimization: use only the purchase data the recommendation logic needs.
- Retention: define how long purchase-based profiles are kept and when they are deleted.
Illustrative example: a shop that shows "customers who bought this also bought" on product pages should record which basis it uses and whether customers can opt out of that logic.
Fraud prevention and targeted advertising are both excluded from contract necessity by the EDPB guide, even though each often feels essential to running a shop. Fraud checks, such as device signals or velocity rules, need a basis that is not contract performance, typically legitimate interest with a documented assessment. Targeted advertising, including tracking pixels and profile-based ad audiences, needs consent or legitimate interest, and in practice it also engages the cookie and ePrivacy rules discussed elsewhere on this page.
- Fraud screening: document the legitimate interest, the data used and the proportionality of each signal.
- Automated decisions: where a fraud check blocks an order automatically, consider Article 22 and offer a route to human review.
- Targeted advertising consent: obtain it before loading advertising trackers, not after checkout.
- Data sharing with ad platforms: identify each recipient and whether a transfer is involved.
- Objection: honor objections to profiling for direct marketing under Article 21.
Confirm the basis and the balancing test for fraud tools with counsel before deployment, because the answer depends on the signals used.
How to handle objections to direct marketing and recommendations
Where personal data are processed for direct marketing, the data subject may object at any time, and the controller must then stop processing that data for that purpose (Article 21(2) and (3)). For an online shop, this is a system requirement, not only a policy statement. The objection must be honored in every place marketing data is used, including email and SMS campaigns, retargeting audiences, recommendation jobs that use past purchases, and exports sent to advertising platforms. Start by confirming which of these purposes actually rely on the shop's own data and which rely on consent or legitimate interest, because the objection right in Article 21 attaches to the direct marketing use, and the shop must be able to show which records feed which campaigns.
The practical control is a suppression flag on the customer record, with a timestamp and the channel the objection came through. Every marketing sender and every recommendation job should check that flag before selecting a recipient, and the check should fail closed: if the flag cannot be read, the record is excluded. Processors that send campaigns, run analytics or push audiences to ad platforms need the objection passed on as an instruction, and the shop should confirm how each of them removes or stops using the person's data and how they confirm it back. Ask each vendor, in writing, how it receives suppression changes and how long it takes to apply them. Keep the flag after an objection rather than deleting the record, so that a later CSV import, CRM sync or re-subscription from a partner list does not silently re-enroll the person. Imports should be checked against the suppression list before any record is loaded.
Test the control the way an assessor would: create a test customer, object through each channel, then confirm that no campaign, recommendation email or audience upload includes that address during the next full send cycle and after a bulk import. Record the results, the test dates and the logs that show the suppression check ran. Treat any recommendation feature as a separate purpose: a shop that wants to recommend titles from past orders needs its own lawful basis, and a customer who objects to that use must be removed from it even if they still receive order emails. Confirm with counsel or your data protection officer which basis applies to each use before the feature goes live.
What do online shops ask before hiring GDPR help?
What does GDPR help cost for an online shop?
The cost depends on the written scope, not on a standard package, so no fixed figure applies. Most of the fee pays for people's time: reviewing what the shop collects at checkout, mapping data flows across the storefront, payment provider, email tools, analytics and fulfilment partners, and fixing the systems involved. Some costs are one-time, such as the initial review and configuration changes, while others recur, such as updating consent settings when tools change or refreshing records each year. Costs rise with the number of systems, third-party tools and countries served. Ask any provider for a quote that lists deliverables, the systems in scope, who does each task, what is one-time and what recurs, and what a change to scope would cost. DeployOpen does not publish prices. A quote follows from the written scope.
How long does a GDPR readiness project take for a shop?
No duration applies to every shop, so treat any single number with caution. The timeline is set by how many systems hold customer data, how much custom code sits in checkout and marketing flows, how quickly the team can answer questions, and how many changes must be tested before release. A shop on a hosted storefront with few integrations will move faster than one with a custom platform and many marketing tools. Ask for a timeline tied to named milestones in the written scope, and check which tasks depend on your staff, such as approvals, access and decisions about retention periods.
What must our team provide before outside GDPR work starts?
Expect to supply access and decisions, not only documents. The usual inputs are:
- Read access to the storefront, order database, CRM, email platform, analytics and tag manager, and a list of payment, shipping and support providers.
- The current checkout form, privacy notice, cookie banner settings and marketing consent wording.
- Named owners for marketing, customer service, finance and IT who can confirm how data is used and kept.
- Existing contracts with processors, and the retention rules the business already follows.
The organization owns its controls and decides the lawful basis for each purpose. An implementation partner prepares systems and evidence, and only an independent party can issue an assessment result. Ask the provider to list these inputs in the quote so gaps show up early.
Can an online shop handle GDPR compliance in-house?
A small shop can often do much of the policy and records work itself, especially if the team can read its own tools and make decisions about purposes. The harder parts are technical: changing checkout fields so only needed data is requested, configuring consent for cookies and marketing, building a way to find a customer's data across systems, and keeping deletion and objection requests working through backups and logs. The European Data Protection Board's small business guide is a practical starting point for the lawful-basis questions. Decide early which tasks your staff will own over time, because the recurring work of answering requests and reviewing new tools usually outlasts the initial project.
Does an online shop need a data protection officer?
Not automatically. The GDPR requires a data protection officer in specific cases, such as where core activities involve large-scale regular and systematic monitoring of individuals or large-scale processing of special category data. A typical web shop selling goods usually does not meet those tests on its own, but the answer depends on the business model, such as profiling for advertising at scale. Ask an adviser to document the reasoning in writing. Even when no DPO is required, someone must own privacy decisions, so name a responsible person regardless.
What evidence will a regulator or customer ask a shop to produce?
Regulators and customers look for proof that a decision was made and carried out. For an online shop, that usually means a record of which data each purpose needs and why, evidence of the lawful basis for marketing and recommendations, proof of consent such as a timestamped record of a deliberate action, the cookie settings in force at a given date, and logs showing that access and objection requests were handled within the one-month deadline in Article 12(3) of the GDPR. Keep these records current, since consent should be refreshed at appropriate intervals. The organization must be able to demonstrate its compliance. Ask any provider which evidence it will prepare, where it will be stored, and who keeps it current after go-live.
How to choose a GDPR consultant for an online shop
Hiring outside help for GDPR is a scoping decision before it is a vendor decision. The four cards below cover what to pin down in writing, how the partner divides its work from the auditor's, which shop-specific experience matters, and what the organization keeps when the engagement ends. No GDPR certificate exists unless an accredited body issues one under Article 42, and that certification is voluntary.
Pin down scope and deliverables
Ask for a written scope that names the storefront, checkout, order system, marketing tools, customer service tooling and any hosting or payment providers in play. Each deliverable should be listed with an owner and an acceptance step, such as a configured consent banner tested in a live browser or a rights-request runbook walked through with your team. Vague phrases like "GDPR review" leave the shop paying for work nobody can measure. Confirm what happens if the shop adds a new checkout provider halfway through.
Separate evidence from opinions
A consultant prepares evidence; only an independent auditor or accredited certification body issues an opinion. Ask the partner to state in writing that it will not sign attestations or certify compliance on your behalf. Clarify who signs the record of processing, who approves legitimate interest assessments, and who is accountable if a supervisory authority asks questions. Your data protection officer or responsible manager should keep these decisions in-house.
Check e-commerce and marketing experience
Ask for evidence of work on order flows, tag managers, analytics and advertising pixels, recommendation engines and email platforms. A shop-focused partner should know how a checkout form can collect more than an order needs and how a consent banner interacts with tags that load before the user responds. Request a sample of how the partner has documented a cookie inventory, and ask how it tests that technically necessary cookies are the only ones set before consent.
Confirm what the shop keeps
Require a handover list before work starts: the record of processing, the cookie and consent configuration with its change log, the rights-request runbook, retention settings for orders and accounts, and the processor agreements mapped to each vendor. Ask whether configuration exports and scripts are delivered in editable form. Ask who can operate the consent tool after the engagement ends, and what support, if any, is included or sold as a separate retainer.
What a shop should ask for in a fixed-scope quote
DeployOpen works to a fixed scope that is agreed in writing before any work starts, and it does not publish a price list. The quote follows from that scope, so the most useful thing a shop can do before asking for a number is to write down what the scope must cover. A quote that names only "GDPR compliance for our web shop" gives the provider nothing to price and leaves the shop exposed to later change requests. Ask that the scope list each checkout field and the order purpose it serves, including whether date of birth, phone number and delivery address are collected for every order or only where a purpose needs them, and which fields are kept after fulfilment.
The scope should also name the systems that touch customer data outside the checkout. Ask for the marketing and recommendation components (email tools, segmentation, on-site recommenders), the cookie banner and consent tooling, the tag manager and each analytics or advertising tag it loads, and the rights request workflow that handles access, erasure and objection requests. For each, the quote should state which processors receive personal data, where the data is hosted, and which contracts or sub-processor records must be reviewed. Confirm with the provider which of these items are in scope and which are your own responsibility, because the organization keeps ownership of its controls and decisions even when a partner prepares the systems.
Finally, ask for the evidence the engagement will deliver, such as configuration records, consent logs, a data map of checkout and marketing flows, and a documented rights request procedure, and confirm that the deliverables are handed over in a form your auditor or data protection lead can review. Ongoing support, upgrades and continuous testing are available as a separate retainer, so ask the provider to price that separately from the one-time build and to state what the retainer covers after handover. Only an independent assessor or certification body can issue a certificate or report, so the quote should not promise an outcome of that kind.
What delays online shop GDPR projects and how to avoid it
Most online shop GDPR projects stall on the same few gaps: data arriving through tools nobody documented, consent that does not match what actually loads, rights requests that never reach the systems holding the data, and vendors processing customer data without a contract. Each card below names one of these blockers and the single check that prevents it.
Document every marketing import
Ad platforms, email tools and affiliate networks often receive customer emails, order values or browsing identifiers through tags or CSV uploads that no one wrote down. Each import is a processing activity with its own purpose and lawful basis, and it belongs in the record of processing. Before go-live, export a list of every script, pixel and scheduled file transfer from the shop platform and match each one to a named purpose and owner. Any flow without an owner is a flow to switch off until it is justified.
Test the consent tool against live tags
A cookie banner that blocks only the tags it was configured for leaves gaps when developers add a new marketing pixel or a tag manager container changes. Under the ePrivacy rules, storing or reading a cookie requires informing the user and obtaining consent unless the cookie is technically necessary. Test the banner in a clean browser session, reject all categories, and confirm that no non-essential requests fire. Repeat the test after each release that touches the tag manager.
Map rights requests to every system
A customer's erasure or access request is often answered from the shop database alone, while copies sit in the helpdesk, the warehouse system, the email platform and analytics. The controller must act on requests under Articles 15 to 22 without undue delay and within one month of receipt. Keep a written map of every system that holds customer records, with the owner and the deletion or export method for each, and test one request end to end before peak season.
Sign processor contracts for every vendor
Marketing automation, review widgets, analytics, customer support chat and payment-adjacent services usually process customer personal data on the shop's behalf, which makes them processors. A processor without a written contract setting out instructions, confidentiality and sub-processor rules is a gap an assessor will find quickly. Build a vendor list from the tag inventory and the accounts-payable history, check whether each provider offers a data processing agreement, and record the signed version next to the vendor entry.
Fix the order form before launch
Checkout forms often ask for date of birth, phone number or a full address on every order because one template was reused for all products. The fix is to split the form by purpose, so that a digital product order no longer asks for a delivery address. Review each mandatory field against the order it serves, and mark the rest as optional or remove it. Record the decision in the data minimization review so the reason survives future redesigns.
Separate contract and marketing consent
Teams often treat a customer's purchase as permission to send promotions, recommend products from past orders, or share purchase history with advertisers. Contract necessity covers only what the order cannot be completed without, such as payment and delivery details. Marketing, fraud prevention and targeted advertising need consent or legitimate interest, and objections to direct marketing must stop processing for that purpose. Check each campaign against the lawful basis documented for it, and build an unsubscribe path that updates every connected system.
How DeployOpen prepares checkout, consent and rights evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the shop's own infrastructure, whether that is its cloud account, a data center or a private network. For an online shop, that work usually means configuring the checkout and order data flows so that only the fields each purpose needs are stored, separating the data used to complete an order from the data used for marketing, setting up consent records that show what the customer agreed to and when, and building a request queue that tracks each access or erasure request against the one-month deadline in Article 12(3). The shop decides what each field is for, which lawful basis applies and how long each record is kept. DeployOpen implements those decisions and produces the configuration, logs and records that show them in operation.
Evidence is the part shops most often leave until the end. DeployOpen can help prepare system documentation, configuration baselines, access logs for the order and customer databases, consent log exports, request-handling records and test results from restore and erasure exercises, so that the shop's own team or an independent assessor can check them. Before work starts, the shop should confirm in writing which systems are in scope, which evidence each control will produce and who in the business signs off each decision, since a fixed scope makes that expectation clear to both sides.
DeployOpen does not issue audit reports, attestations or certificates. Only an independent auditor, assessor or certification body can give those, and GDPR itself requires no certificate, although Article 42 certification is voluntary. The shop owns its controls, its lawful bases, its cookie choices and its responses to customers, and remains responsible for compliance regardless of who built the platform. Legal interpretation of marketing and consent rules should come from the shop's data protection adviser or counsel, and DeployOpen's work is limited to preparing systems and evidence that reflect the decisions the shop has made.
