Nesvo Data Processing Agreement

Last updated: September 5, 2026

This agreement governs how Nesvo handles the personal data of your customers. It applies whenever you use Nesvo, and it forms part of the Terms of Service.

It is written to be read by the person who runs the store, not only by a lawyer. Where the law requires particular wording, we use it — and then say what it means.

The two parties

You — the business that installs Nesvo into its Shopify store. In this agreement you are the controller. Your customers' personal data is yours; you decide why it is collected and what it is used for.

Us — NESVO LLC, a New Jersey limited liability company at 83 Crease Road, Budd Lake, New Jersey 07828, United States. In this agreement we are the processor. We handle your customers' data on your instructions, to run the service you installed.

Contact for anything in this agreement: support@nesvo.co.

Your customers' data is yours. We do not own it, we do not sell it, and we do not use it for our own purposes. Everything below exists to make that concrete.

1. What we process, and why

The subject matter

We process personal data about your customers so that Nesvo can do the two things you installed it for: show you analytics about your store, and — on paid plans — decide who should receive which marketing email and send it on your behalf.

How long

For as long as you have Nesvo installed, and then through the deletion process in section 8.

Categories of data subject

Your customers and the visitors to your storefront. We have no relationship with any of them.

Categories of personal data

We do not process shopper phone numbers. We do not receive or store payment card details. We do not process special categories of personal data — health, biometrics, race, religion, political opinion, sexual orientation — or criminal-offence data, and Nesvo has no field for any of it.

Nature and purpose of the processing

Collection, storage, organisation, computation, transmission of marketing email, and erasure. Specifically: syncing your store data, computing your analytics, scoring and segmenting your customers, deciding campaign eligibility, rendering and sending email, measuring whether a campaign led to a purchase, protecting the deliverability of our shared sending infrastructure, and deleting data when you or a customer asks.

2. We act only on your instructions

We process your customers' personal data only on your documented instructions, including for any transfer to another country. Your instructions are: this agreement, the Terms of Service, the Privacy Policy, and the configuration you set inside the app.

Using Nesvo as it is designed is an instruction. Turning on a campaign instructs us to send it. Building a segment instructs us to compute it. Setting a frequency cap instructs us to enforce it.

⚠️ If we ever believe an instruction from you breaks data protection law, we will tell you, and we will not carry it out until it is resolved. That is a legal obligation on us and not one we would want to be without.

We will not process your customers' data for our own purposes. We do not build a cross-merchant marketing database, we do not sell or share personal information, and we do not use it to train any machine-learning model — ours or anyone else's.

One thing we do that you should understand, because it is the only aggregate use. We compute performance benchmarks — the median result for a campaign type within an industry category — so you can see whether your own campaign is performing normally. That computation runs on aggregates only, never surfaces another merchant's data to you or yours to them, and only activates for a category once enough stores sit in it that no individual store can be inferred. No personal data leaves your account through it.

3. Confidentiality

Everyone we authorise to process your customers' data is bound by confidentiality obligations. Access is limited to the people who need it to run the service and support you.

We keep the number of those people small on purpose, and we design the need away where we can.

• Our internal console holds no permission to read the customer table at all. It can read only a masked view of it. That is enforced by database grants, not by application code.
• Searching your customers to find one record is scoped to your store, returns masked results, and is logged. Revealing a record requires a separate permission, a recorded reason, and writes its own audit entry.
• The identity in that log comes from the authenticated session, not from anything the calling software supplies, so an operator cannot write someone else's name into their own audit entry.
• The console cannot write to a single table holding your data. Where an operator needs something done to your account, the console records an instruction and the app carries it out.

Section 11 of our Privacy Policy describes this in full.

4. Security

We implement appropriate technical and organisational measures to protect your customers' data. The full list is in Annex II, and it describes what is built rather than what is planned.

