Subprocessors
A subprocessorA third-party service that processes data on our behalf as part of running First Six. is any third party that touches your data as part of running First Six. We keep the list short, because the fewer hands on the data, the smaller the surface for something to go wrong. Every one of them is below.
These providers process data on behalf of First Six Technologies Pty Ltd (ACN 699 938 817), the entity that runs First Six and the data processor under your agreement.
The current list
| Subprocessor | Purpose | Region | Data it can see |
|---|---|---|---|
| Supabase (AWS, Sydney) | Primary database, authentication, and file storage: the system of record | Australia (ap-southeast-2) | The application data of record, isolated per tenant |
| Vercel | Application hosting and content delivery | Sydney region for compute; global CDN for static assets | Requests in transit; no student system of record at rest |
| SendGrid | Transactional email (sign-in links, notifications), and inbound replies: a student replying to a help-request email is received by SendGrid and written into their request | United States | Recipient and sender email address, and message content in both directions, including anything a student writes in a reply and any attachment they send with it (received by SendGrid, discarded by us, never stored) |
| Slack (per-tenant webhook) | Crisis alerts mirrored to a tenant-chosen Slack channel, where an institution enables it | Your own Slack workspace (US-default hosting) | The crisis-alert payload: the student's full name, program, week, category, and an excerpt of what the student wrote in their own words, plus a link to open the request. Sent to a webhook URL your institution provides |
| Microsoft (per-tenant Teams webhook) | The same crisis alert, where your institution configures a Microsoft Teams webhook instead of a Slack one | Your own Microsoft tenant, via Microsoft-operated webhook endpoints (US-default) | The same payload as the Slack row above, including the student's full name and the excerpt of what they wrote |
| Your help desk (per-tenant signed webhook) | Signed notifications when a help request changes, so your own service desk can mirror it, where your institution enables it | Your institution's own help-desk system | Event type, request status, category, priority and crisis flag, plus the student's name, institutional email and external student id. The student's free-text message is not in the payload. Sent only to the HTTPS endpoint your institution configures, and every delivery is signed so your system can verify it came from us |
| Sentry | Error monitoring | United States | Scrubbed diagnostics, with personal data filtered out before it leaves |
| Anthropic | Two AI features: staff assistants in the console (drafting content, plus an admin assistant that can propose setup changes for a staff member to confirm), and the public help assistant on this knowledge base | United States | The staff assistants see only what staff submit: prompts, tags, cohort and audience settings, week content they are drafting against, and since August 2026 any file a staff member chooses to attach (a handbook, a term calendar, a services list, a screenshot). Attached files are read for that one request and are never stored by First Six. The public help assistant sees the visitor's typed question plus published help content. Neither is sent student welfare records or any platform data; not used to train models. Your staff must not attach individual student records, and the console says so where the attach button is. Spreadsheets with a student ID, surname, date of birth or address column are refused automatically, and the assistants are instructed to stop if a file holds individual records; that automatic check cannot read inside a PDF or an image, so it does not replace the rule. The AI never changes anything itself: a staff member confirms each change and First Six applies it |
| Upstash | Rate-limit counters that throttle abusive traffic before it reaches the database | Australia (Sydney) | Visitor IP and route key for short-lived counters; no personal records stored |
| Plausible | Cookieless analytics on the public knowledge base only | European Union | Anonymised page visits and "was this helpful?" votes on the KB. No cookies, no cross-site tracking, no PII. The student and admin apps are not instrumented. |
| Google Fonts | Web fonts loaded from Google at page-load time | Google global (US) | End-user IP and User-Agent on each page load. The price of using fonts hosted on Google's CDN. Self-hosting is on the follow-up list. |
| Webflow (lead webhook, optional) | Forwards demo-signup contact details to a CRM endpoint, when one is configured | The CRM endpoint you point it at (US default) | Lead name, lead email, demo slug, timestamp. Only fires for marketing demo signups, never for real student data |
| BetterStack | Uptime monitoring and the public status page at status.firstsix.com.au | European Union | Server-to-server uptime probes carry no personal data; the public status page collects standard visitor metadata |
| Expo | Push notifications and app updates for the mobile app | United States | The device's push token and a generic notification ("you have a new message"). Welfare and personal detail is deliberately kept out of the notification and stays behind sign-in. Applies to the native app only |
| GitHub | Stores our daily off-site backup, so a copy of the database exists somewhere other than our main cloud provider | GitHub storage (United States / global) | Stored as encrypted data only, which GitHub cannot read. The backup job runs on GitHub's build machines: the copy is encrypted there in memory, before anything is written to disk or stored, so the only version that is ever kept is the encrypted one. The key that opens it is held offline and never goes to the cloud. Kept for 30 days, then deleted automatically. Added 2026-07-26 |
Primary data stays in Australia. The US services that can touch content are email (which carries notification text, including some welfare-relevant excerpts), crisis alerts to Slack or Microsoft Teams (only where your institution enables them, and these carry the most: the student's full name and an excerpt of what they wrote), mobile push (Expo, which carries only a generic notification, welfare detail is kept out of it), and the two AI assistants (the staff console assistant sees staff prompts, tenant configuration context and any file your staff attach, and can propose changes for a staff member to confirm, never writing to the platform itself; the public help assistant on this knowledge base sends a visitor's unauthenticated question plus published article text, and is rate-limited and budget-capped; neither is ever sent student welfare records). One further US flow is the daily off-site backup: a copy of the database is stored with GitHub so that losing our main cloud provider does not lose your data with it. The backup job runs on GitHub's build machines and encrypts the copy in memory before anything is written down, so what GitHub actually stores is a file it cannot read: the key that opens it is held offline and never goes to the cloud. Error monitoring is US-hosted but personal data is scrubbed before it leaves the app, and session replay is disabled entirely.
Not subprocessors
- Your identity provider (Microsoft Entra, Okta, or your own OIDC/SAML IdP) is your system, not ours. First Six links a sign-in to a person who already exists in your roster; it never receives or stores your directory.
- Webflow (the marketing site at
firstsix.com.au) runs only the public marketing site. The apps run on their own subdomains and the marketing site does not process student data. A separate Webflow lead-capture webhook receives demo-signup contact details. That flow is listed above, since it does process personal data (just never student data).
The data-processing terms behind each one
Reviewed provider by provider in August 2026. The short answer is that data protection terms are in force with every subprocessor that offers them, and for most the mechanism is not a signature: a modern provider incorporates its data processing addendum into the standard terms of service the account already accepted, so the terms bind automatically and what matters is recording which clause they rest on.
In force through incorporation into the terms we accepted, each with EU Standard Contractual Clauses where a restricted transfer arises: Supabase, Twilio SendGrid (which also holds Binding Corporate Rules), Anthropic (whose addendum is an exhibit to the commercial terms, the same document carrying the commitment not to train models on customer content), Vercel, Webflow and Upstash. Plausible carries an automatic addendum and needs no transfer clauses at all, being an EU company hosting in the EU.
Being confirmed: Sentry, whose addendum is accepted in-product rather than incorporated; Expo, whose addendum is provided on request; GitHub, where the published addendum's scope depends on the account tier we hold for the encrypted backup artifact; and BetterStack, the lowest-sensitivity of the four, where probes carry no personal data at all.
Three flows are covered by your agreement rather than ours. Where you enable crisis alerts to Slack or Microsoft Teams, or the outbound webhook to your own help desk, the receiving workspace, tenant or service desk is yours, under your own agreement with that provider. We list them as subprocessors because the message leaves our infrastructure, which is a disclosure we owe you. But we hold no account with Slack or Microsoft on those paths and could not enter a processor agreement for them if we tried. What governs the disclosure is your own documented instruction to switch the channel on, which the DPA records.
One provider cannot have processor terms at all, and we would rather say so than list it as a missing document. Our pages currently load typefaces from Google's font service, so a visitor's browser makes a direct request to Google and Google receives that request's IP address and browser string. No application data and no student record is involved. Google states that it acts as an independent controller for that service, and it is a free public API with no account and no contract, so a processor agreement is not merely unsigned, it is not a thing that exists to be obtained. The fix is a code change rather than paperwork: we are removing the dependency by self-hosting the typefaces, after which no font request leaves our own infrastructure.
How we manage them
- The list is maintained and kept current; the version here reflects the latest review date at the top of this page.
- Data-processing agreement coverage per provider is being compiled and is provided on request as it lands.
- If a subprocessor changes, it shows up here, and the full current list is available on request for a formal assessment.
Common questions
Can we get a formal, signed subprocessor list?
Yes. Request it as part of a security or procurement assessment and we'll provide the current list; per-provider DPA status is being compiled and is shared as part of that assessment.
Why is email a US service?
Transactional email currently runs through a US-hosted provider, and some notification content travels in email bodies. We disclose this rather than bury it; if AU-region delivery is a hard requirement, raise it early.
Is student welfare data ever sent to the AI vendor?
No. There are two AI features and neither is sent student welfare records or any platform data. The staff assistants in the console see only staff prompts and tenant content such as tags and cohort settings. The public help assistant on this knowledge base sees the visitor's typed question plus published help content, nothing from the student platform. One of the console assistants can make a few setup changes for your admins (creating a cohort, adding a student group, inviting a colleague), and even then the AI does not perform the change: it proposes it, your staff member presses Apply, and First Six carries it out with that person's own permissions.
Related
The fastest answer is usually one question away.