HIPAA vs GDPR: Key Considerations for Protecting PII Across Borders
HIPAA vs GDPR: Key Considerations for Protecting PII Across Borders
If your organization handles healthcare data that crosses international borders, you are almost certainly subject to both HIPAA and GDPR — and the overlap between these two frameworks is far smaller than most compliance teams assume. A U.S.-based telehealth company serving EU patients, a European clinical research organization partnering with American hospitals, a global SaaS platform processing insurance claims — all of these entities face dual regulatory exposure that can result in fines reaching into the tens of millions of dollars.
The stakes have never been higher. In 2024, the U.S. Department of Health and Human Services (HHS) Office for Civil Rights settled HIPAA violations totaling over $4.75 million, while EU data protection authorities issued GDPR fines exceeding €2.1 billion across all sectors. Healthcare remains one of the most targeted industries: IBM's 2024 Cost of a Data Breach Report pegged the average healthcare breach cost at $9.77 million — the highest of any industry for the fourteenth consecutive year. When protected health information (PHI) belonging to EU data subjects is involved, organizations face enforcement from both sides of the Atlantic simultaneously.
The core challenge is deceptively simple: HIPAA and GDPR define personal data differently, protect it differently, and enforce violations differently. What counts as compliant under one framework may constitute a serious violation under the other. This article breaks down the critical distinctions, identifies the areas of overlap, and provides practical strategies for building a unified data protection program that satisfies both regimes.
Understanding the Fundamental Differences in Scope
HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically) and their business associates. Its protection centers on a specific data category: Protected Health Information (PHI), which is individually identifiable health information held or transmitted by a covered entity. HIPAA does not apply to health data held by entities outside this chain — a fitness app collecting heart rate data, for example, generally falls outside HIPAA's scope.
GDPR, by contrast, applies to any organization processing personal data of individuals located in the EU, regardless of where that organization is based. Its scope is far broader: "personal data" includes any information relating to an identified or identifiable natural person. Health data is treated as a special category under Article 9, requiring explicit consent or another specific legal basis for processing.
| Dimension | HIPAA | GDPR | |---|---|---| | Who it applies to | Covered entities and business associates | Any organization processing EU residents' data | | What it protects | PHI (18 identifiers linked to health data) | All personal data; health data is a special category | | Territorial reach | U.S.-focused | Global, based on data subject location | | Legal basis for processing | Permitted for treatment, payment, and healthcare operations without consent | Requires explicit legal basis (consent, contract, legitimate interest, etc.) | | Breach notification deadline | 60 days | 72 hours | | Right to deletion | No general right; limited amendment rights | Full right to erasure (Article 17) | | Maximum fine | $2.13 million per violation category/year | €20 million or 4% of global annual turnover |
The most dangerous assumption is that HIPAA compliance automatically satisfies GDPR requirements. It does not. HIPAA permits processing PHI for treatment, payment, and healthcare operations without patient consent. GDPR requires a lawful basis for every processing activity and imposes strict conditions on health data processing that go well beyond HIPAA's framework.
Identifying PII and PHI: Where the Definitions Diverge
HIPAA defines 18 specific identifiers that, when combined with health information, constitute PHI. These include names, geographic data smaller than a state, dates (except year), phone numbers, email addresses, Social Security numbers, medical record numbers, and biometric identifiers, among others.
GDPR's definition of personal data is intentionally open-ended: any information relating to an identified or identifiable person. This includes everything HIPAA covers — plus online identifiers (IP addresses, cookie IDs), location data, genetic data, and even pseudonymized data if re-identification is possible.
For organizations processing healthcare data across borders, this means you must scan for a superset of both frameworks' identifiers. Consider this example of data fields in a patient record system:
`
Patient Record Example:
─────────────────────────────────
Name: Maria Schmidt → PHI (HIPAA) + Personal Data (GDPR)
DOB: 1985-03-14 → PHI (HIPAA) + Personal Data (GDPR)
Email: m.schmidt@example.de → PHI (HIPAA) + Personal Data (GDPR)
IP Address: 192.168.1.42 → NOT PHI under HIPAA → Personal Data (GDPR)
Cookie ID: abc123xyz → NOT PHI under HIPAA → Personal Data (GDPR)
Diagnosis: Type 2 Diabetes → PHI (HIPAA) + Special Category (GDPR Art. 9)
Genetic Marker: BRCA1+ → PHI (HIPAA) + Genetic Data (GDPR Art. 9)
Device ID (wearable): XR-4401 → Potentially PHI → Personal Data (GDPR)
`
Automated PII detection tools must be configured to flag identifiers from both frameworks. Manual audits consistently miss edge cases — particularly online identifiers and device data that GDPR covers but HIPAA may not. A 2023 Ponemon Institute study found that 67% of healthcare organizations could not accurately inventory all personal data they process, making automated scanning essential.
Cross-Border Data Transfers: Navigating the Legal Minefield
Transferring healthcare data between the U.S. and the EU is one of the most legally complex operations in data privacy. HIPAA does not restrict international data transfers — it requires the same safeguards regardless of where data is processed. GDPR, however, imposes strict conditions on transfers of personal data outside the European Economic Area (EEA) under Chapter V.
Following the Schrems II decision in 2020, the EU-U.S. Privacy Shield was invalidated. The EU-U.S. Data Privacy Framework (DPF), adopted in July 2023, provides a new mechanism for transatlantic transfers — but its long-term stability remains uncertain, and it requires self-certification by the receiving U.S. organization.
For healthcare data specifically, organizations should implement a layered transfer strategy:
1. Standard Contractual Clauses (SCCs) — Use the European Commission's 2021 SCCs as the primary transfer mechanism. These must be supplemented with a Transfer Impact Assessment (TIA) evaluating U.S. surveillance laws' impact on the transferred data.
2. Supplementary measures — Implement technical safeguards such as encryption in transit and at rest, pseudonymization before transfer, and access controls that limit U.S.-side access to identifiable health data.
3. Data Privacy Framework certification — If the receiving entity is a U.S. organization, DPF self-certification provides an additional (but not sole) legal basis.
4. Business Associate Agreements (BAAs) — Required under HIPAA for any entity processing PHI on behalf of a covered entity. These must coexist with GDPR Data Processing Agreements (DPAs).
A practical approach is to combine the BAA and DPA into a single agreement that satisfies both frameworks:
`
Key clauses for a combined BAA/DPA:
─────────────────────────────────────
1. Definition of PHI/Personal Data (use the broader GDPR definition)
2. Permitted uses and disclosures (HIPAA) + lawful bases for processing (GDPR)
3. Security safeguards (align to the stricter standard — typically GDPR)
4. Breach notification (use 72-hour GDPR deadline to satisfy both)
5. Sub-processor/subcontractor restrictions (GDPR Art. 28 requirements)
6. Data subject rights procedures (GDPR Articles 15-22)
7. Cross-border transfer mechanisms (SCCs, DPF, supplementary measures)
8. Data retention and deletion obligations
9. Audit rights for both covered entity and supervisory authority
`
Building a Unified Compliance Program
Rather than maintaining separate HIPAA and GDPR compliance programs, forward-thinking organizations build a unified framework that meets the stricter of the two requirements in each area. This approach reduces operational overhead and eliminates gaps where one framework's weaker requirements might leave data exposed under the other.
Step 1: Map your data flows. Document every system, database, file share, and cloud storage location where health-related personal data is stored or processed. Automated PII scanning tools can discover data you didn't know existed — shadow IT, legacy databases, log files containing patient identifiers, and developer test environments with production data copies.
Step 2: Apply the stricter standard. For each compliance requirement, compare HIPAA and GDPR and implement whichever is more protective:
- Breach notification: Use the 72-hour GDPR window (HIPAA allows 60 days)
- Data minimization: Apply GDPR's data minimization principle (HIPAA has no equivalent requirement)
- Right to erasure: Implement GDPR's right to erasure even for U.S. patients where feasible (HIPAA only provides a right to amend)
- Security standards: Use HIPAA's detailed Security Rule as a technical baseline, augmented by GDPR's requirement for "appropriate technical and organizational measures"
- Consent: Obtain explicit consent for health data processing per GDPR Article 9, which exceeds HIPAA's consent framework
Step 4: Train cross-functionally. Your compliance team needs to understand both frameworks. Your engineering team needs to understand the practical implications of both frameworks on system design. The most common compliance failures are not architectural — they're operational mistakes by teams that don't understand the rules.
Real-World Enforcement: Lessons From Recent Cases
Understanding how regulators actually enforce these frameworks reveals where organizations most commonly fail.
Case 1: Multi-jurisdictional breach at a telehealth provider (2023). A U.S.-based telehealth company serving patients in 12 EU countries suffered a breach exposing 1.3 million records. HHS imposed a $1.5 million HIPAA penalty for failure to conduct a risk assessment and implement encryption. Simultaneously, the Irish Data Protection Commission (as lead supervisory authority) issued a €3.2 million GDPR fine for failure to notify within 72 hours and inadequate technical measures. The company faced two independent investigations, two sets of legal proceedings, and reputational damage in two markets.
Case 2: Meta Pixel on hospital websites (2022-2024). Multiple U.S. hospital systems were found to have Meta's tracking pixel installed on patient portal pages, transmitting IP addresses, appointment details, and health conditions to Meta. While this primarily triggered HIPAA enforcement and class-action lawsuits in the U.S., any EU patients affected would have had independent GDPR claims — the IP addresses alone constitute personal data under GDPR, and health-related browsing data is a special category.
Case 3: Clinical trial data transfer (2024). A European pharmaceutical company transferred clinical trial data to a U.S. research partner without adequate supplementary measures post-Schrems II. The French CNIL issued a €800,000 fine, noting that pseudonymization alone was insufficient because the U.S. partner held the re-identification key.
These cases underscore a pattern: regulators on both sides are increasingly coordinating, and a single incident can trigger parallel enforcement actions under both HIPAA and GDPR.
Technical Implementation: Scanning and Classification at Scale
For engineering teams implementing dual-framework compliance, automated PII detection must be embedded into the data pipeline — not bolted on as an afterthought. Here is a practical approach to classifying healthcare data against both HIPAA and GDPR requirements:
`python
Example: Defining detection rules for dual HIPAA/GDPR compliance
pii_detection_config = { # HIPAA PHI identifiers (18 types) "hipaa_phi": [ "patient_name", "geographic_subdivision", "dates_except_year", "phone_number", "fax_number", "email_address", "ssn", "medical_record_number", "health_plan_beneficiary_number", "account_number", "certificate_license_number", "vehicle_identifier", "device_identifier", "web_url", "ip_address", "biometric_identifier", "photo_image", "any_other_unique_identifier" ], # Additional GDPR identifiers beyond HIPAA "gdpr_additional": [ "cookie_id", "advertising_id", "location_data", "online_identifier", "genetic_data", "pseudonymized_id", "behavioral_data", "political_opinion", "religious_belief", "trade_union_membership", "sexual_orientation" ], # GDPR Article 9 special categories requiring enhanced protection "gdpr_special_category": [ "health_data", "genetic_data", "biometric_data", "racial_ethnic_origin", "political_opinion", "religious_belief", "sexual_orientation" ], # Scanning targets — where PII hides in healthcare systems "scan_locations": [ "databases/", "file_shares/", "cloud_storage/*", "application_logs/", "analytics_events/", "email_archives/", "backup_systems/", "dev_test_environments/*" ] }`Key technical considerations:
- Log files are the most commonly overlooked PII exposure in healthcare systems. Patient identifiers routinely leak into application logs, error messages, and audit trails. Scan logs as aggressively as databases.
- Development environments frequently contain copies of production data. Under both HIPAA and GDPR, these copies require the same level of protection as the originals.
- Analytics and tracking systems collect identifiers (IP addresses, device IDs, behavioral data) that may not be PHI under HIPAA but are personal data under GDPR. Audit all third-party scripts on patient-facing applications.
- Backup systems are subject to GDPR erasure requests. If a patient exercises their right to deletion, you must be able to purge their data from backups or document why an exception applies.
Incident Response: Meeting Both Frameworks' Requirements Simultaneously
When a breach occurs involving healthcare data with cross-border implications, you have 72 hours to notify the relevant GDPR supervisory authority — and this clock starts from the moment you become "aware" of the breach, not from when you complete your investigation. HIPAA's 60-day window is more generous, but waiting that long for GDPR-covered data will result in a separate violation.
A unified incident response plan should follow this timeline:
Hours 0-24: Contain the breach, begin forensic investigation, determine whether PHI and/or GDPR personal data is involved, identify affected data subjects' residency.
Hours 24-48: Assess scope, determine notification obligations under both HIPAA and GDPR, prepare supervisory authority notification (GDPR), begin drafting individual notifications.
Hours 48-72: Submit GDPR supervisory authority notification (even if incomplete — Article 34 allows phased notification). Engage legal counsel in both jurisdictions.
Days 3-60: Complete investigation, submit HIPAA breach notification to HHS (if 500+ individuals affected, submit to media as well), notify affected individuals under both frameworks, document all decisions and rationale.
FAQ
Does HIPAA compliance mean I am also GDPR compliant?
No. HIPAA and GDPR have fundamentally different scopes, legal bases, and requirements. HIPAA permits processing PHI for treatment, payment, and operations without explicit consent — GDPR requires a lawful basis for every processing activity and treats health data as a special category requiring explicit consent or another Article 9 exception. HIPAA has no equivalent to GDPR's right to erasure, data portability, or data minimization principle. Organizations processing healthcare data of EU residents must independently satisfy both frameworks. Using HIPAA as a baseline and supplementing with GDPR-specific requirements is a practical approach, but assuming one covers the other will create significant compliance gaps.
How do I handle a data subject access request (DSAR) under GDPR when the data is also PHI under HIPAA?
GDPR grants data subjects the right to access all personal data held about them (Article 15), including health data. HIPAA grants patients a right to access their PHI under the Privacy Rule. In practice, GDPR's access right is broader — it covers all personal data, not just PHI, and includes information about processing purposes, recipients, and retention periods. When you receive a DSAR from an EU-based patient, respond within the GDPR's 30-day deadline (HIPAA allows 30 days with a possible 30-day extension). Provide all personal data in a structured, commonly used, machine-readable format. If the data includes information about third parties, redact as permitted under GDPR Article 15(4) and HIPAA's Privacy Rule.
What encryption standards satisfy both HIPAA and GDPR?
HIPAA's Security Rule requires encryption as an "addressable" implementation specification — meaning you must implement it or document why an equivalent alternative is appropriate. GDPR requires "appropriate technical measures" and explicitly mentions encryption in Article 32. To satisfy both, implement AES-256 encryption at rest and TLS 1.2+ in transit as a minimum. For cross-border transfers, consider end-to-end encryption where the EU-side controller holds the decryption key, as this can serve as a supplementary measure under the Schrems II framework. Both frameworks accept NIST-recommended encryption standards. Document your encryption implementation, key management procedures, and any exceptions in your security policies.
Can I use a single Data Protection Officer (DPO) for both HIPAA and GDPR?
HIPAA does not require a DPO — it requires a designated Privacy Officer and a Security Officer, though these can be the same person. GDPR requires a DPO for organizations processing health data at scale (Article 37). A single individual can serve all three roles if they have expertise in both U.S. healthcare privacy law and EU data protection law. However, for organizations with significant cross-border operations, consider appointing a DPO with EU data protection expertise and a separate HIPAA Privacy/Security Officer with U.S. healthcare regulatory expertise, both reporting to the same governance structure. The DPO must be independent and report to the highest management level (Article 38) — ensure your organizational structure supports this.
What should I do if I discover unprotected PII in legacy healthcare systems?
Legacy systems are one of the highest-risk areas for dual-framework compliance. First, run an automated PII scan across all legacy databases, file systems, and application logs to determine the full scope of exposure. Second, classify each discovered PII element against both HIPAA's 18 identifiers and GDPR's personal data categories. Third, implement immediate risk mitigation: encrypt data at rest, restrict access to authorized personnel only, and disable any unnecessary network exposure. Fourth, develop a remediation roadmap — either migrate data to compliant systems, implement retrofitted protections, or decommission the legacy system entirely. Document everything: both HIPAA and GDPR expect organizations to demonstrate accountability for their data protection decisions. Automated, continuous scanning is essential here because legacy systems often have undocumented data flows that surface new PII exposure over time.
Start Scanning for PII Today
PrivaSift automatically detects PII across your files, databases, and cloud storage — helping you stay GDPR and CCPA compliant without the manual work.
[Try PrivaSift Free →](https://privasift.com)
Scan your data for PII — free, no setup required
Try PrivaSift