GDPR Data Processing Agreements: An eCommerce Guide

Key Takeaways

• A Data Processing Agreement (DPA) is legally required under GDPR Article 28(3) whenever another company processes personal data on your behalf — hosting, email marketing, analytics, fulfillment, helpdesk. No DPA means both you and the vendor are non-compliant.
• Article 28(3) prescribes eight mandatory commitments the processor must make, from acting only on your documented instructions to deleting or returning data when the service ends.
• A typical online store has a dozen or more processors. The real work is not signing one DPA — it is maintaining an inventory of every vendor, their DPA, their sub-processors, and their international transfer mechanism.
• The European Commission publishes free standard contractual clauses for controller–processor relationships (Implementing Decision (EU) 2021/915) you can use as a baseline.
• Violations of Article 28 fall into the fine tier of up to €10 million or 2% of global annual turnover — and as the controller, you stay accountable for your vendors' behavior.

Introduction

Run a quick mental inventory of your store: the platform it runs on, the payment provider, the email tool, the analytics script, the fulfillment partner, the support desk, the review widget. Every one of them touches customer personal data. Under the GDPR, every one acting on your behalf needs a signed Data Processing Agreement — and you, as the data controller, carry the accountability if one is missing or hollow.

This guide explains who needs a DPA, exactly what Article 28 requires it to contain, and how to run vendor DPAs as an ongoing process rather than a one-time paperwork sprint.

This article is informational content, not legal advice. For contract-specific guidance, consult a qualified legal professional.

What Is a Data Processing Agreement — and Who Needs One?

The GDPR splits responsibility between two roles:

• The controller decides why and how personal data is processed. For your store's customer data, that is you.
• The processor processes personal data on the controller's behalf — your hosting provider, your email marketing platform, your warehouse partner's shipping software.

Article 28(3) requires the relationship to be governed by a contract that is binding, in writing (electronic is fine), and that sets out the subject matter and duration of the processing, its nature and purpose, the types of personal data, the categories of data subjects, and the obligations and rights of the controller.

Two boundary cases worth knowing:

• Joint controllers (Article 26). If you and a partner jointly decide the purposes and means — say, a co-branded campaign — you need a joint controllership arrangement, not a DPA.
• Independent controllers. Some vendors process parts of your data for their own purposes — payment providers typically act as independent controllers for fraud prevention and regulatory compliance, even where they are processors for other services. Check each vendor's data processing documentation rather than assuming one label covers everything they do.

Who's who in a typical store stack

Roles are assigned by what a vendor actually does with the data, not by what the contract calls them. Typical patterns — always verify against the specific vendor's documentation:

The misclassification that bites most often is treating everything as "processor by default." When a vendor uses your customer data for its own purposes — improving its models, fraud scoring across its network, advertising — it is acting as a controller for that use, and a DPA alone does not paper over it.

The Eight Mandatory Clauses Under Article 28(3)

Every compliant DPA must commit the processor to all of the following:

1. Documented instructions only. The processor processes personal data only on your documented instructions — including for international transfers — unless EU or member state law requires otherwise.
2. Confidentiality. Everyone authorized to process the data is bound by confidentiality, contractually or by statute.
3. Security (Article 32). The processor implements appropriate technical and organizational measures — encryption, access controls, resilience, testing — proportionate to the risk.
4. Sub-processor controls. The processor engages sub-processors only with your prior specific or general written authorization, flows the same obligations down to them, and remains fully liable to you for their performance. Under a general authorization, the processor must notify you of changes and give you the chance to object (Article 28(2)).
5. Help with data subject rights. The processor assists you, as far as possible, in responding to access, erasure, portability, and other [data subject requests](/resources/blog/data-subject-access-requests-automation).
6. Help with security, breaches, and DPIAs. The processor assists with your Article 32–36 obligations — security, breach notification, [data protection impact assessments](/resources/blog/when-is-a-dpia-required-2026-guide), and prior consultation with supervisory authorities.
7. Deletion or return at the end. When the service ends, the processor deletes or returns all personal data, at your choice, and deletes existing copies unless law requires storage.
8. Audits and information. The processor makes available all information necessary to demonstrate compliance and allows and contributes to audits, including inspections, by you or your mandated auditor.

A DPA that merely gestures at these topics is not enough. Each clause must reflect the actual processing — a generic template that never says what data is processed, for what purpose, or by whom, fails the regulation's specificity requirement. Annexes describing the processing, the security measures, and the approved sub-processors are where a DPA becomes real.

