TRE Compliance in 2026: HIPAA + GDPR + EHDS Explained
Quick answer. A Trusted Research Environment (TRE) achieves multi-jurisdictional compliance by mapping a single technical control set onto three overlapping regimes: the Health Insurance Portability and Accountability Act (HIPAA) Security Rule for US protected health information, the General Data Protection Regulation (GDPR) Article 25 privacy-by-design obligation for European Union (EU) personal data, and European Health Data Space (EHDS) Article 50 governance for secondary use. Federated TREs collapse these into one posture because data never leaves the source — the airlock, audit log and access governance are the same across regulators.
Compliance for a Trusted Research Environment (TRE) used to be three separate projects: one workstream for the Health Insurance Portability and Accountability Act (HIPAA), another for the General Data Protection Regulation (GDPR), a third for whichever national health data framework applied. The European Health Data Space (EHDS), in force from March 2025 with secondary-use provisions phasing in through 2029, has changed the maths. Custodians now need a single architectural posture that satisfies all three regulators at once, because the same cohort may be queried by a US sponsor, an EU academic consortium and a national Health Data Access Body in the same week.
Why the three-regime problem is now operational
Three forces are pushing TRE compliance from paperwork into architecture. First, EHDS Article 50 obliges Member States to make health data available for secondary use through “secure processing environments” — language that maps directly onto the TRE definition published by the UK Health Data Research Alliance in 2021. Second, the May 2026 UK Biobank incident, in which approved researchers walked derived data out of a centralised software-as-a-service (SaaS) TRE through normal export channels, has made every custodian re-examine whether their environment is technically incapable of leakage, not merely contractually prohibited from it. Third, the United States Office for Civil Rights updated its HIPAA Security Rule expectations in late 2024 to demand demonstrable, automated controls rather than attested policies.
A TRE compliance posture is now a continuous engineering output, not an annual audit. The Federated TRE pattern — under which compute moves to data and data never leaves the source — sits naturally inside this convergence because the same airlock that satisfies HIPAA paragraph 164.312 also evidences GDPR Article 25 and EHDS Article 50 simultaneously.
Mapping the HIPAA Security Rule onto a Federated TRE
Administrative, physical and technical safeguards
The HIPAA Security Rule (45 Code of Federal Regulations Part 164, Subpart C) splits requirements into administrative safeguards (164.308), physical safeguards (164.310) and technical safeguards (164.312). In a Federated TRE, administrative safeguards are evidenced by the role-based access workflow that approves researchers against a documented purpose. Physical safeguards collapse into the custodian’s existing site controls because no protected health information (PHI) is replicated to a vendor data centre. Technical safeguards — access control, audit, integrity and transmission security — are implemented once and inherited by every project.
The audit-log obligation
HIPAA 164.312(b) requires “hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information”. A modern Federated TRE produces a tamper-evident, append-only log of every researcher action, every query submitted, every output that crosses the airlock, and every administrator decision. That same log evidences GDPR Article 30 records of processing and EHDS Article 56 transparency reporting, which is why the three regimes can share one control surface.
GDPR Article 25 — privacy by design and by default
GDPR Article 25 is the architectural article. It requires controllers to implement “appropriate technical and organisational measures” both at the time of determining the means of processing and at the time of the processing itself. A Federated TRE evidences Article 25 in three moves. Minimisation is enforced by query-time aggregation — researchers receive cohort-level summaries by default and only receive row-level pseudonymised extracts through an explicit, logged escalation. Purpose limitation is enforced by binding every query to an approved project identifier; queries outside scope are syntactically rejected, not just logged for review. Integrity and confidentiality are enforced by the airlock: every output is hashed, classified and reviewed against a disclosure-control rule set before it can leave the secure environment.
EHDS Article 50 and the secondary-use rulebook
EHDS Article 50 sets the technical standard for secure processing environments used for secondary use of electronic health data. It requires that the environment provides access only to non-identifiable data, that all activity is logged, that anonymisation or pseudonymisation is applied before access, and that the environment is auditable by the national Health Data Access Body. Article 50 reads, in practice, as a regulator-friendly description of what TRE engineers have been building since 2018. The next three years of work will live in the implementing acts the European Commission is expected to publish between 2027 and 2029, which will specify the technical certification scheme for secure processing environments and the cross-border interoperability requirements for federated networks.
The Five Safes framework as the compliance grammar
The Five Safes framework, originally developed at the United Kingdom Office for National Statistics (ONS) and now adopted by most major TREs globally, is the common grammar that lets a single TRE evidence all three regimes at once. The five dimensions — safe people, safe projects, safe settings, safe data and safe outputs — each map onto specific clauses across HIPAA, GDPR and EHDS, which is why custodians who design to the Five Safes find themselves naturally compliant with all three regulators rather than engineering to each separately.
Comparison table — regulation by control
| Control | HIPAA Security Rule | GDPR | EHDS | Five Safes dimension |
|---|---|---|---|---|
| Researcher vetting and access approval | 164.308(a)(3) workforce security | Art. 32 security of processing | Art. 50(1)(a) access conditions | Safe people |
| Project purpose binding | 164.508 authorisations | Art. 5(1)(b) purpose limitation | Art. 53 data permit | Safe projects |
| Secure environment / no local download | 164.312(a) access control | Art. 25 privacy by design | Art. 50(1)(c) secure processing environment | Safe settings |
| Pseudonymisation / minimisation | 164.514 de-identification | Art. 5(1)(c), Art. 25(2) | Art. 50(1)(d) anonymisation | Safe data |
| Output airlock and disclosure control | 164.312(b) audit controls | Art. 32 integrity and confidentiality | Art. 50(1)(e) results review | Safe outputs |
| Continuous audit log | 164.312(b) | Art. 30 records of processing | Art. 56 transparency reporting | Cross-cutting |
Why centralised SaaS TREs cannot share a single posture
A centralised SaaS TRE replicates the cohort into a vendor-operated cloud tenancy. That replication is the moment compliance fragments. The custodian is now reliant on the vendor’s regional cloud footprint for GDPR Chapter V transfer rules, on the vendor’s business associate agreement for HIPAA 164.308(b), and on a separate certification path for whatever EHDS implementing acts emerge. Each new regulator becomes a new contract, a new audit and a new latency point in the workflow.
A Federated TRE inverts this. Because compute moves to the data and the data never leaves the source, the custodian remains the controller for GDPR, the covered entity for HIPAA and the data holder for EHDS. The TRE platform is the technical processor that runs inside the custodian’s existing legal and physical perimeter. Cross-border federation queries — common across European biobank networks, North American genomics consortia and Asia-Pacific population programmes — run as aggregate computations that return statistics rather than records, sitting cleanly inside Article 25 minimisation and Article 50 secure processing requirements simultaneously.
How national programmes are implementing the convergence
National biobank programmes globally are converging on the Federated TRE pattern for exactly this reason. The UK Health Data Research Alliance’s TRE green paper, the European Open Science Cloud federated infrastructure, and the United States National Institutes of Health (NIH) secure analysis platform programme all describe the same architecture in slightly different vocabulary. None ask the data custodian to ship its cohort to a third party, and the same airlock log, researcher-vetting workflow and output-control rule set evidence every regulator the custodian answers to.
Practical next steps for compliance leads
For a TRE compliance lead working through 2026 and 2027, three concrete steps reduce regulatory exposure faster than any policy rewrite. First, map every existing technical control onto the Five Safes dimensions and tag each with the HIPAA, GDPR and EHDS clauses it evidences — most TREs find existing controls already cover 70 to 80 per cent of obligations, with gaps in output airlock automation and tamper-evident audit logging. Second, ensure the secure processing environment can produce machine-readable evidence on demand; manual evidence packs will not scale to EHDS cross-border permit volumes. Third, design the federation layer assuming queries will arrive from jurisdictions the custodian does not currently serve.
Frequently asked questions
Does a Federated TRE remove the need for a Business Associate Agreement under HIPAA?
No. The TRE platform vendor is still a business associate if it processes protected health information on behalf of the covered entity, and a Business Associate Agreement is still required. What changes is the scope: because data never leaves the source, the agreement covers platform operation rather than data custody, which substantially simplifies the breach-notification and subprocessor clauses.
How does a TRE evidence GDPR Article 25 to a Data Protection Authority?
Through the combination of an architectural description (the federated design), a Data Protection Impact Assessment that explicitly addresses minimisation, purpose limitation and integrity, and a continuous audit log that demonstrates the controls are operational rather than merely documented. Most European DPAs now expect to see all three.
What does EHDS Article 50 require that GDPR did not already require?
Article 50 is more prescriptive about the technical form of the secure processing environment, including the obligation to provide access only to non-identifiable data by default, mandatory pseudonymisation before access, and certifiable auditability by the national Health Data Access Body. GDPR set the principles; EHDS is starting to specify the implementation.
Can a single TRE serve US and EU researchers from the same cohort?
Yes, if the architecture is federated. The custodian remains the controller and covered entity, and researchers in each jurisdiction submit queries through the airlock without the underlying records crossing borders. Cross-border outputs — aggregate statistics, models, validated extracts — are reviewed against the disclosure-control rule set before release.
How does the Five Safes framework relate to ISO 27001 or SOC 2?
ISO 27001 and SOC 2 are organisation-level information-security frameworks. The Five Safes is a TRE-specific framework that sits on top, addressing dimensions (safe people, safe projects, safe outputs) that ISO and SOC 2 do not specifically cover. A mature TRE typically holds both an ISO 27001 certification and a Five Safes maturity assessment.
What audit evidence do EHDS Health Data Access Bodies expect?
The EHDS implementing acts are still in draft, but the direction of travel is towards machine-readable evidence: structured logs of every permit, query and output release, an inventory of the secure processing environment’s technical controls, and a continuously updated record of cross-border data flows. Custodians designing now should assume their audit evidence will be queried by automated tools rather than read by a human inspector.
Is anonymisation enough to take a dataset out of GDPR and HIPAA scope?
True anonymisation removes data from GDPR scope under Recital 26 and from HIPAA scope under the Safe Harbor or Expert Determination methods, but the threshold is high and rarely achievable for rich health data without destroying analytical utility. Pseudonymisation inside a TRE is the more common posture: the data remains in scope but the risk profile drops sharply because re-identification requires breaching the secure processing environment itself.