GDPR Article 28 requires a written contract when a processor processes personal data on a controller’s behalf. A mid-market eCommerce brand might process EU customer data across email platforms, analytics, session replay, CRM, payments, support chat, and a CMP — each relationship likely needs a Data Processing Agreement (DPA).
Separately, Chapter V governs international transfers. For many US-based processors, Standard Contractual Clauses (SCCs) (2021 versions) are the practical mechanism — often embedded in vendor DPAs or order forms.
This guide separates what a DPA does vs. what SCCs do, then lists ten DPA clauses eCommerce counsel actually negotiate.
DPA vs. SCC: what each does
Data Processing Agreement (DPA)
A DPA governs how a processor may process personal data on your instructions: scope, security, subprocessors, assistance with rights, deletion, audits.
Typically needs a DPA: ESP/CRM analytics, session replay, support tools, CDPs (as processors), CMPs, payment processors where they process personal data on your behalf.
Often not a “processor DPA” relationship: independent controllers like large ad platforms receiving data for their own advertising business — different compliance tools (transparency, consent/legitimate interest analysis, CPRA “sale/share” mechanics).
Standard Contractual Clauses (SCCs)
SCCs are modular contract clauses approved by the European Commission to enable transfers to countries without adequacy. For typical US SaaS, Module 2 (controller-to-processor) is common.
Schrems II reminder: SCCs are not automatic legality — you may need a Transfer Impact Assessment (TIA) considering government access risks.
EU-US Data Privacy Framework (DPF): some US entities participate — check vendor certifications at the official DPF listing [VERIFY: dataprivacyframework.gov]. DPF participation does not remove Article 28 obligations; it addresses transfer legitimacy for qualifying participants.
The ten DPA clauses that matter most
Clause 1 — Subject matter, nature, and purpose
Must say: the specific processing activities — not “vendor may process data as needed.”
Failure mode: overbroad rights for the vendor to use data for unspecified “service improvement.”
Clause 2 — Categories of data and data subjects
Must say: categories like identifiers, order history, behavioral events, device data; subjects like customers, prospects, site visitors.
Failure mode: omitting behavioral event data while the product’s core function is analytics.
Clause 3 — Duration and deletion
Must say: retention aligned to your instructions; deletion/return timelines after offboarding.
Failure mode: silent indefinite retention or vendor-determined lifecycle.
Clause 4 — Processing only on documented instructions
Must say: vendor processes only as instructed; escalates if instructions appear unlawful.
Failure mode: carve-outs for model training, “analytics,” or “product development” without boundaries.
Clause 5 — Confidentiality
Must say: personnel obligations around personal data access.
Failure mode: generic confidentiality that never mentions personal data duties.
Clause 6 — Security (Article 32)
Must say: specific controls or incorporated standards — encryption, access control, incident response.
Failure mode: “industry standard security” with no incorporated spec or SLA.
Clause 7 — Sub-processors
Must say: authorization model, notice for changes, objection rights, flow-down obligations.
Failure mode: “we may add subprocessors anytime” with minimal notice.
Clause 8 — Data subject rights assistance
Must say: assistance with access/erasure within timelines; operational capability.
Failure mode: “reasonable assistance” with no SLA — deletion requests miss 30-day windows.
Clause 9 — Deletion or return on termination
Must say: how data returns or deletes; proof options.
Failure mode: vague “legal hold” language without scope limits.
Clause 10 — Audit rights
Must say: audit mechanics that can actually validate controls in incidents.
Failure mode: annual-only audits with long notice that cannot respond to a breach.
Practical DPA audit checklist
For each vendor processing EU personal data:
- DPA accepted (sign or click-through) and archived
- 2021 SCCs (Module 2) or valid alternative transfer tool + TIA where required
- Processing described concretely
- Retention + deletion on exit
- Sub-processor rules with meaningful notice
- Data subject assistance with workable timelines
- Security measures specified
- Audit rights that can be used in practice
- Reviewed within the last 24 months or upon material vendor change
Priority vendors: ESP/SMS, analytics, session replay, ads tags (as applicable to role), CRM/CDP, payments, CMP.
Conclusion
DPAs are how Article 28 becomes operational — subprocessors, deletion, security, and rights assistance either work in contracts or they fail under pressure.
Start with the five highest-risk vendors: analytics + session replay + messaging stack + CMP + anything touching special categories.
Internal resources: GDPR compliance framework for eCommerce, third-party vendor privacy risk for eCommerce, when your store needs a DPIA.
This guide is for informational purposes and does not constitute legal advice. DPA and SCC requirements vary by jurisdiction and processing context — consult qualified legal counsel for your specific vendor contracts and data transfer arrangements.