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

Subprocessors

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

1. What this page is for

[PRODUCT NAME] is run by [LEGAL ENTITY NAME]. To run it we use a small number of other companies. Where those companies handle data belonging to a distributor or that distributor's own customers, they are our subprocessors and we stay responsible for what they do.

This page lists the services we use, as of the date at the top. It is written for a distributor's owner or IT reviewer, so it names the individual services we use, not just the company behind them.

2. The list

Three companies are on this list as of the date at the top. Cloudflare runs the service itself and supplies most of what is below; the other two are here for one job each.

Subprocessor Service What it does for us Data it can touch Where it processes
Cloudflare, Inc. Workers (compute) Runs the application. Requests to the product are handled here. What the product handles, in transit — such as sign-in credentials, user accounts, companies, products and prices, orders, contact-form messages. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. D1 (SQL database) Stores each distributor's data. One separate database per distributor, plus one for our own operator accounts, the distributor registry, and the log of operator support sessions and suspensions. User accounts (name, email, password hash, role), companies and their favorites, products and prices, orders and order history, contact-form threads. In our own database: distributor account contacts and operator activity records. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. R2 (object storage) Stores uploaded brand assets — a distributor's logo and favicon. Brand images. Not intended to hold personal data, unless a distributor uploads an image containing some. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Durable Objects The live-update hub. Holds the open browser connections for a distributor and pushes changes (for example, an order changing status) to the people watching. Messages in transit about orders and their status, and the signed-in user's identity for each open connection. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Workers Static Assets Serves the built web application — the JavaScript, CSS and images the browser downloads. No customer data. Static files only. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Email Sending (Cloudflare Email Service) Sends our transactional email: order confirmation (to the person who ordered), new-order notification (to the Distributor's staff), order approved, invitation to set a password, password reset, password changed, a notification when someone uses the contact form, a reply on a contact-form thread, and a notification when someone uses the public request-access form. Recipient email addresses and the contents of those messages — which include order line items, prices and totals, contact-form text, request-access details, and time-limited sign-in links. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Email Routing (inbound email) Receives email sent to a contact-form thread's reply address, so a customer or staff member can answer a thread from their own inbox. The message is parsed and stored on the thread. The sender's address and name, the message text, and the email's headers. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Turnstile (bot check) Decides whether the person using the public request-access form is a human, so that form does not become a spam channel. It loads on that screen only. Browser and connection signals Cloudflare uses to tell people from bots. [FACT NEEDED: the data Turnstile collects, per Cloudflare's current documentation.] [FACT NEEDED: data residency commitment]
Cloudflare, Inc. CDN, DNS and TLS Resolves our hostnames, provides HTTPS, and sits in front of requests to the product. Traffic in transit, plus request metadata such as IP address, timestamp and user agent. [FACT NEEDED: data residency commitment]
Cloudflare, Inc. Workers Logs Keeps application logs so we can diagnose errors. Request metadata and error details. Application logs are not intended to contain personal data, but an error message can include an identifier such as a user or order id. [FACT NEEDED: data residency commitment]
PostHog, Inc. Product analytics Measures how the product itself is used — which screens people open and which controls they press — so we can tell whether something we built is working. It runs for people signed in to a distributor's ordering site, and the browser sends it through the distributor's own address rather than connecting to the provider directly. An account identifier of ours that means nothing outside this service, the signed-in person's role, the identifier of their company, the distributor's short name, the addresses of the screens visited, and the wording on whatever was pressed. Prices, product names and promotion names are hidden from it before anything leaves the page, though a name on a button on a distributor's own staff screens can still reach it that way. It is not sent an email address, a postal address, or the contents of an order. [FACT NEEDED: whether to hide company and person names from that capture as well.] United States
Stripe, Inc. Payments and invoicing Takes the payment method a distributor gives us for their own use of [PRODUCT NAME], issues that distributor's invoices, and collects payment. It is used only for what a distributor owes us. The distributor's billing contact name and email address, the card or bank details typed into the provider's own form, the number of orders that distributor's tenant submitted in a billing period, and the invoices and payment records that follow. Not a distributor's own customers' data, and not the contents of any order. [FACT NEEDED: data residency commitment]

