Indian teams building software for US healthcare clients hit the same confusion early: the client says the system must be HIPAA compliant, and there is no exam to sit, no certificate to purchase and no body that issues approval. HIPAA is a law with requirements, not a certification scheme, and the vendors selling HIPAA certificates are selling their own assessment rather than anything official. What your client actually needs is evidence that specific obligations are met.
The first thing that matters is your legal status. If you handle protected health information on behalf of a US healthcare entity, you are a business associate, and that relationship requires a signed Business Associate Agreement. That document is not a formality - it makes you directly liable under the law, and it will specify breach notification timelines you must be able to meet. Read it properly before signing, because engineering commitments are buried in it.
Then the technical safeguards, which is where the engineering work sits. Access control, meaning unique identities per person and permissions granted by role rather than convenience. Audit controls, meaning a record of who accessed which patient's record and when, kept in a form nobody can quietly edit. Integrity controls that detect improper alteration. Transmission security, meaning encryption in transit as an absolute. Encryption at rest is technically an addressable specification rather than a strict requirement, but treat it as required - every client will expect it and defending the alternative is not worth the conversation.
The requirement Indian teams underestimate most is the minimum necessary principle: access limited to the least information needed for the task. In practice this rules out the common development pattern of giving every engineer read access to production data for debugging. You need a workflow where production access is temporary, approved, logged and rare - and where day-to-day development happens against de-identified or synthetic data. Retrofitting that after the fact is disruptive, so decide it early.
On data residency, a point that surprises people: HIPAA itself does not prohibit processing PHI outside the United States. Many US healthcare clients prohibit it contractually, which is a different constraint, and one you must establish before designing anything. If offshore processing is permitted, your obligations are the same as a domestic vendor's. If it is not, the architecture changes fundamentally and you need to know on day one rather than during a security review.
Practically, the things a US healthcare buyer will ask you to produce are: the signed BAA, a written risk assessment, your access control and audit logging design, encryption details, your incident response plan with notification timelines, evidence of workforce security training, and a list of your own subprocessors - cloud providers, monitoring tools, anything touching the data. Assemble that pack once and every subsequent client conversation gets dramatically shorter.
If you are also selling into India, note that these obligations sit alongside the DPDP regime rather than replacing it, and health data is treated as particularly sensitive under both. Designing to the stricter of the two requirements is less work than maintaining two postures, and it is what we would recommend to any team serving both markets.
