Data Processing Agreement

Effective 17 September 2026 · updated 27 September 2026 (web analytics daily totals, kept past 90 days)

This Data Processing Agreement (“DPA”) forms part of the Terms of Service between Nordva (ENK, org.nr 938 478 473) (“Nordva”, “we”) and the Customer. It applies whenever we process personal data on the Customer’s behalf through Nordva Launch (the “Service”) and that processing is subject to the GDPR, the UK GDPR or equivalent law. It applies automatically: no signature is needed. If you need a countersigned copy, email hello@nordva.dev.

1. Roles

For Customer Data, the Customer is the controller (or a processor acting for its own customer) and Nordva is the processor. For account, billing and usage data about the Customer itself, Nordva is a controller, and the Privacy Policy applies instead of this DPA. Terms not defined here have the meaning given in the Terms of Service or the GDPR.

2. What we process, and why

We process personal data only to provide the Service to the Customer, for as long as the Customer has an account. The categories of data, data subjects and processing are set out in Annex 1.

3. Our obligations

Instructions. We process personal data only on the Customer’s documented instructions. Using the Service, its API, its dashboard and its MCP server, within the Terms of Service, are those instructions. We will tell the Customer if we believe an instruction infringes data-protection law.
Confidentiality. Anyone we authorise to access personal data is bound by confidentiality.
Security. We maintain the measures in Annex 2 and will not materially reduce them.
Data subject requests. The Service lets the Customer find, export, correct and delete its End Users’ data itself. If a data subject contacts us directly about Customer Data, we pass the request to the Customer and do not answer it ourselves. We give reasonable further help where the Customer cannot act through the Service.
Assistance. Taking into account the nature of the processing and the information available to us, we help the Customer with security, breach notification, data protection impact assessments and prior consultation (GDPR Articles 32–36).
Personal data breaches. We notify the Customer without undue delay, and no later than 72 hours after becoming aware of a breach affecting Customer Data. The notice says what happened, which data is affected as far as known, and what we are doing about it. We send it to the account’s email address.
Deletion and return. The Customer can export and delete Customer Data at any time. When an account is closed we delete Customer Data within 30 days, except where law requires us to keep it. Disconnecting a Stripe account or a Lemon Squeezy store deletes the stored key and all data read from it immediately.
Records and audits. On request we provide the information needed to show compliance with this DPA. Where that is not enough, the Customer may audit the processing once in any 12 months, with 30 days’ written notice, during business hours, under confidentiality, at its own cost and without access to other customers’ data.

4. Sub-processors

The Customer gives general authorisation for us to use sub-processors. The current list is in section 3 of the Privacy Policy. We bind each sub-processor to data-protection obligations equivalent to this DPA and remain responsible for what they do.

We give at least 14 days’ notice, by email or in-product, before adding or replacing a sub-processor. The Customer may object on reasonable data-protection grounds within that period. If we cannot resolve the objection, the Customer may close its account and receives a pro-rata refund of any prepaid fees for the period after closure.

A Stripe account or Lemon Squeezy store that the Customer connects is not our sub-processor. It is the Customer’s own account and the source of that data; we only read from it.

5. International transfers

Nordva is established in Norway, within the European Economic Area. Where we transfer personal data to a sub-processor outside the EEA, we do so under a safeguard recognised by GDPR Chapter V: an adequacy decision, or the European Commission’s Standard Contractual Clauses with supplementary measures where needed. Customer Data is stored on Cloudflare’s network, which operates globally.

6. The Customer’s obligations

The Customer has a lawful basis for the personal data it sends to the Service, and has given its End Users the information the law requires, including that Nordva processes their data as a processor.
When importing an existing list, the Customer confirms those people agreed to be contacted about the product.
When connecting a Stripe account, the Customer confirms it is entitled to give us read access to it, and gives us a restricted key with read permissions only.
When connecting a Lemon Squeezy store, the Customer confirms it is entitled to give us access to it. A Lemon Squeezy API key cannot be limited to reading, so the Customer understands that the key itself can do more than read; we use it only to read.
Where the Customer installs the analytics script, it chooses the tracking mode, obtains any consent the law requires for the cookies that mode sets (for example by calling nordva('consent', …) from its consent banner), and describes them in its own cookie policy.
The Customer does not send special categories of personal data, payment-card data or government identifiers to the Service.

7. Liability, term and law

Each party’s liability under this DPA is subject to the limitations in the Terms of Service. This DPA lasts as long as we process Customer Data and ends when that data has been deleted. It is governed by the laws of Norway, and the courts named in the Terms of Service have jurisdiction. If this DPA and the Terms of Service conflict on the processing of personal data, this DPA prevails.

Annex 1: Details of the processing

Data subjects: the Customer’s End Users, prospective users and customers, and visitors to the Customer’s websites where the Customer installs the analytics script. Duration: the life of the Customer’s account. Nature and purpose: storing, retrieving, classifying, matching and transmitting the data below to provide the Service.

