Security

Everything that stores health data runs in Indian regions. No production database, object store or backup sits outside the country.

Database

Managed Postgres — Mumbai

Document storage

Object storage — Mumbai

Web application

Mumbai (bom1)

Processing worker

Bangalore (blr1)

Backups

Encrypted, Indian region

Every clinic is a separate tenant, and cross-tenant access is the failure mode we design hardest against.

• Row-level security is enabled on every table holding customer data; nothing is readable by default.
• Every read and write is scoped to the caller’s organisation at the application layer as well.
• Lookups by record id are scoped the same way — an id is never treated as a credential. A record belonging to another organisation returns “not found”, not “forbidden”, because “forbidden” would confirm the id exists.
• Signed URLs for original scans are short-lived, and object keys are stored in the database rather than URLs, so a database read never yields a usable link on its own.

• Authentication is enforced at the edge before a request reaches any page or API route, and re-checked server-side against the user record — the edge check alone is never trusted to authorise anything.
• Roles carry capabilities. Administrative surfaces — clinic settings, team management, data export — are restricted to the roles that need them and checked on both sides.
• Signing up with the identity provider is not enough to reach any data. An administrator must provision the account into an organisation before it can see anything at all.
• Patients have no account by design. A patient reaches their own record through a one-time code sent to their registered mobile number, or through the link printed on the document itself. Both are rate limited.
• Administrative access to servers is by SSH key only, restricted by source IP. Passwords are not accepted.

• TLS on every external connection — the web application, the API, the database and object storage.
• Data at rest is encrypted by the managed database and object store; backups are encrypted independently before they leave the host.
• Document storage buckets are private with versioning enabled. There is no public read path to a scan.
• Credentials live in the environment, never in the repository. Service-role keys are held only by server-side components and are never exposed to a browser.

The processing worker and the web application do not talk to each other over the network at all. Work is handed over as rows in the database, which the worker picks up.

• No inbound network path exists from the web tier to the worker, so there is no such path to secure or to attack.
• The only inbound listener on the processing host is the callback endpoint used for health-network integration, terminated behind a reverse proxy on a fixed reserved IP address.
• Public endpoints — the free decode tool, medicine search, patient sign-in codes — are individually rate limited by IP address.
• The webhook endpoint that receives email delivery events is authenticated by signature, not by session.

Access to and modification of a clinical record is recorded — who, what and when — and the trail is retained for the life of the record. Corrections made during human review are kept as corrections rather than overwriting the original reading, so what the machine proposed and what a person confirmed remain separately visible.

• Development and production are separate environments with separate credentials. Development is never pointed at production data.
• Schema changes ship as reviewed, version-controlled migrations.
• Dependencies are pinned and updated deliberately.
• The model is constrained to a verified directory of Indian medicines rather than free generation, so it is not able to produce a medicine name that does not exist. Low-confidence fields are withheld from the record and routed to a human.

MyParcha is early. These are real gaps, and we would rather you learn about them here than discover them yourself.

• No independent security audit yet. A security audit by a CERT-In empanelled auditor is required before going live on the national health network, and we have not completed one. It is planned before any production integration.
• No third-party penetration test yet. Planned alongside that audit.
• Machine reading still leaves India. Described above and in the privacy policy. This is the highest-priority item on this list.
• No formal certification. We hold no ISO 27001, SOC 2 or equivalent certification, and we do not imply one anywhere.
• Liability and indemnity insurance is not yet in force. It is planned to be in place before any live testing involving real patients.

If you have found a security problem, please tell us at [email protected] before disclosing it publicly. Include enough detail to reproduce it. We will acknowledge your report, keep you updated while we fix it, and credit you if you would like to be credited.

Please do not access, modify or delete data belonging to anyone else while investigating, and please do not run tests that could degrade the service for a clinic in the middle of seeing patients. We will not pursue action against anyone who reports in good faith within those bounds.