If you are drafting from scratch or evaluating a vendor's paper, the European Commission's standard contractual clauses for controllers and processors (Implementing Decision (EU) 2021/915, adopted 4 June 2021) are a free, regulator-approved baseline. Note these are distinct from the international-transfer SCCs — if your processor is outside the EU/EEA, you also need a Chapter V transfer mechanism, covered in our guide to [GDPR international data transfers](/resources/blog/gdpr-international-data-transfers-2026).

What Happens When a Processor Fails?

The DPA is also your incident plumbing. Under Article 33(2), a processor must notify the controller of a personal data breach without undue delay — your own 72-hour clock for notifying the supervisory authority starts from your awareness, so a DPA that pins down the processor's notification timeline and required detail is the difference between a controlled disclosure and a scramble.

Liability runs both ways too. Under Article 82, a data subject can claim compensation from the controller or the processor, and whichever pays can recover from the party actually responsible. Under Article 83(4), infringements of Article 28 itself — operating without a compliant DPA — sit in the fine tier of up to €10 million or 2% of worldwide annual turnover. In practice, regulators investigating any incident routinely ask for the relevant DPA first; not having one converts a vendor's mistake into your independent violation.

How to Get Your Vendor Stack Under Control

Step 1: Inventory every vendor that touches personal data

Walk through the customer journey — visit, signup, checkout, delivery, support, marketing — and list every third-party tool involved at each step. Cross-check against your tag manager, your billing, and your engineering team's integrations list. This pairs naturally with [data mapping](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities), since Article 30 requires you to record recipients of personal data anyway.

Step 2: Classify each vendor's role

Processor, joint controller, independent controller — or a mix, per service. The classification determines which contract you need.

Step 3: Collect and record the DPAs

Most established SaaS vendors offer a standard DPA, often incorporated into their terms of service or available for countersignature in the account dashboard. "We probably accepted it in the ToS" is not a record — capture which DPA version applies, where it lives, and when it was accepted, per vendor.

Step 4: Check sub-processors and transfer mechanisms

Review each vendor's published sub-processor list and subscribe to their change notifications — that is your Article 28(2) objection window. For non-EU vendors and sub-processors, verify the transfer mechanism (adequacy decision, Data Privacy Framework certification, or transfer SCCs).

Step 5: Make review a routine, not an event

Re-check DPAs at contract renewal, when a vendor announces sub-processor changes, and when you adopt any new tool. The inventory only has value while it is current.

Common DPA Mistakes

• Assuming the vendor "has it covered." Article 28(1) requires you to use only processors providing "sufficient guarantees." Vendor due diligence is your obligation; a signed DPA does not transfer your accountability away.
• Signing DPAs that describe nothing. Empty annexes — no data categories, no purposes, no security measures — are the most common defect in real-world DPAs.
• Ignoring sub-processor notifications. Those emails are a legal objection mechanism with a deadline, not newsletter noise.
• Treating the DPA as the transfer mechanism. A controller–processor DPA does not legalize a transfer to a third country by itself. Chapter V is a separate requirement.
• No central record. When a regulator or enterprise customer asks "show me your processor list and DPAs," assembling it from inbox archaeology takes weeks. A maintained register takes minutes.

How PrivacyForge Helps

Managing processors is an inventory problem that compounds with every tool you add — exactly what PrivacyForge's vendor tooling is for:

• Vendor management gives you a central register of every third party, with document storage for DPAs and structured vendor assessments, so due diligence and Article 28 evidence live in one place.
• Data mapping links each vendor to the processing activities and data categories they touch, keeping your ROPA's recipient records accurate.
• AI governance extends the same discipline to AI vendors, with risk assessments and security questionnaire support for the tools that increasingly sit in eCommerce stacks.
• Compliance scoring surfaces gaps — vendors without assessments, processing activities without documented recipients — before they surface in an audit.

For a first look at where your store stands, run the [free compliance scan](/scan) or work through our [GDPR eCommerce checklist](/resources/blog/gdpr-compliance-for-ecommerce-practical-checklist).

Conclusion

DPAs are where GDPR accountability becomes contractual reality. The law is unusually concrete here: eight mandatory commitments, specific descriptions of the processing, controlled sub-processing, and deletion at the end. The hard part for a growing store is not understanding the requirements — it is keeping a living inventory as the tool stack changes.

Start with the vendor list. Once you know who touches your customers' data, getting the right paper in place with each of them is a checklist, not a mystery.