Submission declined on 6 May 2026 by 331dot (talk). This draft's references do not show that the subject meets Wikipedia's criteria for inclusion. The draft requires multiple published secondary sources that: provide significant coverage: discuss the subject in detail, not just brief mentions or routine announcements; are reliable: from reputable outlets with editorial oversight; are independent: not connected to the subject, such as interviews, press releases, the subject's own website, or sponsored content. Please add references that meet all three of these criteria. If none exist, the subject is not yet suitable for Wikipedia. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by 331dot 31 days ago. Last edited by Maria.Dunford 31 days ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

Submission declined on 1 May 2026 by Pythoncoder (talk). This draft appears to contain text generated by a large language model (such as ChatGPT). You cannot use LLMs to generate article content. LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice. These tools are prone to specific issues that violate our policies: hallucinations: they often invent false information and cite non-existent references. unencyclopedic tone: they tend to be vague, promotional, or essay-like, rather than neutral and factual. copyright issues: they may closely paraphrase existing text, leading to copyright violations. Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject. See the advice page on large language models for more information. Declined by Pythoncoder 36 days ago.

A Trusted Research Environment (TRE), also referred to as a Secure Data Environment (SDE) or Data Safe Haven, is a secure, governed computing environment that enables approved researchers to analyse sensitive data without the data leaving the data owner's control. Data residency, privacy, security, and auditability are enforced through federation, controlled output release (Airlock), and network-level controls, among others, allowing only approved aggregated results, not raw individual-level data, to leave the environment.^{[1] [2]}.

The term was first defined by Health Data Research UK ^{[3] [4]}, which described a TRE as a platform that operationalises the Five Safes Framework, originally developed by the UK Office for National Statistics.^[5] TREs emerged in the UK around 2010 as a response to the risk and inefficiency of traditional data-transfer models, and have since become widely adopted for secure biomedical and health data research at population scale.^[6]

A TRE represents a third architectural model distinct from both SaaS and DIY deployment models. It combines the data residency and control of a self-managed DIY approach with the managed-service capabilities of a SaaS platform. A TRE is built around the principle of bringing researchers to the data, rather than moving data to the researcher or a third-party SaaS vendor. The data custodian retains control of the data storage and compute environment at all times, and sensitive patient-level data never leaves it.

Three architectural controls are widely recognised as defining a true TRE:

1. Federation: A federated architecture enables in-place querying and computation across distributed environments without moving data. The compute travels to the data, not the reverse. Without federation, data must be copied or centralised, which violates the Safe Data principle.

1. Airlock (output control): An Airlock is a mandatory control point governing all data outputs. No results leave the environment without explicit review and approval, ensuring Safe Data and Safe Outputs are enforced by design. Without an Airlock, users retain a path to directly export data, breaking both principles.

1. Firewall enforcement: Active firewall settings block any attempt to bypass the Airlock or export data outside approved pathways. Without firewall-level enforcement, governance relies on policy rather than architecture, and Safe Data cannot be guaranteed.

TREs are governed by the Five Safes Framework, originally developed by the Office for National Statistics^[7] to provide a structured approach to enabling access to sensitive data while managing risk. The framework defines five pillars of safety. Below we describe the architectural controls a TRE uses to enforce these safety pillars:

• Safe People means that only vetted, trained researchers are granted access. TREs enforce mandatory information governance training and require researchers to sign legally binding agreements prior to access, with clear penalties for misuse. Access is further controlled through granular role-based access controls (RBAC), which restrict each researcher to only the datasets and tools required for their approved project. This is combined with IP restrictions, which limits access to approved networks and locations, and multi-factor authentication (MFA) to verify identity at every login.
• Safe Projects means that data use is restricted to ethically approved research projects. Independent review boards evaluate every research proposal, this is commonly referred to as an IRB or DAC process. This process includes ethical review and data protection impact assessments. TREs restrict each researcher to only the datasets and tools required for their approved project, through granular role-based access controls (RBAC).
• Safe Settings means that the data custodian retains full ownership over the data storage and computing environment, including logs and audit trails. TREs enforce data residency through federated architecture, with data querying and compute happening in place. TREs further enforce safe settings through continuous monitoring and management of system health and security posture, providing real-time assurance that the environment remains compliant and tamper-evident at all times. Vulnerabilities identified across the system and firewall are remediated immediately, ensuring that no exposure window remains open and that the security perimeter is continuously hardened against emerging threats.
• Safe Data means that:
  • data stays in-place with the Data Custodians controlled secure data environment. TREs enforce this via federation and capabilities that securely setup, manage and observe the system and firewall.
  • the data is encrypted at all times. TREs enforce this by providing encryption capabilities at rest, in transit, and during computation.
  • the data is de-identified (aka pseudonymized, stripped of direct identifiers, and assessed against re-identification risk to ensure that no combination of remaining variables could be used to identify an individual). TREs provide built-in data transformation tools that let researchers clean, link, and prepare datasets inside the environment without ever touching raw records. Every step is automatically logged as part of an immutable lineage record, capturing the full provenance of any output: what was done, by whom, and when. This gives custodians a complete data lineage and audit trail rather than just a snapshot of the final result.
  • data access to researchers is limited to the specific data fields and records necessary for the approved research project, and nothing beyond. TREs accomplish this via granular role-based access controls (RBAC).
  • individual-level data never leaves its source environment and only aggregate resulting data can be exported. TREs enforce this by providing Airlock (output checking) capabilities.
