GDPR in Healthcare: A Practical Guide to Global Compliance

This is some text inside of a div block.
15 mins
September 23, 2026

Table of contents

Key takeaways

  • GDPR applies to any organisation processing the health data of people in the EU or EEA, wherever the organisation is based. A US hospital offering telemedicine to EU patients is in scope.
  • Health data is special category data under Article 9. Processing needs a general lawful basis (Article 6) plus one Article 9 condition, most often medical necessity, public health or explicit consent.
  • GDPR and HIPAA differ on scope, consent, patient rights and penalties. GDPR fines reach 20 million euros or 4% of global turnover; HIPAA civil penalties are capped at 2,190,294 dollars per provision per year (2026 figures).
  • Breaches must be reported to the supervisory authority within 72 hours and to patients without undue delay where the risk is high. Healthcare is the sector with the most notified breaches in several EU countries.
  • New rules are arriving: the European Health Data Space applies in stages from 2029 and AI Act high-risk obligations for medical devices apply from 2 August 2028.

Healthcare organisations worldwide must balance patient care with strict data privacy laws. The EU's General Data Protection Regulation (GDPR) has global implications for GDPR healthcare compliance, extending beyond the EU to any entity handling EU residents' personal data. In the healthcare context, GDPR treats health data as a special category, imposing extra safeguards and transparency measures. This practical guide explains when GDPR applies to healthcare, how it differs from HIPAA, and key compliance steps for protecting patient information. It is written for compliance leads, DPOs and healthcare professionals who need a working understanding of GDPR in healthcare rather than a legal treatise.

When Does GDPR Apply to Healthcare Organisations?

The GDPR's scope is broad. It governs any "controller or processor" operating in the EU (Article 3(1)) and even non-EU entities offering goods/services to EU individuals or monitoring their behavior (Article 3(2)). This means a US-based telemedicine provider or health app targeting EU users must follow GDPR rules. GDPR applies to all healthcare organisations processing EU individuals' data, regardless of location, and any entity within the EU or EEA.

Territorial scope: EU and non-EU applicability

  • Within the EU/EEA: All hospitals, clinics, labs, insurers, research institutes, and digital health platforms are subject to GDPR when handling patient data.
  • Outside the EU: Non-EU health organisations fall under GDPR if they target or monitor EU residents. For example, a US hospital offering telemedicine to EU patients or a clinical research company using EU patient data must comply.
  • Data subjects: GDPR protects the personal data of people in the EU, whatever their nationality, wherever it is processed.

Material scope: what counts as health data

GDPR's material scope covers "personal data related to the physical or mental health of a natural person" (Article 4(15)). This includes information from medical records, treatment histories, lab test results, genetic profiles, biometric data, and any data revealing someone's health status. Recital 35 further explains that health data encompasses "any information on disease, disability, risk of disease, medical history, clinical treatment or medical diagnosis". It covers everything from electronic health records to fitness tracker data if it reveals health information.

Types of organisations that must comply

GDPR compliance extends to all entities handling the health data of EU persons. This includes hospitals, medical practices, health insurers, pharmacies, telehealth providers, public health authorities, research institutions, and even third-party vendors (e.g., cloud IT providers, patient portal software companies). Even if a healthcare organisation is covered by HIPAA in the US, it must also comply with GDPR when processing EU patient data. Conversely, entities not normally covered by HIPAA (like life insurers, employers, or mobile health apps) will still face GDPR obligations if they collect EU health data.

GDPR vs HIPAA: Key Differences for Health Data

Many healthcare entities (especially global ones) must comply with both GDPR and HIPAA. Both of them ensure data protection in healthcare. HIPAA is a US federal law focused on safeguarding Protected Health Information (PHI), whereas GDPR is an EU/EEA regulation protecting all personal data (with additional protections for special categories like health data). Here are some of the key differences in GDPR vs HIPAA.

Roles, responsibilities and contracts