Notes on that table:

  • Cloudflare is one vendor but not one thing. Each row is a separately provisioned service with its own access path and its own data, so each is listed on its own.
  • Email is sent and received by Cloudflare, not by a separate email vendor. We do not use a third-party email service such as Resend, SendGrid, Postmark or Mailchimp. [FACT NEEDED: whether Cloudflare Email Sending's Beta status should be disclosed to distributors, and what that means for the service commitment behind it].
  • Each distributor gets its own database. Separation between distributors is physical, not a filter in a query.
  • The card is typed into the payment provider's own form. The fields on our billing screen are served by that provider inside our page, so the card number goes to them rather than through us. A distributor's own customers do not pay through the product and do not meet that provider: an order placed in [PRODUCT NAME] is invoiced by the distributor outside it.
  • The last two do not apply to everyone. The payment provider is involved only where a distributor is billed for the service. Product analytics runs only once someone is signed in to an ordering site, and it is switched off for a browser sending a Do Not Track or Global Privacy Control signal, and for the support sessions our own staff open on a distributor's tenant.

3. What is deliberately not on this list

We think the absences matter as much as the entries, so they are stated plainly:

  • No advertising or cross-site tracking technology of any kind, and no ad network. The product analytics listed above is confined to the signed-in product and does not follow anyone to another site.
  • No session recording. The analytics provider can record a replay of what someone sees on screen. We switch that off in the product, so it does not run.
  • No general web analytics on a distributor's ordering site — no Google Analytics, no tag manager, and nothing measuring people who are not signed in.
  • No error-tracking or crash-reporting vendor. Errors go to Cloudflare's own logs. [FACT NEEDED: the analytics provider also sells error tracking and heatmaps, which are turned on in the provider's own project settings rather than in the product. Confirm both are off there, and state it here.]
  • No CRM, marketing-automation or support-desk tool connected to product data.
  • No payment details in the product itself. We do not receive or store a card number or a bank detail; the payment provider listed above does, on its own form.
  • No third-party fonts or stylesheets loaded by the browser, and only two third-party scripts, both listed in the table: the Turnstile bot check on the public request-access form, and the payment provider's own script on the billing screen a distributor's administrators use. The typeface is served from our own domain, and the pages are built not to load anything else from Google Fonts or any other content network. Product analytics adds no third-party script and no connection to another company's address.
  • No AI or machine-learning service processing customer data.

4. How we choose a subprocessor

Before we hand any distributor data to another company, we look at four things:

  1. Whether we need them at all. The shortest list is the safest one. That is why this page is short, and why we treat adding a company to it as a decision rather than a convenience.
  2. What they would be able to see. We prefer an arrangement where a vendor handles the least data that still lets them do the job.
  3. Their security and privacy terms, including whether they will sign a data-processing agreement that passes our obligations to a distributor down to them.
  4. How hard they would be to replace. The product is deliberately designed so that the pieces that touch a vendor — the database, the file storage, the live-update hub and the email sender — are small and can each be replaced. That is a design property, not a legal promise, but it is why changing a subprocessor is realistic for us rather than theoretical.

[FACT NEEDED: whether a written vendor-review or security-questionnaire process exists, and who signs it off].

[FACT NEEDED: the data-processing agreement in force between [LEGAL ENTITY NAME] and Cloudflare, Inc., and whether it is the standard Cloudflare DPA].

[FACT NEEDED: the data-processing agreements with PostHog, Inc. and Stripe, Inc., whether each is the vendor's standard form, and the sub-processors each of them uses in turn].

5. Advance notice before we add one

If we want to add a new subprocessor, or replace one on this list, we will tell affected distributors before that company starts handling their data.

  • Notice period: [FACT NEEDED: advance notice period before a new subprocessor starts processing — e.g. 30 days].
  • How we give notice: by email to the contact address on the distributor's account, and by updating this page and its "Last updated" date.
  • If you object: [FACT NEEDED: the objection process — how long a distributor has to object, what we do if they object, and whether objecting gives a right to terminate].

We may need to move faster than the notice period in an emergency — for example, if a vendor fails or has to be replaced for a security reason. If that happens we will tell distributors as soon as we reasonably can, and explain why.

[FACT NEEDED: whether emergency replacement without advance notice is permitted under the distributor agreement, and on what terms].

6. How to follow changes to this page

  • The page itself. This page shows the current list and the date it last changed.
  • By email. [FACT NEEDED: whether a subscription list for subprocessor changes exists, and the address or link to join it]. Until that exists, write to [NOTICE EMAIL] and ask to be added to subprocessor change notices.
  • Retention of old versions. [FACT NEEDED: whether previous versions of this page are published or archived, and where].

7. How to contact us

Questions about this page, a specific subprocessor, or a request to be notified of changes:

  • Legal notices: [NOTICE EMAIL]
  • Support: [SUPPORT EMAIL]
  • Post: [LEGAL ENTITY NAME], [PRINCIPAL ADDRESS]