DRAFT — NOT IN FORCE. This document is an unreviewed placeholder. It has not been reviewed by counsel and does not bind anyone.

Privacy Policy

Effective date: [EFFECTIVE DATE] Last updated: [EFFECTIVE DATE]

1. Who we are

[LEGAL ENTITY NAME] ([ENTITY TYPE]) makes [PRODUCT NAME], a white-label wholesale re-ordering portal. We license it to distributors. Each distributor gets their own subdomain, their own brand, and their own database.

In this policy:

  • "we", "us" means [LEGAL ENTITY NAME].
  • "Distributor" means a business that licenses [PRODUCT NAME] from us and runs it under their own brand. The Distributor is our customer.
  • "End User" means a person who signs in on a Distributor's subdomain to place or manage orders — for example staff at a café, restaurant, hotel or office. End Users are the Distributor's customers, not ours.

Our postal address is [PRINCIPAL ADDRESS].

2. The two roles in this policy — read this first

We handle personal data in two different roles, and they have different rules. Work out which one applies to you before reading on.

Role A — we are a processor. Everything inside a Distributor's tenant is handled on that Distributor's instructions. That covers user accounts, companies, products and prices, orders and order history, contact-form messages, and uploaded brand assets. The Distributor decides what goes in, who may see it, and how long it stays. We only act on their instructions. The Distributor is the controller of that data, not us.

Role B — we are a controller. We are the controller for our own website and sales inquiries, for our account records about each Distributor, for the records of what our own staff do to a Distributor's tenant, and for the service logs we keep to run and secure the service. That is our own data, collected for our own purposes. Section 5 lists it.

