Data Security & Compliance

Swasthy Health Technologies Private Limited

Version 1.2 · Effective 30 September 2026

This document describes how we protect health data. It is written for patients, for the doctors who practise on our Platform, and for partners and regulators who need to assess us.

1. A note on HIPAA, stated plainly

The Health Insurance Portability and Accountability Act (HIPAA) is a law of the United States. It applies to covered entities and their business associates in the US healthcare system.

Swasthy is an Indian healthcare service, regulated by Indian law. HIPAA does not apply to it, and we do not claim to be a HIPAA-covered entity. Any vendor or platform telling an Indian consumer that it is "HIPAA compliant" for an India-only service is describing something with no legal effect here.

What we do claim is this: the HIPAA Security Rule (45 CFR Part 164, Subpart C) is a well-regarded engineering standard for protecting health information, and we have deliberately built to its administrative, physical and technical safeguards, mapped onto our obligations under Indian law. Section 7 sets out that mapping.

If Swasthy AI, Inc. in future serves patients in the United States, or handles protected health information for a US covered entity, HIPAA obligations will attach to that activity and we will execute the Business Associate Agreements required. That is not our position today.

The law that protects you in India is the Digital Personal Data Protection Act, 2023, read with the Information Technology Act, 2000 and its SPDI Rules, and it is enforceable by an Indian regulator against an Indian company. That is stronger protection, for an Indian user, than an inapplicable American statute.

2. The standards we are actually bound by

Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025

Consent, purpose limitation, retention, breach notification, data-principal rights

Information Technology Act, 2000, Section 43A and the SPDI Rules, 2011

Reasonable security practices for sensitive personal data, including health and medical records

IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021

Grievance redressal, log retention, takedown obligations

Telemedicine Practice Guidelines, 2020

Confidentiality of teleconsultation, record retention, practitioner duties

NMC (Registered Medical Practitioner Professional Conduct) Regulations, 2023

Professional confidentiality and record-keeping

ABDM Health Data Management Policy

Consent architecture for health-record exchange, where a user links an ABHA number

EHR Standards for India, 2016

Clinical terminology and record structure

PCI-DSS, through our payment gateway

Cardholder data, handled entirely by the gateway and never by us

The SPDI Rules recognise ISO/IEC 27001 as a reasonable security practice. We have built our controls against that framework and intend to certify. We have not yet completed certification; we will state the date when we have.

3. Technical safeguards

Encryption in transit. All traffic between the apps, our servers and every third-party service uses TLS 1.2 or higher. Certificates are managed and rotated by our infrastructure provider.

Encryption at rest. Database storage, file storage and backups are encrypted at rest using AES-256.

Access control at the data layer. Authorisation is enforced in the database itself through row-level security policies, not only in application code. The practical effect:

• •A patient can read only their own consultations, prescriptions and records.
• •A doctor can open a case's full record and files, and the patient's profile, only once the case is assigned to them. They keep that access afterwards.
• •While a case is waiting for a doctor, every approved doctor on the Platform can see a summary of it, so that they can decide whether to accept it. The summary includes the patient's name, age and sex, the health details in the case and the AI's draft for the case.
• •A doctor cannot open a patient's photos, documents or voice recordings unless they have been assigned a case from that patient. Declining a case does not remove the summary view while the case is still waiting.
• •Administrative tables are readable only by verified administrators, checked by a database function against a registry of administrative accounts.
• •The anonymous application key cannot read patient data at all.

Immutable prescriptions. Once a prescription is signed, the database refuses any change to it, or deletion of it, from the apps or the admin console.

Authentication. Patients and doctors sign in with a one-time password sent to a verified mobile number. Sessions are held in the device's secure storage and expire. Administrators must also be listed in our registry of authorised administrators, and the admin console cannot be used without a code from an authenticator app.

Secrets management. API keys and service credentials are stored as server-side secrets, never embedded in the mobile apps and never in source control. Keys are rotated on a schedule and immediately on any suspected exposure.

Server-side processing. In our apps, creating a consultation, running AI triage, taking payment, accepting a case and signing a prescription run in server functions that check who is calling. The apps save some other changes directly to the database. The patient app saves intake answers this way, and only until the case is sent to doctors. The doctor app changes a case this way only when the case is assigned to that doctor.

