HIPAA compliant app development means building an app that handles protected health information (PHI) in line with the HIPAA Privacy, Security and Breach Notification Rules: the right people see only the data they need, every access is logged, data is encrypted, hosting runs under a business associate agreement (BAA), and there are written policies and a tested plan for when things go wrong. There is no official HIPAA certification for apps; compliance is something you do and can show, not a badge you buy.
This checklist is for founders and product teams building for the US market, including teams in India or elsewhere building for US clients. It covers whether HIPAA applies at all, the safeguards mapped to app features, a cloud BAA reality check, offshore team rules, and a table of equivalent laws in the UK, UAE and India.
Does your app need to be HIPAA compliant?
HIPAA applies to covered entities (health plans, clearinghouses and most healthcare providers that bill electronically) and their business associates (vendors that create, receive, store or transmit PHI on their behalf). Your app is in scope if:
- A hospital, clinic, health plan or other covered entity uses it to handle PHI, or
- You provide it to a covered entity and handle PHI for them, which makes you a business associate.
A consumer wellness app that users download themselves, with no covered entity involved, is usually not under HIPAA. It is not off the hook, though. The FTC's Health Breach Notification Rule, amended in 2024, reaches health apps and connected devices outside HIPAA and requires breach notices to users and the FTC. State privacy laws may apply too.
| Situation | HIPAA applies? | What else applies |
|---|---|---|
| Telehealth app used by a US clinic | Yes, as business associate | State telehealth and privacy laws |
| Patient portal for a hospital | Yes | ONC information blocking rules |
| Direct-to-consumer fitness tracker | Usually no | FTC Health Breach Notification Rule, state laws |
| Employer wellness app via a health plan | Often yes | Plan's BAA terms |
| Clinical trial app for a sponsor | Depends | FDA rules, GDPR if EU subjects |
The "HIPAA certification" myth
There is no government HIPAA certification for software or companies. HHS's own Security Rule FAQ says evaluations can be done internally or by an outside firm offering "certification" services, but that such a certification does not stop HHS from later finding a violation. Third-party audits such as SOC 2 or HITRUST are useful evidence, not a legal shield.
HIPAA compliant app development checklist
The Security Rule groups safeguards into administrative, physical and technical. Here is how each maps to app work.
Administrative safeguards
- Security risk analysis. Document where PHI lives, threats, likelihood and controls. Repeat after major changes.
- Risk management plan. Track each identified risk to a fix or an accepted, documented decision.
- Named security and privacy officers. Someone owns compliance by name.
- Workforce training. Developers, support and operations staff trained on PHI handling, with records kept.
- Access management policy. Who gets production access, how it is approved and how it is removed.
- Incident response and contingency plans. Written, with a tested backup restore and a breach decision process.
- BAAs. Signed with every vendor that touches PHI: cloud, email, SMS, analytics, support tools, developers.
Physical safeguards
- Data centre controls. Covered by your cloud provider under the BAA.
- Device controls. Laptops encrypted, screen locks enforced, no PHI on personal devices, remote wipe for mobile devices used by staff.
Technical safeguards
| Requirement | What it means in the app |
|---|---|
| Unique user identification | Individual accounts; no shared logins for staff |
| Authentication | Strong passwords, MFA for clinicians and admins |
| Access control | Role-based permissions, minimum necessary data per role |
| Automatic logoff | Session timeouts on web and mobile |
| Encryption | TLS 1.2+ in transit; encryption at rest for databases, files, backups |
| Audit controls | Log every PHI read, create, update, delete and export, with user and time |
| Integrity | Prevent and detect unauthorised changes; checksums on files |
| Emergency access | Break-glass process with extra logging |
App-specific items teams miss
- Push notifications and lock screens. Never put PHI in a push message body. "You have a new message" is fine; a lab result is not.
- Mobile storage. Keep PHI off the device where possible; if cached, use encrypted storage and clear on logout.
- Logs and crash reports. Scrub PHI from application logs, crash reports and analytics events.
- Third-party SDKs. Analytics and advertising SDKs that receive PHI need a BAA, which most will not sign. Remove them from PHI screens.
- Email and SMS. Use providers that sign BAAs, and limit content to what is necessary.
- AI features. Only send PHI to model providers under a BAA and with data retention settings you have confirmed.
Cloud BAA reality check
All three major clouds offer BAAs, but only for listed services, and you still have to configure them securely.
| Platform | BAA | What to check |
|---|---|---|
| AWS | Standard BAA accepted through AWS Artifact | Use only HIPAA eligible services for PHI |
| Microsoft Azure | BAA included in Microsoft's contract terms for in-scope services | Confirm each service is in scope |
| Google Cloud | BAA available for covered products | Several Firebase-branded services have sat outside the covered list; check before use |
| Backend-as-a-service tools | Varies; many offer BAAs only on higher plans | Plan cost and confirm in writing |
A BAA makes your cloud provider responsible for its part. Encryption settings, access control, logging and patching on top remain yours. Our AWS and cloud and DevOps in healthcare teams set these up as code so they can be audited.
Breach notification in brief
If unsecured PHI is breached, HIPAA requires notice to affected individuals without unreasonable delay and within 60 days of discovery. Breaches affecting 500 or more people also require notice to HHS and, in many cases, the media; smaller breaches are reported to HHS annually. Encryption that meets HHS guidance can mean a lost device is not a reportable breach, which is one more reason to encrypt everything.
Civil penalties are tiered by level of culpability and adjusted for inflation each year, with annual caps above $2 million per violated provision. Lessons from large incidents are covered in our post on hospital ransomware protection.
Privacy Rule features to build in
The Security Rule gets most of the attention, but the Privacy Rule shapes features too:
- Minimum necessary. Show each role only the PHI it needs. A scheduler does not need lab results.
- Patient right of access. Patients can request copies of their records, generally within 30 days. A self-service export or portal download makes this easy.
- Amendment requests. Patients can ask for corrections; track the request and the decision.
- Accounting of disclosures. Be able to report certain disclosures of a patient's PHI outside treatment, payment and operations.
- Marketing and sale limits. Using PHI for marketing generally needs authorisation. Keep marketing tools away from PHI.
What is changing: the proposed Security Rule update
HHS published a proposed overhaul of the Security Rule in January 2025, with stricter expectations on encryption, MFA, asset inventories and risk analysis. It is not final: according to Fierce Healthcare, the federal regulatory agenda now pushes final action to at least July 2027. The current rule stays in force. Building to the proposal's stricter controls now (MFA everywhere, encryption everywhere, a written asset inventory) costs little and avoids rework.
Offshore and outsourced development teams
Many US health tech companies build with teams in India, Eastern Europe or Latin America. HIPAA does not forbid this, but it changes the controls.
- Keep developers away from production PHI. Use synthetic or de-identified data in development and testing.
- If production access is needed, sign a BAA (or subcontractor BAA) with the development company, grant access through VPN or bastion hosts with MFA, and log every session.
- Data stays in the US region. Offshore staff access it remotely; it is not copied to local machines.
- Training and background checks for anyone with access, with records available on request.
- Contract terms. Breach notice duties, return or destruction of data at contract end, and the right to audit.
A dedicated team model works well here, because the same people stay on the product and can be trained and audited once.
HIPAA equivalents in the UK, UAE and India
If your app also serves other markets, these are the closest equivalents.
| Market | Main rules | Notes |
|---|---|---|
| UK | UK GDPR, Data Protection Act 2018, NHS DSPT, DTAC | Health data is special category data; NHS buyers assess suppliers through DTAC |
| EU | GDPR | Data processing agreements instead of BAAs; transfer rules for non-EU hosting |
| UAE | Federal Law No. 2 of 2019 on health ICT, ADHICS (Abu Dhabi), DHA policies (Dubai) | Health data generally must stay in the UAE |
| India | DPDP Act 2023, DPDP Rules 2025, ABDM policies | Most DPDP duties apply from around May 2027; consent and breach duties are central |
Residency rules matter for architecture; see health data residency in India and the UAE.
How Algon approaches HIPAA work
Algon is a Kochi-based team that builds healthcare software for clients in India, the UAE and the USA, with HIPAA-aligned design for US work. In practice that means roles and audit logging designed before screens, PHI kept in BAA-covered cloud services in the client's region, synthetic data for development, and named owners for access reviews and incident response. We do not claim certifications; we show how each safeguard is met.
Conclusion
HIPAA compliant app development is mostly disciplined engineering: know whether HIPAA applies, map each safeguard to a feature, sign BAAs with every vendor that touches PHI, keep PHI out of logs, notifications and SDKs, and document what you did. There is no certificate that proves it; there is evidence that shows it.
Use the checklist above at design time, not after launch. For the budget side, see our healthcare app development cost guide.
Frequently asked questions
How do I make my app HIPAA compliant?
Do a documented risk analysis, design role-based access, MFA, encryption and audit logging into the app, host PHI only on BAA-covered cloud services, sign BAAs with every vendor that touches PHI, keep PHI out of logs, notifications and analytics, and maintain written policies, training and an incident response plan.
Is there an official HIPAA certification for apps?
No. HHS does not certify apps or companies. Third-party assessments such as SOC 2 or HITRUST can show good practice, but HHS's guidance is clear that an outside certification does not prevent it from finding a violation later.
Is AWS HIPAA compliant?
AWS offers a business associate addendum through AWS Artifact and lists the services eligible for PHI. Using those services under the BAA is necessary, but you are still responsible for configuring encryption, access, logging and patching correctly.
Is Firebase HIPAA compliant?
Only some Google Cloud products are covered by Google's BAA, and several Firebase-branded services have sat outside the covered list. Check Google's current HIPAA covered products page and avoid putting PHI into any service that is not listed.
What is a Business Associate Agreement (BAA)?
A BAA is a contract required by HIPAA between a covered entity and a vendor that handles PHI on its behalf, or between a business associate and its subcontractors. It sets out permitted uses, safeguards, breach reporting and data return or destruction.
Does my health app need to be HIPAA compliant at all?
Only if a covered entity or business associate is involved, for example a clinic using your app with its patients. A direct-to-consumer app usually falls outside HIPAA but may be covered by the FTC Health Breach Notification Rule and state privacy laws.