Under GDPR, controllers (e.g., hospitals) determine how and why data is used, while processors (e.g., a cloud provider handling EHRs) follow the controller's instructions. Both must put appropriate safeguards in place. The GDPR explicitly requires that processing by a processor be governed by a contract specifying each party's obligations (Article 28). Similarly, HIPAA requires covered entities to sign Business Associate Agreements with any vendor receiving PHI, ensuring the same safeguards apply.

GDPR also introduces the Data Protection Officer (DPO) role in healthcare (required for large-scale/sensitive processing). The DPO must operate independently (no instructions about their duties, protected from dismissal) and report to top management. Under HIPAA, while not called a DPO, covered entities must designate a Privacy Officer (for the Privacy Rule) and a Security Officer (for the Security Rule) to oversee compliance. Healthcare DPOs often work alongside IT security and clinical risk teams, reviewing contracts and SLAs with vendors, and ensuring DPIA coverage and transfer-impact assessments are performed.

Legal bases and consent models

GDPR: To process health data (Art. 9), explicit consent is one allowed basis, but not the only one. Article 9(2) permits processing without consent if necessary for healthcare provision or public health (e.g., "processing necessary for medical diagnosis, healthcare treatment or management of health" under law or contract). Still, organisations must document the legal basis (Art. 6 for general processing, plus an Art. 9 condition for special data). Consent under GDPR must be "freely given, specific, informed and unambiguous" and in healthcare contexts, obtaining it can be challenging (especially from incapacitated patients). Our guide to GDPR data consent covers the conditions in detail.

HIPAA: There is no GDPR-style "lawful basis" framework. Instead, HIPAA's Privacy Rule defines permitted uses/disclosures of PHI. For example, healthcare providers can share PHI with other providers for treatment without needing patient authorization. Patient "consent" in HIPAA (sometimes called authorization) is only required for uses beyond standard care (e.g., marketing communications, certain research uses). Thus, HIPAA generally allows more flexibility in routine care: consent isn't needed every time a patient's data flows for treatment and billing.

Patient rights and transparency

GDPR grants patients (data subjects) a suite of rights: access, rectification, erasure ("right to be forgotten"), restriction, data portability, and objection. Organisations must have processes to honor these rights, ensuring data protection in healthcare. By contrast, HIPAA grants patients a right to access and amend their records and to receive an accounting of disclosures, but it has no erasure or portability requirement. GDPR generally requires transparent communication. Notices must explain all data uses and the patient's rights. HIPAA requires a simplified Notice of Privacy Practices, but it need not explain rights like erasure or portability. Each GDPR right is examined in the healthcare context in the "Patient Rights Under GDPR in Healthcare" section below.

Enforcement and penalties

Both GDPR and HIPAA carry significant enforcement risk. Under GDPR, serious breaches or noncompliance can trigger fines up to €20 million or 4% of annual global turnover, whichever is higher (Article 83(5)), plus corrective orders by data protection authorities. Under HIPAA, civil penalties are tiered by culpability level, from 145 dollars to 73,011 dollars per violation, with an annual cap of 2,190,294 dollars per provision (inflation-adjusted amounts effective 28 January 2026). HIPAA violations can also lead to criminal charges with jail time (up to 10 years for willful, malicious acts). High-profile healthcare data breaches have led to multi-million-dollar settlements in both regimes, underscoring that patient privacy failures carry steep costs.

Key GDPR Compliance Requirements for Health Data Processing

When processing patient or health data, healthcare entities must embed GDPR principles into operations:. The four requirements below are the ones supervisory authorities test first in a healthcare inspection.

Article 9: special-category data and lawful conditions

GDPR Article 9 prohibits processing "special categories" including health data, unless one of the listed conditions applies. The key GDPR health data conditions for healthcare are:

  • Explicit consent (Art. 9(2)(a)): The patient has given explicit, informed consent for a particular use.
  • Medical necessity (Art. 9(2)(h)): Processing is necessary for medical diagnosis, treatment, or healthcare management, based on law or contract with a health professional bound by professional secrecy.
  • Public health (Art. 9(2)(i)): Necessary for public interest in public health (e.g., controlling epidemics).
  • Research purposes (Art. 9(2)(j)): Public interest research with appropriate safeguards.

