Data Processing Agreement
Effective 17 September 2026
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 [email protected].
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 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 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.
- 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. 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. Any metadata the Customer attaches. | Store, rank, detect abusive referrals, send the receipt and invite emails, export to the Customer. |
| Changelog | Subscribers’ email addresses. | Send notification emails for new entries, with one-click unsubscribe. |
| Feedback | Free text written by End Users, the Customer’s own user identifier, page URL, and an email address if the End User gives one. | Store, classify with an AI model after best-effort removal of emails, phone and card numbers, and forward to destinations the Customer configures. The optional email address is never forwarded. |
| Notifications | The Customer’s own user identifier, notification title and body. | Store and serve to the Customer’s application. Deleted after 90 days. |
| 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. |
| 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, and a connected Stripe restricted key) 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.
- 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.
- A Stripe account 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.
- Rate limiting per key and per IP address, and bot detection on public forms.
- Deleting a signup, disconnecting Stripe 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.