LegalSecurity & Compliance Overview
Security & Compliance Overview
1. Our commitment
Being Optimal processes Special Category Health Data (pregnancy timing, body metrics, labs, meal logs, AI conversations that may include health context). We design controls appropriate to that sensitivity: least privilege, encryption in transit, separation of privileged credentials, and honest disclosure of limitations (including erasure caveats in the DSAR procedure).
Security is continuous improvement — not a one-time checklist.
2. Architecture principles (accurate to current design)
| Principle | Implementation (summary) |
|---|---|
| No service role in the frontend host | The Next.js application (Hosting Provider) uses user JWT + anonymous/public keys + Row Level Security. It does not hold or use the database service role key. |
| Privileged operations isolated | Account provisioning, deprovision, share-token lookup, heavy compute, and similar privileged work run on the Cloud Infrastructure Provider (backend), reached via a secured gateway. Service-role use is confined to that privileged path. |
| RLS per authenticated identity | Application tables are protected with row-level security evaluated in the context of the user’s Authentication Provider JWT (and related claims), so users can access their own data under policy. |
| Least privilege | Secrets and admin credentials are not shipped to browsers; operational keys live in server/backend secret stores. |
| TLS | Public endpoints are served over HTTPS/TLS. |
| Encryption at rest | Databases and object storage rely on cloud provider-managed encryption at rest (provider defaults / configuration). |
| Privacy-forward product choices | No third-party ad networks, session-replay SaaS, or third-party analytics pixels in the product surface described in the Sub-processor List “absent” section. |
Named vendors for each role appear only in Sub Processor List.
3. Active controls (implemented today)
| Control | Description |
|---|---|
| Authentication & sessions | Managed by the Authentication Provider; signed-in app use requires valid session |
| Authorization / RLS | Database Provider RLS policies bound to authenticated user identity |
| Privileged backend isolation | Service role and admin APIs only on Cloud Infrastructure Provider backend; frontend host does not embed service role |
| Gateway / edge | Privileged backend traffic may pass through CDN / Edge Network Provider with shared-secret or equivalent gateway controls |
| Encryption in transit | TLS for public site, APIs, and dashboard delivery |
| Encryption at rest | Provider-managed encryption for primary database and object storage |
| Secret hygiene | Server-side environment secrets; not bundled into client JavaScript |
| Webhook authenticity | Authentication Provider lifecycle webhooks verified per provider signing model before provisioning/deprovision runs |
| Rate limiting | Applied on sensitive routes (auth-adjacent, AI, exports, geo) as configured |
| AI safety filters | Pre-checks and disclaimer/red-flag handling for crisis or unsafe medical overclaim in the AI assistant (product safety layer — not a medical system) |
| Community SSO scope | Community SSO designed to pass identity needed for forum login; sensitive gestational fields gated off from SSO payload |
| Origin-checked postMessage | Signed-in iframe shell uses origin checks when exchanging auth with the dashboard document |
4. Data classes and handling notes
| Data class | Examples | Handling notes |
|---|---|---|
| Account identity | Email, auth subject id | Authentication Provider + app profile linkage |
| Special Category Health Data | LMP/EDD, DOB, ethnicity (if collected), weight, blood markers, symptoms, meal logs | Stored under RLS; may appear in AI prompts if you use the assistant |
| AI content | Conversation bodies | Persisted in our database; also processed by AI Model Providers (international transfer) |
| Location | Lat/lng (transient), country/region | Coordinates may be transmitted to Reverse-Geocoding Provider; not stored as GPS by Being Optimal |
| Payment | Subscription status when billing is live | Full card numbers handled by Billing Provider only (when live) — not stored by Being Optimal |
| Community UGC | Posts, uploads | Community Platform Provider; anonymize-on-delete caveats apply |
5. In progress / aspirational (not asserted as complete)
| Item | Status |
|---|---|
| Certified deletion receipts / fully atomic deprovision | Not claimed — automated deprovision exists; known orphan tables and non-atomic steps are documented; remediation planned |
| Provider-side AI deletion APIs on erasure | Not implemented — external model copies follow provider DPAs |
| Hard-delete of all community content | Not claimed — anonymization is the default path |
| Versioned legal-acceptance ledger | Intended — not fully wired at every sign-up surface yet |
| SOC 2 Type I / Type II | Not claimed unless we publish a separate report with dates |
| ISO 27001 | Not claimed |
| HIPAA covered entity / BAA program | Not claimed — Being Optimal is a consumer wellness/nutrition product, not a healthcare provider portal |
| Formal penetration test report public summary | Optional / future — may be shared under NDA case-by-case |
| Bug bounty program | Not default — see Vulnerability Disclosure Policy |
We will not market “bank-grade,” “military-grade,” “HIPAA compliant,” “SOC 2 certified,” or similar language unless and until the underlying program is true and counsel-approved.
6. Incident response
| Step | Practice |
|---|---|
| Report | [email protected] (security) or [email protected] (if unsure) |
| Triage | Assess severity, contain, preserve evidence as appropriate |
| Notify | Notify affected users and regulators as required by law and our Privacy Policy |
| Remediate | Fix root cause; improve controls |
| Researcher reports | Follow Vulnerability Disclosure Policy |
Personal Data breach notification timelines (e.g., GDPR 72-hour supervisory authority notice where applicable) are operationalized by the operator and counsel — this page does not replace a full IR playbook.
7. Vulnerability disclosure
Good-faith security research is welcome under our Vulnerability Disclosure Policy. Primary contact: [email protected]. We also publish /.well-known/security.txt when live.
8. Compliance programs (labels only)
| Program | Our statement |
|---|---|
| GDPR / UK GDPR / CCPA / APAC privacy laws | Product and legal suite designed to support compliance; regional annexes ON — counsel must validate for launch markets |
| Art. 9 health data | Explicit-consent posture in Privacy Policy; AI first-run consent is a recommended follow-on control |
| Security certifications | None publicly claimed in this draft |
| Payment security | When Billing Provider is live, card data remains with that provider’s PCI scope |
9. Your responsibilities
- Keep your Authentication Provider credentials secure; enable available MFA if offered.
- Do not share account access or export files containing health data over insecure channels.
- Report suspected account compromise promptly to [email protected] / [email protected].
- Remember: nutrition scores and AI outputs are informational — not medical advice (Medical Disclaimer).