Trust Centre
How we protect student data: tenant isolation, least-privilege access, and defence in depth.
Security is built into the data model, not bolted on. Every layer assumes the others can fail.
Security is built into the data model, not added on at the end. Every record is isolated to its institution with database row-level security and least-privilege access functions, so one tenant can never reach another's data.
Access is gated by single sign-on through your identity provider, and sensitive actions are written to an audit trail that cannot be quietly edited.
Changes are proven in a separate non-production environment before they reach your students, reviewed for their effect on data access, kept reversible, and recorded.
Defence in depth
No single control is trusted on its own. Each layer is built to hold even if another fails.
01
Isolate every tenant
Each institution's data is fenced off in the database with row-level security, so a query can only ever see its own tenant's rows, rather than relying on app code that has to remember.
02
Authenticate through your IdP
Access is gated by single sign-on through your existing identity provider. First Six links a sign-in to a known person; it never creates one, and sessions can be revoked.
03
Grant the least access that works
Staff see only the courses, campuses, or cohorts in their scope. The few server paths that bypass row-level security re-impose tenant scoping by hand and are treated as the highest-risk code in the system.
04
Record what matters
Sensitive actions are written to an audit trail that can't be quietly edited, so activity stays traceable after the fact.
The controls behind the claim
The specific measures that protect student data, layer by layer.
Tenant isolation in the database
Every tenant-owned row carries its institution and is filtered by Postgres row-level security policies. Isolation is enforced by the database itself, not by application code that has to remember.
Single sign-on
Authentication runs through your identity provider over OIDC, with Microsoft Entra and other OIDC providers supported. SAML is available as a proof-of-concept and productionised on request.
Session control
Sessions are HttpOnly cookies established at sign-in and can be revoked, so access can be cut off the moment someone leaves.
Hardened endpoints
Machine endpoints use bearer tokens compared in constant time, with rate limits and payload caps to blunt abuse.
Immutable audit logging
Sensitive actions are recorded to an append-only trail, so nothing important happens without a record.
Reviewing First Six for procurement?
Request our security pack, including HECVAT responses and the subprocessor list.
What we never do
Support means seeing the pattern, not the person. These limits are built into the product, not just promised in a policy.
We never sell or share student data
Student data is used to run First Six for your institution — never sold, rented, or handed to advertisers or data brokers. Full stop.
We never build watchlists
Individual wellbeing answers stay private to the student. Staff see aggregate trends with small groups suppressed — never a named list of who to watch.
We never train external AI on student data
Student records are not used to train third-party models. AI features process only what staff submit, and that content is not retained for training.
We never hide where data lives
The system of record stays in Australia, and every subprocessor and region is listed openly here in the Trust Centre. No surprises.
Frequently asked questions
What security, privacy, and procurement teams ask us most.
Every record carries its institution ID, and Postgres row-level security policies filter every query to the signed-in tenant. The separation is enforced in the database, so even a bug in app code can't read across tenants. The few server-only paths that use a service credential must re-impose tenant scoping by hand and are reviewed as the highest-risk code we run.
Yes. We share HECVAT responses, an architecture summary, and our subprocessor list under NDA, and we'll complete your security questionnaire as part of procurement.
Yes. Traffic is served over HTTPS, and data at rest in the managed database and file storage is encrypted by the platform.
Secrets are kept in environment configuration and a password vault, never in source control, compared in constant time, and rotated on request or suspected exposure. Per-tenant values, like each institution's OIDC client secret, are isolated per institution.
Because sign-in is through your identity provider, removing someone there removes their access. Sessions can also be revoked directly, and their scope limits what they could ever reach.
See it for your next cohort.
Currently meeting with universities.