Breach and incident response
If data is ever exposed, lost, or a breach is suspected, First Six runs a documented incident-response process. This page is the customer-facing version of that runbook: what we do, who we tell, and when. It exists so your privacy office can see the commitment before they ever need it.
The guiding principle is that the clock starts the moment we are aware, not when we fully understand the problem. Containment and notification do not wait for a complete root-cause analysis.
First Six is an early-stage company. Today, the incident-response process (including the on-call rotation, runbook execution, and notifications) is run by the founder, with documented escalation paths to our infrastructure providers (Supabase, Vercel). As we grow, on-call will extend across the team and a formal 24/7 rotation will follow. The commitments on this page (timing, severity defaults, regulator notification) do not change with team size; they are designed to be deliverable by a small team and to scale up, not down.
How we classify severity
Every incident is triaged to a severity, and we default up, not down: an incident is treated as more serious until evidence shows otherwise.
| Severity | What it means |
|---|---|
| SEV1 | Confirmed unauthorised access to, or loss of, personal or welfare data, or active exploitation. |
| SEV2 | A security control has failed with potential exposure, not yet confirmed exploited. |
| SEV3 | A low-risk or contained issue with no personal data at risk. |
Wellbeing data is treated as high-harm by default. In our assessment, check-in sentiment and help-request notes are taken as likely to cause serious harm if exposed, and crisis content as very likely, which means crisis-related exposure is always treated as notifiable.
What we do, in order
- Detect and record
We open a timestamped incident record the moment we are aware. That timestamp starts the notification clock.
- Contain
We stop the bleeding first, using the minimum action that halts exposure (revoking sessions, disabling a route, isolating a tenant) before deeper investigation.
- Preserve evidence
We snapshot the relevant logs and audit trail before anything mutates, so the record of what happened is defensible. Diagnostics are already PII-scrubbed, so we correlate by opaque ids and timestamps, not by quoted user content.
- Eradicate and recover
We patch the root cause (code, schema, access policy, or config) and add a test for that specific failure mode. If data integrity is at risk, we restore from backup.
- Verify
We re-run the failure path to confirm it's closed and that the audit log captured everything relevant, then re-enable the affected surface.
- Review
Within five business days we complete a post-incident review: timeline, root cause, impact, what worked, what didn't, and action items.
Who we notify, and when
We assess every confirmed personal-data incident against all applicable regimes, and when the assessment is uncertain, we notify.
| Who | When |
|---|---|
| Your institution | Promptly, within the window in your agreement (default target 72 hours from confirmation). |
| Affected individuals | Where an eligible breach is likely to cause serious harm. |
| The OAIC (Australian regulator) | For an eligible breach under the Notifiable Data BreachNotifiable Data Breach scheme under the Australian Privacy Act: eligible breaches must be assessed and notified within 30 days of awareness. scheme. Assessed and notified within 30 days of awareness. |
| GDPR supervisory authority | Within 72 hours of awareness, where EU/EEA/UK data subjects are involved and the breach is likely to risk individuals. |
We keep pre-written notification templates for the institution, affected individuals, and the regulator, so a real incident is a transcription exercise under a clear head, not a writing exercise under pressure.
Backup and recovery
If an incident threatens data integrity, we restore from backup.
- Database backups are automated, and there are two independent kinds: daily snapshots on our platform tier (about seven days of retention), and a daily encrypted off-site copy held with a different provider (kept 30 days, readable only with a key held offline), so a single cloud or region event cannot take out both.
- Recovery point objective is 24 hours or less. For an in-place restore, the fastest path at our current tier runs through our platform provider's support response, which does not carry a fixed SLA on this tier; the off-site copy is the independent fallback that does not depend on them at all. When we take on our first paying institution we upgrade the plan tier to enable point-in-time recovery and self-serve restore, at which point an 8-hour RTO becomes a defensible target rather than an aspiration.
- Recovery is rehearsed, not theoretical, and the two drills are different things on purpose: a scratch restore drill (most recently July 2026, verified with checksums) runs the mechanics, and a genuine end-to-end restore of the off-site copy was performed on 27 July 2026, decrypted with the offline key and reconciled row-for-row against production as at the backup instant. Both repeat quarterly.
We rehearse this
The process is not a document that sits in a drawer. A restore drill has been run end-to-end and repeats quarterly, and the notification templates and contact list are pre-written and reviewed. The first tabletop incident exercise is scheduled as part of standing up production operations, and we say so here rather than imply it has already happened.
Reporting a suspected breach or leak
If you, or a researcher, suspect a vulnerability or a leak, email security@firstsix.com.au. Please do not open a public issue. We acknowledge within two business days. The security posture page has the full responsible-disclosure terms.
Common questions
How quickly will we hear from you?
Within the window in your agreement, defaulting to 72 hours from confirmation for the institution. We'd rather send an early "here's what we know so far" update than wait for a complete picture.
What counts as a notifiable breach?
Unauthorised access to or disclosure of personal information (or its loss in circumstances where unauthorised access is likely) that is likely to cause serious harm. Welfare and crisis data clear that bar readily, which is why they get the most cautious treatment.
Do you notify our students directly, or do we?
We coordinate. Where individual notification is required we'll work it through with your team so students hear a single, consistent message through the right channel.
Can we see your incident-response runbook?
The internal runbook (with the operational detail) is available to review as part of a security assessment. This page is its plain-language summary.
Related
The fastest answer is usually one question away.