Working Inside a Trusted Research Environment

Opening

Why I wrote this guide

Recently I was on a call with the principal investigator of a registry led by an advocacy group. Her organization had received registry data from an industry partner, and she was working through how to share those data beyond her internal team. The partner's stipulation was reasonable on its face: any further sharing had to come with assurance that the data would stay protected and under tight control, never leaving the premises in any meaningful sense, never simply passed along. She did not have a name for the arrangement being described. Partway through the call, I realized that I did. The industry partner was asking for a trusted research environment.

The conversation put its finger on a gap I have been trying to close for years. Many advocacy groups that hold registries have never analyzed data themselves, so when a partner starts describing enclaves, egress, and controlled environments, the vocabulary is new and the machinery behind it is invisible. Newcomers are not the only ones working this out, though. When I looked across my own collaborations, I found the same concept waiting at every level of experience.

I am currently setting up a collaboration with a biorepository that is building an enclave for me to do the analytics. They are asking which tools I need installed and which software I prefer, and I am already thinking several steps ahead: which code I will bring in with me, how I will share my analysis, whether posting a result to a shared folder requires the data owner's review first, whether I can reach the internet from inside the environment, whether GitHub will be available. Every one of those questions has a policy answer somewhere, and the project will go better for everyone if we find the answers before my first login.

Years ago, I worked in a national data set, which I will not name, that described its data as converted to the OMOP common data model. I expected that to make the analytics straightforward, because the shared OHDSI tool stack is one of the great advantages of OMOP. The conversion was real, but the tools were not installed in the environment, which drained most of the meaning out of the format. What remained was a notebook where I could write SQL and code, and since there was no easy way to import code, I wrote it by hand, without my own snippet library, drafting offline and retyping inside. The environment added snippets and conveniences later, but the lesson stayed with me: friction inside a trusted research environment discourages exactly the people we are trying to bring into research.

Consider what we ask of a beginner in these settings. We ask them to work in notebooks, to give up the local downloads that every prior class trained into them, to finish within allotted access windows, and to log in through a VPN or some other unfamiliar gate before the analysis even starts. Working in these environments is a competency, one that can be taught and assessed, and we keep treating it as an incidental detail. The gap runs upward too: many of the executives who commission these environments cannot tell which design decisions will quietly make analysis impractical. I can look at a proposed setup and see the red flags; someone signing the contract without analytic experience cannot, and the procurement process rarely brings those decisions into view.

So this guide is written mainly from the perspective of someone who uses these environments. Built well, they enable research: they are what allows a data steward to say yes, and they let more people see and work with data, sooner, with fewer ethical hazards. Built without attention to the people working inside them, they restrict the research they were meant to enable. Both halves are true, and the stages that follow try to serve both: the case for these environments, and the practices that make them usable.

Who this guide serves

Stage 1

The locked room model

A trusted research environment (TRE), also called a data enclave or secure research environment, is a computing environment in which the data never leave the data steward's control. The researcher does not receive a file; the researcher receives a login. Inside, there is a workspace with analysis tools, most often Jupyter or RStudio in a browser, connected to data the researcher can query but not copy out. Everything that leaves the environment, a table, a figure, a set of model coefficients, goes through a review step before it is released.

The closest physical analogy is the reading room of an archive. The original documents stay in the building; you work with them at the table, under rules you agreed to when you registered; what you walk out with is your notes, after someone at the desk has looked at them. The archive is not accusing you of anything by keeping the documents inside. Keeping the documents inside is what makes it possible to let you in at all.

If you are being onboarded into research data right now, the environment you are entering probably resembles one of the national examples: the All of Us Researcher Workbench, the N3C Data Enclave, the CMS Virtual Research Data Center reached through ResDAC, or an institutional environment built on a platform such as Terra or a cloud enclave a university or nonprofit runs itself. The details differ; the model is the same everywhere: data stay, tools come to the data, outputs are reviewed.

Stage 2

Why downloading is not an option

The question every new enclave user asks, sometimes with real frustration, is why they cannot simply download the data and work on their own machine, the way they did with every data set in graduate school. The answer has four parts, and none of them is about distrust of you personally.

Re-identification risk. Health data that have been de-identified are not anonymous. Combinations of diagnosis, dates, location, and demographics can describe very few people, and in a rare disease registry they can describe exactly one. The environment limits that risk by controlling what can be computed and what can leave, instead of relying on the hope that a file on a laptop stays where it was put.

The consent chain. Participants consented to specific uses under specific protections. The steward promised those protections in the protocol, and the DUA passes the obligation to the researcher's institution. The enclave is the technical enforcement of that chain of promises. Without it, the protections exist only on paper.

