> For the complete documentation index, see [llms.txt](https://documentation.dnanexus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.dnanexus.com/admin/trusted-research-environments.md).

# Managing Trusted Research Environments

Manage Trusted Research Environments (TREs) on the DNAnexus Platform: create environments, configure data inventories, manage access review pipelines, and control the TRE lifecycle.

{% hint style="info" %}
Apollo and Trusted Research Environments licenses are required to use Trusted Research Environments on the DNAnexus Platform. [Contact DNAnexus Sales](mailto:sales@dnanexus.com) for more information.
{% endhint %}

A Trusted Research Environment (TRE) is a secure, configuration-driven framework for sharing sensitive biomedical data. It enables data providers to organize, manage, and share data with authorized researchers while maintaining full ownership and control.

As a TRE Admin, you manage the full lifecycle of secure environments — from initial setup to ongoing maintenance and data releases. This includes configuring data governance policies, organizing versioned data resource inventories, and managing multi-step access review workflows. For the researcher and reviewer perspectives, see [Explore Trusted Research Environments](/user/trusted-research-environments.md).

## Setting Up a New TRE

Setting up a new TRE is a sequential process. Start with [planning your research environment](/admin/trusted-research-environments/planning-a-tre.md) to make the decisions that are hardest to change later:

* How many review steps your governance pipeline needs and who reviews each step
* Whether to enable Data Governance features such as [participant pseudonymization](/admin/trusted-research-environments/pseudonymization.md), which can only be enabled in Draft state
* Which data access restrictions to enforce on researcher projects

You also need to prepare the inventory assets required for your data offering. Every TRE needs a File Inventory TSV and Data Collections JSON, along with an optional Participant IDs (PID) CSV when configuring a file-only inventory. You can also provide an optional Data Showcase for showcase data exploration and cohort selection, plus optional Tabular Data or Assay Data for phenotypic, clinical, and genomic full datasets. Contact [DNAnexus Professional Services](https://www.dnanexus.com/professional-services) for guidance on preparing these assets.

TRE visibility, whether to restrict access to a defined list of authorized users or make the environment publicly discoverable to all users on the DNAnexus Platform, can be configured during initial setup or adjusted at any time after publishing.

Once your inventory assets are ready and your decisions are made, you can [create and publish the environment](/admin/trusted-research-environments/creating-a-tre.md).

## Configuring an Active TRE

After publishing, you can continue adjusting the TRE configuration:

* Control who can discover and access the environment by [managing TRE membership](/admin/trusted-research-environments/configuring-tre-membership.md).
* Add or remove individual reviewers from existing review steps by [configuring reviewers](/admin/trusted-research-environments/configuring-review-workflow.md).
* Set and adjust the restrictions enforced on all researcher projects using [data access policies](/admin/trusted-research-environments/managing-tre-lifecycle.md#update-data-access-policies), which work similarly to [project data access controls](/getting-started/key-concepts/projects.md#project-data-access-controls).

## Lifecycle Operations

A TRE moves through three states that determine what configuration is possible at each stage.

```mermaid
flowchart LR
  Start((Start)) -->|Create| Draft[Draft]
  Draft -->|Publish| Active[Active]
  Active -->|Deactivate| Maintenance[Maintenance]
  Maintenance -->|Reactivate| Active
  Draft -->|Delete| End((Deleted))
  Maintenance -->|Delete| End

  %% Styling
  classDef lifecycleBoundary fill:#60F299,stroke:#1F519D,stroke-width:2px,color:#000
  classDef draftState fill:#66C9F9,stroke:#1F519D,stroke-width:2px,color:#000
  classDef activeCycle fill:#1F519D,stroke:#1F519D,stroke-width:2px,color:#fff

  %% Apply classes
  class Start,End lifecycleBoundary
  class Draft draftState
  class Active,Maintenance activeCycle
```

In the **Draft** state, you have full configuration access: TRE details, membership, resource inventory, data access policies, and review steps. Irreversible features such as [pseudonymization](/admin/trusted-research-environments/pseudonymization.md) and Enforce Full Set Selection can only be enabled in this state. Once you publish to the **Active** state, the resource inventory structure, review pipeline, and draft-only features lock. You can still update membership, adjust policies, and manage reviewers within existing steps.

When you need to update the inventory to a new data version, transition to the **Maintenance** state. The TRE remains visible to researchers but is marked as under maintenance, and new access requests are suspended. Once the updated inventory is ready, reactivating returns the TRE to the **Active** state.

For all state transition procedures, see [managing TRE lifecycle states](/admin/trusted-research-environments/managing-tre-lifecycle.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://documentation.dnanexus.com/admin/trusted-research-environments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.