Part of the Service	Personal data	What we do with it
Waitlist	Email address, IP address and user agent, referral relationships, and where the signup came from: referring site’s hostname, UTM parameters, landing page path. The analytics visitor id, when the Customer’s analytics script may keep one. Any metadata the Customer attaches.	Store, rank, detect abusive referrals, send the receipt and invite emails, export to the Customer.
Changelog	Subscribers’ email addresses and the labels each chose to follow. For reactions: the entry, the reaction, when, and the Customer’s own user identifier or a random identifier the changelog widget makes in the End User’s browser. For entries shown to a signed-in End User (a user identifier the Customer’s server signs): the entry, the user identifier and when it was first shown. For segment entries, the End User’s contact details and consents are read (not copied) to decide what they see. No email address, IP address or user agent is stored with reactions or read records. Entry images are links to the Customer’s own host; we never store, copy or proxy them.	Send a subscription made in a browser one email to confirm it (unconfirmed ones are deleted after 7 days), then send notification emails for new public entries to confirmed subscribers whose labels match, with one-click unsubscribe. Count reactions, views, readers and button clicks per entry, keep read state across devices, show an announcement once per End User, and, on Builder, compare readers with non-readers for the Customer (joined to connected Stripe data by user identifier or email). Anonymous reading only moves counters. Reactions and read records are kept with the entry and deleted with the project; label choices are deleted when the subscriber unsubscribes.
Feedback	Free text written by End Users, the Customer’s own user identifier, page URL, an email address if the End User gives one, the type of feedback and a rating from 1 to 5 if the End User picks them, and from the feedback widget or the hosted feedback form the browser name with its major version and the device type (desktop, mobile or tablet), worked out in the End User’s browser. The full user agent is never stored. The text of each reply the Customer sends from the inbox, and when.	Store, classify (with an AI model on paid plans, after best-effort removal of emails, phone and card numbers; by keywords otherwise) and forward to destinations the Customer configures. The optional email address is never forwarded.
Feedback board	Each idea’s title, text, status and vote count; for an idea an End User suggested, the email they chose to leave. For each vote, a random identifier the board page or widget makes in the End User’s browser, or a one-way hash of the Customer’s user identifier when the Customer’s site signs it. No IP address or user agent is stored.	Show the Customer’s public board, let End Users vote and suggest ideas, and hold suggestions until the Customer approves them. The email is shown only to the Customer. Kept until the Customer deletes the idea or the project; switching the board off hides it.
Notifications	The Customer’s own user identifier, notification title, body, optional link, buttons, category, a data object the Customer chooses, and when it is to show. For a notification to a group, the user identifier of each End User in it. For a notification to a group or to all End Users, per End User: when they read, clicked or archived it. For a notification that takes reactions, per End User who reacted: their user identifier, which reaction and when (on a notification a changelog entry posted, kept with that entry's reactions). For each user identifier the Customer’s application asks about, when it first and last asked (updated at most once an hour). No email address, IP address or user agent; an email address the Customer gives to reach an End User is used only to find their user identifier among the Customer’s own data and is not stored with the notification.	Store and serve to the Customer’s application, and count how many End Users read, clicked and reacted to each notification. Notifications and their read, click, archive and reaction records are deleted 90 days after they showed; a user identifier not asked about for 90 days is deleted.
Revenue (connected Stripe account)	The Customer’s customers’ email, name, Stripe identifiers and, if configured, the Customer’s own user identifier from Stripe metadata; subscription status, plan and amount; paid invoice amounts and dates. Never card or bank details.	Read from Stripe about hourly, store, and report revenue figures to the Customer. We never write to the Stripe account. Invoices older than 24 months are not read.
Revenue (connected Lemon Squeezy store)	The Customer’s customers’ email, name, country and Lemon Squeezy identifiers; subscription status, product, price and dates; order and subscription invoice amounts before tax, currency, dates and refunds; if the Customer sets up the webhook, the End User’s visitor id carried through checkout. Never card or bank details.	Read from the one store the Customer picks about hourly, store, and report revenue figures to the Customer; link a purchase to the visit it came from. We never write to the Lemon Squeezy account. Payments older than 24 months are not kept.
Web analytics (only where the Customer installs the script)	Per page view, goal and engaged-time ping: page path without query string, referring site’s hostname, UTM values, `ref`, window width, goal names and properties the Customer sends; country, region, city and coordinates rounded to about 11 km, and browser, system and device type, derived by us. Where the Customer’s tracking mode and the visitor’s choice allow it: a random visitor id and session id from first-party cookies on the Customer’s site, page number in the session, and whether the visitor is new. The IP address and user agent are seen in transit and not stored. When the Customer passes the script through its own server (a proxy), that server forwards the visitor’s IP address and location with each request; they are used in the same way, and the IP address is not stored. Where ids are allowed and the device is a computer (not a phone): a keyed HMAC of the site id, the IP address, the full user agent and the Accept-Language header, made on the first page of a visit and kept with the visitor id for up to 30 days after it was last seen, so that a browser which cleared its cookies gets its visitor id back. The address cannot be read back from it; a code seen with two visitor ids that both kept their cookies is never used to match again.	Count visits, visitors, sources, pages and places for the Customer, and show them live. Where a visitor id is linked to a person the Customer already knows (a waitlist signup, an identify call, the Customer’s Stripe or Lemon Squeezy checkout), show that person’s visits on their contact page (Builder). For a visitor who may carry an id, the analytics script adds it to links to the Customer’s Lemon Squeezy checkout so a purchase can be traced to its visit. Events are kept 90 days and cannot be deleted one by one before that (they are stored for counting, hold no name or email, and a visitor ends their id by clearing the site’s cookies). After a project is deleted its events can no longer be read and expire within 90 days. Each finished day is also summed into counts per day, page, source, place, device and goal (no visitor id, session or other data about an End User), kept up to five years and deleted with the project.
Analytics identities (only where the Customer calls identify)	The analytics visitor id, the Customer’s own user identifier and, where the Customer sends one, the user’s email address, stored as sent and as a SHA-256 hash of its normalised form, the visitor’s first touch: referring site’s hostname, UTM values, landing page path, and, where the Customer names one, a short label for where the user came in (such as “ios-app”).	Link a visitor to a user so a payment can be traced to the first visit, and list that person as a contact of the Customer. Browser calls from a script are only accepted where the visit may carry ids. A form the End User submits is accepted either way; without ids it keeps the email and what the form sent, with no visitor id, so the visit is not linked. Browser calls are capped per project per day. Kept while the project exists; deleted with it.
Contact details and consents (only where the Customer sends them)	Named values the Customer records about a person who has an email address (for example answers to a form’s questions), and the permissions the Customer records that the person gave (for example to receive marketing email), each with whether it was granted or withdrawn, when, and whether it came from the page, the Customer’s server or the dashboard.	Show them on the person’s contact, filter and export the Customer’s contacts by them. The Customer decides what to record and is responsible for a consent reflecting what the person agreed to. Deleted when the person’s last record in the project is deleted, and with the project.
Page views per source (optional, off by default)	None stored. A request per landing carries the referring site’s hostname and UTM values; the visitor’s IP address and user agent are seen in transit, as for any web request, used to limit abuse and leave out bots, and not stored with the count.	Add one to a daily total per project and source. There is no record per visitor, so there is nothing to export, correct or delete for a data subject. Totals are deleted after two years, or with the project.
Webhooks	What the Customer chooses to be told about: a signup’s email and source, a subscriber’s email and chosen labels, feedback text with its classification (never the submitter’s email), a published changelog entry.	Send to the URLs the Customer configures, signed, over TLS. The Customer decides the destination and is responsible for it. Delivery records are kept for 30 days.
Contacts and attribution	No additional data: the items above, matched on email address. Plus a stage and a free-text note written by the Customer.	Show one record per person, and count which signup sources led to paying customers.

Annex 2: Security measures

Encryption in transit (TLS) on every endpoint, and encryption at rest as provided by Cloudflare’s storage.
API keys are stored only as salted, peppered bcrypt hashes and are shown once. Browser-safe publishable keys can write to a small set of public endpoints and cannot read Customer Data.
Credentials the Customer entrusts to us (feedback routing destinations, a connected Stripe restricted key, and a connected Lemon Squeezy API key and webhook signing secret) are encrypted with AES-256-GCM using keys held as platform secrets, separate for each purpose. They are never returned by the API, never shown again in the dashboard and never written to logs.
Webhook destinations must be public https URLs; addresses that point inside a network are refused and redirects are not followed. Webhook URLs and signing secrets are stored encrypted, and each delivery is signed so the receiver can check where it came from.
Access to a connected Stripe account is read-only. Secret keys are refused; only restricted keys are accepted, and the component that talks to a Customer’s Stripe account can only issue read requests.
Access to a connected Lemon Squeezy store is read-only in practice: the component that talks to it can only issue read requests. The key itself cannot be restricted by Lemon Squeezy, which is why it is encrypted and never shown again.
A Stripe account or Lemon Squeezy store can only be connected or disconnected by a signed-in account owner in the dashboard. It cannot be done with an API key or by an AI assistant through the MCP server.
Every record is scoped to a project, and every query is filtered by the authenticated project. Automated tests check that one project’s key cannot read another’s data.
Web analytics queries are built by a single component that always limits them to the authenticated project and only accepts values from a fixed character set; a test fails if any other code writes such a query. Events from a domain the Customer has not listed are refused.
Rate limiting per key and per IP address, and bot detection on public forms.
Deleting a signup, disconnecting Stripe or Lemon Squeezy, or deleting a project removes the related data, including contact records and notes, rather than hiding it.
Access to production systems is restricted to the operator of the Service.

Annex 3: Sub-processors

See section 3 of the Privacy Policy, which is the current list.