Healthcare providers most often rely on the medical necessity condition for treatment and care, but they must document this basis. Any other use of patient data (e.g., marketing, unrelated research) will typically need explicit patient consent.

Data minimisation, purpose limitation, retention

GDPR's foundational principles (Article 5) impose that organisations collect only the minimum health data needed for a specific purpose, and only use it for that purpose. For example, a pharmacy needs minimal patient identifiers and prescription history, but no more. Any collection of unnecessary details (e.g., extensive family history when not needed) violates data minimisation.

Purpose limitation means health data gathered for patient care cannot be repurposed (e.g., sold or used for marketing) without a further lawful basis. Data must not be kept longer than needed: GDPR requires defining clear retention schedules and routinely deleting or anonymising records when no longer necessary. For instance, hospitals might keep medical records for a set number of years per national law and then securely dispose of them. Retention periods for medical records are set by national law, not by the GDPR itself, so the schedule has to be built country by country; our guide to GDPR and data retention explains how.

Security measures for health data

Article 32 mandates appropriate technical and organisational measures to protect data. In healthcare, this means encrypting electronic health records, pseudonymising patient data for research, securing network access, and ensuring backups/disaster recovery. Article 32 specifically mentions pseudonymisation and encryption as examples. Thus, a HIPAA-compliant approach (e.g., access controls, audit logs, and encryption) aligns well with GDPR's security focus. Regular security audits, vulnerability assessments, and incident response drills are also expected under GDPR's accountability requirements.

Vendor and processor management

Healthcare entities often rely on third-party vendors (EHR platforms, analytics services, telehealth providers). GDPR requires them to conduct due diligence on vendors' data protection practices and to sign GDPR-compliant contracts (Data Processing Agreements) that mandate security and compliance. Just as HIPAA requires Business Associate Agreements, GDPR requires clear processor agreements. Organisations should monitor vendor compliance (e.g., by requiring audit rights or certifications) and ensure the same obligations cover subprocessors. In short, Any handling patient data on the organisation's behalf must be held to GDPR standards. The clauses most often missing from healthcare contracts are listed in our article on GDPR processor agreements.

Patient Rights Under GDPR in Healthcare

Patient rights are the point where GDPR healthcare compliance becomes visible to patients. They are the same eight rights that apply to any data subject, but four of them raise specific questions when the data is a medical record: access, rectification and erasure, restriction and objection, and portability. Each is explained below with the healthcare-specific limits that apply.

Right of access to health data

