Security

1. Data Residency

All patient and clinical data is stored in Australia. No patient data leaves Australian infrastructure.

• Application hosting: Vercel syd1 region (Sydney, Australia)
• Database: Neon serverless PostgreSQL (AWS ap-southeast-2, Sydney)
• Clinical files & recordings: Google Cloud Storage (australia-southeast1, Sydney)

Supporting services that do not handle patient data (such as authentication, billing, and transactional email) may operate from data centres outside Australia. See the Sub-Processors section below for details.

2. Encryption

• In transit: All connections are encrypted with TLS 1.2 or higher. HSTS is enforced with a two-year max-age and preload.
• At rest: Database storage (Neon) and file storage (Google Cloud Storage) use AES-256 encryption at rest.
• Application-level encryption: Sensitive clinical fields are encrypted with AES-256-GCM before being written to the database. This includes session note content (subjective, objective, assessment, plan), NDIS numbers, SMS and email message bodies, and OAuth tokens for email connections. Encryption is transparent — data is encrypted on write and decrypted on read via Prisma extensions.
• Database connections: All connections to the database are encrypted via TLS.

3. Authentication & Access

• Multi-factor authentication (MFA) is mandatory for all users. We support authenticator apps and passkeys.
• Role-based access control (RBAC) ensures clinicians only access clients within their own organisation.
• Session management is handled by Firebase Auth with secure, short-lived session tokens and automatic expiry.
• Guardian access is automatically revoked when a client turns 18.

4. Audit Trail

Every create, update, delete, and read of clinical records is logged with:

• Timestamp of the action
• User who performed the action
• Action type (create, read, update, delete)
• Affected resource and record identifier

Audit logs are immutable and retained for the life of the account. Organisation owners can review audit history within the platform.

5. Breach Response

Figments maintains a written Notifiable Data Breach (NDB) response plan in accordance with the Privacy Act 1988 (Cth).

• 72-hour notification: We commit to notifying the Office of the Australian Information Commissioner (OAIC) within 72 hours of identifying an eligible data breach.
• Affected parties: Impacted organisations and individuals will be notified promptly with details of the breach and remediation steps.
• Designated response lead: A named individual is responsible for coordinating breach response, communication, and remediation.

6. AI Data Handling

Figments's Voice AI feature processes session recordings to generate draft clinical notes. We take the following precautions:

• Audio is transmitted securely to Google Cloud Vertex AI in the australia-southeast1 (Sydney) region for transcription and note generation. All processing stays in Australia.
• Voice AI data is not retained after processing and is not used for model training.
• Your clinical data is never used to train AI models.
• Voice AI is opt-in only and requires explicit client consent.

7. Sub-Processors

We engage the following third-party service providers to deliver the platform:

8. Compliance Frameworks

Figments is designed to support compliance with the following Australian regulatory frameworks:

• Australian Privacy Act 1988(Cth) — including obligations for handling health information as sensitive information.
• Australian Privacy Principles (APPs)— the 13 principles governing how personal information is collected, used, disclosed, and stored.
• Notifiable Data Breaches (NDB) scheme— mandatory breach reporting under Part IIIC of the Privacy Act.

Organisations using Figments remain responsible for their own compliance with applicable state and territory health records legislation.

9. Contact

For security inquiries, vulnerability reports, or questions about our security practices, contact us at security@figments.com.au.

For privacy-related questions, see our Privacy Policy.