The headline measures: encryption at rest and in transit; database-level role separation with a second independent access-control layer; anonymous and public database access explicitly revoked, including for objects created in future; default masking of customer identity in internal tooling; audit logging of every action that changes something; separation of development and production data; and retention limits that delete data we no longer need.

5. Sub-processors

You give us general authorisation to engage sub-processors. Our current list is below, and it is the same list published in our Privacy Policy.

Shopify is not a sub-processor. It is the platform you sell on and the source of the data, and your relationship with Shopify is your own.

Each sub-processor is bound by data protection obligations equivalent to those in this agreement. Where a sub-processor fails to meet them, we remain fully liable to you for their performance.

⚠️ We will give you 30 days' notice before we add or replace a sub-processor, by email or in the app. If you object on reasonable data protection grounds and we cannot resolve it, you may terminate by uninstalling, and section 7 of the Terms governs any refund.

6. Helping you answer your customers

Your customers have rights — to access their data, correct it, have it deleted, restrict its processing, take it elsewhere, and object to it being used for marketing. Those requests come to you, because you are the controller. We help you answer them.

Most of it is automatic, because Shopify routes it. When one of your customers asks you to see or delete their data, Shopify sends the request to every app installed on your store, including us:

• A request to see their data produces a structured export containing their identity and consent fields, their orders, their campaign history, their coupons, and their browse and abandonment history. It is returned to you, as the controller, to give to the person who asked — that is how Shopify's process works.
• A request to delete permanently nulls their name, email address, street address, city, province and postal code, severs the link to their Shopify customer record, and strips the identifiers from their browse and abandonment history.

Correction happens by itself — you fix it in Shopify and it reaches us on the next sync, which runs hourly.

Objection to marketing is the unsubscribe link in every email, which takes effect immediately and permanently.

⚠️ If a request reaches us directly from one of your customers, we will not act on it. We have no way to verify who they are, and acting on their data without your instruction is exactly what a processor must not do. We route it to you.

If you need something the automatic paths do not cover, ask us at support@nesvo.co and we will help.

7. Breach notification, impact assessments, and prior consultation

⚠️ If we become aware of a personal data breach affecting your customers' data, we will notify you without undue delay — and in any event in time for you to meet your own 72-hour obligation to your supervisory authority.

That notification will describe what happened, which categories of data and roughly how many people are affected, what the likely consequences are, and what we are doing about it. If we do not have all of it at first, we will tell you what we know and follow up rather than waiting until the picture is complete.

We will also help you, on request and taking into account what we know and what we have access to, with:

• Data protection impact assessments under Article 35, where your use of Nesvo requires one;
• Prior consultation with your supervisory authority under Article 36;
• Your own security obligations under Article 32.

8. Deletion and return

When you uninstall Nesvo, your customers' personal data is deleted.

The timing is Shopify's, and we would rather be accurate than promise a schedule we do not control. Shopify notifies us of an uninstall 48 hours after it happens — a window that exists so an accidental uninstall can be undone. From that notification we have 30 days to complete the purge, and we do not wait for the deadline.

You have 30 days from uninstalling to export anything you want to keep, from the analytics surfaces you already use.

What deletion actually does. Personal data is hard-deleted: name, email address, street address, city, province and postal code are permanently nulled, and the link to the Shopify customer record is severed so no later sync can refill it. The same treatment reaches the browse and abandonment history.

Three things survive deletion, deliberately:

• De-identified analytics — order values, dates, country — so your dashboards do not develop holes. These cannot be traced to a person.
• A one-way hash of any suppressed email address, so that "never email this person" survives the deletion of the person's record. This protects the individual as much as it protects us: without it, a deleted unsubscribe could be re-collected and mailed again.
• A suppression entry for the deleted person themselves, added at the moment of deletion and stored as the same one-way hash, for the same reason.

⚠️ We cannot delete on request faster than Shopify tells us to, because the request is how we learn of it. Once it arrives, nothing waits.