Patients have a GDPR medical records access right: they can obtain a copy of their health data and know why it is processed, who receives it and how long it is kept (Article 15). The response deadline is one month, extendable by two months for complex requests. Two healthcare specifics apply. First, Member State law may allow a health professional to review the record before release where disclosure could seriously harm the patient. Second, notes about third parties (a relative's medical history, for instance) may be redacted to protect their rights. Access requests are the most frequent GDPR request in hospitals, so a standard form, an identity check step and a tracking log are the minimum process.

Right to rectification and erasure

Patients can have inaccurate data corrected (Article 16) and incomplete data completed. Rectification does not mean rewriting clinical judgement: a diagnosis the patient disagrees with is an opinion, not a factual error, and the right response is to add the patient's statement to the record rather than delete the entry. The right to erasure (Article 17) is limited in healthcare because most records are kept under a legal retention obligation or for public health and research purposes, which are explicit exceptions in Article 17(3). Erasure requests should therefore be assessed against the retention schedule, and the reasons for refusal explained to the patient in writing.

Right to restrict or object to processing

Restriction (Article 18) lets a patient freeze processing while accuracy is disputed or an objection is assessed; the data is kept but not used. Objection (Article 21) applies to processing based on legitimate interests or public task and to any direct marketing, which must stop immediately. It does not apply to processing that is necessary for treatment under Article 9(2)(h), so a hospital does not have to stop using a record needed for ongoing care. Objection to research use is common, and researchers should design studies so that a single participant's data can be withdrawn without invalidating the dataset.

Right to data portability

Portability (Article 20) applies only where processing is based on consent or contract and is carried out by automated means. That excludes most hospital records, which rest on the medical necessity condition, but it does cover patient-facing apps, wearables and private telehealth services that process data on the basis of consent. The European Health Data Space will widen this in practice: from 2029, patients will have a right to access and share their electronic health data across borders in a common European format, whatever the lawful basis of the original processing.

Clinical Research and Cross-Border Data Transfers

Clinical trials and global research introduce special privacy considerations under GDPR:. Two questions dominate: which lawful basis the research relies on, and how data leaves the EU.

GDPR considerations for clinical trials

Clinical trials frequently involve health data processing at scale. GDPR for healthcare requires clinical research to respect patient rights (informed consent, withdrawal, data erasure in some cases) and often mandates Data Protection Impact Assessments (DPIAs) for high-risk studies. Consent forms should clearly explain data use, retention, and international data sharing. Ethical review boards now often require privacy safeguards (e.g., anonymisation for analysis). If a trial spans EU and non-EU sites, researchers must ensure GDPR rules cover all phases (e.g., consents in line with EU standards, appropriate data transfer mechanisms between sites). Informed consent to take part in a trial under the Clinical Trials Regulation is not the same as GDPR consent: the EDPB has confirmed that the GDPR basis is usually public interest or legitimate interest, with Article 9(2)(i) or (j) as the special-category condition. Our guide to Clinical Trial Compliance sets out the full picture.

Cross-border transfers in healthcare and research

Transferring personal health data outside the EU requires GDPR safeguards. Mechanisms include:

  • Adequacy decisions: The EU (and UK) maintains "approved" lists of countries providing adequate protection. Notably, since July 2023, the EU-U.S. Data Privacy Framework (DPF) allows transfers to U.S. organisations that self-certify under the framework. The General Court upheld the DPF on 3 September 2025 (Case T-553/23); an appeal to the Court of Justice (C-703/25 P) is pending, so keep a fallback mechanism ready. Similarly, the UK extended a "data bridge" to the U.S., enabling transfers to certified U.S. entities. However, healthcare organisations should note that some EU Member States impose stricter national rules on health-related cross-border data transfer, which may require additional safeguards.
  • Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs): In the absence of adequacy, exporters can adopt approved SCCs or BCRs. But these must be supplemented by a Transfer Impact Assessment (TIA) evaluating local laws. For example, if sending patient data to a non-adequate country, an organisation may need to implement encryption and strict access controls (a "supplementary measure") on top of SCCs.
  • Derogations: In limited cases (e.g., explicit patient consent, vital interests), derogations may permit specific transfers, but these are narrow and risky for routine practice.
  • Remote platforms and shared data: For telemedicine platforms or health data lakes, additional technical measures are crucial. Encrypted cloud services and robust access management help address cross-border challenges.

Practical Steps to Operationalize GDPR in Healthcare

To turn theory into practice, healthcare organisations should take concrete steps:. The four below cover the documentation, risk assessment, people and incident-response pillars that every supervisory authority inspects.

Data mapping and records of processing

Start by creating a GDPR patient data map. Document what patient data is collected, from where, how it flows (e.g., from clinics to labs to insurance), and who receives it. Article 30 requires maintaining a Record of Processing Activities (RoPA) that lists categories of health data, purposes, recipients, retention periods, and security measures. For each department (e.g., Radiology, Billing, Research), record the types of data processed and legal bases. This inventory is critical for audits and DPIAs.

DPIAs and high-risk processing

Under Article 35, a Data Protection Impact Assessment (DPIA) is mandatory when processing health data on a large scale or with new technologies. Any high-risk processing (e.g., genetic profiling, patient tracking, or linking hospital records across countries) should trigger a DPIA. A DPIA should systematically describe the processing activity, assess its necessity and proportionality, identify privacy risks, and outline safeguards. For example, a hospital implementing a new AI diagnostic tool on patient data would perform a DPIA to ensure the risks (like re-identification) are mitigated. Regulators expect DPIAs for major projects involving patient data.