So:

  • If you are an End User (you sign in on a Distributor's subdomain to order supplies), Role A applies to you. Your relationship is with that Distributor. Their privacy notice governs your data, and questions about it go to them first. See section 11.
  • If you are a Distributor evaluating or using [PRODUCT NAME], Role A applies to the data you put into the service and Role B applies to your dealings with us as a prospect or customer.
  • If you contacted us about buying [PRODUCT NAME], Role B applies.

[FACT NEEDED: whether a written data processing agreement (DPA) is offered to Distributors, and its terms — this policy is not a substitute for one.]

3. What we handle as a processor (Role A — tenant data)

A Distributor's tenant holds the following, as of the effective date.

  • User accounts — name, email address, phone number, password hash, role (standard user, administrator or owner), and display preferences such as rows per page.
  • Companies — the customer businesses a Distributor sells to: name, address, phone, contact name and email, and each company's Favorites list.
  • Products and prices — the Distributor's catalog, including any product note and the per-tenant price visibility setting.
  • Orders and order history — carts, submitted orders, order items, the price recorded at the time of submission, any special-instructions note typed on the order, and the history of who changed the order — its status, or its lines before approval — and when.
  • Contact-form messages — messages sent by signed-in users to the Distributor's staff, the staff replies, and the thread they form. A reply sent by ordinary email to the thread's address is received by us and stored on the thread too, with the sender's address and the message text.
  • The Distributor's own settings — contact details, the from-address for email, notice and footer text, and theme colors.
  • Uploaded brand assets — the Distributor's logo and favicon.
  • Security records — short-lived counters keyed by IP address that limit repeated sign-in, password-reset and request-access attempts, and hashed one-time tokens for invitations and password resets.

One more thing passes through a tenant without being stored in it. A Distributor's sign-in page has a public request-access form for a business that is not yet a customer. What someone types there — business name, address, contact name, email, phone, and a message — is sent as one email to the Distributor's staff and is not stored; the only thing written is the temporary rate-limit counter above, keyed by IP address. An account exists only if the Distributor then chooses to invite that person.

Things we do not handle inside a Distributor's tenant:

  • No payment card data and no bank details. Nobody pays through the ordering site. A Distributor's own customers do not pay us or the Distributor in the product, and an order placed in it is invoiced by the Distributor outside it. The card a Distributor gives us for their own fees is a different matter, and it is covered in section 5.
  • No consumer or household data beyond a work name and work email address.

4. Why we handle tenant data (Role A)

We handle it for one purpose: to run the service for the Distributor, on their instructions. In practice that means storing their data, showing it to the people they have authorized, sending the service's transactional emails (the full list is on our Subprocessors page), and keeping the service secure and working.

We do not use tenant data for our own purposes, other than the operational and usage figures that our Terms of Service describe. We do not sell it, we do not share it for advertising, and we do not use it to train anything. There is no error-tracking provider, no CRM and no ad network in the product.

We do measure how the product itself is used — which buttons and screens people reach for — so we can tell whether a feature we built is working. That is product telemetry about our own software, not about a Distributor's business: the signals we define record that a control was used, by an account id and a role, and carry counts and identifiers rather than a product name, a company name, a price or anything from an order. Most of it is counted on our own infrastructure; a portion also goes to our product-analytics provider, named on our Subprocessors page. See section 13.

That provider also records the wording on whatever was pressed, which is how a click nobody thought to instrument still gets counted. Prices, product names and promotion names are hidden from it. A name a Distributor's staff typed into their own catalog, company list or user list can still reach it that way, on the staff screens where those names are on the buttons. [FACT NEEDED: whether to hide company and person names from that capture as well, which is a setting on our side.]

The lawful basis for handling this data is the Distributor's to establish, because the Distributor is the controller. [FACT NEEDED: the lawful bases to state here, once counsel decides which privacy regimes apply.]

5. What we collect as a controller (Role B — our own site and sales inquiries)

This covers our own website, our dealings with Distributors as customers, and the records we keep to run and secure the service itself.

  • Sales inquiries — the name, email address, business name and message content that someone chooses to send us when they ask about [PRODUCT NAME].
  • Correspondence — the emails that follow from that inquiry.
  • Distributor account records — the business name, the subdomain, and the account contact's name and email address, which live in our own operator database, separate from any tenant; plus correspondence about the agreement, which we keep in our ordinary business records.
  • Billing records for a Distributor's own account — the billing contact's name and email address, the number of orders their tenant submitted in a billing period, and the invoices and payment records that follow. The payment method itself is typed into our payment provider's own form and is held by them; we hold the invoice and the record of whether it was paid, not a card number. This is between us and the Distributor, and it holds nothing about a Distributor's own customers. Our payment provider is named on our Subprocessors page.
  • Operator activity records — when one of our staff creates, suspends or restores a Distributor's tenant, or opens it for support (see section 10), we record who did it, to which Distributor, and when. We keep these for accountability to the Distributor.
  • Service logs — request metadata such as IP address, timestamp, user agent, the URL requested and any error raised, kept by our hosting provider so we can diagnose faults and detect abuse. Logs are not meant to hold personal data, but an IP address is one, and an error message can include an identifier such as a user or order id. We collect these for our own purposes — keeping the service working and secure — so we treat ourselves as the controller of them. [FACT NEEDED: counsel to confirm the controller/processor analysis for service logs under the regimes that apply.]

Two limits:

  • The in-product contact form is not part of this. It sits behind a sign-in and it goes to the Distributor's staff, not to us. That is tenant data under Role A.
  • We run no advertising or cross-site tracking technology of any kind, on any surface. The usage measurement described in section 4 is confined to the signed-in product and never follows anyone anywhere else. See section 13.

[FACT NEEDED: whether our own website has a contact or inquiry form, and exactly which fields it collects.]

6. Why we collect it (Role B)

To answer the inquiry, to talk to a prospective Distributor about the product, to keep a record of that conversation, to run and bill the Distributor's account, and to keep the service working and secure.

We do not send marketing email to people who did not ask us about the product, and we operate no mailing list. [FACT NEEDED: the lawful bases to state here, and whether any marketing consent mechanism will exist, once counsel decides which privacy regimes apply.]

7. Who we share data with

We use three subprocessors, as of the date at the top of this policy.

Beyond those three, we share personal data only:

  • where a Distributor instructs us to;
  • where the law requires it, or to respond to legal process or to establish or defend a legal claim;
  • with our own professional advisers, under confidentiality;
  • with a successor to our business if it is sold or merged, on the same terms as this policy.

Our Subprocessors page breaks each of them out service by service, says what each one can touch, and carries our commitment to give notice before the list changes.

8. Where data is stored, and international transfers

Data is stored and processed on Cloudflare's platform, including the databases, the brand asset storage, the application itself, and the email it sends and receives. Our Subprocessors page lists the individual services.

Our deployment is US-oriented. We do not make a data residency guarantee.

[FACT NEEDED: data residency commitment.]

[FACT NEEDED: the transfer mechanism to state for personal data that leaves its country of origin — for example Standard Contractual Clauses — once counsel confirms which regimes apply.]

9. How long we keep data

Tenant data (Role A). The Distributor decides. Records stay in their tenant until they delete them or until their agreement with us ends.

What happens after the agreement ends — the export window, the deletion window, and how long copies persist in backups — is set out once, in section 15 of our Terms of Service.

[FACT NEEDED: retention window for server logs and email delivery logs.]

Our own data (Role B).

[FACT NEEDED: retention window for sales inquiries and the correspondence that follows.]

10. How we protect data

What we do today, described as outcomes rather than mechanisms:

  • Passwords are stored only in a hashed form, using a standard, deliberately slow password hashing method. We do not store a password in readable form.
  • Sign-in cookies are protected so that page scripts cannot read them and other sites cannot reuse them, and the server checks where each change request came from.
  • Each Distributor's data is kept in its own separate database.
  • Traffic between your browser and the service is encrypted in transit.

Our own staff can open a Distributor's account. To support a Distributor, one of our operators can sign in to that Distributor's tenant, either read-only or with the same access as the Distributor's own top-level administrator, depending on that operator's permission. This is a deliberate support tool, not a back door, and it is bounded: the session it creates expires after 30 minutes instead of 8 hours, and every time it is used we record which operator opened which tenant, with which level of access, and when. We use it to help with a support request or to investigate a suspected misuse of the service, and not otherwise. Our Terms of Service say the same. [FACT NEEDED: whether a Distributor can see the log of support sessions on their tenant, and whether access requires the Distributor's prior request.]

What is not true today, so you are not misled:

  • There is no multi-factor authentication, on either the customer app or our own operator console.
  • We hold no security certifications. No SOC 2, no ISO 27001, no HIPAA, no PCI.
  • We do not claim penetration testing.

No system is perfectly secure, and we do not claim ours is.

[FACT NEEDED: encryption-at-rest commitment for stored data and files, if one can be backed.]

[FACT NEEDED: breach notification commitment — who we notify, and within what timeframe.]

11. Your rights, and how to use them

If you are an End User, contact your distributor first. They are the controller of your data. They decide what is held about you and they can correct or remove it. Their privacy notice — not this one — governs your account, your company's orders, and any message you sent through the app. We cannot act on tenant data without their instruction, and if you write to us we will normally pass the request to them and tell you we have done so.

If you are a Distributor, you can reach your own tenant data through the app: user accounts, companies, products, orders, messages and your tenant settings are all editable by your administrator and owner staff. For anything the app cannot do, write to us at [SUPPORT EMAIL].

For data we hold as a controller (section 5), write to [NOTICE EMAIL] and tell us what you want. We will ask enough to be sure it is really you before we act.

[FACT NEEDED: which privacy regimes apply — for example GDPR / UK GDPR, CCPA / CPRA, other US state privacy laws — and the specific rights, disclosures, appeal routes and supervisory authority details each one requires. This section is deliberately generic until counsel decides that.]

[FACT NEEDED: the response timeframe we commit to for a rights request.]

[FACT NEEDED: how we verify the identity of someone making a rights request.]

12. Children's data

[PRODUCT NAME] is a business tool. It is sold to distributors and used by their staff at work. It is not directed to children, and we do not knowingly collect data from children. There is no self sign-up: an account exists only when a Distributor's staff create one and send that person an invitation to set their password. The public request-access form creates no account — it sends the Distributor a message, and it is the Distributor who decides whether to invite anyone.

If you believe a child's data has reached the service, tell the Distributor who runs the subdomain, or write to us at [NOTICE EMAIL].

[FACT NEEDED: the minimum age term, if the Terms of Service set one.]

13. Cookies and client storage

The short version: the product uses one sign-in cookie on a Distributor's site and a separate one on our own operator console, plus a small amount of browser storage holding a copy of who you are signed in as and a few settings you chose. There is no advertising or cross-site tracking technology of any kind, and nothing here follows you to any other site.

Signed in to a Distributor's site, our product-analytics provider also stores a cookie and a matching browser-storage entry so that a sequence of actions can be recognized as one visit. They hold an identifier for your account in this service and a few technical values — not your name, not your email address, and nothing from an order. That identifier is ours and means nothing outside this service, but it is not anonymous: it is how the measurement tells one account's use from another's. Requests to that provider go through the Distributor's own address rather than the provider's, which keeps our content security policy tight and means the measurement is not defeated by a content blocker; we would rather say that plainly here than rely on it quietly. If your browser sends a Global Privacy Control or Do Not Track signal we turn that provider off for you entirely, and only our own first-party counting continues. The provider can also record a replay of what is on your screen; we switch that off, so it does not run.

Everything else we store is either strictly necessary to sign you in or a preference you set yourself.

Two exceptions, stated so they are not missed. The public request-access form runs a Cloudflare Turnstile bot check, which loads a script from Cloudflare on that one screen; it is there to stop automated spam and it runs nowhere else. And the billing screen a Distributor's administrators use loads our payment provider's own script, which draws the card fields, so the card number goes to them rather than through us. [FACT NEEDED: what Turnstile collects from the browser and whether it sets any storage, and what storage the payment provider's script sets, to state here from each vendor's current documentation.]

The item-by-item inventory is on our Cookies and Storage page.

[FACT NEEDED: the formal "Do Not Track" / Global Privacy Control statement California law requires of any online service collecting personal information from Californians. The product reads both signals and switches the analytics provider off on either, as stated above, so what is left is counsel confirming the wording rather than a gap in behavior.]

[FACT NEEDED: whether a consent banner or an opt-out control is required now that a non-essential cookie exists on the signed-in product. The previous "nothing to consent to" line has been removed from section 13 pending that answer.]

14. Changes to this policy

If we change this policy we will update the "Last updated" date at the top. If a change is significant — a new category of data, a new purpose — we will tell Distributors directly before it takes effect, by email to their account contact. A new subprocessor follows the notice commitment on our Subprocessors page.

Distributors are responsible for passing relevant changes on to their own End Users, because the Distributor is the controller of that relationship.

[FACT NEEDED: the notice period for a material change, and the channel it is sent on.]

15. How to contact us

For privacy questions, rights requests about data we control, and legal notices:

Email: [NOTICE EMAIL] Post: [LEGAL ENTITY NAME], [PRINCIPAL ADDRESS]

For help using the product, Distributors should write to [SUPPORT EMAIL].

End Users: contact your distributor first. They hold your account and they are the controller of your data. If you cannot sign in, the sign-in and forgot-password screens show your distributor's own support contact.

[FACT NEEDED: whether a data protection officer or a designated privacy contact is required and, if so, who it is.]