9. Audits and information

We will make available to you the information you need to demonstrate that we meet the obligations in this agreement, and allow for and contribute to audits, including inspections, conducted by you or an auditor you appoint.

In practice, and because we would rather set an honest expectation than a theoretical one: for most merchants this is answered by the detail already published in our Privacy Policy and in Annex II, and by writing to support@nesvo.co with a specific question, which we will answer.

Where you genuinely need more — because your own regulator or your own customer requires it — tell us what you need and we will work out how to give it to you. We ask for reasonable notice, that an audit happens no more than once a year unless a regulator or a breach requires otherwise, and that it does not disrupt other merchants or expose their data.

10. International transfers

All Nesvo data is stored and processed in the United States.

If you are established in the EEA, the UK or Switzerland, using Nesvo transfers your customers' personal data to the United States. That transfer is covered by:

• Annex III — the European Commission's Standard Contractual Clauses, Module Two (controller to processor), which are incorporated into this agreement and take precedence over it in the event of a conflict;
• Annex IV — the UK International Data Transfer Addendum, where UK GDPR applies.

Annex I completes the Clauses' description of the parties and the processing. Annex II completes their description of our security measures.

We do not rely on the EU–US Data Privacy Framework. We rely on the Standard Contractual Clauses, which do not depend on a certification that could lapse.

11. Your responsibilities

Some of this is only ours to do if you have done your part first. Three things sit with you.

Consent, and the lawful basis for it. You are responsible for having a lawful basis for the marketing you send. Nesvo enforces a double opt-in — a person lands in a pending state and becomes emailable only when they confirm or purchase — and refuses to send to anyone who has not. We build the mechanism; the basis is yours.

Telling your shoppers what runs on your storefront. Our Web Pixel and our signup forms run on your store, collect data about your visitors, and feed your customer relationship. You are the controller for that collection, so the disclosure has to appear in your own store privacy policy. We give you the text to paste in Settings → Data & privacy. Use it, or write your own equivalent.

The people you give access to. ⚠️ You are responsible for the users you provision on your Nesvo account — for the role you assign each of them, for what they do with it, and for the customer data that role lets them see. Some roles can view your customers' personal information. That is your decision about your own customers, and its consequences are yours. We enforce the role you set; we do not second-guess who you trust.

12. Term, and how this fits together

This agreement applies for as long as we process your customers' personal data, and its obligations survive termination for as long as we hold any of it.

Where this agreement conflicts with the Terms of Service about personal data, this agreement wins. Where the Standard Contractual Clauses in Annex III conflict with either, the Clauses win.

If any part of this is unenforceable, the rest stands.

ANNEX I — The parties and the processing

Completing Annexes I.A, I.B and I.C of the Standard Contractual Clauses.

A. The parties

Data exporter — the controller. The merchant: the business that installs Nesvo into its Shopify store. Name, address and contact details are those held on the merchant's Shopify account and Nesvo account. Activities relevant to the transfer: operating an online store and marketing to its customers. Role: controller.

Data importer — the processor.

NESVO LLC
83 Crease Road, Budd Lake, New Jersey 07828, United States
support@nesvo.co

Activities relevant to the transfer: providing analytics and email marketing software to Shopify merchants. Role: processor.

B. Description of the transfer

Categories of data subjects: the merchant's customers, and visitors to the merchant's storefront.

Categories of personal data: as set out in section 1 of this agreement — identity and contact data, marketing consent status, order and transaction history, storefront browse behaviour, signup form activity, email link clicks, and values derived from these.

Special categories of data: none. Nesvo has no field for special-category or criminal-offence data and does not process any.

Frequency of the transfer: continuous, for as long as the merchant has Nesvo installed.

Nature of the processing: collection, storage, organisation, computation, transmission of marketing email, and erasure.

Purpose of the processing: providing store analytics to the merchant, and — on paid plans — determining marketing campaign eligibility and sending marketing email on the merchant's behalf.

