Patient data,
private healthtech, multiple regulators.

The DPDP Act 2023 does not formally categorise "sensitive personal data" the way the older draft Personal Data Protection Bill did — every category of personal data is treated under the same Data Fiduciary regime. In practice though, health data carries operational consequences any reasonable Data Fiduciary will treat as elevated risk: the consequences of breach are higher (medical-record exposure, stigma, insurance impact), most healthtech platforms cross the Significant Data Fiduciary thresholds quickly (volume, sensitivity, risk to Data Principal rights), and the DPDP Rules 2025 introduce additional procedural requirements for high-volume or high-impact Fiduciaries. We scope around that elevated risk: tighter consent capture, stricter retention timelines, dedicated breach-notification runbook, and (where the platform is likely classified Significant Data Fiduciary) the DPIA, DPO appointment and independent data audit obligations.

Integration with the Ayushman Bharat Digital Mission — ABHA health ID, Healthcare Professionals Registry, Health Facility Registry, Personal Health Records and the Health Information Exchange / Consent Manager — is voluntary in 2026 for most private healthtech in India. It is not voluntary if you are competing for government tenders, integrating with public-health programmes, or building a product whose value depends on cross-platform record portability. ABDM operates under the National Health Authority's technical and security guidelines, which prescribe authentication (FIDO2 / OAuth2 / OIDC patterns), encryption, consent capture via the Consent Manager, audit logging and breach-notification obligations beyond those in the DPDP Act. AxVeil scopes the NHA guidelines explicitly when an ABDM endpoint is in scope; otherwise we focus on DPDP, the buyer-side overlay (SOC 2 / HIPAA equivalent for US-facing platforms) and the foundational application security work.

The HIPAA Security Rule (45 CFR Part 164 Subpart C) does not have territorial limits — if your platform processes Protected Health Information of US residents on behalf of a covered entity (a hospital, payer, clinical lab, employer health plan), you become a Business Associate and the Security Rule applies regardless of where you are headquartered. The Office for Civil Rights at HHS settles enforcement actions with non-US entities periodically. AxVeil's healthtech-India engagements include an optional HIPAA-equivalent overlay: Security Risk Analysis under §164.308(a)(1)(ii)(A), administrative / physical / technical safeguards mapping under §164.308 / §164.310 / §164.312, Business Associate Agreement support, and where applicable a SOC 2 Type 2 evidence pack tuned for the Trust Services Criteria most US payers ask about (Security CC1–CC9, Availability A1, Confidentiality C1).

Both stores publish health-data policies that apply on top of the platform's general developer terms. Apple's HealthKit and HealthKit-adjacent policy (App Store Review Guidelines section 5.1.3 and HealthKit framework requirements) covers end-to-end encryption of health data, prohibition on third-party advertising of health data, prohibition on selling health data without explicit user consent, and disclosure obligations in the privacy nutrition label. Google Play's Health Apps policy and Health Connect API requirements track similarly. Mental-health apps additionally face the FTC's ongoing scrutiny of consumer-facing health-data sharing — BetterHelp and GoodRx settlements set the bar. AxVeil reviews the data flow against both store policies and the relevant regulator expectations during the engagement and produces a pre-submission compliance memo when the next store review cycle is imminent.

The two regimes overlap on the technical control set roughly 70-80%. Encryption, access control, audit logging, vulnerability management, change management, incident response — all common. The structural differences are governance (Indian DPDP requires a published grievance officer; SOC 2 expects a documented vendor-management programme) and the cross-border transfer regime. We map every test case to both source standards — DPDP Act 2023 section reference and AICPA Trust Services Criteria reference — so a single evidence pack drops cleanly into both submissions. For platforms that also process US PHI, the HIPAA Security Rule overlay slots into the same evidence base (HIPAA §164.308 maps onto DPDP retention / governance, §164.310 onto DPDP physical safeguards, §164.312 onto DPDP technical safeguards). One engagement, three audiences.

AxVeil is not on the NHA's ABDM Sandbox security-auditor list, and AxVeil is not on the CERT-In Information Security Auditor empanelment list either. For ABDM Sandbox certification security audits — where the NHA requires an empanelled auditor on the report — AxVeil delivers the technical engagement under sub-contract to an empanelled partner who signs the certification submission. For everything else — DPDP advisory, foundational application security, SOC 2 readiness, HIPAA-equivalent overlay, platform-buyer security questionnaire response — AxVeil contracts directly. The buyer is told up front which contracting path the engagement takes.