Staff awareness and training

Human error is a major risk. Regular training on GDPR basics (data subject rights, secure handling of patient data, phishing awareness) is essential for all healthcare staff -, from doctors to admin to IT. Training should cover the differences between GDPR and HIPAA obligations, the importance of not over-collecting data, and procedures for patient data requests. Customised scenarios (e.g., "what to do if a patient withdraws consent" or "how to securely email test results") reinforce learning. Leadership must foster a privacy-conscious culture. GDPR for healthcare professionals works best when it is taught through clinical situations rather than legal articles: a ward round, a discharge letter, a referral to a specialist.

Breach response and incident management

Healthcare organisations must have an incident response plan to address data breaches. Under GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to individuals. If patient data is compromised, affected individuals must also be notified without undue delay where the risk is high. HIPAA's breach rule is longer (60 days for large breaches), but under GDPR, the clock is much shorter. Plans should include detection, containment, risk assessment (does it involve health data?), internal escalation, notification templates, and post-incident review. Testing this plan (e.g., simulations) is a best practice. Have a documented data breach response plan so your team can act swiftly to protect patients and comply with regulators. The next section goes deeper into how breaches happen in healthcare and how to report them.

Data Breaches and GDPR in Healthcare

Data breaches in healthcare attract more regulatory attention than in any other sector because the data is sensitive, the volumes are large and the harm to patients can be irreversible. Healthcare is consistently among the sectors with the highest number of breach notifications to EU supervisory authorities. This section covers the three things a GDPR patient data breach plan must get right: knowing how breaches happen, assessing and reporting them, and telling patients.

Common causes of healthcare data breaches

  • Ransomware and intrusion: Hospitals are targeted because downtime endangers lives, which raises the pressure to pay. Encrypted records that cannot be accessed count as a breach of availability under GDPR even if no data is stolen.
  • Misdirected communications: Results or letters sent to the wrong patient, email or fax number. Low-tech, very frequent, and reportable when health data is involved.
  • Excessive internal access: Staff consulting records of patients they do not treat. Access logs and periodic reviews are the control; several EU authorities have fined hospitals for their absence.
  • Vendor incidents: Breaches at a software supplier, laboratory or cloud host. The controller remains responsible for notification, which is why the processor agreement must set a short internal notification deadline.
  • Lost or stolen devices and paper: Unencrypted laptops, USB keys and printed records left in public places.

Assessing and reporting a personal data breach

Assessing a breach means answering three questions within hours, not days: what data was affected, how many patients, and what could happen to them. For health data the answer to the third question is almost always "a risk", so notification to the supervisory authority within 72 hours (Article 33) is the default assumption. If the full picture is not known within 72 hours, notify in phases: the initial notification with what is known, then supplementary information as it arrives. Every breach, including those not notified, must be recorded in an internal breach register (Article 33(5)) with the facts, effects and remedial action. Organisations that also fall under HIPAA should run the two clocks in parallel, since the GDPR deadline arrives long before HIPAA's 60 days.

Communicating breaches to affected individuals

Patients must be informed without undue delay when a breach is likely to result in a high risk to their rights and freedoms (Article 34). Exposure of diagnoses, mental health notes, sexual health or genetic data almost always meets that threshold. The communication must be in clear, plain language and state the nature of the breach, the DPO's contact details, the likely consequences and the measures taken, including steps patients can take themselves. Communication can be avoided only where the data was encrypted and the key not compromised, where measures have removed the high risk, or where individual contact would take disproportionate effort, in which case a public communication is used instead. A pre-approved patient letter template, translated into the languages your patients speak, saves days when the clock is running.

Special Topics in Healthcare Data Compliance

Two topics sit slightly outside the core GDPR framework but come up in almost every digital health project: children's data and the ePrivacy rules on tracking.

Children's data and adolescent consent

