HIPAA vs GDPR: Clause-by-Clause Comparison

HIPAA Privacy + Security Rules is sectoral and applies to Covered entities (providers, plans, clearinghouses) and business associates handling protected health information (PHI). Sectoral US law; binds any AI vendor that touches PHI. GDPR (Regulation 2016/679, Articles 22, 25, 35) is regulatory and applies to Any controller or processor handling personal data of EU residents, regardless of location. AI relevance via Article 22 (automated decisions), Article 25 (data protection by design), and Article 35 (DPIA). The practical tension is that two privacy regimes that treat the same clinical AI deployment very differently, particularly on automated decisions. They are not substitutes. Across the fifteen governance dimensions compared here, 12 are addressed substantively by both, 0 are materially stronger in HIPAA, and 2 are materially stronger in GDPR. Treating either as a superset of the other is the most common and most expensive mistake.

HIPAA Privacy + Security Rules Type: Sectoral. Jurisdiction: United States (healthcare). In force: Privacy Rule 2003; Security Rule 2005; HITECH 2009. Exposure for getting it wrong: USD 137 to USD 2,067,813 per violation; criminal up to 10 years (45 CFR 160.404, 42 USC 1320d-6). Best suited to: US healthcare providers, plans, clearinghouses, and any vendor processing PHI GDPR (Regulation 2016/679, Articles 22, 25, 35) Type: Regulatory. Jurisdiction: European Union + EEA (extraterritorial via Article 3). In force: May 25, 2018. Exposure for getting it wrong: Up to EUR 20 million or 4% global turnover (Article 83). Best suited to: Any organization processing EU resident personal data through AI The penalty asymmetry is usually what decides sequencing. GDPR carries legal consequences and HIPAA does not, so GDPR sets your deadline while HIPAA sets your method.

These are the dimensions both frameworks address substantively, which means one piece of evidence can often satisfy both. This is where a combined programme saves real effort rather than just feeling tidy. Governance + accountability. HIPAA (45 CFR 164.308(a)(2); 164.530(a)): 164.308(a)(2) requires assigned Security Official; 164.530(a) requires Privacy Official and contact person. GDPR (Articles 24, 37): Article 37 requires a Data Protection Officer for public bodies and large-scale processors; Article 24 controller responsibility. Risk management process. HIPAA (45 CFR 164.308(a)(1)): 164.308(a)(1)(ii) requires a Risk Analysis and Risk Management process. GDPR (Article 35): Article 35 DPIA required for high-risk processing (profiling, large-scale special category, systematic monitoring). Data handling + minimisation. HIPAA (45 CFR 164.502(b); 164.514): 164.502(b) minimum necessary; 164.514(d) standards; 164.514(b) de-identification; restrictions on training-data use. GDPR (Articles 5, 6, 9): Article 5 principles (lawfulness, minimisation, accuracy, storage limitation, integrity); Articles 6, 9 lawful basis. Transparency + disclosure. HIPAA (45 CFR 164.520): 164.520 requires a Notice of Privacy Practices; no AI disclosure obligation, but FDA guidance applies to clinical AI. GDPR (Articles 13, 14, 22(3)): Articles 13-14 provide information; Article 22(3) requires meaningful information about automated decision logic. Post-market monitoring + drift. HIPAA (45 CFR 164.308(a)(1)(ii)(D)): 164.308(a)(1)(ii)(D) requires Information System Activity Review; periodic, not continuous. GDPR (Articles 24, 35(11)): Article 35(11) DPIA review where processing operations change; ongoing controller obligation under Article 24. Incident + serious-incident reporting. HIPAA (45 CFR 164.308(a)(6); 164.400-414): 164.308(a)(6) requires security-incident procedures; 164.400s require breach notification to HHS within 60 days. GDPR (Articles 33, 34): Article 33 requires breach notification to supervisory authority within 72 hours; Article 34 to data subjects. The caveat worth stating: overlapping subject matter does not mean interchangeable evidence. HIPAA and GDPR frequently want the same control documented to a different standard of proof, so plan to write once and format twice.

Stronger in GDPR Human oversight + intervention. GDPR is explicit here (Article 22(3)): Article 22(3) right to obtain human intervention, express point of view, contest the decision. HIPAA is mentioned only by comparison. Bias + fairness testing. GDPR is partial here (Article 5(1)(a); Recital 71): Article 5(1)(a) lawful, fair, transparent; Recital 71 calls out discrimination prevention in profiling. HIPAA is not addressed by comparison. These gaps are the practical argument against treating either framework as complete on its own. If you adopt only HIPAA, the GDPR-stronger dimensions above are the ones an auditor or regulator will find unaddressed.

Start with GDPR (Regulation 2016/679, Articles 22, 25, 35). It is regulatory, it is in force from May 25, 2018, and non-compliance carries Up to EUR 20 million or 4% global turnover (Article 83). Deadlines and penalties dictate sequencing regardless of which framework is intellectually tidier. Then layer HIPAA Privacy + Security Rules. Because it is sectoral, it earns its place by making the first one repeatable and evidenced rather than by adding a separate obligation. Teams that invert this order tend to build an elegant management system and still miss a statutory deadline. The efficient path is to scope HIPAA around the evidence GDPR already forces you to produce, rather than running two programmes side by side.

Areebi does not certify you against either framework. What it does is produce the runtime evidence both of them ask for, from the same control plane, so the overlap above becomes real rather than theoretical. For HIPAA: PHI-aware DLP blocks unauthorised disclosures; BAA signed with hosting provider. 164.312(b) audit controls satisfied by immutable, 6-year-retainable audit log. Per-user access controls with break-glass workflow for 164.312(a) requirements. Encryption at rest and in transit (164.312(a)(2)(iv) addressable) on by default. For GDPR: Article 32 security satisfied by encryption, access controls, and BYOK options. Article 30 records supported by per-tenant processing-activity logs. DPA + Article 28 sub-processor list maintained for tenant download. Article 22 contestability workflows hookable from Areebi response policy. The common thread is that both frameworks want to know what your AI systems actually did, not what your policy said they should do. That is an operational logging and enforcement problem before it is a documentation problem.