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.
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, with point-in-time recovery available.
- Recovery targets for the pilot are a recovery point objective of 24 hours or less and a recovery time objective of 8 hours or less.
- Restore drills are run on a recurring schedule so recovery is rehearsed, not theoretical.
We rehearse this
The process is not a document that sits in a drawer. Restore drills, a tabletop incident exercise, and a review of the notification templates and contact list run on a recurring schedule, so the first time we follow these steps is never a real incident.
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.