Cybersecurity and privacy. Your handover

You are on the institution's cybersecurity, risk, or data-protection team. Running vendor assessment, reviewing the privacy posture, or owning the breach process at your end. This document is the evidence checklist for the pre-go-live review.

Your progress0 of 0 tasks

What's already done for you

The evidence pack First Six ships with the handover covers, end to end:

HECVAT-Lite self-assessment: pre-filled, with the open items listed, in the HECVAT article.
Full HECVAT internal self-audit (control gap analysis with 17 ranked findings). Provided on request under your NDA.
Subprocessor list: the verified inventory of every third party that may touch institutional data, with region and payload (per-provider DPA status is being compiled; see the task below): Subprocessors.
Data residency: primary database in Sydney, AWS ap-southeast-2. Confirmed live, not just claimed: Data residency.
Breach response runbook: AU NDB decision tree, GDPR 72h, FERPA, with templates and a 30-minute containment runbook: Breach response.
Append-only audit log: staff actions are logged to a database table where UPDATE and DELETE are blocked by trigger for every role, including the service role. Two narrow, sanctioned exceptions exist, both requiring a privileged role plus an explicit transaction-local flag: a purge path (demo-data cleanup, and a retention helper with a hard 180-day floor), and an erasure-redaction path that replaces an erased student's own words inside historical entries with a marker while keeping every other field, so the action trail survives the student's right to be forgotten. Institutional audit history is otherwise immutable. Admin-only read.
Row-Level Security on every app-owned table. Tables that need direct PostgREST reads carry per-row policies; tables that are only reachable through SECURITY DEFINER RPCs are deny-by-default (RLS on + no policy + anon/authenticated grants revoked).
Daily security CI: a GitHub Actions workflow that fails the build on any new RLS regression, anon grant regression, schema drift, or storage-policy regression.
PII scrubbing: error telemetry to Sentry runs through a scrubber that strips cookies, auth headers, request bodies, the user object, and regex-redacts email-shaped strings. Session replay is deliberately disabled.

The evidence is real and verifiable in code; we encourage you to ask for the audit's confidence labels rather than take the summaries at face value.

Your verification checklist

Read the HECVAT-Lite article. Flag any row whose Response is "Partial" or "No" that's a blocker for your procurement; raise these with us before sign-off, not after.

Review the Subprocessor list. Each provider lists region and payload; per-provider DPA status is being compiled (see the DPA task below). Confirm the list satisfies your cross-border-transfer disclosure requirements.

Confirm data residency satisfies your APP 8 (or equivalent) policy. Our primary database is in Sydney. Crossing the border to the US: transactional email (SendGrid), the AI surfaces (Anthropic, which since 4 August 2026 includes any file a staff member chooses to attach in the console), error monitoring (Sentry, scrubbed), the daily encrypted off-site backup (GitHub artifact storage, ciphertext only, the one copy of application data at rest outside Australia), and, where you enable them, crisis alerts to your own Slack or Teams workspace, which carry the most: the student's name and their own words. Each is disclosed in the subprocessor list with the payload it carries; treat that list as the inventory, not this summary.

Decide your position on staff AI attachments. Since 4 August 2026 staff can attach PDFs, images and CSVs to the console assistants, and those files go to Anthropic (US) and are not stored by us. An automatic check blocks obvious student-record exports but cannot see inside a PDF or an image, so this is a staff-behaviour control, not a technical one, and our own risk register says so (R237). If your policy needs it disabled per tenant, tell us during onboarding: that control does not exist today and we would rather you know.

Read the breach-response runbook. Confirm the 30-minute containment runbook aligns with your own institutional breach-handling policy.

Share your institution's NDB / privacy contact with us so the breach-notification chain has a real human on your end (not just a shared inbox).

Note: First Six does not have executed DPAs with every subprocessor yet. DPA status is per-provider TBD in the subprocessor list. If your procurement requires executed DPAs as a condition of go-live, raise it explicitly. We are willing to commit to specific DPA milestones contractually.

Note our position on third-party penetration testing: we have not commissioned one yet. We are willing to commission one as a contractual milestone, and we welcome your own institutional security team testing against the demo environment under the scope and safe-harbour terms of our published security policy: demo personas only, never production student accounts or live welfare data, and no denial-of-service testing.

Confirm with the platform owner that they (and the responder pool) know how to surface the audit log: it's at Settings → Audit on the admin console. Reads are admin-only by RLS; the table is append-only.

Things that aren't here yet

Be open about gaps rather than surprised by them later. As of this handover, First Six does not have: SOC 2 Type II, ISO 27001, an executed cyber-insurance policy, a third-party penetration test, an externally-validated accessibility audit (a self-assessed VPAT was published 3 August 2026 and names 15 criteria we do not yet support; external validation is the missing half), or a paid-tier Supabase plan with point-in-time recovery (planned). These are all tracked in the full audit and in docs/compliance/RISK_REGISTER.md. We'd rather you know than discover.

Ongoing posture

Agree a review cadence with us. Typically annual, plus notification on any material change (new subprocessor, region change, breach). The subprocessor list is maintained as SEVEN canonical copies that must move together (the engineering source of truth, this knowledge base, the in-app privacy policy, the Trust Centre, the marketing assistant's corpus, and the rendered signing documents); the count is stated because undercounting it is exactly how a copy has gone stale before, and the Trust Centre item is the one copy that needs a manual update, so it is the one to ask us to confirm.

Subscribe to the public status page so your team gets the same incident notifications we do.

Add security@firstsix.com.au to your incident contacts list. We acknowledge security disclosures within 2 business days and target Critical fixes within 7 days, High within 30, Medium within 90.

What's already done for you

Your verification checklist

Ongoing posture

Related