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.

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.
• An audit log of staff actions inside the console.

What we don't collect

• No passwords. Authentication is delegated to your identity provider, so First Six never holds a credential.
• No payment data.
• No health records beyond the wellbeing a student self-reports.

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.

A student's individual weekly answer is never shown to staff. It feeds a cohort-level view, and that view suppresses any breakdown until at least five students sit behind it, so no one can be singled out of an aggregate. 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.

Right to be forgotten

A student's account is provisioned through your institution's single sign-on, so account deletion is initiated with the institution that owns that identity. When a student's data is deleted it is a hard delete that cascades through their check-ins, help requests, saved items, and timetable. The only thing that remains is anonymous cohort counts that were already aggregated and carry no identifier.