Audit logging. We keep an audit log of security-relevant actions. It records actions in the admin console, such as approving doctors, suspending accounts and changing settings. It records when a doctor or administrator opens a full case or patient record, and when a patient's file is opened through our apps or the admin console. It also records case assignment and acceptance, prescription signing, payments, refunds and account-deletion requests. Each entry records who acted and when, and for many actions the IP address and the app or browser used. The log is append-only: nobody, including our engineers, can edit or delete an entry through the application. Entries are kept for at least 3 years.

Monitoring. Errors and crashes in the apps and the admin console are reported to Sentry, which stores them in the European Union (Germany). Reports carry technical details: the device or browser, the app version, the screen in use, and recent app events such as screens opened, network requests and log messages. Performance timings are also collected from a sample of sessions. Sentry is set not to store IP addresses, and we do not send screenshots. We do not yet filter personal or health details out of these reports, so error messages and recent app events can sometimes contain them (see Section 11). Reports are deleted within 90 days.

4. Administrative safeguards

• •Access to production data is limited to named staff whose role requires it, on a least-privilege basis, and is reviewed periodically.
• •Multi-factor authentication is required to use the Swasthy admin console.
• •Every employee and contractor signs a confidentiality undertaking.
• •We are setting up data-protection and security training for staff, to be given on joining and every year.
• •Access is revoked on the day a person's engagement ends.
• •Each service provider handles data on our instructions under its data processing terms with us, which require confidentiality, security and use of the data only for the service it provides to us. Section 7.2 of the Privacy Policy lists them.
• •We are writing an incident response plan, with defined roles and the notification steps in Section 8.
• •We are preparing a record of processing activities, and will review it as the product changes.

5. Physical safeguards

Swasthy operates no data centre of its own. Data is hosted with infrastructure providers that maintain certified physical security (controlled access, environmental controls, redundant power and continuous monitoring) at facilities audited against ISO 27001 and SOC 2.

Staff devices with any access to production systems are encrypted, screen-locked, and centrally wipeable.

6. Data residency

Application data (profiles, consultations, prescriptions and attachments) is stored primarily in India.

Some processing happens outside India. In the United States, this covers most AI processing, push notification delivery, engineering support from our parent company Swasthy AI, Inc., and our website, its waitlist and spam protection on its forms. Sign-in codes are sent by SMS through a provider that may process your mobile number in the United States. Crash and error reports are stored in the European Union (Germany). The PIN code lookup service the apps use does not publish where it processes data. Section 7.2 of the Privacy Policy lists each provider and where it processes data, and Section 8 sets out the legal basis and the safeguards.

Data sent to AI providers is limited to what each task needs. For organising symptoms, triage, draft assessments, draft prescriptions and test suggestions, that is the clinical details of the consultation, including anything the patient typed or said, but not the patient's name, mobile number or payment details. For translation, it is the text being translated. For speech recognition, it is the recording of the patient's voice. People sometimes mention names or other personal details when they type or speak, so we treat everything sent to AI providers as health data. Our AI providers are contractually prohibited from retaining that data beyond the processing window and from training models on it.

Swasthy's own AI improvement programme is separate. It uses de-identified records only from consultations signed on or after 19 October 2026 where both the patient and the doctor who signed the prescription had agreed to it and neither had switched it off. It never uses voice recordings, photos or uploaded documents. Section 6.1 of the Privacy Policy describes it.

7. Mapping to the HIPAA Security Rule

For partners assessing us against a familiar framework:

Access control (§164.312(a))

Row-level security in the database; role-based access; unique user identity — SPDI Rules, reasonable security practices

Audit controls (§164.312(b))

Append-only audit log of administrative and clinical actions and record opens, kept for at least 3 years — IT Rules, 2021, log retention

Integrity (§164.312(c))

Signed prescriptions cannot be changed; the patient app saves intake answers only before a case is sent to doctors — Telemedicine Practice Guidelines, record integrity

Authentication (§164.312(d))

OTP authentication; MFA for the admin console — DPDP Act, reasonable security safeguards

