The procurement pack
This is the starting point for a security or procurement review of First Six. It pulls the whole assessment bundle into one place and tells you, plainly, what is in place today and what is still ahead.
We would rather you see the gaps from us than find them in a pen test. A reviewer trusts a candid "not yet, and here's the plan" far more than an optimistic "yes". Everything below is written that way.
Ask your First Six contact for the procurement pack and we share it under NDA: the pre-filled HECVAT-Lite responses, the subprocessor list, the incident- and disaster-recovery summaries, and the crisis-detection boundary. Or complete your own questionnaire — whichever your team prefers.
What's in the pack
| Document | What it answers | Where |
|---|---|---|
| HECVAT-Lite responses | The standard vendor security questionnaire, pre-filled and current | HECVAT and vendor reviews |
| Data residency + isolation | Where data lives, how it's encrypted, how tenants are kept apart | Data residency and tenant isolation |
| Subprocessor list | Every third party that touches data, what they see, where they're hosted | Subprocessors |
| Incident response | What happens if data is exposed, and the notification clock | Breach and incident response |
| Disaster recovery | Backup posture, recovery objectives, and the last restore drill | Summarised below |
| Crisis-detection boundary | What the automated crisis detection does, and where the institution's duty of care begins | Summarised below |
The short version
First Six meets or exceeds the technical controls a standard HECVAT looks for — encryption, single sign-on with institution-enforced MFA, row-level tenant isolation, append-only audit logging, data minimisation, and a documented breach process.
The open items are independent attestation and process maturity — the kind of thing that takes an external audit or time as a company, not an engineering change. We propose those as milestones for a pilot rather than blockers.
Headline answers
| Area | Status |
|---|---|
| Data residency (Australia, AWS Sydney) | Yes |
| Encryption in transit and at rest | Yes |
| Single sign-on with institution-enforced MFA | Yes |
| Row-level tenant isolation on every table | Yes |
| Append-only audit logging | Yes |
| Data minimisation with small-cell suppression | Yes |
| Student data used to train AI | No |
| Right to erasure and data export | Yes |
| SOC 2 / ISO 27001 | On the roadmap |
| Third-party penetration test | Planned (happy to make it contractual) |
| Data Processing Agreement | In progress with counsel |
| Cyber insurance | Before production at scale |
| Separate prod / non-prod environments | Known gap, remediation planned |
Data handling
- What we store: student name, email, and program; weekly check-in sentiment; and help or welfare requests. No passwords (sign-in is delegated to your identity provider), no payment data, and no health records beyond what a student self-reports in a wellbeing message.
- Residency: the system of record is Supabase on AWS in Sydney
(
ap-southeast-2). A small set of disclosed subprocessors handle diagnostic-only, PII-scrubbed data — the subprocessor list names each one and what it can see. - Minimisation: staff dashboards are aggregate-only and suppress any cell below five students, so no dashboard can single a student out.
- Erasure and export: you are the data controller. First Six executes deletion only on your instruction, and provides a JSON export on request. This matches how Canvas, Blackboard, and Moodle handle institutional records — the institution stays in control of records it may still need.
Authentication and access
- Single sign-on over OIDC, live with Microsoft Entra; a SAML route also exists. MFA is enforced by your own identity provider, so your MFA policy governs First Six too.
- Role-based access — platform owner, institution admin, content editor, support responder, and student — enforced at the database layer, not just in the UI.
- Row-level security is enabled on every application table. Tables reachable directly carry per-row policies; tables reachable only through vetted server-side functions are deny-by-default. A daily automated sweep fails our build if any table drifts from that posture.
- Session management — short-lived signed sessions with server-side revocation, including "log out everywhere".
Application and infrastructure
- Security headers (HSTS, frame, nosniff) on every response; a nonce-based Content Security Policy is live in report-only and moving to enforcing after a violation-review window.
- CSRF protection via origin and fetch-metadata checks on every state-changing request.
- Rate limiting on help, sign-in, and AI endpoints.
- Append-only audit logging of staff actions and sensitive-record access — update and delete are revoked at the database, so the trail can't be quietly rewritten.
- Secrets are environment-based with a documented rotation schedule; no secrets in source.
Business continuity and disaster recovery
We are candid here because it's where an early-stage vendor is genuinely different from an incumbent.
- Backups: Supabase managed daily snapshots. Point-in-time recovery is a paid-tier add-on scheduled for enablement at the first paying customer; realistic recovery-point objective today is 24 hours or better.
- Restore drill: a logical restore was run against the live project on 2026-07-01 — a scratch-schema damage, restore, and verify cycle, with checksums matched on the institution, cohort, and audit-log slices. A full point-in-time drill is scheduled with the paid-tier upgrade.
- Vendor viability: we're early-stage, and we don't pretend otherwise. The mitigations we offer are data export on demand, a source- and data-escrow option, and a defined support contact written into the agreement.
The crisis-detection boundary
If your institution enables the crisis pathway, it's important that procurement and legal understand exactly what it is:
- The detector runs a per-tenant list of text signals against help-request wording, twice (in the app and again on our server), and can only ever upgrade a request to crisis, never downgrade.
- It is not a clinical tool and not a substitute for care. It routes signals to your responders using your configured wording and contacts. First Six never provides care itself.
- Staff judgment is the final safety net — any responder can escalate a ticket the detector missed, and every escalation is audit-logged.
- The institution remains the data controller and the care provider. First Six is a processor and a tool. The binding version of this boundary belongs in the service agreement and DPA, which counsel is finalising.
The crisis-detection boundary is the item most worth a careful read. We've written it to hold up to scrutiny, but the contractual language is being finalised with Australian privacy and education-technology counsel before it's enforceable.
The open items, named honestly
- SOC 2 / ISO 27001 — not yet certified; both on the roadmap. The controls are largely in place; the external attestation is what's ahead.
- Third-party penetration test — planned; happy to make it a contractual condition. (An internal adversarial security review has already been run and its findings remediated.)
- Data Processing Agreement — being finalised with counsel.
- Cyber insurance — to be obtained before production at scale.
- Prod / non-prod separation — a known gap, with remediation planned and tracked in our internal risk register.
Using the pack in your review
- Request the pack
Ask your First Six contact or procurement lead. We share it under NDA.
- Start from the HECVAT responses
They're organised by the standard HECVAT sections, so they line up with whatever internal checklist your team runs.
- Read the gaps, not just the ticks
Every item is Yes, Partial, Planned, or No, with a note. The notes are where the real picture is.
- Write the open items as milestones
Where something is still in progress — SOC 2, the pen test, the DPA — we can write it into the pilot agreement as a milestone rather than a blocker.
Common questions
Can you send a completed security questionnaire today?
Yes. We keep pre-filled HECVAT-Lite responses that reflect the current state of the product, so your review can start straight away. If your institution has its own questionnaire, we'll complete that instead.
Where is student data stored, and does it leave Australia?
The system of record is in Australia, in the AWS Sydney region. A small set of disclosed subprocessors handle diagnostic-only, scrubbed data — some of those are hosted overseas, and each is named in the subprocessor list with what it can see.
Are you SOC 2 or ISO 27001 certified?
Not yet, and we won't imply otherwise. Both are on the roadmap. The technical controls those frameworks look for are largely in place today; the independent attestation is what's still ahead. We're happy to make it a contractual milestone for a pilot.
What happens to our data if First Six winds down?
Data export is available on demand, and we offer a source- and data-escrow option written into the agreement. You're the data controller throughout, so the records stay yours.
Does the crisis detection replace our duty of care?
No. It's a text-pattern tool that routes signals to your responders using your wording and contacts. It has known limits, staff can escalate what it misses, and the institution remains the care provider and data controller.
Related
The fastest answer is usually one question away.