Security posture

This is the plain-language version of how First Six handles security: the safeguards in place, and how to report a problem if you have found one.

The deeper, institution-facing detail lives in data residency and isolation; this page is the quick reference and the place to start if you have found a problem. Because First Six holds welfare data about students, security here is not a feature bolted on at the end. It is the boundary the whole product is built around.

Reporting a vulnerability

If you believe you have found a security issue, we would rather hear about it than not. The fastest, safest route is a private email, not a public post.

1. Email the security inbox

   Send the details to security@firstsix.com.au. Include a description, the impact you think it has, steps to reproduce, and any affected URL or account. The more precisely you can describe the reproduction, the faster we can confirm and fix it.

2. Keep it private

   Please do not open a public issue, post, or social thread for a security report. Public disclosure before a fix has shipped puts real student data at risk, which is exactly what the report is meant to prevent.

3. Test safely

   Avoid testing against real student accounts or live welfare data. Use the demo personas or a local instance instead, so your research never touches a real person's records.

The posture in brief

The controls below work together: encryption protects data on the wire and at rest, tenant isolation keeps one institution's data away from another's, the audit log makes staff activity reviewable after the fact, and scrubbed diagnostics mean our own tooling never becomes a back door to personal data.

• Encryption. TLS in transit with HSTSHTTP Strict Transport Security. Tells browsers to only ever connect over HTTPS, closing off downgrade attacks., encryption at rest, and a baseline set of security headers on every response.
• Tenant isolation. Row-level securityRow-level security: database policies that decide which rows a given caller can read, so isolation lives in the database, not application code. keys every query to one institution, so a cross-tenant read is structurally impossible from an app client. Because the rule lives in the database rather than in app code, a bug in the application cannot quietly bypass it.
• Audit log. Every staff write, and sensitive reads, are recorded immutably. That record is what makes after-the-fact review possible; see the audit log.
• Diagnostics with the personal data stripped. Error monitoring scrubs names, emails, and message bodies before anything leaves the app. Session replay in the error monitor is disabled entirely. We never record what a user did on screen, even in masked form. The goal is that a useful error report can be read by an engineer without ever exposing who a student is or what they wrote.

How changes reach you safely

First Six ships continuously from main, so only the currently deployed revision is supported. There are no long-lived release branches to patch.

Before a change reaches you, it runs a fixed verification checklist against a separate non-production project, which holds synthetic data and mirrors the production schema. Preview and development builds connect to that project and not to production, and the rule is enforced in code: a deployment that is not production refuses to build if it is pointed at the production database. Any check that must run against live data is still read-only or immediately rolled back, and every data-changing step is written with a way to roll it back. The full standard, mapped to SOC 2 CC8 and the HECVAT change-management questions, is set out in how we change the platform safely.

Common questions

Related