How your data is protected, end to end

This guide follows one student's data from the moment it is created to the moment it is deleted, naming the control that protects it at each stage. It is written for the people who need to trust the system — students wondering who can see them, and the IT, security, and privacy reviewers who have to sign off before First Six goes near student data.

Where a control is in place, this says so plainly; where there is a known gap, it names it rather than papering over it. The detailed, checkable version is the institution's data residency and isolation page.

1. Capture — only what's needed, with consent in view

A student checks in or raises a request. The app is explicit about what is collected and who can see it, so the student is never surprised later (see who sees my check-ins). Collection is scoped to what the product actually needs, not everything it could ask for.

2. In transit and at rest — encrypted both ways

The data travels over TLS, with HSTS enforced so a browser refuses a plain-HTTP connection, and it is encrypted at rest through AWS-managed encryption. These are table-stakes controls, listed so a reviewer can tick them off.

3. Residency — in Australia by default

The data of record — the database, authentication, and file storage — is hosted in AWS's Sydney region, keeping the bulk of student data under Australian jurisdiction.

4. Isolation — enforced by the database, not app code

Every tenant-owned row carries an institution_id, and row-level security policies key off it. One institution can never see another's data, because the database itself refuses to return rows that don't belong to the caller's tenant.

5. Aggregation — individuals disappear into the crowd

When staff look at a cohort's pulse, small groups are suppressed so no individual can be re-identified from an aggregate. A number only appears once the group is large enough to hide the people in it.

6. Access — least privilege, signal-driven

Staff see the aggregate by default; an individual comes into focus only on a real signal, like a help request the student themselves raised. What staff see of a student is framed in what staff see, and sensitive actions are recorded in the audit log.

7. Deletion — the data can leave

When a student deletes their data, it goes (see deleting your data). Retention is bounded rather than indefinite; data of record does not linger past its purpose.

8. When something goes wrong — a clock, not a shrug

If there is a breach, the incident and breach process governs the response: contain, preserve evidence, assess against the Notifiable Data Breaches scheme's 30-day clock from awareness, and notify. The process is written down and rehearsed, not improvised.

What this chain guarantees

• The student knows what's collected and who can see it, up front.
• One institution's data is fenced off by the database itself.
• No individual can be re-identified from an aggregate.
• The data can be deleted, and a breach has a defined, time-bound response.

Common questions

Related