Skip to content
Open the app

Data residency and tenant isolation

This page is for the people who have to be satisfied before First Six is allowed near student data: IT, security, and compliance. It states the posture plainly and points to where each control lives.

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.

Two subprocessors sit outside Australia, and we would rather be upfront about them than bury them:

  • 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 replays mask all text and inputs.
  • Transactional email (SendGrid, US). Some welfare-relevant content (a help category, a message excerpt) travels in notification email bodies.

A staff-only AI drafting assistant uses Anthropic's API (US) and is never sent student welfare records. The full, current subprocessor list is maintained and available on request.

Encryption

Data is encrypted in transit with TLS, with HSTS enforced, and encrypted at rest through AWS-managed encryption. A baseline set of HTTP security headers is applied to every response.

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 security policies key off it on every table. 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 privileged service-role key that can cross that boundary is server-only and governed by a strict convention, audited rather than left to chance.

Why this matters more than a firewall

Because the boundary lives in the database, a bug in a single API route cannot leak another institution's data through it. The policy has already filtered the query before any application code runs.

If something goes wrong

First Six runs a documented incident and breach-response process. Under Australia's Notifiable Data Breach 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.

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. 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.

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, and a documented breach process. A pre-filled HECVAT-style questionnaire is available.

We are candid about the gap: 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. If your process requires an existing certification today, raise it early so we can talk about timing.

Was this helpful?
Need more help?

The fastest answer is usually one question away.

Edit this page on GitHub