The audit trail. Inside the environment, every login, query, and export request is attributable to a person. On a personal laptop, nothing is. When something goes wrong, and across enough projects something eventually does, the audit trail is the difference between an incident that can be scoped and one that cannot.

The protocol condition. Your access was approved on the condition that the data stay in the environment. Downloading is therefore a protocol violation and usually a DUA violation, not a technical inconvenience to route around. The consequence can reach past you to your institution's access for everyone.

Stage 3

How the IRB connects

When an IRB asks a registry to place shared data in a trusted research environment, it is asking for a technical control that lowers the risk profile of the whole protocol. Risk determinations rest on what could plausibly go wrong; an environment that prevents bulk download, restricts who enters, and reviews everything that leaves changes that calculation. In many cases the enclave is what makes the data sharing approvable at all.

A point that registry holders often learn late: egress rules do not come from the platform vendor. They come from the consent language, the protocol, the DUA, and the steward's own disclosure policy. The platform enforces the rules; someone at the steward organization has to write them. A group that buys enclave software without writing an output review policy has bought a lock without deciding who holds the key.

The document chain

Each document constrains the next, so it helps to see them in order:

1. Consent language sets what participants agreed to, and everything downstream has to fit inside it.
2. The registry protocol describes the data, the sharing model, and the protections, and it is what the IRB approves.
3. The data use agreement binds each recipient institution to the protections the protocol promised.
4. The enclave access agreement binds each individual user to the rules of the environment.
5. The output review policy states what can leave, who reviews it, and by what criteria.

What an IRB commonly asks a registry holder to produce

IRBs vary, so treat this as the commonly requested set rather than a universal one: a description of the environment and its security controls, the workflow for approving researcher access, the output review process, breach and incident procedures, and the training users must complete before entry. If you can answer those five before you submit, the review conversation tends to go better; if you cannot, the gaps show you what remains to be decided.

Stage 4

Setting up an enclave for your registry

This stage is written for the advocacy group that holds a registry and has received its first serious data sharing request, along with the instruction that sharing must happen inside a trusted research environment. That instruction can feel like being asked to build a bank vault when you set out to build a library. The task is more tractable than it first appears, provided the decisions are made in the right order.

Build, buy, or join

There are three broad paths. You can build on general cloud infrastructure with your own controls, for example on AWS using a framework such as Service Workbench, which offers the most control and demands the most expertise. You can buy or subscribe to a research platform that ships with enclave features, the category that includes Terra, Verily Workbench, and platforms already used in the registry world. You can also join rather than host: contribute your registry to an existing environment or a federated network such as OHDSI, in which the data stay with you and only analysis code and aggregate results travel. For a small organization, joining is frequently the path that gets research moving soonest, and it can coexist with hosting your own environment later.

Within the build path, there is a growing open source movement, driven partly by the UK's Goldacre Review, which called for standardization across trusted research environments through open source infrastructure. TREEHOOSE, developed by the Health Informatics Centre at the University of Dundee under the DARE UK program, deploys a TRE on AWS with approval-based egress, workspace backups, and budget alerts built in; as of August 2026 it is Apache licensed and in alpha release, with the maintainers encouraging groups to contact them before deploying. Even for a group that never deploys it, the project's architecture, security controls, and operations documentation are a readable, concrete answer to the question of what a trusted research environment consists of. Related efforts to know: the Alan Turing Institute's Data Safe Haven for Azure, the SATRE specification for standardizing TRE architecture, and the UK TRE Community, where much of this coordination happens. Open source lowers the licensing barrier, not the operating one; the egress reviewer, the policies, and the accountability described below are yours to staff regardless of what the software costs.

What it costs

Budget lines that show up in practice: compute billed per researcher session, storage, the security assessment your partners will ask about, help desk time for researchers who are new to the model, and the one groups most often underestimate, egress review labor. Output review is a person applying a policy, not a feature you switch on. Every export request takes someone's time, and that someone needs training, backup coverage, and authority.

Who says yes to outputs

Before the first user logs in, you need a named reviewer role with the authority to decline a request, a written policy for the reviewer to apply, and a turnaround expectation researchers can plan around. A reviewer without a policy improvises; a policy without a reviewer is decoration. The policy's most concrete element is usually the small cell threshold, and here the national programs offer working examples. As of August 22, 2026: the N3C publication policies require suppression of small counts in results leaving that enclave, the All of Us data access policies restrict dissemination of small participant counts, and the CMS cell size suppression policy as summarized by ResDAC suppresses cells representing 1 to 10 beneficiaries. The specific thresholds belong to each steward and can change, so read the linked policy pages rather than borrowing a number secondhand, including from this paragraph.

