Which Shopify apps need a DPA? Article 28, explained

Short answer: any app that handles your customers’ personal data on your behalf — email marketing, reviews, analytics, chat, fulfilment, subscriptions — is a “processor”, and UK GDPR Article 28 requires you to have a Data Processing Agreement (DPA) in place with each one. If an app loses your customers’ data and you have no DPA, the liability lands on you.

What is a DPA, and why Article 28 matters

A Data Processing Agreement is the contract that governs what a third party is allowed to do with the personal data you hand them. UK GDPR Article 28 says you may only use a processor that provides “sufficient guarantees”, and that the arrangement must be set out in a binding contract covering things like security, sub-processors, and what happens to the data when you stop using them.

In plain terms: if you’re the store, you’re the controller — you decide why and how customer data is used. The apps you plug in are processors acting on your instructions. The DPA is what makes that relationship lawful. Without it, you’re sharing customers’ personal data with a company under no agreed obligations — and you carry the consequences.

Which Shopify apps count as processors?

The test is simple: does the app touch personal data on your behalf? If yes, it’s a processor and needs a DPA. On a typical store that includes:

• Email and SMS marketing (Klaviyo, Mailchimp, Omnisend and similar) — they hold your customer list.
• Reviews and loyalty — they collect names, emails, and reviews tied to customers.
• Analytics and heatmaps — they process visitor and customer behaviour.
• Live chat and helpdesk — conversations contain personal data.
• Fulfilment, shipping and subscriptions — names, addresses, order data.
• Any app that exports or syncs your customer or order data.

Apps that never see personal data — a pure theme tweak, a currency converter with no user data — generally don’t need one. But the safe assumption for anything connected to customers or orders is: it’s a processor until proven otherwise.

Why “we used a template” isn’t the same as coverage

A GDPR template can help you start, but a template is a document, not a trail. It can’t tell you which apps are actually installed today, which of them process personal data, and whether a signed agreement is on file for each. That gap is where the real exposure sits — and it’s an operational question, not a paperwork one:

• What tools currently handle personal data?
• Which of them have a DPA in place, and where is it?
• What changed since the last time anyone checked?

Stores rarely have a cookie problem first. They have an evidence problem: the business keeps adding apps, and the record of who has a contract silently falls behind.

How to find your DPA gaps

You can’t fix what you can’t see. The practical first step is an inventory: the apps connected to your store, which of them process customer data, and which have an agreement on file. GuardianStack’s connected checks do exactly this — the DPA Agent lists third-party apps that may process customer data, checks what processor evidence is on file, and flags what still needs confirmation, drafting an Article 28-aligned agreement where one is missing for you to review.

Before any of that, the free public check gives you the outside-in picture in about 30 seconds — no login, read-only.

The bottom line

Every app that touches customer data needs a DPA under Article 28. The risk isn’t usually the app you remember — it’s the one you installed months ago and forgot. Keep an inventory, keep the agreements with it, and treat “which apps process data, and do we have a contract” as a question you can always answer.

Sources

The primary sources behind this guide — check them yourself:

• ICO — Controllers and processors (Article 28)
• ICO — Guide to UK GDPR