Building anything that touches health data? Here's whether HIPAA applies to you, what it requires, and what you need in place before you sign your first healthcare customer.
"Do we need to be HIPAA compliant?" is one of the most common questions in healthtech — and the answer is more nuanced than most founders expect. Some companies that assume they need HIPAA compliance don't. Others that assume they don't absolutely do. Getting it wrong in either direction creates real problems.
This guide covers who HIPAA actually applies to, what it requires, and what you need to have in place before you handle your first piece of health data in a regulated context.
HIPAA applies to two categories of entities: Covered Entities and Business Associates.
Covered Entities are:
Business Associates are companies that perform functions or services for Covered Entities that involve access to Protected Health Information (PHI). This is where most healthtech startups land.
If you're building:
...you are almost certainly a Business Associate the moment a Covered Entity uses your product and PHI flows through it.
What HIPAA does NOT automatically cover:
A consumer wellness app where users voluntarily track their own health information — like a step counter or mood journal — is not automatically covered by HIPAA. If that app has no relationship with a healthcare provider and doesn't use the data for clinical purposes, it may fall outside HIPAA's scope.
However, this doesn't mean you're operating in a regulatory vacuum. The FTC's Health Breach Notification Rule applies to consumer health apps and requires notification to the FTC and affected consumers in the event of a breach. And consumer health data is increasingly covered by state privacy laws (California, Washington's My Health MY Data Act).
The test: do you receive PHI from, or on behalf of, a Covered Entity? If yes, you're a Business Associate and HIPAA applies.
Protected Health Information is health information that is both (a) individually identifiable and (b) held or transmitted by a Covered Entity or Business Associate.
"Individually identifiable" means it can be linked to a specific person. HIPAA specifies 18 categories of identifiers that, when combined with health information, make that information PHI:
Note that IP addresses and email addresses are on this list. A user's health condition combined with their email address is PHI. A patient record with their IP address in the access log is PHI. The list is broader than most founders assume.
HIPAA provides a path to escape its requirements: de-identified data. Data from which all 18 identifiers have been removed is no longer considered PHI and can be used, shared, and analysed without HIPAA restrictions.
This is the HIPAA Safe Harbor standard. If you remove all 18 identifiers and have no reason to believe the remaining information could identify an individual, the data is no longer PHI.
In practice, de-identification is harder than it sounds:
De-identified data is genuinely useful — it can be used for research, analytics, and product improvement without HIPAA constraints. But achieving proper Safe Harbor de-identification requires care and documentation. Claiming de-identification without actually removing all 18 identifiers is a compliance violation.
HIPAA is actually four separate rules. Here's what each means for your product:
1. The Privacy Rule Governs the use and disclosure of PHI. The core principle: PHI can only be used for treatment, payment, and healthcare operations — or with patient authorization. As a Business Associate, you process PHI only as directed by the Covered Entity you serve and for the purposes they've authorized. You cannot use patient data for your own analytics or product improvement without explicit permission.
2. The Security Rule This is the one that most directly affects your engineering team. The Security Rule requires administrative, physical, and technical safeguards to protect electronic PHI (ePHI). Specific requirements include:
The Security Rule is largely what distinguishes "HIPAA compliant" architecture from standard SaaS architecture.
3. The Breach Notification Rule If there's a breach of unsecured PHI, you must notify the Covered Entity you serve without unreasonable delay and within 60 days of discovery. The Covered Entity then has its own notification obligations to patients and HHS. "Unsecured" means unencrypted — if PHI was encrypted and the keys weren't compromised, different rules apply. Breach notification is stricter and more complex than GDPR notification in healthcare.
4. The Omnibus Rule (2013) Extended HIPAA's requirements directly to Business Associates. Before 2013, Business Associates were primarily governed by their contracts with Covered Entities. After the Omnibus Rule, HHS can enforce HIPAA directly against Business Associates — which is why most significant recent enforcement actions involve tech companies, not just hospitals.
A BAA is a mandatory HIPAA contract between a Covered Entity and any Business Associate. It specifies how PHI can be used, the obligations of the Business Associate to protect it, and what happens in a breach.
You need a BAA with every Covered Entity customer before they send you PHI.
You also need BAAs with your own subcontractors that touch PHI — your "subcontractors" in HIPAA terms. This is where startups frequently miss things:
| Vendor | BAA available? |
|---|---|
| AWS | Yes (through AWS Artifact) |
| Google Cloud | Yes |
| Microsoft Azure | Yes |
| Slack | Only for Enterprise Grid, with restrictions |
| Google Workspace | Yes (for eligible plans) |
| Zoom | Yes (for healthcare plans) |
| Standard Slack (free/Pro/Business+) | No |
| Twilio | Yes |
| SendGrid | Yes |
| Consumer-grade tools generally | Typically no |
The critical point: a BAA from your cloud provider is necessary but not sufficient for HIPAA compliance. AWS signing a BAA with you means AWS has agreed to certain obligations regarding the infrastructure they provide. It does not mean your application is HIPAA compliant. Everything you build on top of that infrastructure still needs to meet the Security Rule requirements.
"We're on AWS and have a BAA" is not a HIPAA compliance statement. It's a prerequisite.
"HIPAA compliant hosting" is a marketing term that describes infrastructure that has agreed to sign a BAA and has implemented appropriate physical and operational security controls at the data center level. It covers:
It does not cover:
Most HIPAA violations in software companies are not about the data center. They're about misconfigured applications, inadequate access controls, or missing audit logs. The hosting provider can't fix those.
The HHS Office for Civil Rights (OCR) enforces HIPAA. Fines are tiered based on culpability:
| Tier | Description | Minimum per violation | Maximum per violation |
|---|---|---|---|
| Tier 1 | Did not know | $100 | $50,000 |
| Tier 2 | Reasonable cause | $1,000 | $50,000 |
| Tier 3 | Willful neglect, corrected | $10,000 | $50,000 |
| Tier 4 | Willful neglect, not corrected | $50,000 | $1.9 million |
The maximum annual penalty per violation category is $1.9 million. Penalties can stack across multiple violations.
Recent enforcement actions illustrate the range:
In 2024, OCR specifically launched a HIPAA Security Rule risk analysis enforcement initiative. If you're a Business Associate without a documented risk analysis, you're exposed.
Beyond OCR fines, HIPAA violations can trigger state attorney general actions and, in egregious cases, criminal referrals to the Department of Justice.
If you're at the point of a healthcare organization asking about HIPAA compliance, here's the minimum viable checklist:
1. Execute a BAA with the customer. Before they send you any PHI, the BAA must be signed. This is your contractual obligation and theirs. No BAA, no PHI. Every enterprise health customer will ask for this.
2. Sign BAAs with your own PHI-touching vendors. AWS, your monitoring tools, your logging infrastructure — sign their BAAs. Identify every tool in your stack that receives or processes PHI and confirm a BAA exists.
3. Implement access controls on PHI. Unique user authentication. Role-based access so users only see PHI they need. Automatic session timeouts. MFA on accounts with PHI access.
4. Set up audit logging for PHI access. Every read, write, and delete of PHI must be logged. Who accessed it, when, from where. Retained for six years. This is one of the most commonly missing requirements in startups moving into healthcare.
5. Encrypt PHI at rest and in transit. Encryption in transit (TLS 1.2 or higher) is table stakes. Encryption at rest for databases and storage containing PHI, with key management that meets the Security Rule requirements.
6. Complete a documented risk analysis. A risk analysis is a formal assessment of the threats and vulnerabilities to your ePHI. It doesn't have to be a 200-page document — it does need to be written down, cover your specific systems, identify risks, and document how you're addressing them. OCR has made risk analysis compliance an explicit enforcement priority.
These six items don't make you fully HIPAA compliant on every dimension, but they address the most common enforcement areas and the minimum that sophisticated healthcare customers will verify during vendor due diligence.
Hunchbite reviews healthtech products for HIPAA gaps, Security Rule compliance, and vendor contract issues — giving you a clear picture of what needs to change before enterprise healthcare customers put you through their security questionnaires.
Call +91 90358 61690 · Book a free call · Contact form
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
A practical guide for non-technical founders on how to split equity with a technical co-founder — what factors should drive the number, what vesting protects you both, and how to have the conversation before it becomes a crisis.
11 min readChoosing a PartnerAn honest comparison of fixed-price and hourly billing for software development — when each model makes sense, the hidden risks of both, and how to structure an engagement that protects you.
10 min read