Where to start

1. Inventory what you hold and under what consent. Nothing downstream can exceed what the consent supports.
2. Decide the steward roles: who approves access, who reviews outputs, who answers for incidents.
3. Write the output review policy, including the small cell threshold and the review turnaround.
4. Choose the smallest environment that satisfies the requesting researcher's IRB and your own. Smallest is a feature; every capability you add is a capability you must govern.
5. Run one pilot researcher through the entire path, from access request to approved egress, before opening access more widely.
6. Document what the pilot taught you and revise the policy before user two.

Stage 5

Working inside the environment

Here is what the working experience usually looks like: a browser-based workspace with Jupyter or RStudio, a project directory that belongs to you, a data directory that is read-only, no internet access or a tightly restricted one, and package installation from an approved mirror rather than the open internet. The tools are almost always open source, Python, R, and SQL, because those are what platform teams can license, audit, and maintain at scale.

Adjustments that make the work go smoothly

• Version your code inside the environment, or through an approved git remote if the platform provides one, so your work survives workspace rebuilds.
• Keep an analysis log as you go; the log itself usually clears review easily and becomes the skeleton of your methods section.
• Write anything you intend to export into the designated output folder, named clearly, so the reviewer can see what each file is.
• Assume every export request costs review time, and batch your requests rather than sending one figure at a time.

Getting results out

The question I hear most often is some version of how to remove the data, and the answer is a reframing: you do not remove data, you request the release of approved outputs, and the distinction is the entire point of the environment. An egress request typically contains tables, figures, and model output, each of which the reviewer checks against the disclosure policy. The checks look for small cells, for complementary disclosure across multiple tables that are safe alone and revealing together, and for row-level fragments hiding inside files labeled as summaries. A rejected request is not a punishment; it comes back with the reason, you revise, and you resubmit. Researchers who internalize the reviewer's checklist start writing outputs that pass on the first attempt.

Working without AI assistance

The internet block that keeps the data in also keeps external AI tools out. Whatever assistant you use at your desk will probably not be available inside, and platform policies on built-in AI features vary and change, so check the platform's own documentation before you plan an analysis around one. Sending data out to an assistant is not a workaround; as Stage 2 explains, it is an unreviewed disclosure.

The preparation that works: draft and test your code outside the enclave on synthetic or public data, where AI help is allowed and useful, then bring the reviewed script in with you. Keep an offline reference for the syntax you reach for most. For readers early in their training, there is a larger point underneath the logistics: if prompting an assistant is your only analysis skill, these environments will expose that quickly, and the time to build underlying fluency in the languages themselves is before your first login, not after.

Translating your code

If your fluency lives in Stata, SPSS, or SAS, the enclave's open source stack is a translation problem, and a solvable one, because the operations you know have direct equivalents. Statistics Norway published a comparison document that walks the same basic data processing tasks through SAS, SPSS, Stata, R, and Python side by side, written for exactly this situation, staff who know one package and need another: Data processing in Sas, Spss, Stata, R and Python: A comparison (Notater 2023/1). It is the foundation for the translation tool and printable crosswalk in this series.

One category of commands deserves attention before you translate anything, because these fail or violate policy inside an enclave regardless of language: commands that write to local paths, reach the internet, or open connections out. The table below collects the ones that most often trip new users.

A small example of the shape of the change. The Stata habit on the left fails on both counts inside an enclave; the version on the right does the same analytical work and clears review:

* The desk habit: writes rows to a local drive
export delimited using "C:\Users\me\results.csv"

* The enclave version: an aggregate, written to the
* output folder, submitted for egress review
collapse (mean) onset_age, by(genotype)
export delimited using "/workspace/output/onset_by_genotype.csv"

Stage 6

Sources and further reading

• The Five Safes framework, UK Data Service: safe projects, safe people, safe settings, safe data, safe outputs, the organizing model behind most environments described here, with the original framing in Desai, Ritchie, and Welpton (2016).
• All of Us Researcher Workbench and its data access policies.
• N3C Data Enclave and the N3C publication policies.
• CMS cell size suppression policy, summarized by ResDAC.
• SAIL Databank, the long-running Welsh environment, and HDR UK on trusted research environments.
• OHDSI, the major federated alternative in which analysis travels and data stay home.
• Open source TRE infrastructure: TREEHOOSE (DARE UK, University of Dundee, for AWS), the Alan Turing Institute Data Safe Haven (for Azure), the SATRE specification, and the UK TRE Community.
• NIH scientific data sharing policies.
• Data processing in Sas, Spss, Stata, R and Python: A comparison, Statistics Norway, Notater 2023/1, the basis for the translation tool and crosswalk poster in this series.