Transmission security (§164.312(e))

TLS 1.2+ everywhere; AES-256 at rest — SPDI Rules

Workforce security and training (§164.308(a)(3),(5))

Least-privilege access and confidentiality undertakings; staff training being set up (Section 4) — DPDP Act, Section 8 accountability

Business associate contracts (§164.308(b))

Each service provider handles data on our instructions under its data processing terms with us — DPDP Rules, processor contract requirement

Incident procedures (§164.308(a)(6))

Data Protection Board informed without delay, with a full report within 72 hours; CERT-In informed within 6 hours — DPDP Act, Section 8(6); CERT-In directions of 28 April 2022

Contingency plan (§164.308(a)(7))

Encrypted daily backups kept for up to 30 days; full restoration not yet tested (Section 11) — SPDI Rules

Minimum necessary (§164.502(b))

Doctors open full records and files only for assigned cases; AI providers receive only what each task needs, without the patient's name, mobile number or payment details — DPDP Act, data minimisation

This mapping is offered as an engineering assurance. It does not make Swasthy a HIPAA-covered entity and confers no rights under US law.

8. Breach notification

If a personal data breach occurs:

1. 1.We contain it and begin investigating immediately.
2. 2.We inform the Data Protection Board of India without delay, and send it a full report within 72 hours of becoming aware of the breach, as Rule 7 of the DPDP Rules, 2025 will require once it takes effect. The clock starts when we become aware, not when the investigation finishes.
3. 3.We notify every affected person without undue delay, describing in plain language what happened, what data was involved, what they should do, and what we are doing.
4. 4.We report cyber security incidents to CERT-In within 6 hours of noticing them, as CERT-In's directions of 28 April 2022 require.
5. 5.We publish a post-incident summary once the investigation closes.

We will not conceal a breach or delay telling you in order to manage reputation.

9. Business continuity

Our database provider takes encrypted daily backups, kept for up to 30 days. Data that is deleted can remain in these backups for up to 30 days. We have not yet tested a full restoration from backup (see Section 11). A prescription PDF you have saved or shared stays usable without the app.

If Swasthy ceases to operate, we will give at least 30 days' notice, make your records available for download, and then securely destroy the data we are not legally required to retain.

10. Responsible disclosure

If you find a security vulnerability, tell us at security@swasthy.ai. We will acknowledge within 48 hours and keep you informed.

We will not pursue legal action against a researcher who acts in good faith, does not access, modify or exfiltrate data beyond what is needed to demonstrate the issue, does not degrade the service, and gives us reasonable time to fix the problem before publishing.

Please do not test against real patient data.

11. Known limitations

We would rather state these than let a reader assume otherwise:

• •We are not yet ISO 27001 certified. We have built to the framework and intend to certify.
• •We have not yet completed an independent third-party penetration test. One is planned before general availability.
• •We have not yet tested a full restoration of our database from backup. One is planned before general availability.
• •We do not yet filter personal or health details out of crash and error reports. Error messages, recent app events and performance data can contain them.
• •Our audit log records when someone opens a full case or patient record, but not when lists of cases or patients are shown. The record-open entry is written by the app, not the server. A file open is logged when it goes through our apps or the admin console, not by the storage service itself.
• •Request logs held by our database provider are kept for up to 30 days. CERT-In's directions require system logs to be kept for 180 days in India, and we plan to meet that. Our own audit log of security-relevant actions is kept in India for at least 3 years, but it does not record every request.
• •AI processing currently occurs partly outside India. This is lawful under the DPDP Act's cross-border framework, and we will localise it if the Government restricts the relevant jurisdiction or if we are designated a Significant Data Fiduciary with localisation obligations.
• •End-to-end encryption is not applied to clinical records, because doctors, our clinical-quality audit and our legal record-keeping obligations require server-side access. Records are encrypted at rest and access-controlled at the database layer.

This section is updated as each item closes.

12. Contact

Security: security@swasthy.ai Data Protection Officer: dpo@swasthy.ai Grievance Officer: grievance@swasthy.ai

Officer names, our registered office, CIN and phone number are published in Contact & Company Information.