MISSINdocsLog in

Data processing agreement (merchant)

LAST UPDATED: 10 OCTOBER 2026

This agreement is between [MERCHANT LEGAL NAME] (the Controller) and MISSIN LIMITED, trading as MISSIN, registered office 20 Arthur View Terrace, Danderhall, Dalkeith, EH22 1NT (the Processor). It forms part of the MISSIN terms of service the Controller accepted when it installed a MISSIN Shopify app or created a MISSIN workspace (the Agreement).

1. Subject matter and duration

The Processor processes personal data on the Controller's behalf to provide the MISSIN services. This DPA lasts as long as the Processor processes personal data for the Controller under the Agreement, and then until that data is deleted under section 11.

2. Nature and purpose of processing

The Processor collects, stores, organises, analyses, exports and erases personal data for these purposes only:

  • Forms — collecting the Controller's surveys and post-purchase questions and storing the answers.
  • Waitlists — collecting sign-ups with double opt-in, recording consent evidence, sending confirmation and leave emails, emailing addresses the Controller names a digest of new confirmed sign-ups (when it turns that on), exporting the list to the Controller at release, and, when the Controller links a waitlist to its own email tool, transferring sign-ups to it as section 5 sets out.
  • Discount delivery — issuing the Controller's discount codes and incentives to the people who qualify, by rules the Controller sets.
  • Attribution (including Mend) — linking orders and revenue to the form response, discount code, partner link or marketing touch that produced them, including classifying free-text answers with a model provider after contact details are masked.

3. Categories of data subjects

  • The Controller's customers (buyers on the Controller's store).
  • Visitors to the Controller's website or store who interact with a MISSIN form, waitlist, pixel or link.

4. Categories of personal data

  • Email address.
  • Name, where the Controller's form asks for it.
  • Shopify customer id and order references, with order count, spend and the customer's data-sale opt-out as reported by Shopify.
  • Form answers, including free text.
  • Waitlist sign-ups and consent evidence: the decision, its time, the wording shown, the page it was given on, the browser user agent, and a keyed hash of the IP address (the IP itself is never stored).
  • Click and visit identifiers: visitor ids, click ids, landing pages, referrers and UTM parameters.

No special category data is requested. The Controller must not configure a form to collect it.

5. Documented instructions

The Processor processes personal data only on the Controller's documented instructions. The Agreement, this DPA and the Controller's configuration of the services (its forms, waitlists, incentives and connected integrations) are those instructions. If the Processor believes an instruction breaks data protection law, it will tell the Controller. If law requires processing beyond the instructions, the Processor will tell the Controller first unless the law forbids it.

Email tools you connect. When you link a waitlist to an email-service account you connect (for example Klaviyo or Mailchimp), you instruct us to transfer to that account the people on that waitlist whose sign-up is confirmed and who agreed to your marketing, and to keep what we sent there up to date as set out here. For each person we send their email address; their marketing consent and its evidence (when, how and where it was given, and which version of your consent wording they saw); their signup details (waitlist, signup status, channel, when they joined and confirmed, and the UTM source and campaign of the visit they signed up from); and any incentive code issued to them at release, with its expiry.

We send only two things without your review: adding a person who is not yet in that list and has not unsubscribed or been blocked in that account (people who qualify after you link the list, everyone who qualifies at release if you chose to send at release, and the people already on the waitlist when you ask us to add them), and writing the incentive code issued at release to a contact we added. A person who left and later signs up again with consent counts as one of those people once they are no longer in that list. Any other change to a contact already in that list (updating their details, writing a code to a contact we did not add, re-adding someone we unsubscribed from that Mailchimp audience who signs up again, or removing someone we added who withdrew their consent with us or left your waitlist) is sent only after you have reviewed and confirmed it. A removal takes the person off that Klaviyo list only (never an unsubscribe from the whole account) and clears the waitlist details we wrote, or unsubscribes them from that Mailchimp audience and brings the waitlist details we wrote there up to date. A contact who was already in that list before you linked it is never removed from it by us: when they withdraw or leave with us, we record it on our side and send nothing, and you remain responsible for honouring it in that account. Re-adding someone we unsubscribed from a Mailchimp audience sets them to pending, so Mailchimp asks them to confirm. Someone who unsubscribed in the tool themselves is never re-added by us.