• Safe Outputs means that every output, like charts, statistical summaries, derived datasets, trained models, and any other artefact produced within the environment, must pass through a mandatory review process before it can leave. No export path exists outside of this controlled process. TREs enforce this through two complementary architectural controls: the Airlock and firewall configuration. The Airlock acts as the sole authorised data export point for all outputs. Every data export request is subject to structured review (automated, human, or both) to assess whether the output could reveal sensitive or re-identifiable information before approval is granted. This ensures that Safe Outputs is enforced by architecture, not by researcher self-reporting or policy alone. Firewall configuration provides the complementary enforcement layer. Hardened firewall rules block all alternative egress paths, ensuring that no data can leave the environment through any route other than the Airlock. Together, the Airlock and firewall form a closed output perimeter: the Airlock governs what is permitted to leave, and the firewall ensures nothing else can.

A common point of confusion is the distinction between platforms that market themselves as TREs and architectures that fully satisfy the Five Safes Framework. In a SaaS model, data is copied into a vendor's cloud and researchers work inside that vendor-controlled environment. This creates three architectural problems:

• Safe Settings fails because the environment belongs to the vendor, not the data controller
• Safe Data fails because a copy of the data has been moved into the vendor's infrastructure, a different jurisdiction with a different security model.
• Safe Outputs is weakened because researchers may retain a path to download derived data to a local machine.

In a TRE model, data stays at its source. Compute travels to the data, not the reverse, and every output passes through a mandatory Airlock review before it can leave the environment. No researcher-initiated download path exists.

TREs emerged in the United Kingdom around 2010, initially developed in response to growing concerns about the risk and inefficiency of traditional data-sharing models for NHS patient data ^[6]. The approach was formalised by Health Data Research UK ^{[3] [4]}, drawing on the Five Safes Framework developed by the Office for National Statistics ^[5].

The TRE model moved from concept to operational reality with the deployment of a federated TRE for Genomics England, one of the world's largest national genomic programmes, by Lifebit ^{[8] [9] [10]}. This deployment established a production-grade architecture in which federation, Airlock output controls, and active firewall enforcement operated together as a unified, enforceable standard, not as independent security controls bolted onto an existing platform, but as a coherent architectural model in which each pillar is necessary for the others to hold. The deployment established a reference implementation for TRE security and operational standards, requiring compliance across the following frameworks:

• ISO/IEC 27001, an international standard for information security management,
• Cyber Essentials Plus, a UK government certification for technical cyber controls,
• NHS Data Security and Protection Toolkit (DSPT), a mandatory framework for organisations handling NHS patient data,
• SOC 2 Type II , an AICPA audit framework covering security, availability, and confidentiality controls,
• GDPR and applicable national data protection legislation.

In addtion, compliance is maintained through continuous security posture management rather than periodic audits alone, where the environment is monitored and hardened in real time, vulnerabilities are remediated immediately, and the security state is evidenced at all times, providing data controllers and regulators with continuous assurance rather than point-in-time attestation.

This reference model has since been adopted worldwide for secure research of genomics and real wold data ^{[1] [2]}, across pharmaceutical companies, like Boehringer Ingelheim ^[11], biotechs, like Flatiron Health ^[12] and 23andMe ^[13], and government programmes, like Singapore's national TRUST platform (Trusted Research and Real World Data Utilisation)^[14] and Canada's CanPath initiative (the Canadian Partnership for Tomorrow's Health)^[15]

TREs are used across a range of settings where sensitive data must be made available for research without compromising data residency, privacy, security or regulatory compliance:

• National health programmes: Governments and national health agencies use TREs to enable approved access to population-scale health records, genomic data, and linked datasets while preserving data sovereignty.
• Pharmaceutical and biotech research: Companies use TREs to access real-world evidence from hospital systems, biobanks, and national registries for drug development and biomarker discovery, without the data leaving the source institution.
• Academic and cross-institutional research: TREs enable collaborative studies across multiple institutions without requiring data transfer agreements or centralisation of data. A researcher querying across several national biobanks sends the query to each environment; only aggregated, non-identifiable results are returned.
• Population genomics programmes: TREs support compute-intensive workflows such as genome-wide association studies (GWAS), variant effect prediction (VEP), and polygenic risk scoring (PRS) on population-scale whole-genome datasets without data movement.

• Five Safes
• Federated learning
• Data governance
• Genomics England