Security Policy
1. Purpose and scope
This policy describes how Coach Aandi protects customer data, the controls in place, and what happens when something goes wrong. It applies to the Coach Aandi platform (web app, API, supporting infrastructure) and any data we collect from parents, children, school customers, and practitioner customers.
Coach Aandi is operated by Brio Pty Ltd (for B2B customers) and Meet Aandi (for direct family customers). Both entities follow the same controls.
2. Data classification
We classify the data we hold into three tiers:
Tier 1 (highly sensitive): Child first names and learning profiles, parent or practitioner email addresses, mood data, lesson responses, child voice and text input, uploaded files from contributors.
Tier 2 (operational): Admin allow-list emails, authentication credentials (hashed), lesson generation prompts and outputs (transient), email notification content.
Tier 3 (public): Marketing site content, published expert profiles, pricing pages.
3. Access controls
Customer data access: Each authenticated user can only access their own family’s or practice’s data. This is enforced at the database layer via Supabase Row Level Security (RLS) policies, not at the application layer. Children do not have their own accounts.
Admin access: Administrative functions require an authenticated user whose email appears in the admin_users allow-list table. The allow-list is small and deliberate; adding a new admin is a manual database insert, never an automated grant.
Service-role access: A separate service-role key has elevated database access for system operations. This key is held only in environment variables on Vercel and a single local development machine. It is never exposed to the browser.
Token-gated public access: Expert contributors upload content via single-use token links. The upload endpoint accepts files only when the token matches an active contributor record.
4. Authentication and multi-factor authentication
Customer authentication: Supabase Auth handles all authentication. Password hashing follows industry standard (bcrypt-equivalent). Email verification is required at signup. Password reset flows use signed, time-limited links.
Admin MFA: All accounts in the admin allow-list are required to enroll TOTP-based multi-factor authentication before accessing administrative routes. Enforcement is server-side at the middleware layer; admin routes require a session Authenticator Assurance Level of 2. Compatible with Google Authenticator, 1Password, Authy, Bitwarden, and iCloud Keychain TOTP.
Non-admin user surfaces (parent dashboard, child lesson view, mood selector) do not require MFA by design. This protects the family user experience from authentication friction that is not warranted by the data sensitivity of the family-facing surface.
5. Encryption
In transit: All public endpoints require TLS 1.2 or higher. HTTP requests are redirected to HTTPS automatically. HSTS is enabled on the production domain.
At rest: Supabase encrypts all data at rest using AES-256. File uploads inherit the same at-rest encryption.
Secrets management: API keys, service-role credentials, and third-party tokens are held in Vercel environment variables and a local development environment file. Secrets are never committed to source control.
6. Third-party vendors and data flows
We name every vendor that processes customer data, what we send them, whether they retain it, and where they process it.
| Vendor | Purpose | Data sent | Retains? | Region |
|---|---|---|---|---|
| Supabase | Auth, DB, storage | All customer-facing data | Yes (primary) | Sydney AU |
| Vercel | Hosting, edge | Request metadata, logs | Yes (short) | Sydney AU |
| Cerebras | LLM inference | Lesson prompts (no surnames, no clinical data) | No | USA |
| Runware | Image generation | Prompts only (no PII) | Logs only | EU/Global |
| SendGrid | Transactional email | Email addresses, body | Yes (logs) | USA |
Australian data residency: All persistent customer data lives in Sydney AU. Data leaves Australia only for transient AI inference (no PII content) and transactional email delivery (email address only).
7. Backup and recovery
Supabase performs daily automatic backups of the entire database. Point-in-time recovery is available for the configured retention window. File uploads in our storage bucket are backed up as part of Supabase storage replication.
We have not yet performed a full disaster-recovery drill. This is acknowledged and tracked as a future control. The platform is in early production.
8. Incident response
Severity levels run from P0 (data breach, unauthorised access, child safety incident) through P3 (bug reports, individual account problems). Response steps: identify and contain, assess impact, notify (internal within 1 hour, customer-facing within 24 hours for P0 and P1), remediate, post-incident review.
Coach Aandi is operated by a two-person team. Gerard owns technical response, Belinda owns customer communications. Out-of-hours response is best-effort.
9. Notifiable data breach commitment
We comply with the Australian Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth), Part IIIC. If we become aware of an eligible data breach, we will conduct assessment within 30 days, notify the OAIC as soon as practicable, and notify each affected individual.
10. Honest limitations
What this policy does not claim:
- We are not ISO 27001 certified.
- We are not SOC 2 audited.
- We have not undergone an IRAP assessment.
- We have not performed a disaster-recovery drill.
- We do not perform background checks on personnel.
- We do not have a 24/7 on-call rotation; we are a two-person team operating best-effort.
These are honest gaps. The platform is in early production. As customers and regulatory exposure increase, the controls will be matured. This policy will be updated to reflect that maturation.
11. Review cadence
Reviewed annually at minimum. Reviewed earlier on any incident response that exposed a gap, change of vendor for any data-handling system, change in regulatory environment, or addition of a new admin or data category. Current version 1.0, written 17 June 2026. Next scheduled review: 17 June 2027.
12. Contact
Privacy and security questions, and OAIC liaison: gerard.blokdyk@theartofservice.com.
Our privacy policy is at /privacy.