GDPR DPA checklist: what to demand from every e-commerce module vendor

Every e-commerce module that touches customer data needs a Data Processing Agreement (DPA). Most merchants treat this as a rubber-stamp formality at signup and never look at it again. Then the auditor visits.

This is the checklist your DPO should be running through for every module on your privacy notice. It's also what we offer customers in regulated verticals when they ask for our DPA.

1. Is there an actual DPA?

Sometimes the "DPA" is a sentence in the Terms of Service. That's not a DPA. A DPA is a separate document with these required Article 28 GDPR elements:

• Subject matter and duration of processing
• Nature and purpose of processing
• Type of personal data + categories of data subjects
• Obligations + rights of the controller
• Sub-processor approval mechanism
• International transfer mechanism (SCCs if applicable)
• Data-deletion / return at end of processing

If your module vendor's "DPA" doesn't have these elements, it isn't a DPA. Don't use it as one.

2. What's the sub-processor list?

The sub-processor list is the most fact-rich page of any DPA. Read it. Specifically look for:

• Where they are. EU, US, both? US-based sub-processors add transfer mechanism complexity.
• What they process. Hosting (Mostly fine). Email delivery (Bring SES / Postmark, etc.). Analytics (this is where tracking-the-tracking gets weird). Payment processing (Stripe, Adyen, etc.)
• Notification of changes. Most DPAs let the vendor add a sub-processor with 30 days notice. Some let them do it silently. Walk away from the silent ones.

3. International transfers

If any sub-processor is outside the EEA, there must be a transfer mechanism. Post-Schrems II (2020), Standard Contractual Clauses (SCCs) + Transfer Impact Assessment are the practical mechanism. Some vendors still cite "Privacy Shield" — they're behind by 4+ years; don't trust them.

Adequacy decisions (UK, South Korea, parts of US under DPF) are valid where applicable. Verify on the European Commission's adequacy page, not the vendor's blog.

4. Data deletion

When you stop using the module, what happens to the data the vendor has accumulated? The DPA should specify:

• A delete-after-period (usually 30–180 days post-contract end).
• A mechanism for you to request deletion mid-contract (for GDPR customer-delete request propagation).
• A certificate of deletion you can keep for audit trail.

Self-hosted modules have a simplification here: there is no vendor-side data, so the DPA can be substantially shorter. NP Rewards Pro's DPA is two pages because we don't process customer data — your PrestaShop does.

5. The audit right

Article 28(3)(h) GDPR gives the controller the right to audit the processor. In practice this is rarely exercised but should exist in the DPA. Look for:

• Annual audit right OR substitute (e.g. ISO 27001 certificate).
• Reasonable notice period (30+ days).
• Audit cost allocation (usually controller pays).

Vendors who refuse audit rights or buried them behind premium tiers — walk away.

6. Breach notification

72 hours is the regulator-facing notification window (GDPR Article 33). The DPA should specify a tighter processor-to-controller window — typically 24–48 hours — so the controller has time to prepare the regulator notice.

7. The data minimisation question

Not strictly a DPA item, but worth asking: does the module process data it doesn't actually need? Common offenders:

• Age verification modules that capture and store birthdate when they only need a boolean.
• Search modules that ship full session data to the SaaS when relevance only needs queries + clicks.
• Loyalty platforms that pull entire order history when monthly aggregates would do.

Data minimisation is the cheapest GDPR risk reduction. If a vendor defends a particular data point as "necessary," ask them to point at the specific feature it enables. If they can't, push back.

The walk-away signals

1. No separate DPA document.
2. Sub-processor changes without notice.
3. "Privacy Shield" still cited.
4. No deletion certificate offered.
5. No breach notification window specified.
6. Audit rights gated behind premium plans.

Any one of these is a yellow flag. Two is a no-go.

Bottom line

DPAs are paperwork until they aren't. For €100/year in module fees, you should be getting the same DPA quality you'd demand for a €100k SaaS contract. The market has shifted to make this realistic; if a vendor can't meet it, that's information about their operational maturity.