GDPR recognises children as having special protection. For online information society services aimed at minors, the general rule is that consent of a parent or guardian is required for children under 16 (EU default; Member States can lower to 13) under Article 8. UK GDPR sets the threshold at 13. In pediatric settings, even beyond online services, healthcare providers should verify appropriate consent procedures for adolescents. For example, a mental health app targeting 15-year-olds in Germany would need parental permission under GDPR. Consent to medical treatment itself is governed by national health law, not Article 8, and the two should not be confused.

ePrivacy and tracking in digital health tools

Separately from GDPR, the ePrivacy Directive regulates the confidentiality of electronic communications. Telehealth platforms must secure patient communications (no listening or recording without consent) and manage cookies/tracking. Any app or website that uses cookies to track users' health-related browsing requires consent under ePrivacy. Medical device connectivity also triggers ePrivacy rules. Healthcare organisations should treat ePrivacy compliance (cookie banners, opt-ins for marketing) as part of overall data protection. The draft ePrivacy Regulation that was meant to replace the Directive was withdrawn by the European Commission in early 2025, so the 2002 Directive and its national transpositions remain the applicable law.

AI and Emerging Technologies in Healthcare Data

AI in healthcare data processing is now governed by three overlapping instruments: the GDPR (which already applies), the EU AI Act (phasing in) and the European Health Data Space Regulation (applying from 2029). The practical consequence for a GDPR healthcare programme in a hospital or health-tech company deploying AI is that a single project may need a DPIA, an AI Act conformity assessment and, in future, an EHDS secondary-use permit.

  • GDPR applies today. Training or running a model on patient data is processing of special category data. It needs an Article 9 condition, a DPIA under Article 35 and, where decisions are fully automated with significant effect, the Article 22 safeguards. Re-identification risk in "anonymised" training sets is the point regulators probe first.
  • EU AI Act timeline. Most medical AI is high-risk because it is embedded in a medical device regulated under the MDR or IVDR (Annex I of the AI Act). Following the Digital Omnibus on AI adopted in 2026, high-risk obligations for Annex I products apply from 2 August 2028 and for stand-alone Annex III systems from 2 December 2027. Transparency duties under Article 50, such as telling patients they are interacting with an AI system, apply from 2 August 2026. Our guide to the EU AI Act tracks the dates.
  • European Health Data Space. Regulation (EU) 2025/327 creates a right for patients to access and share their electronic health data across the EU and a permit system for secondary use of health data in research and AI development, with most obligations applying from 26 March 2029. Our article on the European Health Data Space (EHDS) explains what it changes for controllers.
  • Generative AI in clinical documentation. Ambient scribes and AI-drafted reports are the fastest-growing use case. They raise lawful basis, transparency and processor questions that we examine in AI-generated medical reports.

What this means for you: run the DPIA and the AI Act risk classification together. The two assessments share most of their inputs, and doing them in one exercise avoids the common finding that the AI vendor was contracted before anyone checked whether the tool was high-risk.

The Role of the Data Protection Officer in Healthcare

A DPO has a multifaceted role for data protection in healthcare:. Public health bodies must appoint one, and private providers processing health data at scale almost always meet the Article 37 threshold.

  • Responsibilities and independence: The DPO monitors GDPR compliance across clinical and IT operations. By law, the DPO must act independently (not directed by management on how to do their job) and report directly to top leadership. They advise on new systems (e.g., an AI diagnostic) or projects (e.g., data sharing agreements), and ensure all processing of health data is lawful.
  • Governance and KPIs: An effective healthcare privacy program often sets metrics such as the number of DPIAs completed, the percentage of staff trained, breach incidents/response times and audit results. The DPO works with IT and quality teams to integrate privacy into risk registers and compliance frameworks (e.g., ISO 27701). DPOs also liaise with clinical risk committees, so patient safety and privacy go hand-in-hand.

Core tasks: According to GDPR Art 39, the DPO's tasks include informing and advising on compliance obligations, training and auditing staff, advising on DPIAs, and cooperating with Data Protection Authorities. In healthcare, this translates to things like running GDPR for healthcare professionals workshops on patient data rights, reviewing consent forms, and ensuring research protocols include data safeguards.

