Data residency and tenant isolation

If you have to be satisfied before First Six goes near student data, this is the page for you: IT, security, and compliance. It sets out the posture and points to where each control lives, so you can check a claim rather than take it on faith.

A control described here is in place today, and a gap is labelled as one. Anything not stated here should be assumed to be available on request, not implied.

Where the data is hosted

Primary data (the database, authentication, and file storage) is hosted in Australia, in AWS's Sydney region. The application runs on Vercel with the Sydney edge for serverless functions and a global CDN for static assets. Keeping the data of record in-country is a deliberate choice, not an accident of deployment: for an Australian institution it keeps the bulk of student data under Australian jurisdiction and shortens the conversation with a privacy office.

A subprocessorA third-party service that processes data on our behalf as part of delivering First Six. is any third-party service that touches data on our behalf. Several of ours sit outside Australia, and we would rather be upfront about them than bury them in an appendix. Those involved by default are:

• Error monitoring (Sentry, US). Diagnostics only. Personal data is scrubbed before it leaves the app: no names, emails, message bodies, cookies, or auth headers, and session replay is disabled entirely.
• Transactional email (SendGrid, US). Some welfare-relevant content (a help category, a message excerpt) travels in notification email bodies.
• Mobile push (Expo, US). Applies to the native mobile app. Carries the device's push token and a generic notification line ("you have a new message"); welfare detail is deliberately kept out of the notification, so the substance stays behind sign-in.
• Off-site encrypted backup (GitHub artifact storage, US). A daily encrypted copy of the production database, kept 30 days, so no single cloud or region event can take out both copies. It is encrypted in memory on the runner before it is stored and the key is held offline, so the provider holds bytes it cannot read. This is the one place application data at rest sits outside Australia, and it is disclosed in the DPA in exactly those words.

Where your institution enables them, crisis alerts to Slack or Microsoft Teams also carry welfare-relevant content to that provider: the student's name and an excerpt of their own words, which is what makes the page a responder can act on. Anthropic's API (US) powers the AI surfaces: staff assistants in the console (which receive staff prompts, tenant content, and, since 4 August 2026, any file a staff member chooses to attach: an automatic check blocks obvious student-record exports but cannot see inside a PDF or an image, so attachments are a staff-behaviour control and our risk register says so) and the public help assistant on our knowledge base (a visitor's typed question plus the article's published text). The platform itself never sends student welfare records to the model, and the AI is never in the write path: a confirmed change is carried out by First Six with the staff member's own permissions. The full, current list is published on the Subprocessors page, so a reviewer can assess each one against their own residency requirements rather than relying on this summary.

Encryption

Data is encrypted in transit with TLSTransport Layer Security. The standard protocol that encrypts data moving between a browser and a server., with HSTS enforced so browsers refuse to connect over plain HTTP, and encrypted at rest through AWS-managed encryption. The daily off-site backup copy is additionally encrypted with its own key before it is stored (age public-key encryption; the private key lives offline, never in CI), which is a different mechanism with a different custodian, deliberately. A baseline set of HTTP security headers is applied to every response. These are table-stakes controls; they are listed here so you can tick them off against a checklist, not because they are remarkable.

How one tenant's data is isolated

Isolation is enforced in the database, not in application code. Every tenant-owned row carries an institution_id, and row-level securityRow-level security: database rules that filter which rows a given session is allowed to see, enforced by the database itself. is enabled on every table: tables the app reads directly carry per-row policies keyed to the institution, and the most sensitive tables are deny-by-default, reachable only through vetted server-side functions that enforce the same boundary. An application client (a student's or a staff member's session) can only ever read rows for its own institution; a cross-tenant read is structurally impossible, not merely discouraged.

The distinction matters because the two approaches fail differently. Isolation written in application code is only as good as the last developer who remembered to add the WHERE institution_id = ... clause; one forgotten filter on one route is a cross-tenant leak. Isolation written as a database policy is applied to every query whether the application asked for it or not, so the safe path is the default path.

The privileged service-role key that can cross that boundary is server-only and governed by a strict convention, audited rather than left to chance. Its use is the deliberate exception, and the audit query that surfaces every use of it is part of the evidence pack.

Can First Six's own staff see your students?

By default, no. First Six operates the platform through an operator console that is PII-free by design: it shows fleet health as aggregate counts and timestamps (how many students, how many open help requests, activation rate), and never a student's name, email, or the content of a help request or check-in. The same row-level security that separates one institution from another also means First Six's own staff have no standing access to any student's records.

There is exactly one exception, and you control it. If you ask us to look into a specific student (a support ticket where their data looks wrong, or a help request that didn't route the way it should), an admin at your institution opens a break-glass grant from your console (Settings → First Six access) for one student, with a reason and an expiry of at most 72 hours. You can revoke it at any moment, and it expires on its own. First Six can never open that door itself: the permission to grant access is a capability held by your admins, not by us.

Even under a live grant, what we see is redacted to the technical shape of the records (that help tickets and check-ins exist, their status, priority and timing, and counts), and never the words in a help request or check-in, never the student's name, and never anything in their private workspace. Every time we look is written to your own audit trail (with a running count you can see on the grant) as well as ours. So the answer to "can your staff read our students' data" is: not unless you explicitly and temporarily let us, for one student, and then only its structure, and you can watch and stop it.

If something goes wrong

First Six runs a documented incident and breach-response process. Under Australia's Notifiable Data BreachNotifiable Data Breach scheme. The Australian regime requiring assessment and notification of eligible data breaches. scheme, the assessment clock starts the moment we are aware, with up to thirty days to assess and notify the regulator and affected individuals where the breach is eligible. We do not treat that thirty-day ceiling as a target; it is the outer bound, and the runbook is written to move faster than it.

Welfare data is treated as high-harm by default in that assessment: check-in sentiment and help-request notes are taken as likely to cause serious harm if exposed, and crisis content as very likely. Defaulting to high-harm is the conservative choice. It errs toward notifying rather than toward staying quiet, which is the posture an institution would want taken with its students' welfare data. Notification templates for the institution, affected individuals, and the regulator are pre-written so a real incident is a transcription exercise, not a writing one, and the relevant slice of the audit log is preserved before anything is touched (see the audit log).

Independent assurance

The technical controls meet the bar a standard HECVAT review looks for: encryption, SSO with institution-controlled MFA, row-level security, immutable audit logging, data minimisation, a documented breach process, and a documented change-management standard. A separate non-production project holds synthetic data for pre-production testing, and preview and development builds run against it rather than against production, enforced in code rather than by convention. A pre-filled HECVAT-style questionnaire is available.

One gap to be clear about: First Six does not yet hold a SOC 2 or ISO attestation. We are willing to commit to SOC 2 as a contractual milestone for a pilot, so the absence today is something we will close to a timeline rather than a permanent gap. If your process requires an existing certification before you can proceed, raise it early so we can talk about timing before it becomes a blocker late in procurement.

Common questions

Related