HIPAA vs GDPR for Health Data: What Founders Must Know
HIPAA and GDPR both regulate health data, but they draw the boundary in different places. HIPAA follows the entity — it applies only to healthcare providers, insurers, clearinghouses, and the vendors who handle protected health information on their behalf. GDPR follows the data — it applies to any organization processing an EU resident's personal data, and it holds health data to a stricter standard than most.
Quick Answer: HIPAA is a US sector law — it governs specific parties (covered entities and business associates) handling protected health information. GDPR is an EU-wide data protection law — it governs personal data generally, with health data classified as a special category that needs extra justification to process. A product can clear HIPAA entirely and still carry real GDPR exposure, or the reverse.
Founders building health products often treat "compliance" as one undifferentiated wall to climb before launch. It isn't. HIPAA and GDPR are separate regimes built on separate premises, and knowing which one actually applies to you — and when — determines how much of your early runway goes to lawyers versus to finding out whether anyone wants the product.
The confusion is understandable. Both regimes talk about "health data," both carry real enforcement teeth, and coverage tends to flatten them into a single scary category called "privacy law." But the difference in how each one decides who is covered changes almost everything about how you build: your data architecture, your consent flows, your vendor contracts, and the order in which any of this should even worry you.
One caveat before we go further: this article explains the structural difference between the two regimes so you can reason about your own exposure. It is not legal advice. Nothing here substitutes for a conversation with privacy counsel who knows your specific jurisdictions, data flows, and business model — especially once you have live users and real data at stake.
HIPAA vs GDPR at a Glance: Scope, Consent, Penalties, and Research Rules
The fastest way to see the difference is side by side: HIPAA narrows by who you are, GDPR narrows by whose data you hold. Everything else — consent requirements, penalty structure, and how research gets special treatment — follows from that one design choice.
The table below compares the two regimes across the dimensions that matter most for early building decisions.
| Dimension | HIPAA (US) | GDPR (EU) |
|---|---|---|
| Scope | Applies only to covered entities (providers, health plans, clearinghouses), their business associates, and business associate subcontractors handling protected health information | Applies to any organization processing the personal data of people in the EU, in any sector, regardless of where the organization itself is based |
| Consent | Not generally required for treatment, payment, and healthcare operations; individual authorization is required for most other uses and disclosures | A documented legal basis is required for all processing; health data as a special category needs a heightened basis, typically explicit consent or a narrow exemption |
| Penalties | Tiered civil (and in some cases criminal) penalties enforced by the HHS Office for Civil Rights, scaled to the organization's degree of culpability | Tiered fines enforced by national data protection authorities, with the most serious tier calculated as a share of global annual revenue rather than a fixed amount |
| Research carve-outs | De-identification methods and institutional review board–approved waivers let sufficiently de-identified or minimal data move outside PHI rules | Scientific research purposes get accommodations too, typically conditioned on safeguards like pseudonymization and data minimization |
Read the rows in order and a pattern emerges: HIPAA asks "are you the kind of organization this law was written for," while GDPR asks "is this a real person's data, and did you have a valid basis to use it." That's also why a company can sit squarely outside HIPAA — no covered-entity relationship, no business associate agreement — and still carry full GDPR exposure the moment an EU resident signs up. Neither regime substitutes for the other, and neither one's absence means the other doesn't apply.
When HIPAA Governs Your Product
HIPAA attaches to you only if you are a covered entity, a business associate, or a subcontractor of one, handling protected health information (PHI) within that relationship — not because your app happens to touch a health topic.
A covered entity is a narrow category. Health plans, healthcare clearinghouses, and providers who transmit health information electronically for standard transactions such as billing and claims fall into this bucket. A pre-launch startup almost never does, on day one or otherwise, unless it is itself operating as a clinic, plan, or clearinghouse.
A business associate is a vendor acting on a covered entity's behalf. Think of a scheduling tool a clinic runs, or an analytics platform a hospital points at its patient records. That relationship comes with a signed Business Associate Agreement (BAA) binding you to HIPAA's security and privacy obligations, and any subcontractors you use inherit the same obligations downstream. Our deeper walkthrough on HIPAA for startups covers exactly where that line sits and how to validate a health idea without crossing it prematurely.
Most consumer health products sit outside HIPAA's direct reach: a symptom tracker, a general wellness app, a fertility app people use on their own initiative, with no provider relationship in the loop. That does not mean the data is unregulated — state privacy laws and consumer-protection rules can still apply, and for products handling reproductive or sexual health data specifically, the femtech data privacy checklist is worth reading before you assume you're in the clear.
A few concrete signals tell you HIPAA scope has arrived, whether or not you were expecting it:
- A covered-entity customer asks you to sign a BAA. That request means they consider you a business associate, and signing it makes HIPAA contractually binding.
- Your product starts storing identifiable clinical data — uploaded records, diagnoses, or treatment notes tied to a named person — on someone else's behalf.
- You begin transmitting data for standard healthcare transactions, such as insurance claims or eligibility checks, for a covered entity.
Until one of those happens, most early validation work — interviews, landing pages, de-identified surveys — never touches PHI at all, and HIPAA simply isn't in play yet.
When GDPR Applies — and to Whom
GDPR applies the moment you process the personal data of someone located in the EU — regardless of your company's location, sector, or size — if you're offering them goods or services, or monitoring their behavior. No healthcare relationship is required for it to attach.
This is the structural difference that trips founders up most: GDPR is not a health law that happens to cover health data — it's a general data-protection law that treats health data more strictly than most other categories. A US-based fitness app with no clinical function whatsoever, no provider relationship, and no BAA anywhere in sight can be fully outside HIPAA and fully inside GDPR the instant someone in Berlin creates an account.
Health data under GDPR is "special category" data, a classification broader than most founders expect. It covers not just diagnoses and lab results but also inferred health information — a fitness app's activity data, a period-tracking app's cycle logs, a mental-health app's mood entries. Processing this category of data requires a stronger legal basis than ordinary personal data, most commonly explicit, freely given consent, or a narrow set of other conditions such as public-health or safeguarded research purposes.
A few obligations follow directly from that special-category status, and they apply whether or not you'd call yourself a "health company":
- A documented legal basis for every processing purpose — a blanket privacy policy is not sufficient on its own.
- Operable data subject rights — access, correction, deletion, and portability — that a user can actually exercise, not just language that describes them.
- A data protection impact assessment for higher-risk processing, which health data usually triggers by default.
- Breach notification to the relevant supervisory authority, on a genuinely tight clock once a qualifying incident occurs.
None of this depends on your product being marketed as a healthcare tool. It depends on whether the data you collect, including data you merely infer, falls into the special category — and whether your users are in scope geographically.
Operating Under Both — Practical Sequencing
If you plan to operate in both the US and the EU — or your US product simply starts picking up EU signups — you don't need two separate compliance programs running from day one. You need to sequence the work so you build what your actual user base and data flows require, in the order the evidence justifies it.
A workable sequence looks like this:
- Map who your users actually are and where they're located. Geography, not intent, is what determines GDPR exposure. If nobody in the EU is signing up yet, GDPR obligations are lower-priority than architecture that could accommodate them later.
- Map your relationships, not just your product category. Are you selling to or through a covered entity? That relationship, not your app's subject matter, is what determines HIPAA exposure.
- Design data collection to be minimal and de-identified by default during validation, regardless of which regime you're worried about. Fewer identifiers and less retained data reduces exposure under both simultaneously, and it's cheap to do early and expensive to retrofit.
- Build consent and disclosure flows to the higher bar. If you design for GDPR's explicit-consent standard on sensitive data from the start, you're not maintaining two parallel systems later — the stricter regime effectively covers the looser one.
- Bring in privacy counsel once you have paying users, a signed pilot, or a specific EU or enterprise customer — not before. Generic compliance spend on an unvalidated product is runway you can't get back.
This mirrors the general discipline of validation itself: confirm the underlying idea is worth building before you invest in infrastructure — legal or technical — to support it at scale. The complete guide to startup idea validation walks through how to sequence early experiments so compliance spend arrives after evidence, not ahead of it.
None of this replaces jurisdiction-specific advice. HIPAA and GDPR each interact with a growing patchwork of other rules — state health-privacy laws in the US, country-level implementing rules across the EU — and the right answer for your specific data flows depends on facts a general article cannot know. Treat this piece as a map of the terrain, and bring in privacy counsel before you finalize your data architecture or sign your first enterprise or EU customer.
Key Takeaways
- HIPAA scopes by relationship; GDPR scopes by data subject. HIPAA asks whether you're a covered entity or business associate handling PHI; GDPR asks whether the data belongs to someone in the EU, in any sector.
- Clearing one regime says nothing about the other. A product can be entirely outside HIPAA's reach and still carry full GDPR exposure, or vice versa — check both independently.
- Health data is GDPR's "special category," and it's broader than diagnoses. Inferred health signals — activity, cycle, or mood data — can qualify, not just clinical records.
- HIPAA permits routine treatment, payment, and operations uses without individual authorization; GDPR requires a documented legal basis for every processing purpose. That's the biggest day-to-day difference for consent design.
- Penalty structures differ, not just penalty size. HIPAA fines scale to culpability and are enforced federally; GDPR fines are enforced by national authorities and, at the top tier, scale with global revenue.
- Design for the stricter regime from the start if you might operate under both. It avoids maintaining two parallel consent and data-handling systems later.
- This article is a map, not legal advice. Bring in privacy counsel before finalizing your data architecture, especially once real users or real data are at stake.
Frequently Asked Questions
Is GDPR stricter than HIPAA?
In scope, generally yes — GDPR covers any personal data in any sector, while HIPAA covers only specific entities handling protected health information. In consent mechanics, GDPR also requires an affirmative legal basis for essentially all processing, where HIPAA permits many core healthcare uses without individual authorization. HIPAA can be more prescriptive on security controls for the entities it does cover, so "stricter" depends on which dimension you're asking about — not a single yes-or-no answer.
Does GDPR apply to a US health startup with no EU offices?
Yes, if you offer goods or services to people in the EU or monitor their behavior — company location doesn't matter. GDPR has extraterritorial reach by design: a US-based app with EU users can be fully in scope even with zero physical presence in Europe. The trigger is who your users are, not where your servers or your headquarters sit.
What counts as health data under GDPR's special category rules?
More than clinical records. Diagnoses, treatment history, and lab results clearly qualify, but so does data that reveals health status by inference — fitness tracking, menstrual cycle logs, sleep or mood data, and similar signals a consumer app collects without ever calling itself a healthcare product. If the data lets you infer something about a person's physical or mental health, treat it as special category data rather than assuming it's exempt because it wasn't collected by a clinician.
Do I need to comply with both if I only serve US patients today?
If you genuinely have no users located in the EU, GDPR likely isn't triggered yet — but HIPAA still depends entirely on your entity relationship, not your user base. Design your data handling with both regimes in mind anyway: expansion into EU markets, or an unexpected signup from an EU visitor, can bring GDPR into scope faster than a compliance program can be stood up from a cold start.