DRAFT FOR COUNSEL REVIEW - not legal advice - counsel review is planned after launch

Lumioh Cloud subprocessors (draft)

Draft 0.2, updated 14 October 2026. Operator: [COMPANY LEGAL NAME], ABN [ABN] ("Lumioh").

This page lists the outside services that handle customer data and account data on Lumioh's behalf, what they handle and where. It is part of the DPA (Annex 3) and is referred to by the Privacy Policy and the Terms of Service.

"Customer data" means the data an agency or site owner puts into Lumioh Cloud about its sites and clients. "Account data" means the e-mail address, workspace name, sign-in records and billing records of the people who use Lumioh Cloud.

1. Subprocessors

Subprocessor	What it does for us	What it handles	Where
Supabase (project "Lumioh")	Database (PostgreSQL), sign-in (Auth), private file storage, and database backups when the plan includes them	All customer data and account data that Lumioh Cloud stores: workspace, client, site and member records; audit findings, change events, crawl results and Search Console figures; alert and billing records; the audit log; encrypted site credentials and encrypted Google tokens; Auth records (e-mail address, password hash, sessions, sign-in IP addresses); private storage objects (report PDFs for up to 24 hours, agency logos)	Sydney, Australia (`ap-southeast-2`). Supabase's own support access and its own subprocessors may be elsewhere
Google Cloud (project `lumioh-0001`)	Runs the web application and the background jobs (Cloud Run, Cloud Scheduler); encrypts site credentials and Google tokens (Cloud KMS); holds service secrets (Secret Manager); stores container images (Artifact Registry); network egress for the crawler (Cloud NAT); application logs and monitoring (Cloud Logging, Cloud Monitoring); the load balancer and Cloud Armor in front of the web application	Data in transit and in memory in the web application and the jobs (all customer data and account data the product handles); encrypted credential envelopes (the key is in KMS, not the data); service secrets; application logs, which carry random identifiers, not names, e-mail addresses, page addresses or payloads. Crawl bodies are discarded after parsing	Sydney, Australia (`australia-southeast1`). Google may process some service data elsewhere under its own terms
Resend	Sends our e-mail: workspace invitations, critical alert e-mails, the opt-in daily digest, account-deletion and ownership-transfer notices, and the sign-in e-mails (confirmation and password reset) that Supabase Auth sends through Resend's mail server	The recipient's e-mail address; message text, which can include the workspace name, site names and counts; delivery status (delivered, bounced, complained). We keep only payload-free delivery details for 90 days	Outside Australia. Region: [RESEND REGION]
Stripe	Payments for paid plans: customers, subscriptions, invoices, payment methods and tax documents	The billing Owner's e-mail address and name, the workspace reference, subscription and invoice records, and payment details entered directly at Stripe. Lumioh Cloud never sees or stores card numbers. We keep Stripe customer, subscription and price identifiers, the subscription state, and a copy of Stripe's records in our own database (Supabase's Stripe sync). Stripe may also act as an independent controller for fraud prevention and its own legal duties	Stripe processes data in Australia and overseas, including the United States, under its own terms
Cloudflare	Turnstile, the bot check on sign-up, sign-in and password reset; and DNS for `lumioh.com`. The DNS records point straight at our load balancer, so page requests do not pass through Cloudflare	For Turnstile: the visitor's IP address, browser signals and a one-time check token, sent from the visitor's browser to Cloudflare while a form is shown (Supabase Auth then verifies the token with Cloudflare). For DNS: the names that are looked up. No customer data	Cloudflare's global network
PostHog	Product analytics: which parts of Lumioh Cloud are used, and where people stop in sign-up and setup, so we can fix problems and decide what to build	Product events about account activity: a random user identifier, a random workspace identifier, the plan, event names, counts and the page route. Kept 13 months. Never e-mail addresses, personal names, the addresses or content of customer sites, tokens or the data in a customer's reports (see section 4 of the Privacy Policy)	[POSTHOG REGION]. PostHog has no Australian region, so this is outside Australia

Lumioh relies on each provider's published data processing terms for the service it uses, and requires each provider to protect data at least as well as the DPA asks of Lumioh (see section 6).

The Stripe sync that copies Stripe records into our database is software running inside our own database environment. It is not a separate service.

2. Where customer data is stored and processed

Database, sign-in records and file storage: Supabase, Sydney.
Application servers, jobs, encryption keys and secrets: Google Cloud, Sydney.
Customer data leaves Australia only through the services above whose location is outside Australia (Resend for e-mail, Stripe for payments, Cloudflare for the bot check), and through Supabase's and Google's own operations if they process data outside Sydney. Product analytics (PostHog) carries account activity only, not customer site data.
The people who run Lumioh Cloud work from Australia.
Lumioh makes no regional hosting promise beyond what is stated here.
Data a customer exports, and anything on the customer's own WordPress site, is outside Lumioh's systems.

3. Google Search Console: a data source, not a subprocessor

When an agency connects Search Console, it signs in to Google and authorises Lumioh Cloud to read its Search Console properties with the read-only webmasters.readonly permission. Lumioh then calls Google's Search Console API and stores the figures it receives (daily clicks and impressions, and for a connected site the top 50 page or query rows per date, kept 120 days), plus an encrypted refresh token so it can keep reading. The agency can disconnect at any time. Lumioh then deletes the stored token and stops reading, and workspace erasure revokes the token at Google first, as far as Google allows.

In this flow Google is the origin of the data and the identity provider the agency authorises, and it applies its own terms and privacy policy to the data it holds. Google does not receive customer data from Lumioh through this connection, other than the API requests themselves, which name the agency's properties and date ranges. That is why Google appears here as a source and not as a subprocessor. Google Cloud, the hosting service, is a different Google service and is listed in section 1.

Lumioh's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Lumioh uses the Search Console data only to show it to the agency that connected it, and to the clients and members that agency gives access to. It does not use it for advertising, does not sell it, and does not let people read it other than as described in the Privacy Policy.

4. Services that are not used, or do not receive customer data

If any of these is introduced, it will be added to section 1, with notice under section 6, before it receives customer data.

Service type	Position
Search engine results (SERP) data providers	None selected or used. No customer data is sent to one
AI and language-model providers	None. Lumioh Cloud does not send customer data to an AI provider
Other analytics sources (GA4, Bing Webmaster, a customer's own PostHog)	Planned as future data sources that a customer connects; not available
Advertising or tracking services	None. Product analytics is described above and in the Privacy Policy
Error or performance monitoring service	None beyond Google Cloud logging and monitoring
Slack and other alert channels, outbound webhooks	E-mail is the only alert channel. A customer's own webhook receiver, if webhooks are ever offered, would be the customer's, not a subprocessor
Source hosting and builds (GitHub)	Source code and build tooling only; no customer data

5. Not Lumioh's subprocessors

The customer's own WordPress site and the Lumioh plugins (the Lumioh Cloud Connector, the Lumioh Cloud module of the Lumioh SEO plugin, and the Lumioh SEO Pro add-on). They are under the customer's control. Cloud cannot uninstall them or erase what the site holds.
The customer's e-mail provider and browser. Where alerts and exports end up.

6. How this list changes

Lumioh will add or replace a subprocessor only after updating this page, and will give customers at least 30 days' notice by e-mail to each workspace Owner before the new subprocessor receives customer data. A customer may object on reasonable data protection grounds within that notice period, as the DPA sets out. Each subprocessor is bound by a written agreement that requires it to protect data to the same standard as the DPA, and Lumioh remains responsible for it.

Facts to verify with counsel

Which of Supabase, Google Cloud, Resend, Stripe, Cloudflare and PostHog are processors, which are independent controllers for part of what they see, and whether their standard terms already contain the processor commitments that section 1 relies on.
The legal entity and contract for each provider, the link to its data processing terms, and its own subprocessors (Supabase's infrastructure provider in particular).
The Resend and PostHog regions, which the owner chooses (README, section 4).
Whether Google Search Console should be described as a source (section 3) and whether the Limited Use statement is enough for Google's API Services User Data Policy.
Whether Cloudflare Turnstile's handling of IP address and browser signals needs separate disclosure to people who sign up (the Privacy Policy discloses it).
The 30 days' notice and the objection right in section 6.
Whether the people who run Lumioh Cloud all work from Australia, and what the privilege and logging model for operator access is.

Facts this draft assumes that the code may not yet implement

Hosted provisioning. The Sydney pairing of Supabase and Google Cloud is the owner's decision (13 October 2026). The production environment is created after this draft; the list must be checked against what is actually provisioned on launch day.
Resend. Sending from team@lumioh.com and the sign-in mail through Resend's mail server are configured on the development project. No real alert e-mail has been delivered from the hosted worker yet, and the Resend delivery webhook is not registered.
Stripe. Test mode only. There is no checkout or billing portal yet. The description of what Stripe holds is the intended design.
PostHog. Not in the product code. This entry is the commitment the analytics implementation must meet before it is switched on: events carry only the items in section 1, and the region is the one named here.
Cloudflare DNS. The statement that DNS records are DNS-only (not proxied) follows the Terraform design and must be checked in the Cloudflare account.
Cloud KMS for credentials. The adapter is built and the key ring is defined in Terraform. Hosted acceptance (Q15) is open.
Logging. Hosted Cloud Logging and its 30-day retention are not provisioned yet (doc 32, R4).
Per-worker database keys. Dedicated keys exist for each hosted job on the development project; rotation of the project's shared default key is deferred by the owner until after launch.
Subprocessor notice. There is no mailing list or objection workflow in the product; the notice is sent by hand to workspace Owners.
Public API and webhooks are not available, and a customer-chosen webhook destination would need to be reflected here before it ships.