Most founders hear “HIPAA” and picture hospitals, insurers, and a problem that belongs to someone older and larger than they are. That instinct is exactly how a health-tech startup ends up handling a stream of patient records with no agreement, no risk analysis, and no idea it is already a regulated party. HIPAA is not a rule about being a hospital. It is a rule about a kind of data, and the question that decides whether it applies to you is far simpler and far less flattering to the size of your company than most people expect.
What HIPAA Actually Is
HIPAA — the Health Insurance Portability and Accountability Act of 1996 — is a US federal law, and the part everyone means when they say the word is the set of rules it created to protect health information. It does three things: it limits how that information may be used and shared, it requires the information to be secured, and it sets out what must happen when the protection fails. Everything else is detail hanging off those three ideas.
The law is enforced by the Department of Health and Human Services through its Office for Civil Rights, and the enforcement is real — settlements, corrective action plans, and civil penalties that run into the millions. For a startup, the relevant fact is not the size of the fine but the fact that the obligations attach automatically the moment the data is in your hands. There is no grace period for being small and no exemption for being early-stage.
The Data Triggers It, Not the Industry
The thing HIPAA actually protects is protected health information — PHI — and understanding what that is removes most of the confusion. PHI is health information that can be tied to a specific person. It is the combination of a health detail (a diagnosis, a treatment, a payment for care) and an identifier that links it to an individual. The regulation lists eighteen such identifiers, and they are broader than people guess: not just names and Social Security numbers, but dates, email addresses, account and record numbers, device identifiers, IP addresses, biometric data, and full-face photographs.
This is why the trigger is the data and not the industry. Strip every identifier out and you no longer hold PHI; leave a single one in, attached to a health fact, and the full weight of the rules applies — regardless of whether you call yourself a healthcare company. A scheduling tool, an analytics layer, a billing integration, a note-taking app for clinicians: if patient health data flows through it in identifiable form, it is handling PHI.
In 2016 the Office for Civil Rights reached its first settlement directly with a business associate. Catholic Health Care Services, which provided management and IT services to a group of nursing facilities, had an unencrypted company iPhone stolen — exposing the protected health information of 412 residents, including diagnoses and medical histories. CHCS was not a hospital or an insurer; it was a vendor acting on behalf of covered entities. That did not matter. OCR found it had no risk analysis and no risk management plan, and it paid $650,000 with a corrective action plan attached. The lesson generalises to every startup selling into healthcare: once you handle PHI for a client, the regulator can come to you directly, and “we only build the software” is not a defence.
Who Must Comply: Two Categories
HIPAA divides the world of regulated parties into two groups, and a startup almost always lands in the second. Covered entities are the organisations at the centre of healthcare: health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically in connection with standard transactions. These are the hospitals, clinics, and insurers people picture when they hear the word.
Business associates are the parties that handle PHI on a covered entity’s behalf. If you create, receive, maintain, or transmit protected health information to provide a service to a covered entity, you are a business associate — and since the HITECH Act of 2009, you are directly accountable to regulators, not merely contractually answerable to your customer. This is the category that catches the most startups by surprise, because it has nothing to do with treating patients and everything to do with touching their data.
| Role | Who it covers | Typical examples |
|---|---|---|
| Covered entity | Sits at the centre of care or coverage and handles PHI directly | Hospitals, clinics, doctors, health plans, clearinghouses |
| Business associate | Handles PHI to provide a service to a covered entity | Cloud hosting, SaaS platforms, billing, analytics, transcription |
| Subcontractor | A business associate’s own vendor that touches the same PHI | A sub-processor, a downstream cloud provider, an offshore dev shop |
The third row matters for startups that build on top of other vendors: a business associate’s subcontractors are themselves business associates. The obligation flows down the chain, which means you can inherit HIPAA duties not only from your customer but from a vendor whose customer is the covered entity. You can read more on the boundary in Does HIPAA Apply to Your Business? Covered Entities vs Business Associates.
The Three Rules in Plain English
Underneath the acronym sit three rules that, taken together, describe what you may do with health data, how you must protect it, and what happens when protection fails. They are far less intimidating once translated.
The Privacy Rule
The Privacy Rule governs the uses and disclosures of PHI — who may see it, for what purposes, and with what permission. Its organising idea is the minimum necessary standard: use and share only the smallest amount of health information needed for the task. For a product team, that translates directly into access controls and data minimisation rather than abstract policy.
The Security Rule
The Security Rule covers electronic PHI specifically and requires safeguards in three families: administrative (policies, training, a designated security official, and a risk analysis), physical (control over devices and facilities), and technical (access controls, encryption, audit logging, transmission security). This is the rule a startup spends most of its engineering effort satisfying, and it maps cleanly onto controls a serious security programme already runs.
The Breach Notification Rule
The Breach Notification Rule sets out what must happen when PHI is exposed: affected individuals must be notified, the Office for Civil Rights must be notified, and for large breaches the media must be too — generally without unreasonable delay and no later than sixty days. A business associate that suffers the breach must tell the covered entity, which is why your incident response plan and your contracts have to line up.
Assumes It Doesn’t Apply vs Knows It Does
Pattern-matching from real scoping conversations — the gap between a startup that assumes HIPAA is someone else’s problem and one that has actually placed itself in the framework tends to follow the same shape:
| Assumes it doesn’t apply | Knows where it stands |
|---|---|
| ✗ “We’re too small for HIPAA” | ✓ Knows size is irrelevant — PHI is the trigger |
| ✗ “We just host the data, we don’t read it” | ✓ Knows maintaining PHI makes you a business associate |
| ✗ “HIPAA is our customer’s responsibility” | ✓ Knows liability attaches directly since HITECH |
| ✗ Handles patient data with no agreement | ✓ Has a signed BAA before any PHI changes hands |
| ✗ Treats compliance as paperwork for later | ✓ Ran a risk analysis before going live |
| ✗ Assumes a vendor’s certificate covers them | ✓ Knows the obligation flows down the subcontractor chain |
What Compliance Actually Requires
The reassuring part is that HIPAA compliance for a startup is not exotic. It is a short list of disciplined, evidenced practices, most of which overlap with what a security-conscious company already does:
- Business Associate Agreements. A signed BAA with every covered entity you serve and every subcontractor you pass PHI to — in place before any data moves, not after.
- A security risk analysis. A documented assessment of where ePHI lives and what threatens it. Its absence is the single most common finding in OCR settlements.
- Administrative, physical, and technical safeguards. Policies and training, device and facility control, and the technical controls — access management, encryption, audit logging — the Security Rule expects.
- Workforce training. Everyone who can touch PHI understands the minimum-necessary rule and how to handle an incident.
- A breach response plan. A tested process that meets the notification timelines and the contractual duty to inform the covered entity.
None of this requires a compliance department. It requires deciding, deliberately and early, that you are a regulated party — and then writing down and evidencing the controls you should be running anyway. If you also sell into enterprises, much of this work doubles as ISO 27001 for healthcare and SOC 2 readiness, so it is rarely wasted effort.
Final Thought
HIPAA looks like a law for hospitals and turns out to be a law about data. The companies that get caught out are not the ones that read the rules and decided they were too burdensome; they are the ones that assumed, on the strength of being small, that the rules were addressed to someone else. The moment identifiable health information passes through your systems on behalf of a healthcare client, you are inside the framework — and the only question is whether you knew it in time to build for it.
The test: trace one piece of patient data through your product and ask three things — is it identifiable, are you handling it for a covered entity, and is there a signed agreement that says so. If the data is real and the agreement isn’t, you are already a business associate operating without the controls the law assumes you have.
Frequently Asked Questions
It can, and the trigger is the data, not the size of the company. If a startup creates, receives, maintains, or transmits protected health information on behalf of a covered entity — a provider, health plan, or clearinghouse — it is a business associate and must comply with HIPAA directly. A two-person health-tech vendor is as in scope as a hospital.
PHI is health information that can be tied to an individual. It is the combination of a health detail and one of eighteen identifiers — name, dates, contact details, account or record numbers, IP addresses, biometrics, and more. Strip every identifier and it stops being PHI; leave one in and the full weight of the rules applies.
The Privacy Rule governs how PHI may be used and disclosed. The Security Rule sets administrative, physical, and technical safeguards for electronic PHI. The Breach Notification Rule dictates who must be told, and how fast, when PHI is exposed. Together they describe what you may do with health data, how you must protect it, and what happens when protection fails.
A signed Business Associate Agreement with every party you handle PHI for or pass it to, a documented security risk analysis, administrative, physical, and technical safeguards, workforce training, and a breach response plan. None of it is exotic — it is the same discipline a serious security programme already runs, written down and evidenced.