HIPAA vs. GDPR: What Health Software Teams Must Know

HIPAA and GDPR are not the same law with different names. HIPAA is a US federal law that only applies to protected health information touched by a healthcare provider, health plan, clearinghouse, or their business associates. GDPR is a European regulation covering essentially all personal data, in any industry, the moment an EU resident’s data is involved. A health product can sit inside HIPAA’s scope, GDPR’s scope, both, or neither, and each classification carries its own paperwork, its own rights for the person the data belongs to, and its own breach clock.

Are HIPAA and GDPR the same thing?

No. HIPAA is sector-specific: it names exactly two bound actors, covered entities and business associates, and one protected data type, PHI. GDPR is horizontal: it binds anyone who controls or processes personal data tied to an EU resident, in any industry.

Some engineering practices carry over between the two, encryption and audit logging among them. The legal instruments, individual rights, and specific technical mandates mostly don’t. Being GDPR compliant doesn’t make you HIPAA compliant, and the reverse is just as false.

PHI vs. PII: the actual dividing line

HIPAA protects PHI: individually identifiable health information created, received, maintained, or transmitted by a covered entity or its business associate, in any form. The word that matters is who. A blood pressure reading is PHI when a clinic’s system holds it, and not PHI at all when a random fitness app does, because HIPAA’s coverage is tied to the entity holding the data, not the sensitivity of the data itself.

GDPR doesn’t use the term PII, that’s a US habit. Its own term is personal data: any information relating to an identified or identifiable person, with health information further classified as Article 9 “special category” data and no covered-entity gate. If it’s health data about an EU resident, GDPR’s stricter rules apply regardless of who is processing it.

HIPAA asks who is holding the data. GDPR asks whose data it is, and a system can clear one question and fail the other.

Who each law actually binds

HIPAA binds covered entities (health plans, clearinghouses, and providers who transmit health information electronically for standard transactions) and business associates, meaning anyone who creates, receives, maintains, or transmits PHI on a covered entity’s behalf to perform a covered function like claims processing or billing.

GDPR binds controllers and processors, in any industry, whenever an entity has an EU establishment or offers goods or services to, or monitors, people in the EU.

The same product can be a HIPAA business associate for a US client and, independently, a GDPR processor or controller for its own analytics, the moment any EU resident’s data passes through it. Two separate classifications, each needing its own contract.

Permitted uses versus lawful basis

GDPR is lawful-basis-first. Every processing activity needs an Article 6 basis, and health data, as special category data, needs a second Article 9 condition too, such as explicit consent or processing by a bound medical professional.

HIPAA works differently. Its Privacy Rule defines permitted uses and disclosures rather than a consent regime. A covered entity may use or disclose PHI for treatment, payment, and healthcare operations (TPO) without patient authorization at all. Authorization is required only outside that list: mainly marketing, sale of PHI, psychotherapy notes, and most non-care third-party sharing.

Porting GDPR-style consent infrastructure into a HIPAA build over-engineers the TPO path and under-builds the minimum necessary limits and authorization tracking HIPAA actually requires for the narrower non-TPO category.

HIPAA compliance vs. GDPR compliance

Aspect	HIPAA	GDPR
Scope	Sector-specific: covered entities and business associates handling PHI	Horizontal: any controller or processor handling personal data of an EU resident
Governing concept	Permitted uses and disclosures (TPO); authorization required outside that list	Lawful basis under Art. 6, plus a separate Art. 9 condition for health data
Vendor contract	Business Associate Agreement (BAA)	Data Processing Agreement (DPA)
Breach notice to regulator	No later than 60 calendar days after discovery	Within 72 hours of becoming aware, where feasible
Right to erasure	No equivalent right	Article 17, a named right
Data portability	No mandated interoperable format	Article 20, mandated machine-readable format
Penalty structure	Tiered, capped, per-violation civil penalties set by a US federal agency	Percentage of global annual turnover or a flat amount, whichever is higher

Treat the penalty row as a structural difference, not two versions of the same fine. HIPAA’s schedule is bounded and predictable. GDPR’s scales with worldwide revenue and is effectively uncapped for a large global company.

Individual rights: what GDPR grants that HIPAA doesn’t

This is where the two laws stop rhyming. GDPR gives data subjects a right to erasure (Article 17) and a right to object to processing (Article 21). HIPAA has no equivalent to either: a patient can request that a covered entity amend their record, but the entity can deny it, leaving the patient only able to append a statement of disagreement.

GDPR also mandates data portability in a structured, machine-readable format. HIPAA lets a patient direct a copy of their record to a third party, with no mandated format behind it.

The Business Associate Agreement and the DPA aren’t interchangeable