Retention period: for the duration of the merchant's installation, then deleted per section 8. Raw storefront behaviour is retained for 90 days regardless. Suppression records are retained indefinitely as one-way hashes.

Transfers to sub-processors: as listed in section 5, for the purposes and durations stated there.

C. Competent supervisory authority

The supervisory authority of the EEA member state in which the data exporter is established, or — where the exporter is not established in the EEA but falls within the GDPR's territorial scope — the supervisory authority of the member state in which its EU representative is or will be established.

ANNEX II — Technical and organisational measures

Completing Annex II of the Standard Contractual Clauses. This describes what is built, not what is planned.

Encryption

• At rest: AES-256 platform encryption on the database, always on. Backups are encrypted.
• In transit: TLS on every connection — browser to application, application to database, and to every sub-processor.

Access control

• Database-level role separation. The application, the internal console, and the partition-maintenance process each hold their own tightly-scoped database role. ⚠️ The console holds no read permission on the raw customer table at all — only on a masked view of it, owned by a separate minimal-privilege role that cannot log in.
• A second, independent access-control layer sits on top of the role separation, so a single misconfiguration does not expose data.
• ⚠️ Anonymous and public database access is explicitly revoked, including for objects created in future, so a new table cannot be exposed by default. Exactly six database roles hold any permission at all, and none of them is anonymous.
• The console cannot write to any table holding merchant or customer data. Where an operator acts on an account, the console records an instruction and the application executes it.
• The internal console is behind its own login with mandatory two-factor authentication, on a separate domain, not reachable from anything a merchant can see, with no shared session or cookie with the app.
• Merchant authentication is delegated to Shopify. We never issue or hold a merchant password.

Minimisation and masking

• Customer names, email addresses and addresses are masked by default in internal tooling, enforced in the database rather than in the interface.
• Searching for a customer and revealing one are separate, separately-logged actions. A search is scoped to a single merchant and returns masked results. Revealing a record requires a distinct permission, a recorded reason, and writes its own audit entry.
• ⚠️ The actor recorded in an audit entry is read from the authenticated session, never supplied by the caller, so an entry cannot be attributed to the wrong person.
• We collect no shopper phone numbers and no payment data, because the product does not need them.
• Our storefront tracking subscribes only to the events the product uses. Checkout contact details, address entry, payment information and site searches are all available and deliberately not collected.
• Diagnostic logs of third-party calls are built so they cannot hold personal data — status codes, counts and timings only — and are deleted after 14 days.

Logging and accountability

• Every action that changes something writes to an append-only audit log — configuration changes, account suspensions, offboarding, deletions, and every unmask. The console can add to that log and can never edit or delete it.
• Merchant exports of customer and account data are logged with who, when, from where, how many rows, and their role at the time.
• Error monitoring alerts us to failures before merchants encounter them.

Data segregation

• Every record is scoped to its merchant, enforced at the database layer rather than by application logic alone.
• Development and test data is kept separate from production data.

Retention and deletion

• Raw storefront behaviour is deleted after 90 days by dropping daily partitions. Aggregates derived from it survive; the raw rows do not.
• Original support emails are deleted after 90 days. The ticket record survives.
• Completed background jobs are purged after 48 hours; failed ones after 30 days.
• Deletion severs the join key, so a later sync cannot resurrect a redacted record, and sync paths refuse to write to one.

Sending controls

• A merchant cannot upload a list for us to email. No import path exists.
• Every marketing email carries an unsubscribe link, an unsubscribe header and a postal address, injected outside the editable area so it cannot be removed.
• Consent requires confirmation before anyone enters a marketing audience.
• Bounces and complaints suppress addresses automatically, and suppression is not merchant-overridable.
• Each merchant sends as an isolated tenant, so one merchant's reputation does not sink another's.

Resilience

