A HIPAA compliance programme does not make a health organisation GDPR compliant, because the two laws start from opposite ends: HIPAA regulates named types of US health entities and the uses they may make of health information, while the GDPR regulates anyone processing personal data of people in the EU and treats health data as a prohibited category unless an exception applies. This guide compares territorial and entity scope, lawful basis against permitted uses, breach notification clocks, business associate agreements against Article 28 processor contracts, and the security controls that satisfy both. It is written for privacy, security and compliance leads at health organisations and vendors operating in both markets.
Status checked on 14 November 2026 against EUR-Lex (Regulation (EU) 2016/679, applicable since 25 May 2018) and HHS Office for Civil Rights pages on the HIPAA Privacy, Security and Breach Notification Rules. The HHS proposed update to the HIPAA Security Rule was still a proposal on that date.
Key takeaways
- Scope runs on different axes. HIPAA applies to covered entities (health plans, clearinghouses and providers that transmit standard transactions electronically) and their business associates. The GDPR applies to any controller or processor with an EU establishment, or offering goods or services to, or monitoring, people in the EU (Article 3).
- Permission works in reverse. HIPAA permits treatment, payment and health care operations without authorisation. The GDPR prohibits processing health data (Article 9(1)) unless an Article 9(2) condition applies, and an Article 6 lawful basis is needed on top.
- The breach clocks differ by an order of magnitude. GDPR: notify the supervisory authority within 72 hours of awareness unless the breach is unlikely to result in a risk. HIPAA: notify individuals without unreasonable delay and no later than 60 days after discovery, with HHS and media notice depending on the count.
- Contracts are similar but not interchangeable. A business associate agreement and an Article 28 data processing agreement overlap on safeguards, subcontractors and return or destruction, but each has terms the other lacks. Use one contract with two schedules, not one template stretched over both.
- The security core can be shared. Risk analysis, access control, encryption, logging and tested incident response satisfy HIPAA Security Rule standards and GDPR Article 32 at the same time, provided the evidence is mapped to both.
The short answer
HIPAA is a sectoral US law about who may use protected health information (PHI) and how it is safeguarded; the GDPR is a general EU law about whether any processing of personal data is lawful at all. HIPAA compliance answers part of the GDPR question (security of processing, processor contracts, breach handling) but not the core one: whether you have a legal basis to process the health data in the first place. A US telehealth provider marketing consultations to patients in Ireland is inside both.
| Dimension | GDPR | HIPAA |
|---|---|---|
| Who is regulated | Any controller or processor within Article 3 scope, in any sector | Covered entities and business associates only |
| Data protected | All personal data; health data is a special category (Article 4(15), Article 9) | PHI: individually identifiable health information held or transmitted by a covered entity or business associate, in any form |
| Default position | Processing of health data prohibited unless an Article 9(2) condition applies | Uses for treatment, payment and health care operations permitted; authorisation for other uses |
| Breach notice to regulator | Within 72 hours of awareness (Article 33) | 500 or more affected: within 60 days; fewer than 500: annual log within 60 days of year end |
| Breach notice to people | Without undue delay if likely high risk (Article 34) | All affected individuals, no later than 60 days after discovery, unless low probability of compromise is shown |
| Vendor contract | Article 28(3) processor terms | Business associate agreement (45 CFR 164.504(e)) |
| Anonymised or de-identified data | Truly anonymous data is outside scope; pseudonymised data stays personal data | Data de-identified by Safe Harbor or Expert Determination is no longer PHI |
| Maximum administrative fines | Up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, for Article 9 and transfer breaches (Article 83(5)) | Tiered civil money penalties by culpability, adjusted for inflation; criminal penalties under the statute |
Territorial and entity scope
GDPR: where and to whom
Article 3(1) applies the GDPR to processing in the context of the activities of an EU establishment of a controller or processor, wherever the processing physically takes place. Article 3(2) reaches organisations with no EU establishment when they process personal data of people in the EU in connection with offering them goods or services, or monitoring their behaviour in the EU. A non-EU controller caught by Article 3(2) must designate a representative in the Union in writing (Article 27(1)), unless its processing is occasional, excludes large-scale special category data and is unlikely to result in a risk.
Typical health triggers: an EU clinic or subsidiary (3(1)); a portal or telehealth service promoted to EU residents (3(2)(a)); remote monitoring or wellness apps tracking users in the EU (3(2)(b)); and processing for an EU controller.
HIPAA: which entities
HIPAA reaches three kinds of covered entity: health plans, health care clearinghouses, and health care providers of any size that electronically transmit health information in connection with standard transactions such as claims or eligibility checks. HHS notes that using email alone does not make a provider covered. Business associates, people or organisations that perform functions or services for a covered entity involving PHI, are directly liable for Security Rule compliance and for uses and disclosures their contract does not permit. HIPAA has no territorial test: a consumer health app that is neither a covered entity nor a business associate sits outside HIPAA even if it holds detailed health data, which is where state health privacy laws and the FTC rule come in. See the Health Data Privacy Beyond HIPAA Guide (My Health My Data) and the FTC Health Breach Notification Rule Guide.
Lawful basis versus permitted uses
This is where HIPAA thinking most often misleads GDPR programmes. Under HIPAA, a covered entity may use and disclose PHI for treatment, payment and health care operations without authorisation, may disclose for listed public interest purposes such as public health, and needs a written authorisation for most other uses. The minimum necessary standard limits how much PHI is used or disclosed, except for treatment and a few other cases.
Under the GDPR the controller needs two things for health data: an Article 6 lawful basis and an Article 9(2) condition. The conditions most used in health are explicit consent (Article 9(2)(a)), medical diagnosis, provision of care and management of health systems by or under the responsibility of a professional bound by secrecy (Article 9(2)(h) with 9(3)), public health (Article 9(2)(i)) and scientific research with safeguards (Article 9(2)(j)). Article 9(4) lets Member States add further conditions for genetic, biometric and health data, so national law matters. See GDPR Variations in Six EU Member States.
| Activity | HIPAA position | GDPR position |
|---|---|---|
| Treating the patient | Permitted without authorisation (treatment) | Article 9(2)(h) with professional secrecy; Article 6 basis such as contract or vital interests |
| Quality improvement analytics | Permitted (health care operations) | Needs a condition; often 9(2)(h) or (i), sometimes consent; purpose limitation applies |
| Marketing a new service | Authorisation generally required | Explicit consent is the realistic route; ePrivacy rules may also apply |
| Research on records | Authorisation, IRB or privacy board waiver, limited data set or de-identification | Article 9(2)(j) with Article 89 safeguards, or explicit consent; national research laws |
| Training an AI model on records | Health care operations only if within the definition; otherwise authorisation or de-identification | Needs a fresh Article 6 basis and Article 9 condition; DPIA required for large-scale health data (Article 35(3)(b)) |
Consent is not interchangeable. A HIPAA authorisation is a specific written document naming the information, recipients, expiry and the right to revoke. GDPR explicit consent must be freely given, specific, informed and unambiguous, and can be withdrawn at any time; reliance on it for core care is fragile because a patient who withdraws leaves you without a basis. Most EU health providers rely on Article 9(2)(h) for care and keep consent for optional processing. For AI-specific bases see the AI and GDPR Guide.
De-identification is not anonymisation. HHS says data meeting Safe Harbor (removal of 18 identifier categories with no actual knowledge of re-identification) or Expert Determination is no longer PHI. Under the GDPR, data that can still be attributed to a person with additional information is pseudonymised personal data and remains in scope. A Safe Harbor dataset sent to an EU research partner may still be personal data in the partner's hands.
Breach notification: 72 hours versus 60 days
The two definitions start differently. GDPR Article 4(12) defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data, which includes availability incidents such as ransomware that locks records. HIPAA defines a breach as an impermissible use or disclosure that compromises the security or privacy of PHI, presumes any impermissible use or disclosure is a breach unless a four-factor risk assessment shows a low probability of compromise, and applies notification only to unsecured PHI, meaning PHI not rendered unusable, unreadable or indecipherable by encryption or destruction to the HHS guidance standard.
| Step | GDPR | HIPAA |
|---|---|---|
| Clock starts | When the controller becomes aware | On discovery (first known, or would have been known with reasonable diligence) |
| Regulator | Supervisory authority within 72 hours, unless unlikely to result in a risk; phased information allowed (Article 33(4)); reasons for delay if late | HHS: without unreasonable delay and within 60 days if 500 or more affected; otherwise annually, within 60 days of the end of the calendar year |
| Individuals | Without undue delay when likely high risk; exemption where data was made unintelligible, for example encrypted (Article 34(3)(a)) | Written notice without unreasonable delay and no later than 60 days; substitute notice if contact details are insufficient |
| Media | Public communication only as an alternative where individual notice involves disproportionate effort | Prominent media outlets if more than 500 residents of a state or jurisdiction are affected |
| Processor or business associate | Notify the controller without undue delay (Article 33(2)) | Notify the covered entity without unreasonable delay and no later than 60 days after discovery |
| Record keeping | Document every breach, notified or not (Article 33(5)) | Burden of proof: keep evidence that notice was given or not required |
| Encryption effect | Removes the duty to tell individuals if the key was not compromised; authority notice still assessed on risk | Secured PHI falls outside breach notification entirely |
Run one incident process on the GDPR clock: meet 72 hours and the HIPAA risk assessment is drafted with weeks to spare. Note that the HIPAA 60 days is an outer limit, not a safe harbour: HHS expects notice without unreasonable delay. Add US state breach laws, which can be shorter and cover different data. See the Data Breach Notification Checklist and the HIPAA Breach Notification Rule Guide.
Business associate agreements versus Article 28 contracts
Both laws require a written contract before a service provider touches the data, and both flow obligations down to subcontractors. HHS lists the BAA terms, including HHS access to books and records and termination for material breach; GDPR Article 28(3) adds processing only on documented instructions, staff confidentiality, help with all data subject rights and with Articles 32 to 36, and a duty to flag instructions that would infringe the law.
| Term | BAA | Article 28 DPA | Drafting note |
|---|---|---|---|
| Scope of use | Permitted uses and disclosures | Documented instructions | Write one purpose schedule satisfying both |
| Security | Security Rule safeguards for electronic PHI | Article 32 measures | Attach one technical and organisational measures annex mapped to both |
| Breach reporting | No later than 60 days; security incidents also reportable | Without undue delay | Set a contractual deadline in hours (24 to 48 is common) so the controller can meet 72 hours |
| Sub-processors | Same restrictions flow down | Prior authorisation, same obligations, initial processor fully liable | Keep a sub-processor list with change notice |
| Individual rights | Access, amendment, accounting | Assistance with all data subject rights, including erasure and objection | GDPR rights are wider; the DPA schedule must cover them |
| International transfer | Not addressed; offshore storage allowed with BAA and risk analysis | Chapter V transfer tool required (adequacy, SCCs or derogation) | Add SCCs or rely on the EU-US Data Privacy Framework where the importer is certified |
HHS guidance on cloud computing is direct: a cloud provider storing encrypted electronic PHI is a business associate even without the decryption key, the conduit exception covers only transmission services, and offshore storage is permitted if a BAA is in place and the location risk is part of the risk analysis. For EU data the transfer question is separate: the Commission adopted the EU-US Data Privacy Framework adequacy decision (2023/1795) on 10 July 2023, which covers only importers that participate in the framework. See the HIPAA Business Associate Agreements Guide and the GDPR Article 28 Processor Guide.
Security requirements and dual-compliance control mapping
GDPR Article 32 asks for measures appropriate to the risk, naming pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration of access after an incident, and regular testing of effectiveness. The HIPAA Security Rule asks for administrative, physical and technical safeguards for electronic PHI, starting with an accurate and thorough risk analysis, with some implementation specifications required and others addressable. The table maps one control set to both.
| Control | HIPAA anchor | GDPR anchor | NIST CSF 2.0 / SP 800-53 |
|---|---|---|---|
| Data inventory and records of processing | Risk analysis scope (all ePHI) | Article 30 records; Article 35 DPIA | ID.AM-07; RA-3 |
| Legal and contractual requirements register | Policies and procedures; BAAs | Article 5(2) accountability; Article 28 | GV.OC-03; GV.SC-05; SA-9; SR-6 |
| Purpose and authority to process | Permitted uses; authorisations; minimum necessary | Articles 6 and 9; purpose limitation | PT-2; PT-3 |
| Strong authentication for workforce and remote access | Access control and person or entity authentication | Article 32(1)(b) | PR.AA-03; IA-2 |
| Encryption at rest and in transit | Addressable encryption; secured PHI safe harbour | Article 32(1)(a); Article 34(3)(a) | PR.DS-01; SC-28 |
| Audit logging and review | Audit controls; information system activity review | Article 32(1)(b) and (d) | DE.CM-03; AU-6 |
| Incident response and notification | Security incident procedures; Breach Notification Rule | Articles 33 and 34 | RS.CO-02; RS.CO-03; IR-6; IR-8 |
For ISO/IEC 27001:2022 users, Annex A controls 5.34 (privacy and protection of PII), 5.20 (supplier agreements), 5.24 to 5.26 (incident management) and 8.24 (use of cryptography) carry the same evidence. For the HIPAA side in depth see the HIPAA Security Rule Guide; for the GDPR side, the GDPR Compliance Guide for Security Teams.
Where identity fits
Both laws turn on who and what can reach health data, and service accounts, integration engines, API keys and AI agents now reach more records than staff do. Inventory every non-human identity with access to EHR, claims or analytics stores, tie each to an owner and a documented purpose (which doubles as the Article 30 record and the HIPAA minimum necessary justification), and log its access. The Change Healthcare breach began with a stolen credential on a remote-access portal without multi-factor authentication at a clearinghouse, and its notification exercise ran for months across covered entities. See the AI Agents in Healthcare guide.
Decision guidance
- Only US patients, no EU presence or targeting: HIPAA and state law; document why the GDPR does not apply, and recheck when marketing or apps change.
- US covered entity with EU patients or an EU subsidiary: build a GDPR layer on the HIPAA programme: Article 9 conditions per purpose, Article 27 representative if no establishment, DPIAs, transfer tools and a 72-hour incident runbook.
- Vendor serving both markets: sign BAAs with US clients and Article 28 DPAs with EU clients from one master contract; commit to the shortest breach deadline in both.
Worked scenario: a US telehealth provider expands to Ireland
A US telehealth company, a HIPAA covered entity, launches video consultations for patients in Ireland from US servers. It is now within GDPR Article 3(2)(a) and appoints an EU representative. Care rests on Article 9(2)(h) with clinicians under professional secrecy; analytics on consultation transcripts gets its own purpose assessment and a DPIA. Its cloud provider already has a BAA; the company adds an Article 28 schedule and a transfer tool. Six months later a leaked integration token for its scheduling vendor is used to read 2,000 records, 300 of them Irish. The lead authority is notified inside 72 hours with phased details, Irish patients are told without undue delay because consultation notes were exposed, and the US risk assessment, individual notices and HHS log entry follow well inside 60 days. The token is replaced with a short-lived credential.
How to implement: phased approach
- Scope: map every product, site and data flow against Article 3 and the covered entity and business associate definitions; record the conclusion and its reasoning.
- Purpose register: for each processing purpose, list the HIPAA permission or authorisation and the GDPR Article 6 basis and Article 9 condition. Gaps here are the real work.
- Contracts: consolidate BAA and DPA terms into one master agreement with schedules; set breach reporting deadlines in hours; add transfer tools.
- Controls: map the Security Rule safeguards and Article 32 to one control set and one evidence library; run a combined risk analysis and DPIA where health data is processed at scale.
- Incident runbook: one triage with a 72-hour branch and a HIPAA four-factor branch; pre-draft notices; test with a tabletop that crosses both.
- Review and roll back: pilot in one product line, review findings with counsel, then extend; if a basis or contract term proves wrong, stop that processing purpose until it is fixed rather than amending records afterwards.
Detection and measurement
- Purpose coverage: percentage of processing purposes with both a HIPAA permission and a GDPR basis and condition recorded (target 100%).
- Notification timeliness: hours from awareness to authority notification for GDPR-scope incidents, and days from discovery to individual notice for HIPAA.
- Contract coverage: percentage of vendors touching health data with a signed BAA or DPA and a breach deadline of 72 hours or less.
- Non-human access: number of service accounts and tokens with access to health data that lack an owner or purpose record.
Common failure patterns
- Treating a BAA as a DPA: it lacks instructions, full data subject rights assistance and transfer terms.
- Using the HIPAA 60 days as the plan: the GDPR 72 hours has already passed by the time the HIPAA risk assessment is finished.
- Assuming de-identified means anonymous: Safe Harbor data can remain pseudonymised personal data under the GDPR.
- Forgetting availability breaches: ransomware that only encrypts records is a GDPR personal data breach, and under HIPAA it still needs the documented four-factor assessment rather than being dismissed as an outage.
Practitioner checklist
- Document whether each entity and product falls under GDPR Article 3 and HIPAA covered entity or business associate status.
- Record an Article 6 basis and Article 9 condition for every health data purpose, alongside the HIPAA permission.
- Run DPIAs for large-scale health data processing and fold in the HIPAA risk analysis.
- Use one master contract with BAA and Article 28 schedules and a breach deadline in hours.
- Put a Chapter V transfer tool in place for EU data processed in the US.
- Operate one incident process on the 72-hour clock with a HIPAA four-factor branch.
- Inventory and own every service account, token and agent with access to health data.
Standards and references
- EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation)
- HHS: Summary of the HIPAA Privacy Rule
- HHS: Breach Notification Rule
- HHS: Sample Business Associate Agreement Provisions
- HHS: Guidance on HIPAA and Cloud Computing
- HHS: Guidance on De-identification of Protected Health Information
- European Commission: EU-US data transfers
Related NHI Mgmt Group resources: HIPAA Privacy Rule Guide · GDPR Compliance Checklist · European Health Data Space Guide · HIPAA vs HITRUST. This guide summarises the GDPR and HIPAA as of November 2026 and is not legal advice.