A Business Associate Agreement is the contract HIPAA’s Privacy Rule requires between a covered entity and a business associate, obligating the business associate to safeguard PHI and limiting how it uses or discloses it. GDPR’s Article 28 Data Processing Agreement is structurally similar, both bind a downstream processor to the upstream party’s obligations and require breach notification and subprocessor flow-down, but they’re legally distinct instruments under different statutes, and one doesn’t substitute for the other.

A BAA carries HIPAA-specific mandatory content, PHI safeguard obligations and a duty to return or destroy PHI on termination among them, that a standard DPA won’t contain. A vendor’s DPA is real and useful. It isn’t a BAA, and it won’t stand in for one if PHI is actually in scope.

Whether a specific engagement needs a signed BAA depends on real access to PHI, not on “doing IT work for a healthcare company” generally, a determination for counsel, not a blog post.

GDPR healthcare data: special category by default

Under GDPR, health data is Article 9 special category data: processing it is prohibited by default unless a separate condition applies, explicit consent or medical diagnosis by someone bound by professional secrecy among them. That’s a stricter starting point than HIPAA’s, where routine TPO flows require no consent tracking at all. A product serving both a US covered entity and EU residents needs two separate gates on the same health record, an Article 9 condition for EU users and a TPO-or-authorization classification for US patients, and satisfying one doesn’t satisfy the other.

Breach notification: 72 hours versus 60 days

GDPR requires notifying the relevant supervisory authority within 72 hours of the controller becoming aware, where feasible, unless the breach is unlikely to result in a risk to individuals. Notice to affected individuals is required only for high risk, with no fixed day count.

HIPAA runs a longer clock with the opposite default: an incident is presumed a reportable breach unless a documented four-factor risk assessment shows a low probability that PHI was compromised, and once something is a breach, individuals must be notified without unreasonable delay, no later than 60 calendar days after discovery.

A detection and response pipeline built for GDPR’s 72-hour clock is more than sufficient for HIPAA’s 60-day clock, one of the few places GDPR experience genuinely over-delivers for HIPAA.

Does the US have a GDPR equivalent?

No single federal law does what GDPR does. The US has no horizontal privacy statute covering all personal data across every industry, only sector-specific laws (HIPAA for health, GLBA for finance) plus a growing patchwork of state privacy laws.

For health data specifically, HIPAA is the closest domestic analog, but narrower in scope (only covered entities and business associates, only PHI) and weaker in the rights it grants (no erasure, no object right, no mandated portability format). HIPAA alone won’t get a product to GDPR-equivalent protection for US health data.

Serving both markets at once

If your product touches PHI for a US covered entity and personal data belonging to any EU resident, both regimes apply independently, not as alternatives. Passing one doesn’t establish compliance with the other, and a control built for one regime’s documentation still needs its own paper trail for the other. Healthcare data compliance here means treating HIPAA and GDPR as two separate obligations layered on the same system, designing data classification, access control, and audit logging before a single real record exists, not retrofitting them after a client asks. That’s the same discipline we bring to every healthcare software development project, regardless of which regime ends up applying.

Which architectural controls actually transfer

This is the part worth the most attention if you’ve already built for GDPR and are wondering how much of that work you get to keep.

Transfers cleanly. Encryption at rest and in transit is the clearest case: GDPR names it as an example of an appropriate technical measure, and HIPAA lists it as addressable under Access Control and Transmission Security. A team already encrypting everywhere for GDPR has cleared the practical bar HIPAA sets here, though the addressable-specification write-up explaining why encryption was reasonable still has to be produced separately. Breach-response tooling built for GDPR’s 72-hour clock transfers cleanly too, and so does the habit of gating vendor relationships behind a data-protection contract, though the specific contract has to change.

Similar shape, must be rebuilt. A BAA and a DPA look alike but aren’t interchangeable, as above. Risk analysis and DPIAs have different triggers too: HIPAA’s risk analysis is mandatory for every covered entity and business associate, ongoing, covering all PHI, while GDPR’s DPIA is only required for processing likely to cause high risk, so a team used to DPIAs-on-demand tends to under-invest in HIPAA’s always-required version. Minimum necessary and data minimization also sit on different axes: GDPR’s minimization constrains what you collect, while HIPAA’s minimum necessary constrains use and disclosure of what you’ve already collected, a role-based discipline at query time, not a schema decision.

No GDPR equivalent, genuinely new work. HIPAA’s Audit Controls standard requires mechanisms to record and examine activity in any system touching PHI, as its own named safeguard. GDPR’s equivalent language is general risk-based wording with no comparable audit-log mandate, so a GDPR build without systematic, PHI-specific access logging needs new work here, not a port. The Required-versus-Addressable framework itself has no GDPR parallel either. A 2025 HHS proposal would tighten this framework and add an explicit multi-factor authentication mandate, but it isn’t finalized and its timeline has already slipped, so today’s framework is still what’s operative.

This is general information about how HIPAA and GDPR compare, not legal advice for your specific product or engagement.