What we collect, and what we don't

First Six is built to hold as little as it needs, and to treat what it does hold about a student's wellbeing as the sensitive data it is. The governing principle is data minimisationCollecting and keeping only the data needed for a stated purpose, and no more.: the less held, the smaller the surface a breach could expose and the simpler the answer when a privacy office asks what is on file. This page lists what is held, what is deliberately not, and why wellbeing data is handled differently from the rest.

What we collect

• Identity provided by your roster: name, institutional email, program, campus.
• Weekly check-in responses (a single sentiment answer per week).
• Help and crisis requests the student chooses to raise.
• If a student uses the "thinking about whether to stay" page and chooses to say why, the driver they pick (and anything they type). Reading that page records nothing; only an explicit submit does. Staff see it as a suppressed group total, never as an item against a named student.
• An audit log of staff actions inside the console.

Each of these earns its place. Identity is what lets a student resolve to the right record and a cohort to the right wellbeing team; the check-in is the signal the product exists to surface; help and crisis requests are raised by the student themselves; and the audit log is what makes staff action accountable. Nothing on the list is collected speculatively in case it is useful later.

What we don't collect

• No passwords. Authentication is delegated to your identity provider, so First Six never holds a credential. There is no password store to breach.
• No payment data. Billing happens at the institution level, off the student path entirely.
• No health records beyond the wellbeing a student self-reports. First Six is not a clinical system and does not ingest medical history.

What students can see about themselves

Students are not in the dark about their own data. They can look back over their own check-in history, read the full thread of any help request they have raised, and see the read-only enrolment details synced from your systems. The product is designed so a student is never surprised by what is held about them.

The wellbeing-data special case

Wellbeing data gets stricter handling than the rest, by design, because it is the most sensitive thing the product holds and the easiest to misuse.

A student's individual weekly answer never appears on a staff dashboard. The default staff view is cohort-level, and it suppresses any breakdown until at least five students sit behind it, so no one can be singled out of an aggregate. The support staff responsible for a student can open that student's check-in history deliberately, and every such read is written to the audit log. The threshold is what turns "how this student feels" into "how this group is travelling": below it, a small filtered slice could re-identify someone, so the breakdown simply is not shown. In our breach assessment, check-in sentiment and help notes are treated as likely to cause serious harm if exposed, and crisis content as very likely: a conservative classification, chosen so the response errs toward protecting the student. Where exactly the staff line sits is set out for students in what staff see (and what they don't).

Right to be forgotten

Your institution is the system of record for student identity: it owns the single sign-on and can revoke a student's access immediately by disabling that identity. Erasing the data First Six holds is a separate step, and First Six actions it: when your institution requests it, when a student exercises their right to be forgotten by contacting us at privacy@firstsix.com.au, or as part of a breach response.

When a student's data is deleted it is a hard deleteThe records are removed outright, not just flagged as hidden while the data remains. that cascades through their check-ins, help requests, saved items, and timetable in the live system. Group statistics recalculate without the deleted responses; what remains beyond them is anonymous usage counts that never carried an identifier, routine encrypted backups that age out on their own cycles (within 30 days, including the encrypted off-site copy), and the tamper-resistant audit trail of staff actions, kept for accountability.

Common questions

Related