Aligning GDPR With Other Frameworks

Many healthcare organisations already follow security standards like ISO 27001 or the NIST Cybersecurity Framework. GDPR can be integrated with these:

  • ISO 27001/27701: An existing ISO 27001 Information Security Management System can incorporate ISO 27701 to manage privacy. Many GDPR requirements align with ISO controls (e.g., ISO/IEC 27001:2022 control 5.34 covers privacy and protection of personal data, and controls 5.24 to 5.28 cover incident management, which supports breach notification). Using these standards helps structure GDPR compliance.
  • NIST CSF and Privacy Framework: NIST's frameworks cover risk management and privacy outcomes that overlap with GDPR's Article 32 security and risk assessment requirements. For example, NIST CSF's "Protect" function addresses encryption (Article 32) and identity management
  • Health-specific controls: Guidelines like the HITRUST CSF or NHS data standards can be cross-walked to GDPR. For instance, if a hospital follows NIST or PCI on patient data access, those measures often satisfy GDPR's need for "integrity and confidentiality". Our comparison of Healthcare Data Compliance frameworks shows how HIPAA, GDPR and HITRUST map to one another.
  • Bridging registers: It's wise to combine privacy and cybersecurity risk registers. Many threats (ransomware, insider breaches) impact both. A unified register prevents gaps and shows auditors a holistic view.
  • Automation and tools: Privacy management software (like ROPA and DPIA automation tools) can streamline compliance. Automated questionnaires for DPIAs, breach reporting checklists, and centralised documentation systems help collect evidence for audits and reduce manual effort.

On the international front, organisations also need to consider other data protection laws. For example, Canada's PIPEDA has some parallels with GDPR. Reviewing differences (e.g., consent requirements under PIPEDA vs GDPR) ensures global strategies work everywhere.

For a cohesive approach, aligning GDPR requirements with existing information security measures and privacy practices makes compliance more efficient and less redundant.

Get Expert Help with GDPR for Healthcare

Given the complexity of GDPR in healthcare, many organisations seek outside expertise. DPO Consulting is an expert partner helping organisations with GDPR compliance. GDPR healthcare compliance can feel overwhelming, particularly when it comes to ensuring your privacy team stays current with the latest legal requirements, internal procedures, and technical protocols. We are your trusted partner in building in-house expertise through practical, scalable training and coaching tailored to your healthcare needs. We begin with a comprehensive Compliance Audit Services engagement to identify gaps in your privacy program (records, policies, technical controls) and recommend fixes tailored to healthcare.

Our DPO Consulting team specialises in healthcare data privacy through our dedicated Health Sector GDPR Compliance practice. We can help you interpret GDPR articles in clinical contexts, integrate privacy with clinical risk management, and ensure you have processes (consent management, breach response, cross-border protocols) that withstand regulatory scrutiny. US organisations that also process EU patient data can pair this with our HIPAA Compliance Services so one programme covers both regimes. With expert support, you can focus on patient care while maintaining robust privacy compliance. Request a healthcare GDPR assessment to get a scoped plan within one call.

FAQ

Does GDPR apply to US-based healthcare organisations?

Yes, if a U.S. healthcare provider processes personal data of EU residents or markets services to them, GDPR applies. For instance, a U.S. hospital offering online appointments to EU patients must comply. Even if the hospital is not physically in the EU, GDPR's Article 3(2) captures any controller targeting or monitoring EU individuals.

What qualifies as health data under GDPR?

Health data means any personal data about physical or mental health status. This includes medical records, diagnoses, test results, genetic information, or any information revealing health conditions. Anything you'd find in a patient's file (or that reveals illness or treatments) counts as health data.

Can GDPR and HIPAA both apply at the same time?

Yes. For example, a multinational hospital chain may be subject to GDPR when handling EU patient data and HIPAA for US patient data. Even a single patient's data could be subject to both if they cross borders. When both apply, you must satisfy both sets of rules (often HIPAA's baseline security plus GDPR's extra requirements for consent and rights).

