How we protect your patients' data
MyDosha handles special-category health data on behalf of Ayurvedic practitioners. We treat that as a responsibility, not a checkbox. This page sets out — in plain language — where your data lives, who can reach it, and what happens if something goes wrong.
Where your data lives
All practitioner and patient records are stored in the European Union, in a managed PostgreSQL database (Supabase, AWS eu-central-1, Frankfurt). MyDosha is operated from the EU; the operating entity is European. We do not sell data, and we do not show advertising.
✓ EU data residency
Primary database and file storage hosted in the European Union.
✓ Encrypted in transit
HTTPS/TLS everywhere; insecure requests are upgraded. No plaintext endpoints.
✓ Encrypted at rest
Database, file storage, and backups encrypted at rest (AES-256) by the platform.
✓ Daily backups
Automated, validated daily backups with periodic restore drills.
Who can reach the data
- Two-factor sign-in. The practitioner portal is protected by a password plus a one-time email code. Codes expire quickly and lock out after repeated wrong attempts.
- Per-clinic isolation. Each clinic's records are partitioned by a clinic identifier and every data request is scoped to the signed-in clinic. One clinic cannot read or write another's patients, appointments, messages, documents, invoices, or AI-assistant context. This isolation is covered by automated regression tests and a static check that run on every change.
- Least privilege. Database credentials never reach the browser. The front end talks only to our API, which enforces access on the server side.
- Audit trail. Security-relevant actions are written to an append-only audit log.
- Patient access. Patients reach their own dossier and journal through signed, expiring magic links tied to their email — no shared passwords, no account to breach.
- Messaging stays in the portal. Two-way messages between a practitioner and a patient live behind that same magic-link portal — not in personal email threads or WhatsApp chats, where special-category health data has no business sitting. Threads are scoped to the clinic, so one practice can never read another's.
How the AI assistants handle your data
- Scoped to your clinic only. The intake, dossier and practitioner assistants are given only the records belonging to the signed-in clinic. The data is filtered to your clinic on the server before it ever reaches the model — another clinic's records are never placed in the assistant's context.
- The assistant cannot fetch data on its own. It has no database access and no ability to call other systems; it can only work with the clinic-scoped information we hand it for that one request. So it cannot be instructed to "go and look up" anyone else's records.
- Resilient to prompt manipulation. Because the clinic boundary is enforced in our database layer beneath the AI — not by the AI's own instructions — manipulating the assistant's wording cannot make it cross into another clinic's data. We additionally screen intake text and AI output to keep the assistant within its intended, non-diagnostic scope.
- Not used for training. Intake text is processed in session to produce the response and is not retained or used to train models (Anthropic API terms).
Our subprocessors
We rely on a small set of established providers. Each processes only what its function requires, under a data-processing agreement. International transfers, where they occur, are covered by Standard Contractual Clauses.
| Provider | Purpose | Data it touches |
|---|---|---|
| Supabase | Database & file storage (EU) | Practitioner & patient records, uploaded documents |
| Vercel | Application hosting / delivery | Request traffic; no database stored here |
| Resend | Transactional email | Recipient address & message content (login codes, notifications) |
| Anthropic | AI dossier & intake assistance | Intake text submitted for processing — not used to train models |
| Cloudflare | Bot protection (sign-up) | Challenge token only; no patient data |
| Stripe | Subscription billing | Practitioner billing details — never patient data |
Backups & recovery
The full database is backed up automatically every day. Each backup is validated for completeness (table coverage, row-count floors, referential integrity) so a half-failed dump is caught rather than silently kept. We periodically restore a backup into a throwaway environment to confirm it actually works — an untested backup is not a backup.
Your rights & our commitments
- Data Processing Agreement. A signed DPA is available to every paying clinic, with EU Standard Contractual Clauses where relevant.
- Access, export, deletion. You can request a copy of, or the deletion of, your clinic's data at any time. Deletions of patient and clinic records run through audited, safeguarded routines.
- Breach notification. In the event of a personal-data breach, we will notify affected customers without undue delay, consistent with GDPR's 72-hour standard.
- GDPR Article 9. Health data is processed under the appropriate legal basis; see our privacy policy for detail.
Reporting a vulnerability
If you believe you have found a security issue, please email security@mydosha.org. We aim to acknowledge reports within 48 hours and welcome responsible disclosure. Our machine-readable policy is published at /.well-known/security.txt.
This page describes our security posture in good faith and may evolve as the product does. It is informational and does not by itself form part of any contract; the binding terms are in your service agreement and DPA.
Last updated: 19 June 2026