Join our Newsletter — 33% off our NHI Course

How should organisations govern health data sharing under the European Health Data Space and GDPR at the same time?

Organisations should treat EHDS and GDPR as complementary, not interchangeable. EHDS governs access, sharing, and reuse of electronic health data across defined participants, while GDPR continues to set the baseline for lawful processing, privacy rights, and security. The practical task is to map each data flow, identify the role of each entity, and align consent, access, retention, and cross-border controls to both regimes.

How EHDS and GDPR fit together in practice

EHDS does not replace GDPR, and GDPR does not disappear because health data is being shared under EHDS. The useful way to govern them is to treat EHDS as the sector-specific rulebook for access and reuse, then use GDPR as the baseline for lawful processing, rights, security, and accountability. That means every sharing arrangement still needs a clear legal basis, a defined purpose, and documented controller or processor roles.

The governance question is usually not “which law wins?”, but “which obligations apply at each step of the flow?” A hospital, research body, payer, or digital health intermediary may be acting under EHDS access rules while still needing GDPR controls for minimisation, access limitation, retention, records, and data subject rights. A single data flow can therefore carry both sector access obligations and ordinary privacy obligations at the same time.

For organisations, the practical unit of governance is the data flow, not the regulation. Map each dataset, each recipient, each purpose, and each transfer path, then decide whether the flow is primary care, secondary use, cross-border exchange, or a mixed use case. The same flow may require different controls depending on whether the organisation is disclosing data, receiving data, or operating an access service in the middle.

EHDS changes the operational shape of health data sharing, but GDPR still drives the privacy and security floor. That means consent, where used, must be real and traceable; access must be limited to the authorised use case; retention must be defensible against both legal regimes; and cross-border handling must respect the applicable transfer and supervisory conditions. Organisations should avoid one-size-fits-all sharing workflows because the compliance risk comes from mismatched purpose, not just from the data itself.

Special category health data makes the alignment stricter, not looser. Under GDPR, health data needs careful lawful-basis analysis, tight purpose limitation, and strong security controls. Under EHDS, the organisation also has to think about standardised access mechanisms, permitted reuse, and the obligations attached to participating in the health data space. A compliant design usually requires privacy by design, role-based access, audit trails, and clear rules for re-identification risk, secondary disclosure, and onward sharing.

That is why identity and access governance matter so much in health data environments. If staff, partners, or platforms can reach more records than their function requires, the organisation can satisfy the text of one regime and still fail the operational intent of both. The strongest Identity Security Regulatory Map and Identity Data Privacy and Consent Guide both point to the same pattern, compliance depends on proving that access, consent, and retention are controlled together rather than as separate workstreams.

How to build a governance model that satisfies both regimes

Start by assigning ownership for legal basis, access governance, and data stewardship separately, but make them report into one operating model. EHDS participation often creates new counterparties, intermediaries, and reuse scenarios, while GDPR creates the obligation to explain and evidence why processing remains lawful. Organisations should keep a living inventory of datasets, processing purposes, recipients, and disclosure channels, because the inventory is what lets you prove that EHDS access and GDPR processing are aligned.

Next, define decision rules for the common edge cases. If the flow is for care delivery, the GDPR basis and patient-facing controls may differ from a secondary-use scenario. If the flow crosses a border or moves to a new participant, the transfer assessment and access conditions need review. If the organisation is relying on delegated access, it needs stronger evidence of authority, logging, and revocation discipline than it would for direct patient-held sharing alone.

For broader control design, it helps to anchor the programme in a documented control framework. The EU General Data Protection Regulation (GDPR) remains the reference point for lawful processing, minimisation, security, and DPIA discipline, while CIS Controls v8 is useful for the operational safeguards that make the policy real, especially inventory, access control, logging, and data protection.

Risk and Threat Considerations

Health data sharing creates compounded risk when sector access rights and privacy obligations are managed separately. The main failure mode is over-disclosure, where a flow is authorised for one purpose but reused, retained, or forwarded beyond that purpose, or where access tooling grants more visibility than the legal basis supports.

Failure mechanism: weak role mapping, poor access review, or inconsistent purpose tagging allows a legitimate EHDS exchange to become an unlawful GDPR processing activity, or allows sensitive records to be exposed through excessive internal or third-party access.

Impact: the organisation can face privacy harm, regulatory findings, loss of trust, and operational disruption, especially if it cannot evidence who accessed what, why they accessed it, and whether the access remained within the declared use case.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 sets the technical controls, while GDPR defines the regulatory obligations.

Framework Control / Reference Relevance
GDPR Art.5 — Principles relating to processing of personal data Health data sharing must still meet purpose limitation, minimisation and accountability.
Art.25 — Data protection by design and by default EHDS-aligned sharing needs privacy controls built into the workflow, not added later.
Art.32 — Security of processing Secure access, logging and retention controls remain mandatory for shared health data.
Recommendation — Map each health data flow to purpose, minimisation and accountability requirements. Design sharing workflows with least access and default restrictions from the outset. Apply proportionate technical and organisational measures to protect shared health data.
CIS Controls v8 CIS-5 — Account Management Shared health-data environments depend on controlling accounts, roles and revocation.
CIS-6 — Access Control Management EHDS and GDPR governance both depend on enforcing who may reach which records.
CIS-8 — Audit Log Management Health data governance requires evidence of who accessed, shared or reused records.
Recommendation — Centralise account lifecycle and remove stale or excessive access quickly. Enforce least privilege and review access paths for every data-sharing role. Log data access and sharing events with sufficient detail for investigation and audit.

Practitioner Guidance

What to prioritise: Build one control inventory that ties each health data flow to its lawful basis, participant role, retention rule, and access path. If you cannot express a flow in those terms, the governance model is not ready for production sharing.

What to verify: Check that every EHDS-enabled disclosure has a matching GDPR record of processing, a documented access decision, and a revocation path. Also verify that secondary-use workflows cannot silently inherit the same permissions as care workflows.

Practitioner takeaway: The organisations that do this well treat EHDS as the sharing mechanism and GDPR as the accountability mechanism, then prove both through one auditable operating model.