• Managed database hosting with automated encrypted backups.
• Application hosting with health monitoring.
• A public status page hosted away from our own infrastructure, so it survives our outages.

Sub-processor governance

• Each sub-processor is bound by obligations equivalent to those in this agreement.
• The list is published in our Privacy Policy, and changes are notified 30 days in advance.

ANNEX III — Standard Contractual Clauses

The European Commission's Standard Contractual Clauses for the transfer of personal data to third countries, adopted by Implementing Decision (EU) 2021/914 of 4 June 2021, are incorporated into this agreement in full and form part of it.

The following applies:

• Module Two — controller to processor. The merchant is the data exporter and controller; NESVO LLC is the data importer and processor.
• Clause 7 (docking clause): included.
• Clause 9 (sub-processors): Option 2, general written authorisation. The list of sub-processors is in section 5 of this agreement, and we give 30 days' notice of any addition or replacement.
• Clause 11 (redress): the optional independent dispute resolution paragraph is not included.
• Clause 17 (governing law): the law of Ireland.
• Clause 18(b) (forum): the courts of Ireland.
• Annex I to the Clauses is Annex I of this agreement.
• Annex II to the Clauses is Annex II of this agreement.
• Annex III to the Clauses — the sub-processor list — is section 5 of this agreement.

Clause 14 — Transfer Impact Assessment

Clause 14 requires a written assessment of whether the laws and practices of the destination country prevent us from meeting our obligations under these Clauses. This is that assessment.

We confirm we have no reason to believe those laws prevent us from complying, and the assessment rests on what we actually are and actually hold.

What we are. A small software company providing analytics and marketing tooling to independent online retailers. We are not an electronic communications service provider within the meaning of the US surveillance authorities most often raised in this context, and we do not provide services to any government body.

What we hold. Names, email addresses, postal addresses, purchase history and browsing behaviour of retail shoppers. We hold no special-category data, no criminal-offence data, no financial account data, no health data, no government data and no communications content. This is commercial e-commerce data of no intelligence interest.

What has happened. ⚠️ We have never received a request from any government authority for personal data — not a subpoena, not a national security letter, not an informal request.

What reduces the exposure regardless. Encryption at rest and in transit. Default masking of customer identity in internal tooling, enforced at the database layer. Data minimisation — we collect no phone numbers, no payment data, and only the storefront events the product uses. And short retention on behavioural data, ninety days, after which the raw rows no longer exist to be produced.

⚠️ If we receive a legally binding request from a public authority for your customers' personal data, we will notify you promptly unless we are legally prohibited from doing so — and where we are prohibited, we will use reasonable efforts to obtain a waiver of that prohibition and will challenge it where there are grounds. We will challenge any request we consider unlawful, and we will provide only the minimum the request actually compels.

We will re-assess this whenever circumstances change, and keep a record of each assessment.

ANNEX IV — UK International Data Transfer Addendum

Where UK GDPR applies to the transfer, the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, issued by the Information Commissioner under section 119A of the Data Protection Act 2018 (version B1.0, in force 21 March 2022), is incorporated into this agreement and applies to that transfer.

Table 1 — Parties. As set out in Annex I.A of this agreement. Start date: the date the merchant installs Nesvo.

Table 2 — Selected SCCs, Modules and Selected Clauses. The Approved EU SCCs as incorporated at Annex III of this agreement, with the module and options selected there.

Table 3 — Appendix Information.

• Annex 1A, list of parties: Annex I.A of this agreement.
• Annex 1B, description of transfer: Annex I.B of this agreement.
• Annex II, technical and organisational measures: Annex II of this agreement.
• Annex III, list of sub-processors: section 5 of this agreement.

Table 4 — Ending the Addendum when the Approved Addendum changes. Neither party may end this Addendum under Section 19 of the Addendum.

Contact

NESVO LLC
83 Crease Road
Budd Lake, New Jersey 07828
United States

support@nesvo.co