Ten questions a reviewer asks, answered.

1. 1

   Where is our data hosted?

   Fund records, documents and BGL tokens are stored in a Supabase Postgres project and a private storage bucket in the Sydney (ap-southeast-2) region. Application code runs on Vercel serverless functions pinned to Sydney, and the rate-limit store (Upstash Redis) is in Sydney.

   No BGL data is stored on staff devices. Four providers in the United States receive limited adjacent data, described in the next answer and on the security page.

2. 2

   Which data reaches an AI provider, and what is excluded?

   Only the extracted text of a document the trustee uploads or forwards, and the request it answers, go to Anthropic in the United States, to classify the document before the trustee confirms it. The file itself is not sent.

   Nothing read from the BGL API (fund list, balances, documents, workpapers) is ever sent to a model provider. Anthropic deletes API inputs and outputs within 30 days and does not use them for training. A trustee can turn AI document reading off for a fund, and the model is then not called for that fund.

3. 3

   Is multi-factor authentication mandatory?

   Yes, for every BGL-connected user. Sign-in is a single-use magic link with PKCE, and TOTP enrolment is enforced at the first request for any BGL-connected surface: a user with a connected fund cannot reach fund data, documents, reconciliation or the practice workspace until an authenticator is enrolled and verified. Practice members are gated the same way.

   Every administrative account we hold (hosting, database, source control, payments, email delivery, error monitoring, workspace email, DNS and the BGL developer portal) is behind MFA.

4. 4

   Do you hold ISO 27001 or SOC 2?

   No. We hold neither, and our controls have not been independently verified.

   The controls are drawn from OWASP guidance, the framework and database provider security guides and the Australian Privacy Principles, and are enforced in code and CI rather than by a certified management system: row-level security on every table, an enforced Content-Security-Policy, append-only ledgers, and a pull-request gate that fails on a new table without row-level security or on privileged-client use outside a reviewed allow-list.

5. 5

   Have you had an independent penetration test?

   Not yet. Testing to date has been internal: a code-level review of the AI surfaces and a five-repository security audit, both in July 2026, plus the per-pull-request CI gate.

   An independent penetration test is scheduled for the first quarter of 2027, before the pilot cohort grows beyond the first practices. The date and a summary will be published on the security page.

6. 6

   How long are logs retained?

   Every BGL-related security event (connection, token refresh, read, document download, document write, practice access, access denied, two-step sign-in, connection removed) is written to an append-only security audit ledger with actor id, opaque fund id, event, outcome, source and timestamp. There is no purge job, so retention is at least 12 months, and the rows survive fund deletion.

   Platform request logs are shorter: hosting runtime logs one day, database API logs seven days. They are not drained to long-term storage during the pilot; the security audit ledger is the forensic record for BGL-related events.

7. 7

   Who can access production?

   The Director is the only person with production access, across hosting, database, source control, payments, email delivery, error monitoring, workspace email and the BGL developer portal, all behind MFA. There are no employees or contractors, and access is reviewed quarterly under a written Access Control Policy.

   One machine credential exists: the CI pipeline holds a database service-role key as a repository secret, used only by the calculation parity and citation checks, which run with synthetic inputs and read no fund or BGL data. It is rotatable from the database console and is scheduled to move to a non-production database project.

8. 8

   How are BGL tokens stored?

   Access and refresh tokens are encrypted in the application with AES-256-GCM before they are written to Postgres, with a fresh random IV per encryption and the authentication tag stored alongside the ciphertext; the table holds ciphertext only. The platform encrypts the database at rest with AES-256 underneath that.

   The 256-bit key is held only in the hosting platform's encrypted environment store, never in the repository, a configuration file or the database, with one backup copy in an MFA-protected vault controlled by the Director. Under row-level security the row is readable by the fund owner and, server-side, by the scheduled worker; practice users cannot read it.

9. 9

   What happens in an incident?

   A written Incident Response Runbook sets out detection sources, severity levels and first-hour containment: the scheduler kill switch, disabling the affected BGL connection and deleting its stored tokens, rotating application secrets and coordinating credential revocation with BGL.

   BGL is notified immediately of any confirmed or suspected breach exposing BGL client data or API tokens, affected customers are notified, and an OAIC notifiable data breach assessment is made under the Privacy Act. A post-incident review follows within seven days. No security incident or data breach has occurred; one availability incident in September 2026 was resolved the same day with no data exposure.

10. 10

    How do we end the service and get our data out?

    Exports in BGL SF360, Class and CSV formats are free on any plan, during the trial and after a subscription ends; a lapsed account drops to read-only rather than disappearing. A trustee can remove the Simple Fund 360 connection in the product, which deletes the stored tokens, and can revoke a practice's access with immediate effect.

    A trustee lodges a deletion request in the product. It is completed within 30 days after SIS Act retention windows are checked, and the deleted records then age out of the seven-day backup window. Security events, which carry only opaque ids, are retained.

Available on request at hello@smsfcore.com: the Access Control Policy, the Patch and Dependency Policy, the Incident Response Runbook, the vendor and subprocessor register and the July 2026 internal review records.