What are the penalties for non-compliance?

GDPR fines can reach the higher of €20 million or 4% of global annual turnover. HIPAA violations carry tiered civil penalties 145 to 73,011 dollars per violation) capped at 2,190,294 dollars per provision per year as of January 2026, plus possible criminal charges (jail time for willful violations). In both regimes, settlements and reputation damage can be even more costly.

How do we conduct a DPIA in a healthcare setting?

You can start by describing the processing (what data, why, who, how long). Then assess necessity and proportionality (is this processing needed for patient care or research?). Identify risks to patients (e.g., re-identification, unauthorised access) and list measures to mitigate them (encryption, access controls, consent protocols). Document this assessment thoroughly.

Do we need consent for every use of patient data?

Not necessarily. Under GDPR, explicit consent is one lawful basis, but not the only one. If processing is necessary for treatment or mandated by law, organisations can rely on those legal bases instead of fresh consent. HIPAA similarly allows PHI use for treatment/payment without authorization. However, any secondary use (e.g., research not covered by care) generally requires explicit patient consent under GDPR (or HIPAA authorization in the U.S.), unless a public interest or research condition applies.

How do we manage cross-border patient data transfers?

You can use GDPR-approved mechanisms. Transfers to a country with an EU adequacy decision (or to a US DPF-certified organisation) can flow freely. Otherwise, implement Standard Contractual Clauses (SCCs) or Binding Corporate Rules with a Transfer Impact Assessment and extra safeguards (e.g., encryption at rest) as needed. For example, if sending research data from an EU hospital to a U.S. lab, ensure the lab is DPF-certified or sign SCCs and document the transfer rationale.

How long can healthcare organisations retain patient data?

GDPR medical records retention has no fixed period; the regulation requires that health data be kept no longer than necessary for the purpose (Article 5(1)(e)). Retention is set by national health law, which typically requires medical records to be kept for many years after the last contact with the patient, and longer for minors or in certain specialities. Build the retention schedule from national law first, then apply GDPR to everything national law does not cover, such as appointment logs, marketing data and website analytics.

What security measures should healthcare organisations use to protect health data?

Article 32 expects measures appropriate to the risk, and GDPR health data security means, at a minimum: encryption of records at rest and in transit, role-based access with logging and periodic review, multi-factor authentication for remote and administrative access, pseudonymisation for research and analytics, tested backups, a patch and vulnerability management process, and staff training. Certification against ISO 27001 or ISO 27701 is not mandatory but is the clearest way to demonstrate the measures to a regulator.

When does a healthcare organisation need to appoint a DPO?

A DPO is mandatory under Article 37 for public authorities and bodies (public hospitals and health agencies) and for any organisation whose core activities involve large-scale processing of special category data, which covers most private hospitals, clinic groups, laboratories, health insurers and digital health platforms. A single-practitioner practice is generally exempt, although some Member States, and several national medical bodies, recommend appointing one. Outsourcing the role is permitted and common where in-house expertise is thin.

References

  • European Parliament and Council. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 3, 4(15), 5, 8, 9, 15 to 22, 28, 30, 32 to 35, 37, 39 and 83. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj
  • European Parliament and Council. (2025). Regulation (EU) 2025/327 on the European Health Data Space. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2025/327/oj
  • European Parliament and Council. (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  • General Court of the European Union. (2025, September 3). Judgment in Case T-553/23, Latombe v Commission. https://curia.europa.eu
  • U.S. Department of Health and Human Services. (2026, January 28). Annual civil monetary penalties inflation adjustment, 45 CFR Part 102. Federal Register. https://regulations.justia.com/regulations/fedreg/2026/01/28/2026-01688.html
  • European Parliament and Council. (2002). Directive 2002/58/EC (ePrivacy Directive). Official Journal of the European Communities. https://eur-lex.europa.eu/eli/dir/2002/58/oj

Read this next

See all