“Are we a hospital?” is the wrong opening question, and it sends companies to the wrong answer. HIPAA does not classify you by what you call yourself; it classifies you by what you do with protected health information. Ask the right question — do we handle PHI, and for whom — and the law sorts almost everyone into one of three boxes with surprising precision. Get the box wrong and you either over-build for a rule that never applied or, far more commonly, run a regulated service while insisting you are merely a tool.
Start With the Data, Not the Org Chart
The whole analysis turns on a single phrase that recurs throughout the regulation: an entity that creates, receives, maintains, or transmits protected health information. Notice how operational that list is. You do not have to diagnose, treat, or insure anyone. You do not even have to read the data. Maintaining it — holding it on your servers — is enough to put you in scope. The org chart, the pitch deck, and the word “healthcare” on your website are all irrelevant; the data flow is everything.
So before deciding which role you occupy, answer the prior question honestly: does identifiable health information pass through your systems at all? If the answer is no — you handle only de-identified data, or no health data — HIPAA does not reach you and the rest is moot. If the answer is yes, the only remaining question is whose data it is and on whose behalf you hold it. That is what separates the two regulated roles.
Covered Entities: The Three Categories
Covered entities are the organisations HIPAA was written around — the parties with the direct relationship to the patient or member. There are exactly three categories, and most companies can rule themselves out of all of them in a sentence.
| Category | What it means | Examples |
|---|---|---|
| Healthcare providers | Provide care and transmit health data electronically for standard transactions like billing | Hospitals, clinics, physicians, dentists, pharmacies, labs |
| Health plans | Pay for or provide the cost of medical care | Insurers, HMOs, employer group health plans, government programmes |
| Healthcare clearinghouses | Translate health data between standard and non-standard formats | Billing services and value-added networks that reformat claims |
One nuance trips up providers specifically: a provider only becomes a covered entity if it transmits health information electronically in connection with a HIPAA standard transaction — chiefly billing and eligibility. A cash-only practice that never bills electronically can, in principle, fall outside. For the startups reading this, though, the relevant point is usually the opposite one: you are almost never a covered entity, which pushes the real question onto the second role.
Business Associates: Where Most Startups Land
A business associate is a person or company that performs a function or service for a covered entity that involves handling PHI. This is the category that catches technology companies, because the modern healthcare stack is built almost entirely on outside vendors. If a hospital uses your software to schedule patients, your platform to store records, your service to process claims, or your model to analyse outcomes — and PHI is involved — you are a business associate.
The test is functional, not nominal. It does not matter that health data is a small slice of your business, that you serve a hundred non-healthcare customers, or that no employee ever opens a record. What matters is that your service creates, receives, maintains, or transmits PHI for a covered entity. Common business associates include:
- Cloud and hosting providers that store ePHI, even encrypted and even without access to it.
- SaaS platforms — EHR add-ons, scheduling, telehealth, patient communication, analytics dashboards.
- Billing, coding, and revenue-cycle services that process claims containing PHI.
- Data and AI vendors that run analysis, transcription, or model training on patient data.
- Professional services — consultants, lawyers, or accountants who see PHI while doing the work.
The relationship is formalised by a Business Associate Agreement (BAA), the contract HIPAA requires between a covered entity and its business associate. The BAA is not a formality you sign afterward; it is the document that defines, and limits, what you may do with the PHI — and the law expects it to be in place before any data changes hands. Much of what the BAA commits you to overlaps with an ISO 27001 control set, which is why teams selling into healthcare often build both at once.
The Conduit Exception, and Its Limits
There is one genuine carve-out, and it is narrower than the companies relying on it tend to hope. The conduit exception says that a pure transmission service — one that only moves data and does not store it beyond what transport transiently requires — is not a business associate. The classic examples are the postal service and an internet service provider: they carry the envelope without keeping its contents.
The trap is assuming this covers cloud storage. It does not. The moment a service maintains ePHI — holds it at rest, persistently — it has done more than transmit, and it is a business associate. The misconception worth killing is that not looking at the data is a defence. It isn’t.
In 2016 the Office for Civil Rights published guidance settling a question cloud providers had hoped to dodge: a cloud service provider that stores or processes electronic PHI for a covered entity or business associate is itself a business associate — full stop. The guidance went further on the point everyone wanted to argue. Even if the ePHI is encrypted and the provider holds no decryption key — so it genuinely cannot read a single record — it is still a business associate, because persistent storage is more than the transient transmission the conduit exception was written for. Encryption reduces risk; it does not remove the role. A BAA is still required, and the provider is still directly liable. The lesson for any infrastructure startup: “we just hold the bytes, we never open them” describes exactly what a business associate does.
When HIPAA Does Not Apply
It is just as important to know where the law stops, because over-scoping is its own kind of mistake. HIPAA generally does not apply when you collect health data directly from consumers and are not acting on behalf of a covered entity. A direct-to-consumer wellness app, a fitness tracker, or a symptom-logging tool you sell straight to the public typically falls outside HIPAA, because there is no covered entity in the chain — you are the source, not the service provider to a provider.
“Outside HIPAA,” however, is not the same as “unregulated.” The FTC’s Health Breach Notification Rule reaches many of exactly these consumer health apps, and a fast-growing set of US state privacy laws — several written specifically around health and biometric data — apply regardless of HIPAA. So the honest conclusion when HIPAA doesn’t fit is rarely “we have no obligations”; it is “our obligations come from somewhere else, and we need to find out where.”
Thinks It’s the Customer’s Problem vs Knows the BAA Flows Down
Pattern-matching from real vendor reviews — the gap between a company that treats HIPAA as its customer’s burden and one that understands where the obligation actually lands tends to follow the same shape:
| Thinks it’s the customer’s problem | Knows where the obligation lands |
|---|---|
| ✗ “The hospital is the covered entity, not us” | ✓ Knows handling their PHI makes you a business associate |
| ✗ Signs a BAA and files it away | ✓ Treats the BAA as the limit on what it may do with PHI |
| ✗ “We encrypt it, so we’re just a conduit” | ✓ Knows storage at rest defeats the conduit exception |
| ✗ Passes PHI to sub-vendors with no agreement | ✓ Has BAAs down the subcontractor chain |
| ✗ Assumes a consumer app is automatically exempt | ✓ Checks the FTC rule and state law when HIPAA doesn’t fit |
| ✗ Decides scope from the industry label | ✓ Decides scope from the data flow |
Decide in Five Questions
If you want a fast, defensible read on where you stand, work through these in order. The first “yes” that lands you in a role is your answer.
- 1. Does identifiable health information flow through your systems at all? If no, HIPAA does not apply — stop here.
- 2. Are you a provider, health plan, or clearinghouse handling that data directly? If yes, you are a covered entity.
- 3. Do you handle that PHI to provide a service to a covered entity (or its business associate)? If yes, you are a business associate.
- 4. Do you only transiently transmit it, never storing it? Possibly a conduit — but persistent storage cancels this.
- 5. Did the health data come straight from consumers, with no covered entity in the chain? Likely outside HIPAA — now check the FTC rule and state law.
For a longer, scored version of this logic across frameworks, the self-assessment approach we use for ISO 27001 applies the same “decide from triggers, not labels” discipline.
Final Thought
The two HIPAA roles are easy to keep straight once you stop reading them as identities and start reading them as relationships to data. A covered entity owns the relationship with the patient. A business associate is brought in to help and inherits the duties by touching the data. A subcontractor inherits them again, one step down. Liability does not stay politely at the top of the chain; the BAA carries it downhill to everyone who handles the PHI.
The test: name the covered entity at the top of your data chain and trace the PHI from them to you and onward to your vendors. If at any hop the data moves but a BAA doesn’t, you have found the link that is in scope and out of compliance at the same time.
Frequently Asked Questions
A covered entity is a healthcare provider, health plan, or clearinghouse that handles protected health information directly as part of care or coverage. A business associate is an outside party that handles that PHI on the covered entity’s behalf to provide a service. The covered entity owns the relationship with the patient; the business associate is brought in to help, and inherits HIPAA duties by doing so.
If your software creates, receives, maintains, or transmits protected health information to provide a service to a covered entity, then yes — you are a business associate, even if PHI is only a fraction of what you handle and even if no human at your company ever looks at it. The test is functional: it turns on what your service does with the data, not on your industry label.
Rarely. The conduit exception is narrow — it covers pure transmission services like the postal service or an ISP that only move data and don’t store it beyond what transmission requires. A cloud provider that maintains ePHI is a business associate even if the data is encrypted and the provider holds no key, because persistent storage is more than transient transport.
Usually not — if you collect health data directly from consumers and aren’t acting for a covered entity, HIPAA generally doesn’t reach you. But that doesn’t mean you’re unregulated: the FTC Health Breach Notification Rule and a growing list of state privacy laws can still apply, so “HIPAA doesn’t cover us” is the start of the analysis, not the end.