What happens when a European retailer asks your Shopify app for a DPA?

For many European retailers, approving a Shopify app involves more than checking its features and price. Legal, privacy, security and procurement teams may also need to understand exactly what the app processes, where data is hosted, which other providers are involved and what happens when the service ends.

That makes the provider's response part of the product. A useful app can still become difficult to approve if the team behind it cannot answer those questions clearly.

When a retailer asks for a Data Processing Agreement, or DPA, it is not looking for another generic policy. It needs documentation that reflects how the app actually works.

What is a Data Processing Agreement?

A DPA records how personal data will be handled when one organisation processes it for another. It identifies the parties' roles and covers the processing, security, subprocessors, assistance, retention, deletion and other relevant responsibilities.

The Information Commissioner's Office explains when a controller-processor contract is needed. Its guidance also sets out the information and minimum terms such a contract should contain.

A retailer may request a DPA when an app processes personal data on its behalf. The request often forms part of a wider vendor review before an app is approved, renewed or expanded.

Why this matters to European retailers

European retail businesses may operate across several countries, sell to customers in different markets and answer to established internal privacy and security standards. Their teams need to understand which requirements apply to a supplier and whether its documentation matches the service being purchased.

A request can involve questions about UK GDPR, EU GDPR, Swiss data protection requirements, international transfers or the retailer's own procurement controls. The relevant position depends on the parties, the processing and the markets involved.

This does not mean every app needs the same document. It means the provider should understand the questions, involve the right people and give the retailer facts it can assess. A clear response can reduce avoidable rounds of questions and help a review move forward.

A DPA is not another privacy policy

These documents serve different purposes:

• A DPA governs processing between a controller and a processor.
• A privacy policy or notice explains to individuals how an organisation uses their personal data.
• A cookie notice explains the cookies and similar technologies used on a website or service.
• General terms govern the wider commercial relationship, including use of the product, payment and liability.

A link to a privacy policy may be useful, but it does not give a retailer the contractual detail it may need about processing carried out on its behalf.

Start with the app, not the template

A DPA should reflect the service being supplied. That means answering practical questions before drafting:

• Who decides why and how the personal data is processed?
• What information does the app receive, create or store?
• Which customers or other users are affected?
• Where is the information hosted?
• Which subprocessors support the service?
• How long is information kept?
• What causes it to be deleted?
• Which technical and organisational security measures apply?
• Could an international transfer take place, and which safeguards would apply?

Those answers rarely sit with one team. Legal wording depends on product behaviour. Product behaviour depends on engineering decisions, infrastructure and the way Shopify data is used. Accurate documentation therefore needs input from people close to the app.

What this looked like for Wysh

A European retailer asked us for a signed DPA covering Wysh, our unified wishlists app for Shopify. We treated it as a product-documentation exercise rather than sending a generic form.

We first established the relevant controller and processor roles. We then checked the app's actual data flow.

For registered wishlists, Wysh uses Shopify Customer IDs and product IDs. For guest wishlists, product IDs are stored in the shopper's browser local storage without collecting personal details. That distinction matters because the two journeys do not involve the same information or storage.

We documented the retention and deletion periods and what happens when a wishlist, a Shopify customer account or the Wysh app is deleted. We also recorded that, at the start of the arrangement, ANS Group Limited was the sole subprocessor and that hosting was in the United Kingdom.

The agreement addressed the UK, EU and Swiss requirements relevant to that retailer's request. It also covered international transfers and safeguards, technical and organisational security measures, and named privacy and data protection contacts.

The retailer received a clear, branded and signable draft. Its legal company details and signatory information were left for its team to complete and review.

Two decades of ecommerce experience behind the response

VS Labs draws on Visualsoft's two decades of experience running a full ecommerce platform. That has meant working across storefronts, orders, customer data, integrations, hosting and the day-to-day demands of retail operations.

It has taught us that data protection documentation cannot be separated from the technology. A contract template cannot tell you what happens when a customer deletes a wishlist. It cannot confirm whether a guest journey uses an account identifier, which hosting provider is involved or how an app behaves after uninstall.

We are not a law firm. Our role is to understand the product, bring in the right technical and operational knowledge, and explain the relevant processing accurately. That gives a retailer's advisers and internal teams a better basis for their own review.

Choose a provider that can support the review

When you choose an app provider, you are also choosing the team that will answer your legal, privacy, security and procurement questions.

A prepared provider should be able to give you:

• a named route for legal and privacy enquiries;
• a description of the processing and the data involved;
• current hosting, subprocessor, retention and deletion information;
• relevant security information;
• international transfer wording where it is required; and
• a professional document that can be reviewed, amended where appropriate and signed.

This capability is not an administrative extra. It is part of being a dependable technology partner, especially for retailers with established approval processes and teams working across European markets.

Have you considered how each of your app providers handles customer data, and how quickly they could answer your legal, privacy or procurement team's questions? With VS Labs, those questions are treated as part of the service. Our apps are backed by people who understand the technology, the operational realities of retail and the documentation your teams may need.

Request documentation for a VS Labs app

If your legal, procurement or privacy team needs data protection documentation for Wysh or another VS Labs app, email legal@visualsoft.co.uk. For data protection enquiries, contact dpo@visualsoft.co.uk.

Tell us which app and Shopify store the request relates to, which organisation will review the document and which countries or legal requirements need to be considered. We will review the app's processing and confirm the appropriate next step.

This article provides general information, not legal advice. The documentation required will depend on the app, the processing, the parties' roles and the law that applies. Retailers should take their own advice where needed.