We learn of some changes made in that account: in Klaviyo, an unsubscribe or suppression of the person's whole profile, which we check for every 15 minutes; in Mailchimp, an unsubscribe from that audience or a cleaned address, which Mailchimp reports to us. We record it as a withdrawal of their marketing consent with us. They stay on your waitlist and keep any incentive, and we send nothing further about them to that list. Other changes made in that account, such as removing someone from a list, are not reported to us.

That account is yours, under your agreement with its provider; you are responsible for your lawful use of the data there. An erasure you ask us to make, or that reaches us through your store, erases our copy only: nothing is deleted in that account, so erase any copy there yourself.

6. Confidentiality

Everyone the Processor authorises to process the personal data is bound by confidentiality. Staff access is limited as described in the security controls.

7. Security

The Processor applies the technical and organisational measures described in the data protection controls, including encryption in transit, encryption of stored credentials, row-level tenant isolation and scrubbing of personal data from logs.

8. Sub-processors

The Controller gives general authorisation for the sub-processors in the sub-processor list. The Processor will give at least 30 days' notice of any addition or replacement by email to Sam@missin.co.uk. The Controller may object on reasonable data protection grounds within that period; if the parties cannot resolve the objection, the Controller may end the affected service. The Processor imposes data protection terms on each sub-processor no less protective than this DPA and remains liable for them.

9. Assistance with data-subject rights

The Processor gives the Controller tools to answer requests:

  • Access — a Shopify customers/data_request produces a downloadable export of the person's data, kept for 30 days in Settings → Privacy. See the customer data request runbook.
  • Erasure — a Shopify customers/redact and the Controller's own erase action on a waitlist erase the person's sign-ups, form answers and identifiers. Consent evidence is anonymised and the bare decision kept as proof.
  • Objection to marketing — every waitlist email to a sign-up carries a one-click leave link (RFC 8058), and the exported list carries each person's status so the Controller can honour it.

For any request the tools do not cover, the Processor will help within 10 business days of the Controller's written request.

10. Personal data breaches

The Processor will notify the Controller without undue delay after becoming aware of a personal data breach affecting the Controller's data, with what it knows then and more as it learns it, so the Controller can meet its own obligation to notify the supervisory authority within 72 hours. The process is the security incident response runbook.

11. Deletion or return at the end

  • Shopify store uninstalled — Shopify sends shop/redact 48 hours after the last MISSIN app leaves the store; the Processor erases that store's personal data.
  • Workspace deleted — deleting a workspace in MISSIN cancels its Stripe subscription and ends its Metronome contract, and marks the workspace deleted. Its data is kept so it can be restored. A connected store that still has a MISSIN app installed is not stopped: its connection is moved, with its orders and events, into an ownerless holding workspace where processing continues, and it can be re-claimed. Processing for that store ends when the apps are uninstalled and shop/redact arrives. On the Controller's written request the Processor deletes it within 30 days. There is no automated purge of a deleted workspace today; deletion on request is a manual operation until one is built.
  • Return — before deletion the Controller can export its waitlists as CSV and download any data request export.

Retention windows that apply during the Agreement are listed in the protected customer data inventory.

12. Audits

The Processor will make available the information needed to demonstrate compliance with Article 28, and will allow audits by the Controller or an auditor it appoints, on 30 days' written notice, no more than once a year unless a breach or a supervisory authority requires it, at the Controller's cost. The Processor may first answer by written questionnaire and by sharing this DPA's linked documents.

13. International transfers

The Processor's primary database runs in the EU (Railway, europe-west4). Some sub-processors process data in the United States or elsewhere; each transfer relies on the UK International Data Transfer Agreement or Addendum, the EU Standard Contractual Clauses, or the UK Extension to the EU–US Data Privacy Framework where the provider is certified. The mechanism for each provider is available on request.

14. Liability and precedence

Liability is as set out in the Agreement. If this DPA and the Agreement conflict on data protection, this DPA wins.

Signed for the Controller: [NAME, TITLE, DATE] Signed for the Processor: Sam, on behalf of MISSIN