Who else can see your data
Everyone involved in running this service, what each one can actually see, and where it is. Written from what a provider can see rather than what it is meant to see — a hosting provider that never opens a database still runs the process that reads every row into memory, and that is the disclosure a customer is entitled to know about.
This is one list, and both the privacy policy and the data processing agreement are generated from it. A sub-processor added to one document and not the other is a false document, and that is the commonest way a set of these goes wrong.
Supabase
What it does: Database, file storage and sign-in.
What it can see: Every record in the system — customers, contacts, instruments, readings, certificates, invoices — and the stored PDFs.
Where: Sydney, Australia (ap-southeast-2). Supabase Inc is incorporated in the United States. (Australia)
Data at rest never leaves Australia. The corporate parent is American, which is a different question from where the data is, and both are stated because procurement asks about both.
Hostinger
What it does: Runs the application itself.
What it can see: Reads records into memory to render pages, certificates and invoices. It does not store or log them to disk, but it can see them in memory.
Where: Asia. Hostinger has no Australian data centre; its Sydney presence is a cache for static files. (outside Australia)
An interim arrangement, recorded as a decision rather than an oversight — see ADR 0009. It ends before the first laboratory is sold to: signup refuses while this entry is in use, which is a mechanism rather than a policy somebody has to remember. The target is AWS or Azure Sydney, and moving is a deployment rather than a migration because nothing in the software names a host. Until then the only laboratory on the system is the reference laboratory, which knows and has agreed.
The email provider (SMTP)
What it does: Delivers recall notices, certificates, quotes and invoices.
What it can see: Recipient name and address, the subject line, and the message — which for a certificate or invoice includes the customer’s name and the instrument concerned.
Where: Depends on the provider configured. Brevo, the first, processes in the European Union. (outside Australia)
Deliberately plain SMTP rather than a vendor API, so a laboratory that needs an Australian sending provider can be moved to one by changing credentials rather than by changing software.
Stripe
What it does: Takes the laboratory’s subscription payment, and card payments from its customers.
What it can see: Billing name, email and card details. Card numbers never reach this system — they are entered on Stripe’s own hosted page.
Where: United States and Australia. (outside Australia)
A laboratory’s takings settle to its own bank account through its own Stripe account, and never pass through a platform-held account. That separation is deliberate: money landing in a platform account and being paid out later would make the platform a payment facilitator, with AUSTRAC and possibly AFSL consequences.
Amazon Bedrock — not yet connected
What it does: Reads a customer’s written list of instruments into intake lines a person then confirms.
What it can see: Only the text somebody pastes into the intake screen — typically an instrument list, which may carry a contact name if the customer signed their email. It is sent, read, and answered. No record, reading, certificate or price is sent, and none can be: the extraction is structurally incapable of carrying one (ADR 0018).
Where: Sydney, Australia (ap-southeast-2), pinned to the region rather than a cross-region profile. (Australia)
Not connected. There is no AWS account yet, and until there is, a pasted spreadsheet is read by splitting it — no model, no network, no third party — which is most of what customers send. Only prose needs this, and while it is absent the screen says so rather than failing. When it is connected this entry flips to in_use and the privacy policy follows by itself.