Where exactly is our data?
Your primary data (the database, sign-in, and file storage) lives in Australia, in AWS's Sydney region. The application runs on Vercel's Sydney edge. Keeping the data of record in-country is deliberate: it keeps the bulk of student data under Australian jurisdiction.
Several services sit outside Australia. The ones that carry the most are named here; the subprocessor list is the complete inventory, and it is the page to hold us to. By default: error monitoring (Sentry, US, with all personal data scrubbed before it leaves the app), transactional email (SendGrid, US, which carries notification content and inbound student replies), and a daily encrypted off-site backup held in GitHub's artifact storage (US): a ciphertext copy of the production database that only a key held offline by the founder can read, kept 30 days as the independent second copy no single-cloud event can take out. Where your institution enables them, crisis alerts to Slack or Microsoft Teams carry the most of any offshore flow: the student's full name and an excerpt of their own words, sent to the workspace you chose so your responders are paged where they already work. Two AI assistants run on Anthropic's API (US): the staff assistants in the console receive staff prompts, tenant content and any file your staff attach to them, and the public help assistant on our knowledge base receives a visitor's typed question plus published article text; the platform never sends them student welfare records itself, and the attachment note staff see says plainly that what they attach is their call. The full, current subprocessorA third-party service that processes data on our behalf as part of delivering First Six. list is published at Subprocessors, naming each provider with its region and the data it can see. The data residency and isolation page has the detail and the reasoning behind each control.
The out-of-country services are scoped narrowly on purpose. Error monitoring receives diagnostics with personal data scrubbed before it leaves the app; transactional email carries notification content because that is what an email has to contain to be useful; crisis alerts apply only where you switch them on. One offshore copy of the data of record exists, and it is deliberate: the daily off-site backup, which is encrypted before it is stored so the provider holding it can never read it. The readable data of record stays in Sydney.
Can we white-label First Six?
Yes. Each institution gets its own branding (logo, accent colour, fonts) and a tenant-aware sign-in, so students see your identity, not ours. The intent is that First Six reads as an extension of your institution rather than a third-party tool bolted on, which matters for how students receive it in their first weeks.
What happens if we leave?
Your data can be exported, and cohorts can be archivedKept and queryable, but moved out of the active working view. rather than discarded. Individual student erasure is authorised by your institution as the data controller: a student can delete their own account from inside the app, and erasure requests that reach First Six directly are routed to your privacy contact rather than actioned unilaterally, because deciding whose data goes is your call, not your vendor's. You own the sign-in identity, so you can revoke a student's access immediately. The commercial off-ramp is defined, not left open: engagements run on a 12-month term that renews unless either side gives 90 days' notice, set out in how pricing works. What is worth agreeing at the start of an engagement is the mechanics of leaving, whether you want your data returned or deleted and in what format, so the exit is never a surprise.
Can we self-host?
Not today. First Six is delivered as a managed, multi-tenant service, and self-hosting is not an option we can offer. If your underlying requirement is continuity rather than control (being sure you can get your data out and keep operating), an on-demand export is usually the answer. Raise it early and we will talk through options.
How does this work with FERPA and GDPR?
The controls that matter for both are in place: row-level isolation, an immutable audit log, data-subject erasure, and a documented breach process with the right notification clocks (the Australian NDB scheme, plus GDPR's 72-hour rule where EU data subjects are involved). Listing the controls rather than asserting "compliance" is deliberate. A control you can verify is worth more than a label. Our privacy policy is the binding statement; this is the plain-language version, and where the two differ the policy governs.
Common questions
Is our data of record stored in Australia?
Yes. The database, sign-in, and file storage are in AWS's Sydney region, and the app runs on Vercel's Sydney edge. Data that leaves the country goes only to the disclosed subprocessors, scoped as described above.
Can we get a full list of subprocessors?
Yes. The full, current list is published on the Subprocessors page, naming every provider with its region and the data it can see, so your privacy office can assess each flow.
Can we run it on our own infrastructure?
Not today; it is a managed multi-tenant service. If the concern is continuity of access to your data rather than hosting control, an on-demand export addresses it. Raise it early in the conversation.
Related
The fastest answer is usually one question away.